Blockchain Cybersecurity Blockchain-Sicherheit in der Praxis

Anbieter zum Thema

Fujitsu Technology Solutions GmbH

FTAPI Software GmbH

Bei vielen Blockchain-Implementierungen bleiben die klassischen Schutzziele der IT-Sicherheit bisher noch auf der Strecke. Aber was sollte schon bei der dezentralisierten Verarbeitung vertraulicher Informationen in einem Netzwerk autarker, potenziell anonymer Teilnehmer schief gehen? Eine ganze Menge wie sich zeigt!

Blockchain-Technologie soll Vertrauen in die Digitalisierung stärken. Sie bildet das Rückgrat der „IoT-isierung“ der digitalen Wirtschaft schlechthin und als solches soll die Blockchain unter anderem die Ereignisaufzeichnung erleichtern und die Transaktionsabwicklung automatisieren.

Diese und andere hoch gesteckten Ziele können DLT-Plattformen aber nur erreichen, wenn sie tatsächlich jeglichen Cyberangriffen standhalten. In dezentralisierten Anwendungsarchitekturen, die über öffentliche Netze kommunizieren müssen, gestaltet sich Letzteres recht problematisch.

Hinzu kommen ja auch noch GDPR-spezifische Voraussetzungen an digitale Datenspeicher im Hinblick auf den Schutz vertraulicher Informationen, die Unveränderlichkeit der Blockchain (mehr dazu im Bericht „Blockchain – das Aus für konventionelle Datenbanken?“) und eine Vielzahl anderer Herausforderungen.

Die Führungskräfte in Unternehmen haben inzwischen ein höheres Vertrauen in die Cybersicherheit von Blockchain-Lösungen als in die Cybersicherheit von konventioneller IT, stellte Deloitte im Rahmen seiner Global Blockchain Survey 2019 fest. Die Antworten offenbaren eine gewisse Gutgläubigkeit. Gerade bei DLT-Lösungen ist es wichtig, nicht alle Implementierungen über denselben Kamm zu scheren. Denn die Unterschiede im Hinblick auf die gebotene Sicherheit sind von Blockchain zu Blockchain recht gravierend.

Der Bericht „Blockchain sicher gestalten“ von Mai 2019 des Bundesamtes für Sicherheit in der Informationstechnik warnt vor ernsthaften Implikationen lückenhaft umgesetzter Cybersicherheit in gängigen Blockchain-Frameworks, insbesondere beim Auftreten unvorhersehbarer Ereignisse. Es sei „vergleichsweise einfach und daher verlockend, einen neuen Algorithmus zu konzipieren, der unter günstigen Bedingungen gut funktioniert“, schreiben die Forscher. Es sei aber „ungleich schwieriger“ dafür zu sorgen, dass er auch unter sehr ungünstigen Bedingungen und im Fall byzantinischer Fehler bei potenziell unvorhersehbaren Ereignissen seine Sicherheitsgarantien einhält. Dies betreffe sowohl den kryptografischen Unterbau (zum Beispiel die Hash-Funktion) als auch den Konsensmechanismus und selbst die Anreizsysteme des Ökosystems.

Byzantinische Fehlertoleranz von Blockchains

Byzantinische Fehlertoleranz ist die Fähigkeit eines verteilten Informations­verarbeitungs­systems, trotz eines heimtückischen Fehlverhaltens einzelner Komponenten (Netzwerkknoten) fehlerfrei zu funktionieren. So können beispielsweise einzelne Teilnehmer in einem Blockchain-Netzwerk falsche Informationen an andere Peers weitergeben, um die Inhalte der Blockchain zu verfälschen oder sonstige Störungen zu erwirken. Byzantinische Fehlertoleranz schützt das System vor manipulativen Eingriffen und katastrophalen Ausfällen, indem die ehrlichen Knoten ungeachtet jeglicher Manipulationsversuche seitens heimtückisch betrügerischer Knoten den korrekten Konsens durchsetzen.

