Cybersicherheitsberatung Blockchain

Die Sicherheit von Blockchain-Systemen ist von der Sicherheit von Blockchain-Anwendungen zu unterscheiden. Wenn beispiels­weise eine bestimmte Wallet-Software schwerwiegende Sicherheitslücken hat, dann lassen sich hieraus keine Aussagen über die Sicherheits­eigenschaften und die Güte der Implementierung des darunterliegenden Blockchain-Systems ableiten.

Sicherheit von Blockchain-Systemen

Es folgt eine Auswahl von Sicherheitsfragen bezüglich Blockchain-Systemen.

Einigungsalgorithmen

Unter bestimmten Voraussetzungen können mehrere, gleichberechtigte Parteien (die sogenannten peers) in einem Kommunikationsnetzwerk eine gemeinsame Einigung herbeiführen. Die Einigung erfolgt dezentral, was für viele kritische Anwendungen eine höhere Fehlertoleranz und ein stärkeres Vertrauensmodell ermöglicht, als zentrale Ansätze. Bei einem zentralen Ansatz, z. B. mit nur einer zentralen Stelle, stellt diese Stelle typischerweise den Flaschenhals bezüglich Vertrauen und Verfügbarkeit dar. Im dezentralen Fall können selbst dann Einigungen herbeigeführt werden, wenn sich unter den Parteien solche befinden, die nicht kommunizieren (z. B. weil sie offline sind) oder auf andere Weise nicht in Richtung Einigung beitragen, z. B. weil sie fehlerhaft oder korrupt sind. Korrupt bedeutet hier, dass diese Parteien versuchen, die Einigung bösartig zu hintertreiben oder zu manipulieren – typischerweise zum unfairen Eigennutz.

Die Bitcoin-Blockchain ist permissionless und public, weltweit können ihr beliebige Akteure beitreten. In der Bitcoin-Blockchain ist ein Proof-of-Work-Verfahren vorgesehen, mit dem faire Einigungen selbst dann zustande kommen, wenn man aktuell nicht weiß, welche Akteure auf welche Weise unkooperativ sind. Hierfür müssen allerdings bestimmte Voraussetzungen im laufenden Betrieb gegeben sein, beispiels­weise, dass ein bestimmtes Verhältnis von Rechenkapazität unkooperativer Parteien zu kooperativen Parteien nicht überschritten wird (vergleiche hierzu auch den >50%-Angriff). Die Incentivierung von Minern im Proof-of-Work Verfahren soll zudem sicherstellen, dass ein netzwerkbasierter Angriff und selfish mining teurer wird als das regelkonforme Mining. Allerdings gibt es hier einen Trade-Off bezüglich Effizienz und Sicherheit: Je höher die Wertigkeit einer Transaktion, umso länger muss abgewartet werden, bis die Transaktion als zuverlässig registriert angesehen werden kann.

Für verteilte Einigungen stehen eine ganze Reihe von Algorithmen, wie byzantinische Algorithmen, Proof-of-X-Verfahren (Proof-of-Work ist nur einer hiervon) und Kombinationsalgorithmen, zur Wahl. Diese sind für unterschiedliche Anforderungen wie Funktionalität (z.B. aktuelle Flughöhe bei widersprüchlichen Daten von unabhängigen Höhenmessern in einem Flugzeug), Effizienz (z.B. Echtzeitanforderungen), Compliance (z.B. Auflagen bzgl. Revision bei Banken), Privatsphärenschutz (z.B. bei Daten, die sich auf Personen zurückführen lassen) und Sicherheit (z.B. angenommenes Angreifermodell) geeignet. Beispielsweise unterscheiden sich die Sicherheits­anforderungen von permissioned Blockchains stark von denen von permissionless Blockchains.

Eine Sicherheitsanalyse des Fraunhofer SIT unterstützt die Entscheidung für den zu wählenden Einigungsalgorithmus für Blockchains.

Transparenz aller Transaktionen

Bezüglich der Offenlegung von Informationen gilt es ebenfalls Sicherheits- und Privatsphärenschutzabwägungen zu machen. Selbst in einer privaten Blockchain erhalten alle autorisierten Akteure Kenntnis über das komplette Buchhaltungssystem der Blockchain, in einer public Blockchain potenziell die ganze Welt. Diese Transparenz kann sowohl einen Gewinn als auch einen Verlust an Sicherheit und/oder Privatsphäre bedeuten - je nach betrachtetem Schutzziel und Zweck der Blockchain (insbesondere bezüglich des Spektrums der Anwendungen, die sie verwenden können sollen).

Code = Code?

Das Dogma (Program) Code = (Legal) Code, d.h. der Programmiercode setzt unumstößlich die Regeln für eine Blockchain bzw. Smart Contracts auch für Konfliktfälle fest und kann nicht mehr korrigiert werden, muss kritisch betrachtet werden. Allein aus dem Grund, dass es unwahrscheinlich ist, dass Programme ab einer gewissen Anzahl von Zeilen keine Fehler enthalten. Deshalb ist es sehr empfehlenswert, Regelwerke (gerade auch für das potenzielle „Versagen“ von Programmcodes, sowohl hinsichtlich Funktionalität als auch bezüglich IT-Sicherheit) bereits bei der Einführung von Blockchains und Smart Contracts abzustimmen bzw. bekannt zu geben und sie und ihre Verschränkung mit dem Programmcode agil änderbar über den gesamten Lebenszyklus zu konzipieren. Die Frage, was es bedeutet, wenn eine Minderheit sich nicht an die Beschlüsse der Mehrheit halten möchte, ist dabei höchst relevant (siehe beispiels­weise bisherige hard-forks).

Kryptographie

Die in einem Blockchain-System verwendeten kryptographischen Verfahren müssen hinsichtlich ihres aktuellen Sicherheitsniveaus (inklusive potenzieller Implementierungsschwächen), ihrer Änderungsfreundlichkeit und ihrer voraussichtlichen Zukunftssicherheit bewertet werden.

„Klassische“ Angriffsvektoren

Die Implementierung einer Blockchain muss selbstverständlich entsprechend dem ihr zu Grunde liegenden Angreifermodell auch gegen Angriffe geschützt werden, die nicht spezifisch für Blockchains sind.

Angriffsvektoren auf Anwendungen von Blockchains

Neben der Sicherheit von Blockchain als Technologie ist auch die Sicherheit der durch sie ermöglichten Anwendungen zu betrachten. Prominente Beispiele aus dem Bereich der Kryptowährungen sind Hackingangriffe auf Wallets (wo sind privaten Schlüssel gespeichtert: "hot storage" vs. "cold storage"?) und Angriffe auf Tauschbörsen (z. B. Mt Gox, Cryptsy, Bitfinex-Hack).