Kategorien
Digitale Transformation

Technische Aspekte von selbstsouveräner digitaler Identität (SSI)

Aufbauend auf unserer allgemeinen Einführung zur Nutzung von Digitalen Identitäten, werden wir tiefer in die Materie eintauchen und einen Blick auf den gegenwärtigen Stand von SSI Implementierungen und deren Anwendungsfälle werfen. Zum Zeitpunkt des Schreibens dieses Blog-Posts (Frühjahr 2021) haben mehrere anerkannte Organisationen bereits Vorschläge für Standards der unterschiedlichen Aspekte  selbstsouveräner digitaler Identitäten und deren Anwendungsfällen veröffentlicht. Unter diesen die Vorschläge ‚DID Core‘ und ‚Verifiable Credentials‘, die bereits Basis für alle aktuell maßgeblichen SSI Implementierungen sind.

Um zu verstehen wie diese funktionieren, lassen Sie uns zunächst unser Wissen über einige technische Begriffe und Prinzipien auffrischen, die im Feld der digitalen Identitäten genutzt werden.

Vorüberlegungen

Hinsichtlich der Sicherheit gibt es zwei Aspekte, die zu bedenken sind. Zum ersten die Kommunikation wischen den Geräten, die für SSI Implementierungen genutzt werden. Zum zweiten die SSI Prozesse selbst.

Ein zeitgemäßer Standard für sichere Kommunikation sollte von Verbindungsaufbauprozeduren (sog. ‚Handshakes‘) Gebrauch machen die TLS 1.3 (Transport Layer Security) entsprechen. Solche Handshakes sollten außerdem ‚Perfect forward secrecy‘ bereitstellen.

Für die Prozesse selbstsouveräner digitaler Identitäten wird asymmetrische Verschlüsselung, im Besonderen der Prozess des ‚Signierens‘, benutzt. Für diesen Prozess werden zwei Datenblöcke erstellt, die „Schlüssel“ genannt werden. Einer davon wird als ‚öffentlicher Schlüssel‘ beschrieben, der andere als ‚privater Schlüssel‘. Mit unserem öffentlichen Schlüssel und einem standardisierten Algorithmus kann man beliebige Daten so verschlüsseln, dass sie nur mit unserem privaten Schlüssel zu entschlüsseln sind. Das Verfahren wird als asymmetrisch bezeichnet, da der Schlüssel, der verschlüsselt, den Vorgang nicht umkehren kann. Zusätzlich dazu können wir unseren privaten Schlüssel und einen Algorithmus nutzen um Daten zu „unterschreiben“ (signieren). Jede Person kann mit unserem öffentlichen Schlüssel gegenprüfen, dass die Daten mit unserem privaten Schlüssel unterschrieben wurden.

Dezentrale Identifier (DID)

„Dezentralisierte Identifier“ sind der Kern der digitalen Identitäten und damit der selbstsouveränen Identitäten. Sie funktionieren als Zeiger oder Adressen um Identitätsdokumente zu finden. Diese Identitätsdokumente sind weder von einer oder wenigen Autoritäten ausgegeben noch werden sie an einem Ort zentral gespeichert. Daher ist das System dezentralisiert.

Auf technischer Ebene sieht eine DID wie folgt aus:

did:example:123456789abcdefghi

Es ist dabei eine Zusammenstellung aus drei, mit Doppelpunkt getrennten, Teilen. Damit folgt es den Regeln für ‚Uniform Resource Locators‘ (URL), so wie auch Web-Adressen, die man in den Browser einträgt. Der erste Teil (did) gibt an, dass die Zeichenkette als DID zu interpretieren ist. Der zweite Teil (example) benennt die ‚DID method‘. Der letzte Teil (123456789abcdefghi) ist ein einzigartiger Bezeichner innerhalb der ‚DID method‘. Das World Wide Web Consortium (W3C) hat zu diesem Thema Designentwürfe herausgegeben, deren zentraler Bestandteil der ‚DID Core‘-Draft ist.

Es gibt verschiedenste Wege mit DIDs umzugehen. Diese werden als ‚DID method‘ beschrieben. Jede ‚DID method‘ muss zumindest öffentlich beschreiben, wie CRUD Operationen innerhalb ihres Geltungsbereiches durchgeführt werden. CRUD bezeichnet dabei das Erstellen (Create), Lesen (Read), Ändern (Update) und Löschen (Delete). Da die ‚DID methods‘ öffentlich beschrieben sein müssen, sollte jeder Entwickler in der Lage sein eine ‚DID method‘ zu implementieren und so seiner Software erlauben mit DIDs aus dieser ‚DID method‘ umzugehen. Zusätzlich sind Softwarebibliotheken oft bereits verfügbar.

DID Documents

Eine DID auf dem in der ‚DID method‘ beschriebenen Weg zu lesen bedeutet, das ‚DID Document‘ zu laden. Wenn DIDs der Kern von digitalen Identitäten im allgemeinen sind, ist das ‚DID Document‘ der Kern einer spezifischen dezentralen digitalen Identität. Von einem technischen Standpunkt ist das ‚DID Document‘ eine Datei die in das Datenmodell für digitale Identitäten überführt werden kann um umgekehrt. JSON, JSON-LD und CBOR sind Dateiformate die explizit als mögliche Formate für ‚DID Documets‘ benannt werden. Doch jedes Format das verlustfrei in Datenstrukturen und zurück konvertiert werden kann wäre möglich, wie z.B. auch XML oder YAML.