Mehrere verschiedene Konsensverfahren können unter gewissen Bedingungen die byzantinische Fehlertoleranz eines Blockchain-Systems gewährleisten. Das Projekt Hyperledger Iroha leitet beispielsweise seine byzantinische Fehlertoleranz von einem Konsensverfahren namens YAC (kurz für Yet Another Distributed Consensus Algorithm) ab.

YAC ermöglicht das Erreichen der Finalität von Transaktionen unter Einhaltung sehr geringer Latenzen. Andere Blockchain-Frameworks vertrauen entweder auf probabilistische Konsensalgorithmen wie den Nakamoto-Konsens oder opfern die byzantinische Fehlertoleranz zugunsten niedrigerer Latenzen. Bei Hyperledger Iroha handelt es sich um eine berechtigungsfähige Allzweck-Blockchain für die Verwaltung von digitalen Assets, Identitäten und serialisierten Daten.

Sybil-Resistenz einer Blockchain

Bei einer Sybil-Attacke handelt es sich um einen Angriff in Peer-to-Peer-Netzwerken, bei dem ein Knoten mehrere Identitäten gleichzeitig aktiv betreibt und das Reputationssystem sabotiert. Die Attacke kann etwa darauf abzielen, durch Mehrheitsabstimmungen die Netzwerk-Organisation zu beeinflussen, das Netzwerk gezielt zu verlangsamen, die Kommunikation zwischen Knoten zu stören oder abzulauschen. Eine Sybil-Attacke kann die byzantinische Fehlertoleranz eines Systems aushebeln.

Verschiedene Verfahren können die Sybil-Resistenz einer Blockchain-Plattform erhöhen. Dazu zählen unter anderem das PoW- (Proof of Work) und das PoS-Schema (Proof of Stake, geplant für Ethereum Serenity für Anfang 2020).

Beim PoW-Schema (derzeit im Einsatz u.a. bei Ethereum) müssen die einzelnen Netzwerkknoten eine Menge Ressourcen aufwenden, um einen Block vorzuschlagen. Es wird angenommen, dass sich eine Sybil-Attacke deswegen einfach nicht rechnet.

Beim PoS-Schema (Proof of Stake, geplant für Ethereum Serenity) müssen Teilnehmer die interne Währung investieren, um sich an der Erstellung neuer Datenblöcke beteiligen zu dürfen. Diese sogenannten Validator-Knoten bürgen für ihre Ehrlichkeit mit einer Kapitaleinlage (hierbei ist vom sogenannten Staking die Rede) und bekommen dafür Anteilsweise eine Vergütung. Die hohen Kapitalanforderungen der Teilnahme sollen eine Sybil-Attacke unterdrücken.

Das Proof-of-Stake-Verfahren hat einen entscheidenden Vorteil gegenüber dem Proof-of-Work-Mechanismus: Es senkt die Energieaufwendungen und damit die Kosten der Transaktionsabwicklung.

Das PoS-Verfahren sieht tatsächlich gut aus — zumindest auf dem Papier. Dennoch hat es auch eine Schattenseite. So könnte eine organisierte Gruppe böswilliger Teilnehmer aus der Welt organisierter Cyber-Kriminalität heimlich eine netzwerkbedrohende Stellung aufbauen, ohne ihren Einfluss unmittelbar auszuüben. Die betreffenden Interessensgruppen wären damit in der Lage, auf lange Sicht im Netzwerk unentdeckt zu schlummern und erst bei einer konkreten Transaktion „zuzuschlagen“. Bei PoW besteht dieses Risiko einer zeitverzögerten Attacke nicht.

Sybil-Attacken lassen sich u.a. auch mit Hilfe von Zertifizierungs- beziehungsweise Authentifizierungsinstanzen unterdrücken. Diese Maßnahmen gehen allerdings möglicherweise zu Lasten der dezentralen Natur einer Blockkette und/oder zu Lasten der Anonymität der Peers.

