Thought Leadership
Das Herzstück jeder Blockchain ist ein Protokoll, das der Reihenfolge und Sicherheit einer Transaktion für den nächsten Block zustimmt. Der folgende Beitrag beschäftigt sich damit wie man die Integrität dieser Kette bewahrt. Sogenannte permissioned Blockchains erfreuen sich wachsender Beliebtheit.
Umso mehr, als Firmen den Blockchain-Trend für sich nutzen und gleichzeitig den „Deckel darauf halten“ wollen. Im Gegensatz zu den Vertretern der Non-Permissioned-Seite (wie Bitcoin oder Ethereum) sind bei permissioned Blockchains die Teilnehmer bekannt, und man kann ihnen gezielt besondere Rechte und Privilegien einräumen. Permissioned Blockchains werden von einer Genehmigungsinstanz kontrolliert, die jedem Einzelnen der teilnehmenden Knoten eine entsprechende Erlaubnis erteilt. Nur wer autorisiert ist kann auf das Transaktionsnetzwerk zugreifen.
Sucht man bei einer gehypten Technologie wie der Blockchain nach konkreten Anwendungsbeispielen, handelt es sich meist um permissoned Blockchains. Die genehmigende Instanz kann ein Konsortium von Unternehmen sein, aber auch eine einzelne Organisation. Der folgende Beitrag beschäftigt sich insbesondere mit den Sicherheitsimplikationen, wenn man autorisierten Teilnehmern eine übersichtliche Blockchain bereitstellen will und gibt Empfehlungen für eine sichere Bereitstellung.
Dazu ist es sinnvoll zunächst zu klären, was man unter permissioned Blockchains versteht und wie die Terminologie verwendet wird.
Was eine permissioned Blockchain ausmacht
Das Herzstück jeder Blockchain ist ein Protokoll, das der Reihenfolge neuer Transaktionen für den nächsten Block zustimmt, der sogenannte „Konsensus“. Transaktionen können dabei jede Art von Informationen sein. Der Konsensus ist eine verbindliche Übereinkunft zwischen allen validierten Knoten. Jeden Computer, der sich mit einem Blockchain-Netzwerk verbindet, nennt man Node, also Knoten. Innerhalb der Blockchain sorgen die Konsensusmechanismen für die Integrität und Konsistenz der Daten. Es ist also ganz entscheidend, dass dieser Prozess sicher abläuft.
In den sogenannten „Non-Permissioned“ Blockchains ist der Konsensus typischerweise der Versuch ein schwieriges mathematisches Problem im Austausch für einen vergleichsweise geringen finanziellen Lohn zu lösen. Die validierenden Knoten sammeln zunächst alle ihnen bekannten Transaktionen, wählen eine Reihenfolge und beginnen damit, die Aufgabenstellung des Blocks zu lösen. Ohne Zugangsbeschränkungen ist der Konsensusmechanismus entsprechend einfach, was unter anderem die Transaktionsgeschwindigkeit erhöht. Die Schattenseite: Im Grunde ist es reines Glücksspiel wer am Ende das Rennen macht. Auch wenn eine gewisse Wahrscheinlichkeit dafür spricht, dass es diejenigen sein werden, die über eine höhere Rechnerleistung verfügen. Das Konsensusprotokoll kann durchaus schwerwiegenden Angriffen auf die Kette standhalten (bis zu 50 % aller Knoten können bösartig sein). Allerdings geht das auf Kosten der Transaktionsgeschwindigkeit und der Bestätigung.
Bitcoin wickelt beispielsweise einzelne Transaktionen innerhalb einer Sekunde ab, die Bestätigung kann allerdings über eine Stunde dauern. In permissioned Blockchains läuft der Konsensus geordneter ab, und die Prüfer wechseln sich dabei ab, einen Block vorzuschlagen, den die anderen anschließend freigeben. Der Prozess läuft also viel schneller ab. Permissioned Blockchains erzielen deshalb eine hohe Durchsatzrate bei Transaktionen, die oftmals sofort bestätigt werden. Dieser Typ von Konsensus basiert im Allgemeinen darauf, dass mehr als zwei Drittel der Knoten vertrauens-würdig sind.
Sicherheitsherausforderungen bei permissioned Blockchains
Der Terminus Blockchain beschwört sofort ein bestimmtes Bild herauf – das von dezentraler Kontrolle und Mehrwert durch Sicherheit. Große non-permissioned Blockchains wie etwa Bitcoin und Etherum haben in der Öffentlichkeit mittlerweile einen hohen Bekanntheitsgrad. Und zuweilen beeinflusst dieses Phänomen auch Unternehmen, die planen permissioned Blockchains zu nutzen.
Eines sollte man verstehen: Senkt man die Zahl der Teilnehmer und verlässt sich auf vertrauenswürdige Prüfer, dann ähneln die Sicherheitsanforderungen und Herausforderungen eher denen in traditionellen IT-Systemen als denen großer Blockchains.
Stellen wir uns eine permissioned Blockchain vor, die zwischen fünf führenden Bankhäusern aufgebaut wird. In einer Blockchain mit fünf Knoten bedeutet das, dass vier von ihnen (also zwei Drittel) vertrauenswürdig sein und sich korrekt verhalten müssen, damit der Konsensus erfolgreich abläuft.
Im Wesentlichen gibt es zwei Gründe wenn Knoten sich nicht so verhalten wie sie sich verhalten sollten. Ihre legitimen Eigentümer haben unredliche Absichten oder die Knoten sind von einem Angreifer kompromittiert worden. Im ersten Fall geht es darum geheime Preisabsprachen und Verdunklung zu verhindern. Im zweiten Fall darum, die privaten Schlüssel der Knoten zu schützen, und sicherzustellen, dass sie nur dazu benutzt werden, die Nachrichten zu signieren, die sich im Einklang mit dem Konsensusprotokoll befinden. Genauso wichtig ist es die privaten Schlüssel der Blockchain-Konten zu schützen. Diese Schlüssel dienen dazu eine Transaktion zu signieren und so einen nicht autorisierten Geldfluss aus dem betreffenden Konto heraus zu verhindern. Der unberechtigte Zugriff auf diese Schlüssel würde dazu führen, dass Werte unrechtmäßig zwischen den beteiligten Banken übertragen werden. Es kann kostspielig werden, dieses Problem zu lösen und schlimmer noch, der unberechtigte Zugriff kann den Bestand des kompletten Projekts gefährden.
Schließlich ist da noch der Dreh- und Angelpunkt des gesamten Systems, nämlich der Schüsselsatz, der die Teilnehmer überhaupt erst autorisiert. Hat ein Angreifer Zugriff auf diese Schlüssel ist er beispielsweise in der Lage neue validierende Knoten zu bevollmächtigen. Ein Angreifer kontrolliert dann beispielsweise ausreichende Stimmrechte, um potenziell die gesamte Kette zu beschädigen oder sogar zu zerstören.
Was tun gegen die Bedrohungen?
Während sich öffentliche Blockchains bei ihrer Sicherheit auf die schiere Zahl der Knoten verlassen, müssen permissioned Blockchains zu anderen Methoden greifen. Dazu gehören Verfahren die Blockchain zu härten beispielsweise durch geschützte Umgebungen für private Schlüssel sowie durch Prozesse und Verfahren für einen sicheren Betrieb der Blockchain als solcher.
Private Schlüssel, die von validierenden Knoten verwendet werden, sollten auch physisch geschützt werden. Dazu dienen Technologien wie Hardware Security Modules (HSMs). HSMs sorgen dafür, dass die privaten Schlüssel nicht vom Serverspeicher ausgelesen werden können wenn der Knoten kompromittiert wurde. Es ist sogar möglich die eigentliche Logik des Konsensus mit HSMs zu schützen. Diese Methode stellt sicher, dass die betreffenden Daten tatsächlich dem Konsensusprotokoll entsprechen bevor sie mit dem Schlüssel signiert werden. Ein klassisches Anwendungsbeispiel ist, das doppelte Signieren zu verhindern wie etwa Forking. Unser Forschungsteam hat ein Open-Source Beispiel dieser Technik veröffentlicht, bei der eine beliebte permissioned Konsensus-Engine verwendet wurde.
Will man die privaten Schlüssel der Blockchain-Konten schützen, sollte man einen auf dem potentiellen Risiko basierenden Ansatz wählen. Für Wallets (digitale Ordner), die nur geringfügige Werte repräsentieren, genügen in aller Regel einfache Methoden, wie ein HSM USB-Stick mit einem Schalter über den sich Überweisungen autorisieren lassen. Im Unternehmensumfeld mit entsprechenden Werten empfiehlt es sich kommerzielle HSMs einzusetzen und gegebenenfalls die Zeichnungspflichten auf unterschiedliche Zeichnungsberechtigte zu verteilen.
Die privaten Schlüssel innerhalb einer Blockchain zu sichern ist deutlich einfacher als jede andere Art von Public Key Infrastructure (PKI) zu schützen. Trotz allem ist aber auch das eine Art von PKI. Anders als in der üblichen Wahrnehmung von Blockchains verlassen sich permissioned Blockchains auf eine PKI, die Anmeldeinformationen an ihre jeweiligen Teilnehmer ausgibt. Und jede einzelne Transaktion lässt sich unmittelbar mit Bezug auf den entsprechenden Vertrauensanker überprüfen und bestätigen. Es ist einleuchtend, dass die betreffenden Schlüssel wie jeder andere vergleichbare Vertrauensanker geschützt werden müssen – über HSMs, die Verteilung der Zeichnungsaufgaben, Auditing und so weiter.
Die Zukunft der permissioned Blockchains
Im Moment zeigt der Hype um das Thema Blockchain keinerlei Anzeichen sich abzuschwächen. Wir können vermutlich damit rechnen, dass Projekte, die permissioned Blockchains nutzen schon bald in den Branchennachrichten auftauchen werden. Wenn es daran geht solche Projekte zu entwickeln und umzusetzen, sollte Sicherheit vom ersten Tag an mit berücksichtigt werden. Wie immer, wenn sich eine neue Technologie anschickt die Märkte zu erobern, wird Sicherheit gerne zugunsten von Schnelligkeit zurückgestellt. Es ist also vermutlich nicht nur mit einem Anstieg entsprechender Projekte zu rechnen, sondern auch mit mehr Sicherheitslücken und Schwachstellen bei Consortium Blockchain-Implementierungen.
Wenn der Hype sich ein wenig gelegt hat, werden vielleicht weniger Projekte in Auftrag gegeben. Aber zu diesem Zeitpunkt haben wir sicherlich bereits gute und praktikable Empfehlungen für Blockchain-Anwender von Körperschaften wie der Accredited Standards Committee X9 und der ISO/TC 307 erhalten.
Autor: Duncan Jones, Thales eSecurity