Das ‚DID Document‘ beinhaltet alle relevanten Informationen zu der dezentralen digitalen Identität selbst. Das ist zu allererst seine eigene ID, eine Selbstreferenz. Um die Identität in einer sinnvollen Weise zu nutzen fügen wir weitere Informationen hinzu, die im engeren Sinne aber optional sind. Wir fügen z.B. dem ‚DID Document‘ hinzu, welche kryptographischen Schlüssel die digitale Identität für welchen Zweck nutzt. Die Identität kann ein Schlüsselpaar nuten zum sich zu authentifizieren, ein Anderes um verschlüsselte Nachrichten auszutauschen und wieder eine andere für überprüfbare Berechtigungsnachweise. Es kann, und sollte, außerdem festgelegt werden, welche Schlüssel das Recht haben, das ‚DID Document‘ zu verändern und wo sich Endpunkte für bestimmte Dienste befinden (z.B. für Sofortnachrichten oder ‚Push Benachrichtigungen‘).

Es gilt zu beachten, dass zu diesem Punkt im DID Document keine persönlichen Informationen oder Aspekte der physischen Welt enthalten sind. Die Identität ist bis jetzt nur ein Dokument, dass festlegt welche Schlüssel die Identität für welchen Zweck nutzt. Jede Information die nicht im ‚DID Document‘ steht, sollte von einer Implementierung nicht als wahr angenommen werden.

Überprüfbare Berechtigungsnachweise

Überprüfbare Berechtigungsnachweise bringen dann die eigentliche Substanz zur dezentralen digitalen Identität. Es werden hier Information mit der Identität verknüpft für die gebürgt wird, sprich die von einer angemessenen Autorität über diese Information „unterschrieben“ sind. Eine angemessene Regierungs-/Verwaltungsstelle könnte z.B. überprüfbare Berechtigungsnachweise über unseren Namen, unsere Adresse und das Geburtsdatum bereitstellen. Aber überprüfbare Berechtigungsnachweise müssen können viel weiter gehen.

Jeder überprüfbare Berechtigungsnachweis hat einen Halter (holder), ein Subjekt (subject), einen Anspruch (claim) und einen Bestätiger (verifier). Somit könnte, z.B., meine (Halter) digitale Identität einen überprüfbaren Berechtigungsnachweis enthalten, dass mein Kind (Subjekt) die deutsche Staatsbürgerschaft (Anspruch) hat und dies wäre durch den Staat (Bestätiger) verifiziert.

Es gibt hierfür bereits de-facto Standards: Das World Wide Web Consortium (W3C) hat Designvorschläge zu Datenmodel, Impementierungsvorgaben und möglichen Anwendungsfällen für überprüfbare Berechtigungsnachweise herausgegeben. Der Entwurf für Anwendungsfälle beinhaltet standardisierte Datenmodelle für überprüfbare Berechtigungsnachweise für verschiedenste Anwendungsfälle von Schulzeugnissen über Versicherungsfallabwicklung und Medikamentenrezepte bis zu Arbeitsnachweisen.

Selbstsouveräne Identität

Aber ist das selbstsouveräne digitale Identität? Noch nicht ganz. Die Kernidee ist, dass die Informationen meiner Identität durch mich selbst kontrolliert werden. Zu diesem Zweck erlauben es Implementierungen von überprüfbare Berechtigungsnachweisen den Informationsfluss selbst zu steuern.

Wenn wir einen Berechtigungsnachweis über unsere Staatsbürgerschaft haben, bestätigt durch eine Behörde, würde sie all die Informationen beinhalten, die auf unserem Pass oder Personalausweis sind. Aber, wir müssten nicht all diese Informationen weitergeben, wenn eine andere Person unseren Berechtigungsnachweis prüft. Für einen Online-Shop wäre z.B. nur Name, Adresse, Alter und ausstellende Behörde interessant. Das exakte Geburtsdatum, Geburtsort und Foto sind es nicht. Statt unseren Personalausweis ganz auszuhändigen enthüllen wir nur die nötigen Informationen.

Algorithmen die ‚Zero-Knowledge Proofs‘ genannt werden können außerdem genutzt werden, um zu garantieren, dass eine Behauptung wahr ist, ohne das weiterführende Informationen über das Thema nötig sind.

Ausblick

Mit dem gegenwärtigen Stand an Standartisierungsentwürfen gibt es eine solide technische Basis für kompatible Softwareimplementierungen. Zusätzliche Funktionalitäten wie ein Decentralized Key Management System (DKMS) oder ein Authentication Module (DID Auth) werden das Ökosystem der dezentralen digitalen Identitäten vervollständigen und die Technologie alltagstauglich machen. Mit Regierungen die sich an Projekten in diesem Feld beteiligen oder diese finanzieren werden wir in Zukunft eine steigende Anzahl an Anwendungen von DIDs sehen.

Senior Consultant

Heinrich Krebs ist Senior Berater bei ifb. Er arbeitet seit 2015 für ifb und ist Mitglied in der Arbeitsgruppe für Blockchain-Technologien. Hier beschäftigt er sich mit den Themen "Selbstbestimmte digitale Identitäten" und Kryptographie.