Untitled
Dieses Dokument ist Teil der Anfrage „ID Wallet des Bundeskanzleramts, ein Projekt der Bundesregierung: Datenschutzrechtliche Aspekte“
Klarungsbedarf BFdI— Fragen vor 30.03.21 KE Hinweis: Die MasterID wurde in “Basis-ID” umbenannt, diese Änderung haben wir hier im Sinne der Konsistenz vorgenommen. Lich RE vielen Dank für die Unterlagen. Die vorliegenden Dokumente haben einen direkten Bezug zum Pilotprojekt "Hotel-Check- In". Ich verweise hier erneut auf die Zuständigkeit der Landesdatenschutzbehörden für die Hotelunternehmen. Meine Fragen und Anmerkungen zu den Arbeitsständen fokussieren daher auf den allgemeinen Teil des Projekts der Bundesregierung, sowie der Basis-ID, die mithilfe der Bundesdruckerei (BDR) aus dem Personalausweis abgeleitet werden soll: Allgemeines Ich habe Ihre Ausführungen so verstanden, dass die Prüfung, ob ein Attributsatz (VC) "echt" ist, lokal abläuft über eine Überprüfung der Signatur. Über das verteilte Netzwerk wird nur der Public Key des Signierenden bezogen. Diese Signaturprüfung folgt einem Zero- Knowledge-Schema. Ist das korrekt? Antwort: Korrekt. Des weiteren wird über das Netzwerk geprüft, ob das Credential widerrufen (revoked) wurde. Wenn ja: Wieso nutzen Sie dann nicht eine herkömmliche Public-Key-Infrastruktur? Antwort: Es solle keine Abhängigkeit entstehen zu zentralen Registern und zentralen CAs inkl. Zentraler Schlüsselverwaltung. Jede Identität stellt seine eigene “Root Authority” mit eigenem DID-Record. Nutzer verwalten selbst ihren privaten Schlüssel. Aktuell gibt es keine PKI Lösung, die Zero-Knowlege-Proof-basierte Credentials unterstützt. Es ist aber davon auszugehen, dass in Zukunft hybride Lösungen entstehen und die Schlüssel aus einer PKI kommen könnten. Nach welchem Verfahren läuft der Zero-Knowledge-Proof? Antwort:Camenisch-Lysyanskaya Signaturen Gibt es hier einen Standard, dem Sie folgen? Antwort: Wir orientieren uns an Ergebnissen und Best Practices aus den verschiedenen Arbeitsgruppen im SSI Umfeld ein, die daran arbeiten Standards zu definieren, aber festgelegte de-facto Standards gibt es in dem Umfeld noch nicht. Weiterhin lese ich die Dokumente so, dass Sie davon ausgehen, dass auf dem Ledger keine
personenbezogenen Daten verarbeitet werden, die zur Echtheitsprüfung der VC benötigt werden. Der Prozess zum Sperren findet aber mit Daten vom Ledger statt, deren Personenbezug nicht auszuschließen ist. Leider war es mir nicht möglich, diesen Prozess und seine Funktionsweise (Tails File und Accumulator) nachzuvollziehen. Hier bitte ich um eine gesonderte Erklärung des Sperrprozesses von der Anlage des VC über den Proof-of-Non- Revocation bis zur Sperrung des VC. Antwort: Das SSI-Ökosystem hat Standardmethoden für den Rückruf mit (Tails Files, Revocation Registry, Kryptografischer Akkumulator) definiert und implementiert. Nach erfolgreicher Zuordnung wird über die Standardverfahren von Hyperledger Indy (Tails Files und Sperrindex) die Sperrung vorgenommen. Dabei spielt der Hash keine Rolle mehr, wird also insbesondere in keiner Form veröffentlicht oder auf den Ledger geschrieben. Eine solche, unten beispielhaft abgebildete, Transaktion enthält die Revocation-ID des zurückgerufenen Credentials (hier: 5). Zu jedem Zeitpunkt enthält die auf der Blockchain liegende Revocation Registry die IDs aller zurückgerufenen VCs. Entscheidend ist, dass das Vorzeigen der VCs selbst gegenüber einem Verifier (wie einem Hotel) keine Informationen über die dem VC zugrunde liegende Revocation-ID beinhaltet und daher der Stand des Akkumulators selbst kein personenbezogenes Datum darstellt, solange die Nutzer*Innen nicht die Inhalte ihrer Credentials mit Hilfsmitteln aus der Wallet-App auslesen und an Dritte preisgeben (die Revocation ID ist selbst für die Nutzer*Innen in der Wallet-App nicht direkt ersichtlich). Der kryptographische Akkumulator ist dabei ein Ergebnis einer Multiplikation unterschiedlicher Faktoren?. Zu jeder Credential Definition wird ein Akkumulator auf dem Ledger veröffentlicht und ein zugehöriges Tails File auf einer anderen Infrastruktur, das die Faktoren zur Errechnung des Akkumulators beinhaltet, von denen jeder einem Credential, das nach der Definition ausgestellt wird, zugeordnet ist. Der Akkumulator wird regelmäßig verändert, damit ungültige Credentials nicht mehr als Faktoren beitragen. Mittels eines Beweises, dass der zum nachzuweisenden Credential zugeordnete Faktor noch zu dem Credential beiträgt, wird dessen Gültigkeit aufgezeigt. Die folgende Abbildung zeigt den Ablauf des Erstellen einer Credential-Definition inkl. Revocation Registry und die Funktionsweise des Accumulator.
Funktionsweise des Accumulator Unternehmen Inhaber Blockchaun Tais Server Überprüfer r I T T 1 | | I | | | Credential Definition I l | T l | whs l | lg... Credental Definition D _______. | | | l | | Tas File AR. | T | URL | | Inne RuNausuinannaaass Hasaaaans | | l | Revocation Registry I | T l | ! l | Revocation Registry ID | | --- nn nn nenn nn nn nun. . | l | | Akkumulator I | t Tr l | | l l | Gredential | | | | I I I | Request Tails File ' | l | | sc Talls Fiie l | | l I | | lAilia Akku : ulator |x | l l Aldcumukator & Wiäness Delta ! A000... ie |l 14 2 9) Proof Request 1 l | I l | l | l | l I l I I l | Proof l I T | l | l Eine Darstellung des technischen und organisatorischen Gesamtsystems mit allen Beteiligten, ihren Rollen und den DS-rechtlichen Verantwortlichkeiten wäre wünschenswert. Antwort: Das System besteht aus den folgenden Entitäten: 1. Verifiable Data Registry: Ein öffentliches, genehmigungspflichtiges Blockchain-Netzwerk (Hyperledger Indy bestehend aus den Indy Nodes) zur Speicherung von öffentlichem Schlüsselmaterial und dezentrale Prüfinfrastruktur, betrieben von authentisierten und autorisierten Knotenbetreibern 2. Issuer: Der Issuer stellt Identitäten in Form von Credentials an den Holder aus. Issuer sind derzeit die Bundesdruckerei (für die Basis-ID) sowie die Deutsche Bahn, Bosch und die BWI für die Company-ID. 3. Holder: Die Nutzer*innen erhalten die Credentials vom Issuer, speichern diese in ihrer Wallet und können diese gegenüber Verifiern präsentieren
4. Verifier: Der Verfier ist der Empfänger von Credentials und den darin enthaltenen Identitätsattributen (“Claims") oder logischen Aussagen aus diesen und stößt den Verfizierungsprozess über das Netzwerk an, um die Integrität, Authentizität der Daten zu prüfen. An dem aktuellen Piloten “Hotel-Checkin” sind die folgenden Entitäten beteiligt: Die Bundesdruckerei als Herausgeber der Basis-ID vr ww nn Deutsche Bahn, Bosch und die BWI als Herausgeber der Company-ID Hotels als Verifizierer der IDs Nutzer*innen (Unternehmenangestellte) mit ihrer Wallet-App auf einem Smartphone BWI GmbH, Deutsche Bahn AG, Bundesdruckerei GmbH, IBM Deutschland GmbH, esatus AG als Knotenbetreiber, die das Blockchain-Netzwerk zur Verfügung stellen Weitere beteiligte technische Komponenten im System beinhalten: Wallet-App: zum Speichern, Freigeben und Übertragen von Credentials, betrieben von esatus Aries Agents, Software-Agenten, die SSI-Funktionalitäten zum Austausch mit anderen Agenten und zur Kommunikation für das Verifiable Data Registry (Hyperledger Indy) zur Verfügung stellen und mit der Wallet-App kommunizieren zu können, betrieben von allen Beteiligten Tails-Server für jeden Issuer, welche die für Revocation grundlegenden Tails-Files öffentlich zum Download zur Verfügung stellen, betrieben von den Issuern Mediator-Service, der Mediator-Service agiert als Notifizierungsdienst und Inbox für eingehende SSI-bezogene DIDComm-Nachrichten für Mobile Endgeräte (ausgehende Kommunikation erfolgt direkt mit den entsprechenden Endpunkten). Dort werden zusätzlich verpackte Nachrichten in der jeweils individuellen Inbox abgelegt. Nach erhalt einer solchen Nachricht sendet der Mediator-Service zudem über einen Azure Notification Hub eine Nachricht an die Endgeräte. Diese Nachricht informiert lediglich über den Erhalt einer neuen Nachricht und gibt der Wallet Bescheid über eine eingehende Kommunikation ohne Verweis auf den Inhalt oder den Inhalt selbst. Der Mediator-Service selbst ist nicht in der Lage die Nachrichten zu lesen, die Entschlüsselung ist nur mit den, auf den Endgeräten liegenden Schlüsseln für die jeweilige Verbindung, von welcher die Nachricht versandt wurde, möglich. Dieser wird von esatus betrieben.
(Basis-ID elD Server Chock-i Wallet-App $51 Issuer 2 Arles Agent Hotel Integration Arles Agent Mediation Agent App (ACA-PY) Controller Service {H} (ACA-PY) Hotel Dataßase Backend Talls Server | - Indy Nodes Idiv. Betreiber) Company: Talls Server n L Frontend a Legende Integration Company Arles Agent Entwicklung m Projekt Service (C] Comtrolker lACA-PY) Open Source Kompumente Proprietäre Systeme C ompany . D a Backend Handreichung zum Datenschutzkonzept Im Kapitel 1.3 formulieren Sie sowohl eine Beziehung der Akteure mit Kennzeichen einer gemeinsamen Verantwortung als auch eine Auftragsverarbeitung. Für beide Formen fordert die DSGVO Dokumente, die das Verhältnis der Beteiligten festlegen (Vereinbarung nach Art. 26 DSGVO bzw. Vertrag nach Art. 28 DSGVO). Sind diese Dokumente bereits erstellt? Diese sind ist unter anderem für die Wahrung der Betroffenenrechte von entscheidender Bedeutung. Antwort: Die Dokumente wurden noch nicht erstellt, das zunächst das grundsätzliche Einverständnis des BfDI zu dieser Betrachtungsweise eingeholt werden sollte. - In der Tabelle unter 1.5 bezeichnen Sie zwei Datenkategorien jeweils als indirekt personenbezogen. Gehen Sie hier davon aus, dass personenbezogene Daten im Sinne der DSGVO verarbeitet werden oder nicht? Eine eigene Bewertung ist mir leider mit den gegebenen Informationen nicht möglich (s.o.) Antwort: Der Personenbezug der Daten ist in sofern noch gegeben, als dass in ihnen zur Gültigkeitsprüfung eines personenbezogenen Zertifikates die Aussage codiert ist, ob das Zertifikat gültig ist. Außerhalb der Gültigkeitsprüfung, zu der auch ein Geheimnis erforderlich ist, das nicht zentral abgelegt ist, ist es aber nicht möglich, alleine aus den Daten auf ein Merkmal einer Person, auch nicht auf die Zertifikatsgültigkeit, zu schließen. Damit haben die Daten nicht die Kritikalität personenbezogener Daten, sie bilden aber gemeinsam mit anderen Daten einen Status des Betroffenen ab. Ein “Recht auf Berichtigung” am Zertifikatsstatus z.B. könnte diese Daten also tangieren. In Ihrer Ausführung in 2.1 zur Rechtmäßigkeit der Verarbeitung, zählen Sie drei Verarbeitungen auf (Speicherung in Wallet, Speicherung Status der Basis-ID sowie
Verarbeitungen zum Meldeschein). An dieser Stelle fehlen mindestens analoge Angaben zur Speicherung sonstiger VCs sowie zum Vorhalten einer Liste aller ausgegebenen Basis-IDs durch den Sperrverantwortlichen (meine Annahme: BDR; s.u.). Antwort: Zur Durchsetzung der Sperrung wird keine Liste der ausgestellten Basis-IDs vorgehalten, sondern es wird der Hash der restrictedID für die ausgestellten Basis-IDs in der Sperrdatenbank der BDR gespeichert. Es werden keine personenbezogenen Daten gespeichert (siehe unten). Zur Speicherung des Status der Basis-ID geben Sie als Grundlage die gesetzlichen Vorgaben zum Sicherheitsniveau an. Stellen Sie damit wie in der Tabelle zu den Löschfristen auf 829 Absatz 5 Satz 2 Ziffer 3BMG ab? Antwort: Ja, denn denn auch die dort erwähnten Credentials können gültig oder gesperrt sein. Abhängig vom Ergebnis der Fragestellung zum Personenbezug der auf dem Ledger verarbeiteten Daten (s.o.), halte ich eine genau juristische Prüfung dieser Rechtsgrundlage für erforderlich. Die benannte Norm definiert den Prozess zur Feststellung eines ausreichenden Sicherheitsniveaus. Einen Erlaubnistatbestand für die Verarbeitung personenbezogener Daten zur Herstellung dieses Niveau kann ich nicht erkennen. Antwort: Für die Basis-ID erfolgt keine Speicherung personenbezogender Daten auf dem Ledger. Die Einwilligung zur Verarbeitung personenbezogener Daten erfolgt durch die Nutzer*in im Ausstellprozess der Basis-ID. Zusätzlich erwähnen Sie die "Zustimmung" des Nutzers: Meinen Sie hiermit eine Einwilligung? Antwort: ja Gegenüber wem wird diese Einwilligung erteilt? Antwort: Im Ausstellungsprozess der Basis-ID wird die Einwilligung gegenüber der Bundesdruckerei erteilt. Beim Proof-Request wird die Einwilligung gegenüber dem Hotel erteilt. Wie können die Bedingungen an Einwilligungen gemäß Art. 7 DSGVO insbesondere die Informiertheit und das Recht auf Widerruf erfüllt werden? Antwort: Im Ausstellungsprozess der Basis-ID werden die Nutzer*in entsprechend informiert und müssen ihre Einwilligung zur Verarbeitung von personenbezogen Daten erteilen. Kann am System auch ohne die Basis-ID teilgenommen werden? Antwort: Ohne die Basis-ID ist der Hotel-Check-In innerhalb des Pilotvorhabens nicht möglich. Ein Hotel-Check-In ist alternativ auf dem bisherigen Weg, durch Nutzung des
Personalausweises möglich. Zur Master-ID: - Sie schreiben "Der Prozess des Prüfens der Informationen aus der elD und das entsprechende Ausstellen des Basis-ID VCs durch die Bundesdruckerei genügt aufgrund der Erfahrungen der Bundesdruckerei und der Integration des Services in die bestehenden Kompetenzen der Bundesdruckerei hohen Sicherheitsanforderungen; dabei wird eine bestehende kryptographische Vertrauenskette (elD) auf eine neue Vertrauenskette (Credential Definition der Basis-ID in der Blockchain und Signatur durch die Bundesdruckerei) übertragen". Welches Vertrauensniveau streben Sie durch diesen Übertrag an? Antwort: Durch die vielfältige Nutzung des Ökosystem lohnt es sich, ein möglichst hohes Vertrauensniveau anzustreben und dadurch viele weitere, wertvolle Anwendungsfälle zu ermöglichen. - Der Basis-ID wird durch ihre formale Definition eine besondere Bedeutung als "Personalausweisersatz" zugewiesen. Könnten in einem zukünftigen System mit mehr Akteuren nicht auch konkurrierende Basis-IDs-Schemata kursieren? Anders gefragt: Gibt es einen technischen Mechanismus, der die Basis-ID auszeichnet, oder wird darauf vertraut, dass die "lesenden Stellen" bei Vorgängen, die die Daten des Personalausweises benutzen, wissen, welches Schema sie akzeptieren sollen? Antwort: Die hochwertigen Credential-Schemata werden auf dem Ledger hinterlegt oder z.B. im Bundesanzeiger separat veröffentlicht. Diese werden von den verifizierenden Stellen bezogen. Im Fall von Hotel-Checkin Use-Case werden nur die Credential-Definition (Definiert den Aussteller eines Schemas) der Bundesdruckerei akzeptiert. - Die Eigenschaft der Basis-ID als "Peronalausweisersatz" leiten Sie aus der Erprobungserlaubnis aus 829 BMG ab. Das Identitätsökosystem soll aberja zukünftig auch für andere Anwendungsfälle Einsatz finden. Werden die Basis-IDs dann zurückgezogen, um eine nachträgliche Zweckänderung zu vermeiden? Antwort: Wir gehen davon aus, dass es für weitere Nutzungsfälle der Basis-ID entsprechende, wenn auch andere Rechtsgrundlagen gibt. Diese werden im Rahmen der weiteren Use Case Entwicklung betrachtet. - Wie stellt die BDR bei Erstellung der Basis-ID sicher, dass die Wallets der Nutzenden unkompromittiert sind? Gerade wenn - wie angedeutet - zukünftig verschiedene Wallets genutzt werden, scheinen nicht-vertrauenswürdige Wallets ein Angriffsvektor für Identitätsdiebstahl zu sein. Antwort: Beim Erstellen der Basis-ID erfolgt eine Wallet-Authentisierung zur Überprüfung der Wallet und der Sicherungsmaßnahmen. Zukünftig sind vertrauenswürdige, sichere Wallets wichtige Grundlage für die Ablage sensibler, hochwertiger Credentials. Eine entsprechende Arbeitsgruppe “Wallet Security” wurde bei der DIF (Decentralized Identity Foundation) zur Vorbereitung der Standardisierung eingerichtet.
- Sie beschreiben, dass alle personenbezogenen Daten in der Wallet gespeichert werden. Dieser Datenhaltung kommt damit eine entscheidende Wichtigkeit zu. Welche Vorgaben werden für die Speicherung gemacht? Antwort: Wie wird der Zugang abgesichert? Antwort: User-Authentisierung mittels PIN ( 6-stellig) Wird der PIN 5x falsch eingegeben, so wird der Schlüssel aus dem Secure Storage gelöscht und die Daten sind nicht mehr zugreifbar. Sind Cloudspeicher ausgeschlossen? Antwort: Die SQLite3 DB wird gesichert, der dazugehörige symmetrische Schlüssel bleibt im Secure Storage des Gerätes. - Wie sieht der organisatorische Sperrprozess aus? Antwort: Sperrprozess für die Basis-ID: Die Nutzer*in zeigt ihre Autorisierung der Sperrung entweder mittels Personalausweis (über die Restricted ID) oder mittels Sperrkennwort, welches ihr im Registrierungsprozess angezeigt wurde. Das Sperrkennwort wird als Hash ausschließlich intern im Sperrdienst des Ausstellers für die Basis-ID vorgehalten. Weiter wird der Hash über die Restricted ID (dienst- und kartenspezifisches Kennzeichen/Pseudonym) des Personalausweisinhabers im Sperrdienst des Ausstellers für die Basis- ID vorgehalten. Damit verknüpft sind Sperrinformationen für das konkret ausgegebenen Basis-ID Credential. Bei einer Sperranfrage wird erneut mittels Hash über das Sperrkennwort bzw. die Restricted ID die Nutzer*in authentifiziert und eine Zuordnung hergestellt. Der Aussteller prüft nun die Autorisierung und löst mittels gespeicherter Sperrliste & Index eine Sperrung aus, indem er den kryptografischen Akkumulator auf dem Ledger anpasst . Genauer: Da der Issuer nach der Ausgabe des Credentials keinen direkten Zugriff mehr hat, gibt es eine anonyme Sperrinformation auf der dezentralen Infrastruktur (Blockchain/Ledger). Diese ist in der Hoheit des Ausstellers. Der Aussteller betreibt dafür Sperrlisten (Tails-Files), in jeder Sperrliste werden eine große Anzahl an Credentials referenziert. Hierdurch ergibt sich eine Herdenanonymität. Der gesamte Zeithorizont zwischen Auslösung der Sperrung und effektiver Umsetzung beträgt ca. 10 Sekunden. Wie werden Nutzer über Sperrmöglichkeiten informiert? Antwort: Die Nutzer*in wird beim Ausstellen der Credentials über die Sperrmöglichkeiten informiert (ist noch offen). Beim Ausstellen der Basis-ID wird das Sperrkennwort mitgeteilt. Was passiert bei Verlust des Personalausweises? Wird die Basis-ID dann automatisch gesperrt?
Antwort: Beim Verlust des Personalausweises wird die Basis-ID nicht automatisch gesperrt. Sie kann vom Nutzer mittels Sperrkennwort gesperrt werden. Dieser Prozess zur Sperrung erfolgt derzeit noch parallel zur Sperrung des physischen Personalsausweises. Wie kann die RestrictedID, die in Ihrer Skizze zum Sperrprozess genannt wird, gebildet werden, wenn der Personalausweis verloren wurde? Antwort: Bei Verlust des Personalausweises dient das Sperrkennwort zum Sperren der Basis- ID. - Ich gebe zu bedenken, dass der Sperrprozess des Personalausweises durch das Personalausweisgesetz mit Gesetzesrang geregelt wird. Für eine Basis-ID, die Eigenschaften des Personalausweises (z.B. Sicherheit und Authentizität) abbilden will, würde ich also eine ebenso hochrangige Regelung erwarten. Antwort: Eine rechtliche Regelung ist anzustreben. - Verstehe ich Sie richtig, dass die BDR eine Liste aller Bürgerinnen und Bürger, die eine Basis-ID nutzen, vorhalten muss, um Sperrungen durchzusetzen? Das halte ich aus datenschutzrechtlicher Sicht für problematisch und bitte hier um Ausführungen zum technischen Vorgehen und der Rechtsgrundlage. Antwort: Zur Durchsetzung der Sperrung wird der Hash der restrictedID für die ausgestellten Basis-IDs in der Sperrdatenbank der BDR gespeichert. Der Restricted Identifier (restrictedID) berechnet sich aus dem Chip des Personalausweises auf Basis eines öffentlichen Schlüssels, der im Berechtigungszertifikat des Online-Dienstanbieters hinterlegt ist und einem geheimen Schlüssel der auf dem Personalausweis gespeichert ist. Durch das Bilden des Hashwerts (restrictedID-hash) erfolgt eine Anonymisierung der verwendeten Schlüsseldaten. Die bdr (1) Verfügt nicht über personenidentifizierende Informationen (2) Noch über legale rechtliche Mittel zur Erlangung von personenidentifizierende Zusatzinformationen bei einem Dritten (3) Noch über eigene Möglichkeiten einer Re-Identifizierung, da sie mathematisch nicht (ohne Zusatzinfo in Form des Vorlegens des Ausweises durch den Betroffenen selbst) möglich ist.