Sybil-Resistenz verleiht einer Blockchain nicht automatisch die begehrte byzantinische Fehlertoleranz. Denn es gibt auch noch andere Methoden zur Umsetzung manipulativer Eingriffe. Diese können sich sowohl auf der Protokollebene als auch auf der Infrastrukturebene ereignen, beobachtet Prof. Emin Gün Sirer vom Department of Computer Science der Cornell-Universität.

Ein Konsensmechanismus, da er das Auftreten von Fehlern nicht verhindern könne, müsse in Störungsphasen, in denen das Netzwerk asynchron ist, eine der Eigenschaften Sicherheit und Lebendigkeit aufgeben, beobachtet kritisch der BSI im Bericht „Blockchain sicher gestalten“. Wie viele ehrliche Knoten nötig sind, um den fehlerfreien Zustand der Blockchain aufrechtzuerhalten, sei von Implementierung zu Implementierung unterschiedlich.

Microsoft befindet sich bei der Entwicklung des hauseigenen Blockchain-Frameworks in der beneidenswerten Lage, die Kontrolle über die Ausführungsumgebung von Windows inne zu haben. So konnte das Unternehmen eine vertrauenswürdige Laufzeitumgebung für das hauseigene Confidential Consortium Framework schaffen (CCF, zuvor als CoCo bekannt). Diesen Vorteil können andere Anbieter nicht so leicht nachholen.

Der BSI warnt jedoch vor übermäßigem Vertrauen. Denn die Firmware eingesetzter Hardware-Kom-ponenten könne Sicherheitslücken und andere Implementierungsfehler aufweisen. Der BSI ruft hierbei einen Vorfall im Bereich der Mining-Hardware bei Bitcoin in Erinnerung, der dem Hersteller Bitmain das Abschalten von Geräten per Fernzugriff ermöglicht haben soll.

Hard- und Soft-Forks

Die Blockchain im Sinne des Transaktionsprotokolls gilt als unveränderlich; die die darunter liegende Blockchain-Plattform (z.B. Hyperledger Fabric oder Ethereum) kann sich im Zuge von Softwareaktualisierungen dennoch weiterentwickeln. Sollte also etwa ein Bug in einer Blockchain-Plattform auftauchen, ließe sich dieses mit einem Bugfix eventuell beheben.

Da es sich bei Blockchain-Lösungen um dezentralisierte Software handelt, die in ein gemeinsames Transaktionsprotokoll schreibt, gestalten sich Aktualisierungen der Plattform-Software etwas komplizierter als bei gewöhnlichen Anwendungen. Die Aktualisierung von Code der smarten Verträge oder Chaincode ist auf Grund der Unveränderlichkeit der Blockkette rein unmöglich.

Bugs im ausführbaren Vertragscode (dem Chaincode) lassen sich durch eine Softwareaktualisierung nicht beheben. Dabei seien gerade smarte Verträge oft fehlerbehaftet, warnt der BSI. Manche Studien beziffern den Anteil schwerwiegender Bugs in smarten Verträgen auf etwa 45 Prozent im Falle von Ethereum, so der BSI. Sicherheitslücken hätten in der Vergangenheit nicht nur das unlautere Abzweigen von Finanzmitteln von betroffenen Accounts ermöglicht, sondern auch unbeteiligten Nutzern Schaden zugefügt.

Bei einer Aktualisierung des Blockchain-Protokolls spricht die Gemeinde von einem sogenannten Fork. Hierbei handelt es sich um diejenige Software, die auf den einzelnen Netzwerkknoten ausgeführt wird, um die betreffende Blockchain zu verwalten. Mit einem solchen Update der Blockchain-Software lassen sich neue Features wie Sharding und/oder ein neues Konsensverfahren einführen, Transaktionen rückgängig machen (wie im Falle von ETC/ETH) und/oder Bugs beheben.

Blockchain sicher gestalten

BSI untersucht Sicherheit der Blockchain

