Self-Sovereign-Identities (SSI) – Das kleine 1×1 der sicheren digitalen Identitäten

Die monatlich erscheinende Blogserie „Das kleine 1×1 der sicheren digitalen Identitäten“ präsentiert Themenschwerpunkte rund um die Erzeugung, Verwaltung und den Einsatz digitaler Identitäten. In diesem Monat wird es um die unterschiedlichen Bestandteile von SSI-Identitätsmanagement-Systeme gehen. Wir erklären, was die Begriffe „Decentralized Identifier“, „Verifiable Credential“, „Verifiable Presentations“, „Zero-Knowledge-Proof“ und „Distributed-Ledger-Technologie“ bedeuten, wie sie funktionieren und wie sie im Zusammenspiel die Realisierung von SSI-Ökosystemen ermöglichen.

  1. SSI-Identitätsmanagementsysteme basieren im Wesentlichen auf folgenden Bestandteilen:
    • dezentrale Identifikatoren für beliebige Entitäten,
    • kryptografisch gesicherte Datenformate zur Beschreibung der Identitätsattribute,
    • ein Protokoll zur Peer-to-Peer Kommunikation zwischen den beteiligten Akteuren,
    • ein vertrauenswürdiges dezentrales Datenregister,
    • Wallets.
    Diese Bestandteile unterliegen verschiedenen Standardisierungsaktivitäten, z.B. in Form von „Decentralized Identifiers“ und „Verifiable Credentials“ im World Wide Web Consortium (W3C) und in Form von „DIDcomm“ in der De-centralized Identity Foundation (DIF).
  2. Eine Decentralized Identifier (DID) ist eine einzigartige Uniform Resource Identifier (URI) und identifiziert dauerhaft ein durch ihren Besitzer (engl. Controller) gewähltes Subjekt (z. B. natürliche Person, Organisation, Maschine usw.). Sie referenziert (vergleichbar einer URL) ein sogenanntes DID-Document, in dem insbesondere Informationen zu kryptografischen Verifizierungsmethoden und Public Keys als Verifizierungsschlüssel sowie zu Service Endpoints enthalten sind, die es dem DID-Besitzer ermöglichen, die Kontrolle über die DID nachzuweisen.
  3. Zu einem Subjekt kann es mehrere DIDs geben.
  4. DID-Methoden definieren für ein SSI-Identitätsmanagementsystem, wie
    • eine DID erstellt,
    • zu einer DID ein DID-Document referenziert,
    • eine DID aktualisiert und
    • eine DID widerrufen bzw. gesperrt werden kann.
  5. Aufgrund der Vielzahl von DID Methoden (in verschiedenen SSI-Identitätsmanagementsystemen) ist auf Implementierungsebene keine Interoperabilität bezüglich der Auflösung eines DIDs zu einem DID-Dokument – also der Leseoperation der jeweiligen DID-Methoden – gewährleistet. Zur Lösung dieses Problems ist von der Decentralized Identity Foundation (DIF) ein sogenannter „Universal Resolver“ entwickelt worden. Dieser arbeitet auf der Basis von Treibern und kann für die unterstützten DID-Methoden entsprechende DID-Dokumente bei Eingabe eines DIDs zurückgeben.
  6. Mit Hilfe eines Verifiable Credential (VC) lassen sich Behauptungen bezüglich bestimmter Subjekte aufstellen, wobei die Integrität des Inhalts, des Herausgebers des VCs und des Subjekts kryptografisch sicher nachgewiesen werden können. (vgl. Punkt 90)
  7. Ein VC besteht aus drei Komponenten:
    • Eine oder mehrere Behauptungen (engl. claims) bezüglich des Subjekts des VCs bilden die erste Komponente eines VCs.
    • Die zweite Komponente enthält Metadaten mit Herausgeber, Typ, Datum und weiteren Datenfeldern, welche das VC beschreiben. Diese können vom Herausgeber signiert sein, um ein erhöhtes Maß an Vertrauen zu gewährleisten. Sowohl der Herausgeber als auch das Subjekt des VCs können mithilfe von DIDs referenziert werden. Dies erlaubt eine eindeutige Identifikation dieser Rollen.
    • Die dritte Komponente umfasst schließlich einen digitalen Beweis zu den beiden ersten. Dieser Beweis stellt u.a. sicher, dass die zugehörige(n) Behauptung(en) und Metadaten tatsächlich vom Herausgeber des VCs stammen. In der Regel werden hierfür gängige Signaturverfahren verwendet.
  8. In der Regel handelt es sich beim Subjekt eines VCs auch um den Inhaber, welcher die Kontrolle über das VC ausübt und es in Interaktionen verwendet.
  9. Um die Behauptungen innerhalb des VCs in Interaktionen geltend zu machen, muss die Akzeptanzstelle diese mit geeigneten Mitteln überprüfen. Es wird davon ausgegangen, dass die Akzeptanzstelle dem Herausgeber des VCs und damit der Korrektheit seiner Behauptungen gegenüber Vertrauen aufbringt.
  10. Bei der Prüfung erhält die Akzeptanzstelle durch den Inhaber nicht das VC selbst, sondern eine als „Verifiable Presentation“ bezeichnete Datenstruktur, welche die für die Interaktion benötigten Daten aus einem oder mehreren verschiedenen VCs enthält. Eine Verifiable Presentation beinhaltet neben den ursprünglichen VCs weitere Metadaten wie Nutzungsbedingungen und einen weiteren Beweis, welcher die Datenstruktur absichert. Ein Spezialfall dieses Beweises ist der sogenannte „Zero-Knowledge-Proof“. Dieser ermöglicht den mathematisch-abgesicherten Nachweis über den Besitz bestimmter Informationen, ohne die zugrundeliegenden Daten selbst vorweisen zu müssen.
  11. Die DIF arbeitet unter der Bezeichnung „DIDComm Messaging“ an der Erstellung eines Standards für ein Kommunikationsprotokoll zwischen allen Akteuren von SSI. In den Mechanismen des Nachrichtenversands bei DIDcomm gibt es Unterschiede zur herkömmlichen Kommunikation im Web. Der Austausch von Nachrichten bei DIDcomm Messaging basiert auf Asynchronität und Simplexbetrieb. Dies bedeutet, dass eine Antwortnachricht weder sofort noch über denselben Kanal wie die Ausgangsnachricht übermittelt werden muss.
  12. Das DIDComm-Protokoll (vgl. Punkt 75) ist so konzipiert, dass es
    • Sicher,
    • Privat,
    • Interoperabel,
    • Transport-agnostisch und
    • Erweiterbar ist.
    Sicherheit und Privatheit ergeben sich aus der durch das Protokoll gegebenen Unterstützung für heterachische (Peer-to-Peer-) Verbindungen und dem dezentralen Design sowie der Verwendung von Ende-zu-Ende-Verschlüsselung.
  13. Zur Registrierung, Aktualisierung, Widerrufung und Beschreibung von Verifizierungsverfahren und Schemata von Decentralized Identifiers und Verifiable Credentials werden vertrauenswürdige dezentrale Datenregister verwendet. Diese dienen als Speicher für
    • die öffentliche DID des Herausgebers,
    • die Informationen zu Verifizierungsmechanismen zur Überprüfung der VCs,
    • die VC-Schemata zur Beschreibung der VC-Attribute
    • und die Gültigkeitsdefinitionen.
    Hierbei können neben Blockchains oder DLTS auch andere unveränderbare Datenspeicher eingesetzt werden.
  14. Oftmals wird der Eindruck vermittelt, dass vertrauenswürdige dezentrale Datenregister zwangsweise auf Basis von Distributed- Ledger-Technologien (DLT) wie Blockchains realisiert werden müssen und somit DLT ein notwendiger Bestandteil von SSI-Identitätsmanagementsystemen seien. Tatsächlich stellen DLT aber nur eine Möglichkeit der Umsetzung dar und werden zum Beispiel für reine Peer-to-Peer Verbindungen nicht benötigt, da in diesem Fall die Verwaltung und der Austausch der DIDs und VCs direkt von den Wallets der Kommunikationspartner vorgenommen werden.
  15. Ein vertrauenswürdiges dezentrales Datenregister kann als Vertrauensanker für die Akzeptanzstellen dienen, der notwendig wird, sobald VCs, die von Dritten herausgegeben wurden, verifiziert werden müssen. Damit ein hohes Vertrauensniveau erreicht werden kann, müssen dezentrale Datenregister eine hohe Verfügbarkeit und Skalierbarkeit vorweisen und zudem resistent gegen Manipulationsversuche sein. Daher stellen DLT aktuell eine häufig verwendete technologische Implementierung für ein vertrauenswürdiges Datenregister dar und werden dementsprechend oft in Verbindung mit SSI-Identitätsmanagementsystemen genutzt.
  16. Der Eigentümer eines SSI-Identitätsmanagementsystems muss nicht notwendigerweise das dezentrale Datenregister, auf der das System aufgebaut ist, besitzen. Tatsächlich lässt sich ein SSI-Identitätsmanagementsystem einsetzen, ohne das zugrunde liegende dezentrale Datenregister, das verwendet wird, aufbauen oder warten zu müssen, sofern dieses den Bedürfnissen des SSI-Identitätsmanagementsystem entspricht.
  17. Eine Wallet, je nach Realisierung auch Wallet-Anwendung oder Wallet-App genannt speichert und verwaltet alle identitätsbezogenen Daten (also insbesondere private Schlüssel und Verifiable Credentials), die sich im Besitz und unter Kontrolle des Inhabers befinden.  Außerdem interagiert die Wallet mit anderen Akteuren, z.B. um den Inhaber bzw. das Subjekt für neue Dienste anzumelden und Anmeldedaten zu erhalten.
  18. Eine Wallet ist häufig als Wallet-App auf einem Smartphone implementiert, kann sich aber auch als Wallet-Anwendung auf anderen Endgeräten, wie z. B. einem Desktop-Computer, befinden. Wallets können auch auf einer Cloud-Computing-Infrastruktur als Cloud-Wallets liegen oder von Dritten als sogenannte Custodial Wallets bereitgestellt werden. Bei Letzteren überlässt der Inhaber die Kontrolle über die privaten Schlüssel einer in seinen Augen vertrauenswürdigen dritten Instanz. Custodial Wallets bilden dabei einen stabilen, stets verfügbaren Endpunkt für andere Dienste und können auch zur Wiederherstellung von Anmeldeinformationen verwendet werden, wenn eine Wallet auf einem Endgerät nicht mehr verfügbar ist. Schließlich dienen spezifische Hardware-Wallets (USB-Sticks, Smartcards, etc.) und Papier-Wallets (privater Schlüssel und/oder Seed-Phrasen und/oder QR-Codes, die auf Papier ausgedruckt werden) als alternative Optionen zur Sicherung und Wiederherstellung privater Schlüssel.
  19. Das Zusammenspiel der Standards DID, VC, VP und DIDcomm ermöglicht die Realisierung von SSI-Implementierungen:
    • Alle identitätsbezogenen Informationen, wie Name, Besitz, Alter, etc., werden in Verifiable Credentials gespeichert. Diese Dokumente kann jeder Inhaber nach der Ausstellung durch den Herausgeber in ein Wallet speichern.
    • Die Wallet interagiert mit anderen Akteuren.
    • Der Inhaber kann mit einer Reihe von VCs eine Beweiskette aufbauen, um sich damit zu identifizieren. Für die Identifizierung nutzt er dazu geeignete Verifiable Presentations.
    • Die Vertrauenswürdigkeit hängt davon ab, welches Maß an Vertrauen die Akzeptanzstelle dem Herausgeber entgegenbringt.
    • Das Problem, wie eine Akzeptanzstelle einen Nachweis verifizieren kann, wird durch die DIDs mit den zugehörigen DID-Dokumenten gelöst. DIDs dienen zum einen zur Identifizierung einer Identität und fungieren zum anderen als Ressourcenbezeichner für die angesprochenen DID-Dokumente. Beide sind unabhängig von ID-Providern und unterliegen der vollen Kontrolle des Herausgebers.
    • Das dezentrale Datenregister stellt als unveränderbarer, d.h. integritätsgeschützter Datenspeicher DIDs, Informationen zum Verifizierungsmechanismen zur Überprüfung der VCs, den VC-Schemata zur Beschreibung der VC-Attribute, etc. bereit.
  20. Durch die Nutzung von DIDs und die Beschreibung der Besitztümer, Authentifizierungs- und Autorisierungsdaten in Verifiable Credentials ist eine Prüfung ohne Zwischenhändler möglich. Über eine dezentrale, öffentlich verteilte Infrastruktur (einer sog. Decentralized Public-Key Infrastructure, DPKI) kann also der Nachweis von VCs erfragt werden und die „Übergabe“ von Identitätsattributen erfolgen.
  21. Neben der eigentlichen Infrastruktur von SSI-Identitätsmanagementsystemen auf Basis des vertrauenswürdigen dezentralen Datenregisters bildet sich auch ein ganzes Ökosystem um die Wallet Apps und Softwareagenten, welche Interoperabilität der Netzwerke ermöglichen sollen.
    • Wallets: Apps (für Smartphones), in welchen Private Keys und VCs vom Nutzer „sicher“ abgelegt, verwaltet und genutzt werden können (vgl. Punkt 56, 62, 65, 78, 81ff).
    • Universal resolver: Spezifikation und Implementierung eines treiberbasierten Frameworks, das die Auflösung eines DIDs zu einem DID-Dokument für verschiedene SSI-Identitätsmanagementsysteme ermöglicht, durch DIF (vgl. Punkt 68).
    • Universal registrar: Spezifikation und Implementierung eines treiberbasierten Frameworks, das die Erstellung/Aktualisierung/Deaktivierung von DIDs für verschiedene SSI-Identitätsmanagementsysteme ermöglicht, durch DIF.

In der Ausgabe des kommenden Monats behandeln wir die unterschiedlichen Sicherheitsaspekte von SSI-Identitätsmanagementsystemen.