Die Schwierigkeit bei der Integration eines digitalen Führerscheins auf einem Mobiltelefon (mDL) liegt nicht darin, eine API zur Identitätsverifizierung aufzurufen, sondern darin zu verstehen, was hinter dieser Schnittstelle geschieht: Wo werden die Zugangsdaten gespeichert, wer schützt die Geräteschlüssel, wie werden Vertrauenszertifikate verwaltet und was funktioniert weiterhin, wenn das Netzwerk ausfällt oder der Dienstanbieter nicht verfügbar ist? Der auf InfoQ veröffentlichte Artikel stellt eine Architekturvorstellung für mDL-Systeme vor, die nach dem Standard ISO/IEC 18013-5 aufgebaut sind, und richtet sich an Organisationen, die einen Anbieter, ein SDK, eine Wallet-Plattform oder einen Verifizierungsdienst auswählen.
Trennung von Identitätsnachweis und Ausstellung der Zugangsdaten
Der vorgeschlagene Rahmen beginnt mit der Trennung zweier unterschiedlicher Phasen im Lebenszyklus einer Identität. In der Phase des Identitätsnachweises nimmt der Nutzer Bilder seines physischen Führerscheins und ein Video zur Lebenderkennung auf. Anschließend werden die Nachweise und die extrahierten Daten an ein Verifizierungssystem übermittelt. Die zuständige Stelle, etwa die Kraftfahrzeugbehörde, prüft diese Nachweise automatisch oder manuell, bevor sie eine Entscheidung über Annahme oder Ablehnung trifft.
Nach der Genehmigung beginnt die Bereitstellungsphase. Das Gerät erzeugt asymmetrische Schlüssel innerhalb einer Secure Enclave oder eines sicheren Elements und sendet den öffentlichen Schlüssel, die Attestierungszertifikate und eine Referenz auf den Nachweisvorgang an die ausstellende Stelle. Diese verknüpft die Führerscheindaten in einem signierten Mobile Security Object mit dem Schlüssel, verschlüsselt das Zugangsdatenpaket und sendet es an die Wallet, um es in einem hardwaregestützten Speicherbereich abzulegen.
Die Organisation muss diese Schritte nicht selbst ausführen, ist aber verpflichtet, für jeden Schritt die verantwortliche Partei und die Partei zu bestimmen, die die daraus resultierende Vertrauensentscheidung besitzt.
Was muss hinter der Schnittstelle des Anbieters geprüft werden?
Der Artikel vertritt die Auffassung, dass der Erfolg eines Pilotversuchs, der Funktionen wie verifyCredential() oder requestPresentation() aufruft, für die Bewertung des Anbieters nicht ausreicht. Die Prüfung sollte sechs miteinander verbundene Bereiche umfassen:
- Kryptografische Architektur: Erzeugung und Schutz der Schlüssel, Geräteattestierung, Algorithmen und Lebenszyklus der Schlüssel.
- Vertrauen und Public-Key-Infrastruktur: Vertrauensanker, Document-Signer-Zertifikate, Vertrauens- und Sperrlisten.
- Datenschutz und Datenminimierung: selektive Offenlegung, Telemetrie, Aufbewahrung von Präsentationsdaten und Risiken der Verknüpfung von Transaktionen.
- Offline-Betrieb: zwischengespeicherte Materialien, veralteter Sperrstatus und Systemverhalten während eines Netzwerkausfalls.
- Interoperabilität: Einhaltung von ISO/IEC 18013-5 und die Möglichkeit zur Interaktion mit unabhängigen Wallets und Verifizierern.
- Betriebliche Resilienz: Auswirkungen eines Ausfalls des Anbieters, Fortbestehen der Zugangsdaten sowie Wiederherstellungs- und Fehlerbehandlungsmechanismen.
Kryptografie und Zertifikate sind keine Implementierungsdetails
Der Artikel schlägt die Verwendung von Hybrid Public Key Encryption gemäß RFC 9180 zum Schutz von Online-Übertragungen und API-Austauschen vor, mit Parametern wie DHKEM(P-256, HKDF-SHA256), HKDF-SHA256 und AES-128-GCM. Kryptografie sollte dem vorgestellten Rahmen zufolge jedoch nicht als von dem Vertrauensmodell getrenntes Merkmal behandelt werden. Es muss bekannt sein, wo die Verschlüsselung beginnt und endet, wer die Schlüssel erzeugt und schützt, wie sie rotiert werden und welche Komponenten innerhalb der Vertrauensgrenzen des Anbieters liegen.
Auch die Kommunikation zwischen Wallet-Servern, Ausstellungsplattformen und Verifizierungssystemen erfordert eine gegenseitige Authentifizierung über TLS und eine klare Zertifikatsinfrastruktur. Der Artikel stellt unterschiedliche Rollen von Zertifikaten dar: vom in einer nicht online verbundenen Hardware-Sicherheitseinheit gespeicherten Vertrauensanker über kurzlebige Document-Signer-Zertifikate und mTLS-Zertifikate bis hin zu Zertifikaten zur Attestierung von Geräteschlüsseln. Entscheidend bleibt die Verteilung der Verantwortlichkeiten: Welche Infrastruktur verwaltet der Anbieter, welche steht unter der Kontrolle der Organisation und welche Vertrauensbeziehungen verbleiben bei der ausstellenden Stelle?
Was ändert sich praktisch bei einem Dienstausfall?
Das Design unterscheidet zwischen synchronen Vorgängen, die während der Verifizierung stattfinden, etwa dem Datenaustausch über NFC oder der direkten Verifizierung über eine API, und asynchronen Vorgängen, die im Hintergrund ausgeführt werden können, beispielsweise der Prüfung des Identitätsnachweises, der Bereitstellung der Zugangsdaten, der Schlüsselrotation und der Synchronisierung von Vertrauenslisten.
Diese Trennung ermöglicht die weitere Präsentation und Offline-Verifizierung vorhandener Zugangsdaten, sofern die Richtlinien dies zulassen, während die Synchronisierung von Vertrauenslisten oder Sperraktualisierungen verschoben werden kann. Der Artikel schlägt vor, Präsentation und Verifizierung ohne Netzwerk, abgelaufene Zugangsdaten, veraltete Sperrlisten, eine Abweichung der Geräteuhr, die Wiederherstellung der Verbindung und das Systemverhalten während eines Ausfalls des Anbieters zu testen. Die Abhängigkeit von einem hochverfügbaren Anbieter kann weiterhin einen Single Point of Failure darstellen, wenn jede Verifizierung eine Verbindung zu seinen Backend-Diensten erfordert.
Selektive Offenlegung und Vermeidung der Anbieterabhängigkeit
Die benötigten Daten unterscheiden sich je nach Situation. Ein Kontrollpunkt an einem Flughafen benötigt möglicherweise den Namen, das Foto, das Geburtsdatum, die Dokumentennummer und die ausstellende Behörde, während sich ein Geschäft möglicherweise mit einer logischen Aussage begnügt, die bestätigt, dass der Nutzer älter als 21 Jahre ist, zusammen mit einem Foto, ohne Name, Adresse oder Dokumentennummer. Daher reicht es nicht aus, den Anbieter anhand eines einzigen Szenarios zu testen; er muss an den Richtlinien der Organisation und den tatsächlichen Transaktionskategorien gemessen werden.
Der Beitrag schlägt vor, die Geschäftslogik von der Infrastruktur des Anbieters unabhängig zu halten, sodass Anwendungen eine Richtlinie wie die Anforderung eines Nachweises, älter als 21 Jahre zu sein, ausdrücken, anstatt anbieterspezifische Datenstrukturen im gesamten System zu verbreiten. Details wie die CBOR-Sequenzierung, der Aufbau von APDU-Nachrichten und Aufrufe von Kryptografiebibliotheken können verborgen werden. Vertrauensanker, Identität der ausstellenden Stelle, offengelegte Attribute, Zertifikats- und Sperrstatus, die Abhängigkeit vom Anbieter sowie die Offline-Fähigkeiten müssen für die Organisation jedoch sichtbar bleiben.
Die certi.news-Einordnung
Die eigentliche Veränderung, auf die der Artikel fokussiert, besteht darin, die Bewertung von mDL von einem Test der SDK-Funktionalität auf die Prüfung eines vollständigen Vertrauenssystems zu verlagern. Dieser Ansatz ist für Sicherheits-, Identitäts- und Beschaffungsteams hilfreich, weil er festlegt, was gekauft werden kann und was unter der Governance der Organisation bleiben muss: Die Wallet-Implementierung, NFC-Protokolle und Kryptografiebibliotheken können gekauft werden, während Richtlinien für Offenlegung, Autorisierung und Auditing sowie die Governance von Schlüssel- und Zertifikatsverwaltung, Datenschutz, Verfügbarkeit und Interoperabilität aufgebaut werden sollten.
Der Rahmen klärt jedoch Fragen wie lokale Compliance-Anforderungen oder Governance-Modelle zwischen ausstellenden Stellen und Verifizierern nicht allein. Zudem garantiert die Sicherstellung einer gültigen Signatur keine Privatsphäre, wenn Systeme übermäßige Protokolle aufbewahren oder Präsentationsvorgänge mit Nutzern verknüpfen. Daher bleiben Fragen der Nachverfolgbarkeit, eines die Privatsphäre wahrenden Widerrufs und der Verantwortlichkeit bei einem Ausfall des Anbieters Punkte, die vor dem Übergang in den Produktivbetrieb institutionelle und regulatorische Entscheidungen erfordern.