Von Ralf Keuper
Am Montag (04.07.22) fand im Deutschen Bundestag die Öffentliche Anhörung Digitale Identitäten statt. Zuvor hatten die Expertinnen und Experten eine schriftliche Stellungnahme abgegeben. Darin äußerten sie sich auch zu den Einsatzmöglichkeiten Selbstsouveräner Identitäten und der Blockchain-Technologie.
Konkret ging es um die Frage: Wie definieren und bewerten Sie das Self-Sovereign Identity (SSI)-Konzept? Eine Kritik an SSI ist, dass beglaubigte Daten bei den Empfängern gespeichert würden. Wie bewerten Sie die Datensicherheit des SSI-Konzepts? Gibt es aus Ihrer Sicht technische Wege, wie diese Empfangsspeicherung durch SSI vermieden werden kann?
Der Bundesbeauftragte für den Datenschutz und die Informationssicherheit, Ulrich Kelber, weist u.a. darauf hin: “Die Richtigkeit der Identitätsdaten wird meist nicht als Ziel einer selbst-souveränen Identität aufgezählt, ebenso werden individuelle Möglichkeiten der Korrektur / Löschen („Vergessen“) von Daten, anders als im Datenschutz (Beteiligtenrechte), oft nicht erwähnt. Die Qualität der Verifikation der Identitätsdaten ist ein wesentliches Element auch der Vorgaben der eIDAS-Verordnung für die Vertrauensniveaus von Identifizierungssystemen”. … Eine Speicherung von einmal übermittelten Daten durch den Empfänger kann jenseits regulatorischer/rechtlicher Vorgaben (technisch) nicht verhindert werden. Dies unterstreicht die Wichtigkeit, von vornherein nur die für einen Anwendungszweck notwendigen Daten zu übermitteln (Datenminimierung) bzw. nach Möglichkeit technische Mittel zur Datenreduktion (Privacy-Enhancing-Technologies, Zero-Knowledge-Proofs, etc.) zu nutzen”[1]Stellungnahme Kelber
Das BSI, das sich bereits in seinem Eckpunktepapier Self-sovereign Identities (SSI) kritisch geäußert hatte, hält eine Fixierung auf die Blockchain-Technologie für unangemessen: “Aus Sicht des BSI ist eine derartige Umsetzung jedoch keineswegs zwingend. Stattdessen sollte im Sinne der Technologieneutralität vor der Entscheidung über die technische Umsetzung eine sorgfältige Analyse der tatsächlich benötigten Funktionen und Sicherheitseigenschaften stehen”. Ebenso wie der Datenschutzbeauftragte des Bundes hält das BSI die Sorge, dass beglaubigte Daten beim Empfänger gespeichert werden, für grundsätzlich berechtigt: “In der Folge ist jede Kopie der Kombination aus Identitätsdaten und Signatur vergleichbar mit einer beglaubigten Kopie. Problematisch ist hierbei, dass jede Person, die in den Besitz der Identitätsdaten mit Signatur gelangt, über nachweislich authentische Daten verfügt und dies auch beliebig an Dritte weitergeben kann, ohne dass der Inhaber der Identitätsdaten dies kontrollieren kann”[2]Stellungnahme BSI. Als Lösung schlägt das BSI vor: “Stattdessen sollte, wie bei der Online-Ausweisfunktion des Personalausweises, die Authentizität der Daten durch den Hardware-Chip im Ausweis sichergestellt und implizit während des Identifizierungsvorgangs nachgewiesen werden. Dadurch ist die Echtheit der übermittelten Daten nur innerhalb der Kommunikation zwischen Diensteanbieter und Nutzer überprüfbar. Auf diesem Wege kann der Dienstanbieter weiterhin zweifelsfrei feststellen, dass es sich um eine echte Identität handelt. Sollte er die Daten aber später (unberechtigterweise) an Dritte weitergeben, kann er deren Echtheit nicht mehr beweisen, wodurch diese Daten ihren Wert für Kriminelle und Unbefugte verlieren”.
Für Christian Kahlo stellt SSI technisch einen Rückschritt dar: “Das zentrale technische Problem ist hier, ähnlich wie bei Zertifikaten, dass validierte, echte Personendaten signiert, d.h. mit „Echtheitsgarantie“ bei der kontrollierenden Stelle landen. Dieser Datensatz, kann vollständig und ohne Kenntnis des Bürgers weiterverwendet werden. Es wäre hier möglich, dass ein Unternehmen, gegenüber dem ich mich mittels SSI ausweise, diese Daten mit Echtheitsgarantie weitergibt. (siehe Identitätsdiebstahl, Adresssammler, Datenhandel)”. Die Hoffnung, das Problem mittels Zero-Knowledge-Proof zu umgehen, sei trügerisch: “ZK-Proofs sind aber bestenfalls als “sehr junge und zweckendfremdete Technologie” anzusehen im Kontext Identitäten. Auch der Mehrwert zu sagen “ich heiße Hans Muster will aber die Signatur unter meinen Daten nicht verraten” ist eher widersinnig bis obsolet”. Weiterhin: “Selbst eine reine Software-Implementierung der eID, wie bereits seit 2014 prototypisch gezeigt, löst alle bisher aufgeworfenen rechtlichen und technischen Fragestellungen schneller, präziser und einfacher als SSI”[3]Stellungnahme Kahlo.
Carl Fabian Lüpke vom CCC: “Nach derzeitigem Stand fallen mit der SSI-Technologie beim Onlinedienst staatlich signierte, also garantiert echte, personenbezogene Daten an, welche auch im Nachhinein digital auf ihre Echtheit geprüft werden können. Das ist vor dem Hintergrund diverser Datenabflüsse bei Onlinediensten in den vergangenen Jahren ein erhebliches Risiko, weil es die Daten sehr viel wertvoller macht, schließlich sind sie garantiert echt. Für das Problem der Empfängerdatenspeicherung gibt es ebenfalls Lösungsansätze, die so genannten Zero-Knowledge-Proofs (ZKP). Die ID Wallet App hat dieses Verfahren nicht implementiert. Während Hersteller gerne mit ZKPs werben, gibt es nur wenige Wallets, die diese Funktionalität tatsächlich unterstützen”[4]Stellungnahme Lüpke.
Prof. Dr. Marian Margraf vom Fachbereich Mathematik und Informatik ID-Management der FU Berlin: “Außerdem halte ich die einseitige Fokussierung auf Blockchain-Technologien für nicht zielführend. SSI sollte technologieoffen erforscht und entwickelt werden. Weitere berechtigte Kritikpunkte an heutigen SSI-Lösungen sind, dass a) keine Sicherheitsbeweise für die verwendeten kryptographischen Protokolle existieren, b) sich Verifier nicht gegenüber Holdern authentisieren müssen, c) Verifier Daten inklusive Zusatzinformationen erhalten, so dass auch gegenüber Dritten nachgewiesen werden kann, dass die Daten echt sind und d) bisher keine technische Lösung für die Umsetzung digitaler Identitäten auf Smartphones existiert, die die sicherheitstechnische Anforderung Gerätebindung (um das Kopieren von digitalen Identitäten zu verhindern) umsetzt, ohne ein eindeutiges Merkmal (einen öffentlichen Schlüssel) zu verwenden, der Verifiern immer übertragen wird”[5]Stellungnahme Margraf.
Prof. Dr. Peter Parycek Kompetenzzentrum Öffentliche IT am Fraunhofer FOKUS: “Self-Sovereign Identity (SSI) ist ein vielversprechendes Konzept im angewandten Forschungsstadium. Aufgrund der grundlegenden Probleme der eID .. und der notwendigen Maßnahmen .. sollte keine hohe Priorität auf SSI gesetzt werden, um die Komplexität nicht weiter zu erhöhen. … Grundsätzlich ist die Datensicherheit von SSI nicht anders zu bewerten als andere Lösungen für Digitale Identitäten. Im Kern setzt das Verfahren auf kryptografische Verfahren, bei denen der private Schlüssel der Nutzer sicher verwahrt werden muss. Auch hier bieten sich die aktuellen technischen Möglichkeiten an, wie Hardware-seitige Verschlüsselung, 2‑Faktor-Verfahren etc. Es ist jedoch klar festzustellen, dass in aktuellen Umsetzungen von SSI den Nutzern zu viel Verantwortung bei der sicheren Verwahrung von kryptografischen Schlüsseln zukommt. Hier müssen noch wesentlich bessere Usability-Konzepte und Backup-Mechanismen entwickelt werden”[6]Stellungnahme Parycek[7]Es ist interessant, dass der Autor eine konträre Position zu der seiner Kollegen vom Fraunhofer-Institut für Angewandte Informationstechnik FIT vertritt. Siehe: Mythbusting Self-Sovereign Identity … Continue reading.
Isabel Skierka vom Digital Society Institute ESMT Berlin: “Wenn SSI/DL/BC Technologien für digitale Identitäten eingesetzt werden sollen, muss geprüft werden, ob sie die damit verbundenen Voraussetzungen der Selbstbestimmtheit auch erfüllen. Dazu gehören auch einschlägige Sicherheits- und Datenschutzeigenschaften. Hier ist offensichtlich noch einiges zu tun (siehe BfDI und BSI – Bewertungen dazu) und es besteht ggf. auch noch Forschungsbedarf. SSI muss zudem nicht mittels Blockchain-Technologien umgesetzt werden”[8]Stellungnahme Skierka.
Fazit
Mit der Grundidee Selbstverwalteter Digitaler Identitäten an sich können sich die Sachverständigen anfreunden. Was die technische Umsetzung betrifft, ist der Tenor fast durchweg negativ. Die enge Kopplung an die Blockchain-Technologie wird infrage gestellt bzw. abgelehnt. Vor allem das Risiko, dass staatlich bzw. hoheitlich beglaubigte Daten in die Hände weniger vertrauenswürdiger Akteure gerät, wird thematisiert. Nach heutigem Stand der Technik deckt die Online-Ausweisfunktion des nPA die Kernanforderungen Selbstverwalteter Digitaler Identitäten bereits ab, ohne dass beglaubigte Daten in die falschen Hände geraten oder zweckentfremdet werden können. Ob sich die Problematik mit der Einführung von Zero-Knowledge-Proof oder Privacy Enhancing Technology lösen lässt, ist Stand heute offen[9]In Mythen und Fakten. Ist Self-Sovereign Identity gefährlich? bringt Hannah Loskamp von Jolocom das kontinuierliche Onboarding ins Spiel: “Das Konzept nennt sich kontinuierliches Onboarding und … Continue reading.
Zuerst erschienen auf Identity Economy
References
| ↑1 | Stellungnahme Kelber |
|---|---|
| ↑2 | Stellungnahme BSI |
| ↑3 | Stellungnahme Kahlo |
| ↑4 | Stellungnahme Lüpke |
| ↑5 | Stellungnahme Margraf |
| ↑6 | Stellungnahme Parycek |
| ↑7 | Es ist interessant, dass der Autor eine konträre Position zu der seiner Kollegen vom Fraunhofer-Institut für Angewandte Informationstechnik FIT vertritt. Siehe: Mythbusting Self-Sovereign Identity (SSI) Diskussionspapier zu selbstbestimmten digitalen Identitäten. Überhaupt zählen einige Fraunhofer-Institute zu den größten Fürsprechern der Blockchain-Technologie hierzulande |
| ↑8 | Stellungnahme Skierka |
| ↑9 | In Mythen und Fakten. Ist Self-Sovereign Identity gefährlich? bringt Hannah Loskamp von Jolocom das kontinuierliche Onboarding ins Spiel: “Das Konzept nennt sich kontinuierliches Onboarding und bedeutet, dass bei jedem Login die Profildaten neu übertragen werden (im Fall von Car Sharing also z.B. meinen relevanten Führerscheindaten, meine IBAN und Rechnungsadresse). Sobald sich der Benutzer abmeldet (und das Auto wieder abgestellt habe) kann der Dienst dessen Daten löschen und behält für sich nur einen individuellen Code, mit dem er den Nutzer oder die Nutzerin beim nächsten Besuch wiedererkennt. Zugegebenermaßen ist man davon abhängig, dass der Dienst diese Daten wirklich löscht, dafür gibt es aber viele Anreize, denn das Risiko eines Hacking Angriffs mit schweren Folgen sinkt enorm. Und nicht zu vergessen, wenn sich bei meinem User etwas ändert (z.B. die Telefonnummer) bekomme ich es durch das Continuous Onboarding in dem Moment mit, in dem er das nächste Mal meinen Service nutzt”.
Weiterhin plädiert sie für ein Trust-Framework. Dabei geben sich die Akteure gemeinsame Regeln und legen Mittel für deren Durchsetzung fest: “In einem SSI Ökosystem kann so beschränkt werden, welche Daten beim User abgefragt werden dürfen und von wem. Der Verifier muss dann klar begründen, was mit diesen Daten geschieht, und ist an das Trust Framework gebunden”. |