Sofern das Update der betreffenden Blockchain-Software ihre Kompatibilität mit der Vorgängerversion nicht beeinträchtigt, ist hierbei von einem sogenannten Soft-Fork die Rede. Ein Beispiel für einen Soft-Fork lieferte etwa die Bitcoin-Blockchain mit dem SegWit-Update (Segregated Witness). Bei einem Soft-Fork können alle Netzwerkknoten ihre Transaktionen weiterhin in dieselbe Blockkette eintragen und miteinander über den Konsensus abstimmen.

Hebt das betreffende Software-Update die Kompatibilität zu älteren Versionen der Blockchain-Software auf, ist hierbei von einem sogenannten Hard-Fork die Rede. Diese Art einer Aktualisierung greift typischerweise in das Konsensverfahren hinein und/oder verändert die Struktur der Datenblöcke, sodass die alte Version der Software mit den Änderungen nichts anfangen kann. So entsteht mit dem ersten neuen Datenblock irreversibel eine neue Blockchain.

Haben alle Netzwerkteilnehmer die Aktualisierung eines solchen Hard-Forks eingespielt, geht die alte Blockchain in der neuen Blockchain auf (und hört somit selbst auf, zu existieren). So wird nur noch die neue Blockchain fortgeführt. Ein gutes Beispiel für einen Hard-Fork dieser Art waren die beiden Ethereum-Updates Constantinople und St. Petersburg vom Ende Februar 2019.

Eine einstimmige Übereinkunft zu einem Hard-Fork ist bei einer öffentlichen Blockchain natürlich nicht immer gegeben. Sind sich die Teilnehmer nicht einig, splittet sich das Netzwerk in zwei auf. Die aktualisierte Version der Blockchain-Software schreibt fortan in eine neue Version der Blockkette, während die alte Blockchain ggf. durch eine Untermenge der Teilnehmer unabhängig davon fortgeführt wird. Genau dieses Schicksal wurde der Ethereum-Gemeinde im Zusammenhang mit dem DAO-Hack zuteil, als sich die Plattform infolge eines Hard-Forks in zwei Ethereum-Blockchains aufteilte: Ethereum Classic (ETC) und das „neue“ Ethereum (ETH).

Um große konzeptionelle Änderungen umzusetzen, können auch mehrere Upgrade-Schritte erforderlich sein. Dies ist der Fall bei Ethereums (ETH) geplanter Migration zum Casper-Protokoll mit einem Proof-of-Stake-Konsensverfahren. Diese noch bevorstehenden Aktualisierungen sollen vor allem Probleme der Skalierbarkeit beheben, die Transaktionskosten senken und neue Anreize für die Teilnehmer schaffen. Wie sich derart massive Veränderungen auf die Cybersicherheit der Ethereum-Blockchain und verwandter Lösungen auswirken, wird erst die Zeit zeigen.

Hintertüren

Die Schlüsselerzeugung und -verwaltung sowie die Interaktionen zwischen Nutzern und der Blockchain erfolgen in der Regel über Softwareprodukte von Drittanbietern wie beispielsweise Wallets. Zu diesen Tools und Diensten würden meist keine Sicherheitsgarantien vorliegen, warnt das BSI.

Fazit

Die Herausforderungen der Implementierung einer sicheren Blockchain sind tatsächlich sehr vielseitig. Die klassischen Schutzziele der IT-Sicherheit, nämlich die Integrität, Authentizität, Verfügbarkeit und Vertraulichkeit, bleiben bei vielen Blockchain-Implementierungen bisher noch auf der Strecke. Angesichts fehlender Standards und regulatorischer Richtlinien liegt es an den einzelnen Unternehmen, die DSGVO-Konformität ihrer Blockchain-Lösungen zu gewährleisten, um operationelle Risiken der Digitalisierung frühzeitig in den Griff zu bekommen — und sei es „nur“ im eigenen Interesse.

Über die Autoren: Anna Kobylinska und Filipe Pereira Martins arbeiten für McKinley Denali Inc. (USA).

(ID:46078841)