Management und Wissen / IAM mit Blockchain
Die Blockchain-Euphorie schlägt weiterhin hohe Wellen. Die Erwartungen sind hoch und noch ist nicht klar, ob und wie die neue Technologie den Ansprüchen verschiedenster Anwendungsbereiche gerecht werden kann. Wie steht es um die technische Umsetzbarkeit einer blockchainbasierten digitalen Identität?
Das Aufkommen der Bitcoin-Blockchain hat 2009 den Grundstein für eine Revolution in der Datenverwaltung gelegt. Nach und nach blickten Pioniere hinter die Fassade der Kryptowährung und erkannten das Potenzial der dahinterstehenden globalen, dezentralen Datenstruktur, die entwurfsbedingt ein hohes Maß an Sicherheit bietet.
Das Prinzip: Netzteilnehmer sind im Rahmen einer asymmetrischen Verschlüsselung im Besitz eines geheimen und eines öffentlichen Schlüssels und weisen sich durch ihre blockchainspezifische Adresse aus. Transaktionen innerhalb der Blockchain werden signiert in Blöcke geschrieben, die sich über einen Blockheader ausweisen, der mittels Hashbäumen Bezug auf die enthaltenen Transaktionen sowie den Blockheader des Vorgängerblocks nimmt – hierdurch findet eine Verkettung statt. Konsensverfahren regeln dabei die Verständigung des Netzes auf den neuesten hinzuzufügenden Block, dessen Transaktionen durch den Einbau in die Blockchain Gültigkeit erlangen.
Dieses Auskommen ohne zentral verwaltende Instanz und der damit verbundene Schutz gegen Ausfall, Manipulation und Zensur machen die Blockchain auch für eine Vielzahl von Anwendungsbereichen abseits digitaler Währungen interessant: Neben digitalen Grundbüchern, Strombörsen und IoT-Anwendungen ist der Einsatz des Verfahrens im Bereich Identity- und Access-Management (IAM) ein weiterer vielversprechender Punkt auf der Blockchain-Agenda.
Im Mittelpunkt einer digitalen Identität auf Blockchain-Basis stünde der Nutzer, der seine Daten und die Zugriffsrechte darauf selbst verwaltet. Eine flächendeckende Adaption einer solchen Blockchain-Identität durch Einzelpersonen, Unternehmen, Onlinedienste und sogar vernetzte Geräte könnte die aktuell gängige Verwaltung dutzendfacher Accounts überflüssig machen und ein echtes „Bring Your Own Identity“ (BYOI) ermöglichen.
Neben rechtlichen Fragestellungen und wirtschaftlichen Konsequenzen, die es im Auge zu behalten lohnt, ist bei dieser Neuorientierung im Umgang mit persönlichen Daten auch eine umfassende technische Betrachtung sinnvoll. Denn die Evolution der Blockchain schreitet weiter voran und Entwicklern stehen heute zahlreiche Architekturen zur Verfügung. Umgekehrt erfordern praxistaugliche Identity-and-Access-(I&A)-Lösungen geeignete Rahmenbedingungen. Dieses Wechselspiel wird im Folgenden durch die exemplarische Betrachtung in Entwicklung befindlicher I&A-Blockchain-Lösungen dargelegt.
Blockchains lassen sich anhand der Dimensionen der Zugriffsberechtigung für Daten und der Validierungsberechtigung für Transaktionen klassifizieren. Dabei kann man beim Zugriff zwischen frei einsehbaren Public Blockchains und auf einen ausgewählten Teilnehmerkreis beschränkte (z. B. unternehmensinterne) Private Blockchains unterscheiden. Analog kann die Berechtigung zum Erstellen von Blöcken jedem Teilnehmer gewährt (Permissionless) oder einem kleineren Kreis vorbehalten sein (Permissioned). Abbildung 1 veranschaulicht die möglichen Kombinationen in einer Matrix.
Ein richtungsweisendes I&A-Projekt auf Blockchain- Basis ist das von Doktoranden der Universität Princeton ins Leben gerufene Blockstack (https://blockstack. org). Sein Ziel ist der Aufbau eines dezentralen Internets abseits der bestehenden DNS-Server – Kernkonzept ist die Kopplung digitaler Bestände, Domains sowie Identitäten an öffentliche Schlüssel mittels der Blockchain.
Blockstack verfolgt dabei einen mehrschichtigen Aufbau mit einer auf eine Public Permissionless Blockchain aufgesetzten virtuellen Chain, auf der Identitäten als eine Verknüpfung von Schlüsseln mit Zonefile- Hashes realisiert werden. Innerhalb eines Routing-Layers führen entsprechende Zonefiles zum Storage-Layer in Form von Cloud-Speichern oder verteilten Dateisystemen (z. B. dem IPFS – InterPlanetary File System), wo die eigentlichen Daten abgelegt sind.
Der Aufbau dieser Blockchain profitiert von der höheren Flexibilität und besseren Speichermöglichkeit der virtuellen Chain, während die zugrunde liegende Public Permissionless Blockchain der Konsensfindung und damit der Sicherheit und „Taktung“ der virtuellen Chain dient. Aktuell wird die Bitcoin-Blockchain als Unterbau verwendet – allerdings wurde erst 2015 aus Gründen der Sicherheit ein Wechsel von Namecoin auf Bitcoin vollzogen, hier besteht also Austauschbarkeit.
Obwohl der Fokus des Projekts aktuell auf dem erst Ende Mai 2017 veröffentlichten Blockstack- Browser für das dezentralisierte Internet liegt, ist die digitale Identität nach wie vor erklärtes Ziel von Blockstack. Mit bereits über 50 000 registrierten Identitäten ist das Projekt ein klarer Vorreiter in diesem Bereich.
Ein weiteres Projekt mit dem Ziel einer selbstverwalteten digitalen Identität ist uPort von ConsenSys (www.uport.me). Es bedient sich der (Public Permissionless) Ethereum- Blockchain, die neben dem Kryptowährungsaspekt vor allem durch ihre Funktion als „World-Computer“ bekannt ist: Mit der Turing-mächtigen Ethereum-Virtual-Machine ausgestattet, unterstützt diese Blockchain so genannte Smart-Contracts. Solche in die Blockchain integrierbaren, automatisierten Verträge sind aus der Perspektive der objektorientierten Programmierung Instanzen von Klassen, deren Methoden von Nutzern durch Transaktionen aufgerufen werden können.
Eine Identität entsteht dabei durch das Zusammenspiel mehrerer Komponenten: Kernstück ist der Proxy-Contract, dessen Adresse in der Ethereum-Blockchain die Identität eindeutig ausweist und mit Smart- Contracts von ethereumbasierten Webapplikationen interagiert. Dem Proxy-Contract vorgeschaltet ist ein Controller-Contract, der die eigentliche Interaktion mit dem Nutzer handhabt und gewissermaßen mit einer Recovery-Funktion der eigenen Identität versehen ist (für den ansonsten fatalen Fall eines Schlüsselverlusts des Users). Ein Registry- Contract sorgt für die Anreicherung der Identitäten mit Attributen durch Verknüpfung von Proxy-Contract- Adressen mit Hashverweisen zu (derzeit noch unverschlüsselten) JSON-Dateien mittels IPFS.
Die Verwaltung der Identität geschieht bei uPort mittels einer Mobile-App; Developer Libraries sollen App-Entwicklern die Möglichkeit geben, Gebrauch von uPort-Identitäten zu machen. Erste praktische Anwendung soll uPort ab September 2017 in der schweizerischen Stadt Zug, zugleich Sitz der Ethereum-Stiftung, finden. Die digitale ID für jeden Bürger könnte – nach einer Beglaubigung durch die Stadt – im Bereich städtischer Dienstleistungen, im E-Voting und anderen Anwendungsbereichen zum Einsatz kommen.
Sovrin ist ein Projekt der gleichnamigen gemeinnützigen Stiftung (https://sovrin.org) und definiert sich als erster „Public Permissioned Ledger“ (engl. für Register, Hauptbuch etc.). Mit einer für die Allgemeinheit offenen Infrastruktur will man so das Internet um eine Ebene selbstverwalteter Identitäten erweitern.
Aus technischer Sicht fällt vor allem die Permissioned-Konzeption ins Auge: Nodes des Sovrin-Ledgers werden von so genannten Stewards betrieben. Dies sollen idealerweise branchen- und grenzübergreifend verteilte Instanzen (Unternehmen, Universitäten, Regierungen etc.) sein, die im Rahmen des Vertragswerks „Sovrin Trust Framework“ ihre gute Absicht erklären. Diese Vertrauensgrundlage ermöglicht den Verzicht auf die rechenintensive kryptografische „Proof-of-Work“- Komponente zur Konsensfindung in Permissionless-Blockchains, in denen kein gegenseitiges Vertrauen vorgegeben ist. Der Einsatz von RBFTAlgorithmen (Redundant Byzantine Fault Tolerance) soll hier für eine hohe Geschwindigkeit bei der Verarbeitung von Transaktionen und eine hohe Skalierbarkeit sorgen.
Sovrins Blockchain-Ebene entsteht durch die Verzahnung vier verschiedener Ledger: drei zur Koordination der reibungslosen Zusammenarbeit aller Nodes sowie der eigentliche Identity-Ledger. Die Stewards nehmen dabei eine von zwei Rollen ein: Validator oder Observer. Ein Validator ist für die Verarbeitung von Transaktionen zuständig, während Observer diesen Vorgang überwachen und bei Bedarf durch Unregelmäßigkeiten auffallende Validatoren ersetzen. Da diese Rollen für eine Aufgabenteilung (Lese- oder Schreibzugriffe) sorgen, kann man durch die dynamische Anpassung des Verhältnisses eine weitere Performancesteigerung erzielen. Weitere Schichten (Sovrin- Agents und -Clients) beschreiben die Kommunikation von Applikationen, die Identitäten nutzen, mit dem Sovrin-Ledger.
Anfang Juli 2017 hat Sovrin sein „Provisional Trust Framework“ veröffentlicht, eine Zusammenstellung von Dokumenten, die das zugrunde liegende Vertrauensmodell beschreiben. Damit wurde aus Sovrins Sicht die Grundlage für ein globales öffentliches Managementsystem für souverän verwaltete Identitäten geschaffen. Während Sovrin weiterhin die Technik und den Aufbau des zukünftigen Netzwerks vorantreibt, ist das Projekt auf Code- Ebene unter dem Namen „Indy“ Teil von Hyperledger geworden (www. hyperledger.org), einem von der Linux Foundation ins Leben gerufenen Dachprojekt zur Weiterentwicklung der Blockchain-Technologie.
Um die Implementierung von Blockchain-I&A greifbar zu machen, hat die Blockchain-Arbeitsgruppe der esatus AG ein eigenes I&A-Prototyping auf Basis von Ethereum durchgeführt. Zielsetzung ist die Realisierung des „Bring Your Own Identity“-Ansatzes. Anhand einiger Use-Cases sollte veranschaulicht werden, welche Vorteile der Einsatz von Blockchain-Verfahren in diesem Fall bringen kann.
Eine „Blockchain-ID“ enthält hierbei zu Beginn nur einige grundlegende Daten einer Person. Der Zugriff auf diese Daten wird direkt über eine Logik innerhalb eines Smart-Contracts geregelt. Diversen weiteren Instanzen (bspw. dem Einwohnermeldeamt) wird die Möglichkeit gegeben, Änderungen an den in der Blockchain abgelegten Daten anzustoßen. Außerdem gibt es für die darin gespeicherten Daten ein Validierungssystem, über das abrufende Instanzen (z. B. Händler) sicherstellen können, dass die bewussten Daten korrekt sind.
Den Zugriff auf die eigenen Daten kann jeder Benutzer selbst verwalten. Dabei ist jedoch zu beachten, dass er nicht alle Berechtigungen entziehen darf: So kann er beispielsweise dem Einwohnermeldeamt nicht den Zugriff auf Namen und Adresse entziehen, wohl aber zusätzliche Informationen, wie Kontodaten oder Telefonnummer, freigeben.
Die eingesetzten Smart-Contracts wurden mit Solidity entwickelt (https://solidity.readthedocs.io), einer Programmiersprache speziell für Smart-Contracts, deren Syntax der von Javascript sehr ähnlich ist. Für die Kommunikation mit der Blockchain wird ein Blockchain- Node benötigt.
Für das Prototyping wurden zunächst drei verschiedene Ansätze evaluiert:
Da BlockApps nur Private Blockchains unterstützt, wurde dieser Ansatz nicht weiter vertieft – da geth der etablierteste Blockchain-Node ist, hat esatus zu Beginn eine Umsetzung mit diesem Ansatz angestrebt. Der Zugriff auf den Blockchain-Node wurde mittels der Javascript-API web3 realisiert (https://github.com/ ethereum/web3.js/). Um die Umsetzung innerhalb der Applikation einfach zu gestalten, wurde auf das Framework Nethereum zurückgegriffen (www.nethereum.com), eine speziell für den Einsatz mit dem .net-Framework angepasste Version des web3-API – hierüber lassen sich alle RPC- und IPC-Funktionen des Blockchain-Node ansprechen.
Um Benutzern einen möglichst komfortablen Umgang mit der Applikation – Zugriff per Benutzername und Passwort – zu gewähren, wurde eine zusätzliche MSSQLDatenbank eingesetzt, die eine Zuweisung der Adresse des Benutzers innerhalb der Blockchain und einen Benutzernamen realisiert (aber keine Passwörter speichert). Die Zuweisung des Schlüsselspaars zu dieser Adresse regelt der Blockchain-Node, in dem die Daten in JSON-Dateien abgelegt sind. Der geheime Schlüssel wird dort mittels AES-128 chiffriert abgelegt – der hierfür verwendete Schlüssel mittels „Password- Based Key Derivation Function 2“ (PBKDF2) aus dem vom Benutzer gewählten Passwort abgeleitet. Ein Zugriff auf die Daten kann somit durch das gewählte Passwort erfolgen, die Daten selbst können dann für Transaktionen in der Blockchain verwendet werden.
Dieser Aufbau bietet einem Benutzer also letztlich die Möglichkeit, sich mit Benutzernamen und Passwort in der Blockchain zu authentifizieren – seine Adresse sowie seinen geheimen und öffentlichen Schlüssel muss er dazu nicht verwenden. Abbildung 2 veranschaulicht die Systemarchitektur inklusive eines potenziellen Anwendungsfalls.
Im Laufe der Entwicklung von Applikation und Smart-Contract sind einige Probleme zum Vorschein gekommen: So zeigte sich mit dem zu Beginn verwendeten Blockchain- Node geth, dass bei einer großen Zahl von Transaktionen (also Anfragen an die Blockchain) bisweilen Transaktionen verloren gehen. Dies ließ sich darauf zurückführen, dass diese Transaktionen, bedingt durch ein Update des Blockchain-Status, nicht in einen Block geschrieben wurden, obwohl sie als durchgeführt markiert wurden. Bei diesem Fehler handelt es sich um ein bei geth bekanntes Problem. In der Konsequenz wurde entschieden, stattdessen Parity zu verwenden.
Da der entwickelte Smart- Contract im Laufe der Zeit deutlich wuchs, wurde überlegt, diesen aufzuteilen, also mehrere Smart-Contracts zu verwenden. Als Alternative kam infrage, eine Private Blockchain mit höherer Blockgröße zu nutzen, also die maximal zulässige Menge von Daten innerhalb eines Blocks zu vergrößern. Da es nach aktuellem Stand des Ethereum-Kurses und dem relativ stabilen „Gas-Price“ einen enormen Anstieg der Kosten von Transaktionen auf der Public- Ethereum-Blockchain gibt, wurde entschieden, den Smart-Contract nicht zu splitten, sondern für das Prototyping eine angepasste Private Blockchain zu verwenden.
Die Möglichkeit, Daten außerhalb der eigentlichen Blockchain zu speichern und nur den Zugriff mittels in der Blockchain gespeicherter Hashwerte zu realisieren, wurde im bisherigen Prototyping hingegen nicht berücksichtigt. Zunächst blieben alle Daten innerhalb der Blockchain.
Die Entwicklung von Blockchain- I&A-Applikationen erscheint nach aktueller Erkenntnislage durchaus als möglich – allerdings ist an einigen Stellen ein Umdenken nötig: Gewohnte Ansätze, wie man sie von Applikationen mit Datenbanken kennt, sind nicht einfach auf das Blockchain-Modell zu übertragen. Außerdem sind viele Dokumentationen schon nach kürzester Zeit veraltet – es ist oft unumgänglich, mit den Entwicklern in direkten Kontakt zu treten.
Überdies sollte man beachten, dass Übertragungen mittels RPC unverschlüsselt erfolgen, also Daten auf dem Weg von der Applikation zum Blockchain-Node abgefangen werden können. Da Daten innerhalb der Blockchain allerdings in jedem Falle einsehbar sind, wäre hier der praktikable und richtige Ansatz eine Verschlüsselung der Daten an sich und nicht die Verschlüsselung der Übertragung. Dennoch bleibt noch immer das Problem der sicheren Passwort-Übertragung zwischen dem Hosting-Server der Blockchain- Applikation und dem Server mit dem Blockchain-Node – hier gibt es Nachbesserungsbedarf.
Sich in Zukunft mit seiner Blockchain-ID à la „mit Facebook/ Google einloggen“ authentifizieren zu können, ist ein wünschenswertes Ziel. Dem Siegeszug der digitalen Identität auf Blockchain-Basis stehen aber noch einige Hindernisse im Wege: Die von Blockchain-Puristen favorisierten Public Permissionless Blockchains in Form von Bitcoin, Ethereum & Co. bieten zwar eine interessante Versuchsplattform. Auch wenn diese Architekturen der ersten Stunde nichts an Funktionalität und Sicherheit eingebüßt haben, sind sie aber doch primär auf Kryptowährungen zugeschnitten. Es erscheint unumgänglich, auch andere Konzepte zu erproben.
So ist es auch kein Zufall, dass viele Entwickler das Backend ihrer Anwendungen nicht als Blockchain verstanden wissen wollen. Schon lange liegt das nicht mehr an einer möglicherweise negativen Konnotation mit Bitcoin – es ist vielmehr die fortschreitende Entwicklung im Bereich der „Distributed Ledger Technology“ (DLT), die sehr oft einen Schritt weg von der klassischen Blockchain bedeutet: Seien es das Zusammenspiel mehrerer Distributed Ledger und virtueller Chains, die Loslösung von verketteten Blöcken zugunsten eines fortlaufenden Transaktionsgrafen (vgl. https:// byteball.org oder iota.org) oder schlichtweg die Wahl von geschlossenen Architekturen – jeder Anwendung mit all ihren Erfordernissen kann und sollte man mit einem geeigneten Design begegnen! So ist die Evolution der Blockchain weiterhin in vollem Gange, wobei man sich von den Wurzeln entfernt.
Die Wahl der richtigen Technik könnte auch einem IAM auf Basis der Blockchain zum Durchbruch verhelfen. Ein erster Schritt ist möglicherweise die Festlegung auf eine Public-Permissioned-Architektur, die von der einfachen Zugänglichkeit und Robustheit der Public Chains profitiert. Die Schwerfälligkeit solcher Chains könnte durch gezielte Rechtevergabe zur Transaktionsvalidierung an ein Konsortium überwunden werden. Insbesondere die mögliche schnelle Taktung durch effiziente Konsensalgorithmen und verhältnismäßig einfach durchführbare Protokolländerungen sind erhebliche Vorteile im Vergleich zu Public-Permissionless-Ansätzen. Der Aufbau eines solchen branchenübergreifenden Konsortiums wäre hierzu ein entscheidender Schritt.
Letztendlich sind aber auch Erfindergeist und das Ablegen ideologischer Scheuklappen gefragt, um die technischen Möglichkeiten der Blockchain-Technologie weiter voranzutreiben und nicht zuletzt die Vision einer souveränen Identität zu verwirklichen.