Konzepte für sichere wallets in dezentralen Identitätsökosystemen

Smartphone und Wearables sind heute der Mittelpunkt des digitalen Lebens vieler Bürgerinnen und Bürger und stellen damit eine prädestinierte Plattform für eine nutzerzentrierte SSI-Wallet dar. Die spezifische technische Architektur einer wallet bietet jedoch viele Gestaltungsmöglichkeiten. Die Lösungen charakterisieren sich hauptsächlich durch den Speicherort der credentials, den sicheren Mechanismus zur Schlüsselverwaltung und die Nutzerauthentisierung. Das Spektrum möglicher Architekturen reicht von nativen, mobilen Wallet-App-Lösungen (auch edge oder non-custodial wallet genannt) ohne zusätzliche Backend-Dienste bis hin zu vollständig cloudbasierten Wallet-Diensten (auch managed oder custodial wallet genannt), die nicht an ein Nutzergerät gebunden sind. Zwischen diesen Lösungen gibt es eine Vielzahl von hybriden Architekturen, die sowohl Nutzergeräte als auch Backend-Dienste nutzen. Die technische Ausgestaltung beeinflusst maßgeblich das sicherheitstechnische Konzept. Daneben hat sie Auswirkungen auf Eigenschaften wie backup & recovery, Sperrmechanismen, Offline-Unterstützung und die Privatsphäre.

In unserem Beitrag fokussieren wir uns ausschließlich auf die mobile Wallet-Architektur. Eine native, mobile Wallet-Lösung ist dabei der dezentralste Ansatz einer Architektur. Hierbei werden alle credentials sowie das Schlüsselmaterial auf dem Smartphone gespeichert und auch die Nutzerauthentisierung findet ausschließlich lokal gegenüber dem Gerät statt. Diese Lösung ist aufgrund der Fragmentierung des Smartphone-Markts technisch komplex und ermöglicht für gerätegebundene credentials keine Backup-Mechanismen, bietet dafür allerdings ein hohes Maß an Nutzerkontrolle, gute Möglichkeiten der Offline-Fähigkeit und Privatsphäre.

Eine wichtige Differenzierung für die Betrachtung der sicherheitstechnischen Konzepte sind die Art und der Ort der Nutzung beziehungsweise die damit einhergehenden Kommunikationskanäle. Hierbei ist zu unterscheiden zwischen der Verifizierung der credentials vor Ort (on-site) und der in der Ferne (remote) über das Internet. Der Standort des verifiers hat einen maßgeblichen Einfluss auf die Vertrauensbeziehung zwischen holder und verifier und insbesondere auf die Möglichkeiten einer Nutzerauthentisierung.

Im On-site-Fall handelt es sich um klassische Identifizierungsprozesse äquivalent zu analogen Ausweisdokumenten: Der verifier fragt ein credential an und der holder übermittelt eine presentation seiner credentials. Der Kommunikationskanal kann hier sowohl offline über lokale Verbindungen wie NFC, Bluetooth oder WiFi stattfinden als auch online, wenn sowohl die wallet des holders als auch die des verifiers mit dem Internet verbunden ist. Der Remote-Fall findet dagegen immanent immer online statt. Die physische Nähe zum verifier ermöglicht oft eine bessere Vertrauensbeziehung, während das Remote-Szenario insbesondere zusammen mit Biometrie Herausforderungen für die Sicherheit und Privatsphäre einer Nutzerauthentisierung darstellt.

Beide Nutzungsszenarien erfüllen gängige und wichtige Anwendungsfälle und müssen deshalb in den Untersuchungen betrachtet werden.

Die technischen Voraussetzungen für eine sichere SSI-Wallet sind heute auf fast allen Mobilgeräten gegeben. Die starke Fragmentierung, insbesondere bei Android, erschwert eine einheitliche Lösung und macht die Gerätebindung und Nutzerauthentisierung technisch komplex. Abb. 3 zeigt die vorhandenen Technologien in Bezug auf ihre Abschätzung zur Verbreitung im Markt und das erreichbare Vertrauensniveau.

Bei einem softwarebasierten Ansatz wird das Schlüsselmaterial im Speicherbereich der App verwaltet und bei den kryptografischen Operationen vom Hauptprozessor im normalen RAM geladen. Ebenso wie die White-box-Kryptografie, bei der das Schlüsselmaterial algorithmisch im Quellcode obfuskiert wird, bietet dieses Verfahren keinen wesentlichen Schutz gegen Extraktion und Duplizierung (Sanfelix et al. 2015).

Die Trusted Execution Environment (TEE) ist eine geschützte, hardwareunterstützte Prozessorumgebung, die sichere Anwendungen für mobile Geräte wie Smartphones, Tablets oder Smartwatches bereitstellt. Die TEE ist vom Hauptbetriebssystem (der Rich OS Execution Environment) isoliert und läuft auf einem separaten Betriebssystem mit eigenem Speicherbereich. Im Smartphone-Markt sind TEEs seit Android-Version 6 vorgeschrieben (Google 2022e), hier hat sich die Technologie Arm TrustZone² in Verbindung mit der GlobalPlatform-Spezifikation durchgesetzt und wird von mehr als einem Dutzend Chipherstellern angeboten. Die TEE ist an einen sicheren Bootprozess gekoppelt und lädt signierten Code in Form von trusted applets, die ihren Speicher mit chipindividuellen Schlüsseln absichern. Eine Schlüsselverwaltung wird in trusted applets innerhalb der TEE organisiert und über die Keymaster-API von Android der wallet bereitgestellt (Google 2022a). Die API bietet auch eine Möglichkeit zur Attestierung der Schlüsseleigenschaften und des Speicherorts mittels Zertifikatsüberprüfung an (Google 2022b). Die Freischaltung der Schlüssel in der TEE ist mit der System-PIN und Biometrie verknüpfbar. Auch wenn die TEE ein erhöhtes Sicherheitslevel anbietet und heute zur Absicherung von Bezahlvorgängen und DRM-Applikationen genutzt wird, gab es in der Vergangenheit mehrfach erfolgreiche Exploits gegen TEEs in Android-Telefonen (Sanfelix 2019; Cerdeira et al. 2020).

Die Secure Enclave ist ein dediziertes sicheres Subsystem des Apple-Ökosystems, das als system-on-chip integriert ist (Apple 2022c). Die Secure Enclave hat einen eigenen Prozessor und greift durch eine memory protection engine verschlüsselt auf den Hauptspeicher zu. Sie besitzt zudem einen sicheren Zufallszahlengenerator, nicht flüchtigen Speicher und eine Hardware-Engine für AES und Public Keys. Sie ist gegen Manipulationen und Seitenkanalangriffe geschützt und enthält ein eigenes Betriebssystem namens sepOS. Erstmals wurde die Secure Enclave im Chip A7 des iPhone 5s verbaut und ist heute in allen Apple-Geräten mit iOS-Version 14 verfügbar. Apple setzt die Technologie sowohl für Touch ID und Face ID als auch für Apple Pay ein, weitere zukünftige Anwendungsfälle sind die mobile Driving Licence und Autoschlüssel des Car Connectivity Consortium. Für Signaturen und Verschlüsselung mit asymmetrischer Kryptographie werden Schlüssel nur auf der elliptischen Kurve NIST P‑256 unterstützt, die ausschließlich auf dem Gerät erzeugt werden können (kein Schlüsselimport), ebenso ist eine Attestierung der hardwaregebundenen Schlüssel bis jetzt nicht möglich (Apple 2022b). Secure Enclave ist derzeit nach FIPS 140-2/3 zertifiziert, eine Common-Criteria-Zertifizierung steht aus (Apple 2021). In der Vergangenheit war die Secure Enclave als Teil des Apple-Ökosystems bereits ein Ziel von Exploits (Gian 2020).

Die StrongBox ist eine Implementierung für den Android-Keymaster ab Android-Version 9 und basiert auf einem separaten, hardwarebasierten Sicherheitschip, Google nennt dabei embedded Secure Elements (eSE) und on-SoC secure processing units (iSE) (Google 2022a). Den Auftakt machte 2018 eine Eigenentwicklung namens „Titan M“ für das Pixel 3, für die zweitjüngste Generation Pixel 6 nutzt Google den „Titan M2“, basierend auf der offenen Befehlssatzarchitektur RISC‑V. Die Anforderungen für eine StrongBox sind ein eigener Prozessor, sicherer Speicher, ein echter Zufallszahlengenerator und eine Resistenz gegen physische und logische Attacken wie zum Beispiel Seitenkanalangriffe. Analog zu den TEEs unterstützt der Android Keymaster verschiedene Algorithmen³ und eine Attestierung der Schlüssel aus einer Strongbox. Im März 2021 verkündete Google die Android Ready SE Alliance, eine Partnerschaft mit führenden Herstellern von Secure Elements, um die Sicherheit des Android-Ökosystems zu stärken und einen Wechsel zu Strongbox-kompatiblen Hardwarechips zu beschleunigen (Google 2021). Damit sollen Anwendungsfälle für digitale Schlüssel, Führerscheine, Identitäten und elektronisches Geld ermöglicht werden. Dies wird wahrscheinlich mittelfristig einen Sicherheitszugewinn für die Android-Plattform mit sich bringen, da die Strongbox bisher den Pixel-Geräten vorbehalten war und so nur einen kleinen Marktanteil abdecken konnte. Bis heute sind keine öffentlich bekannten Angriffe auf die bisherigen Strongbox-Chips der Titan-Familie bekannt.

Ein Secure Element beschreibt einen manipulationssicheren, zertifizierten Sicherheitschip mit eigenem Prozessor, eigenem Hauptspeicher und hardwareunterstützten Co-Prozessoren für kryptografische Operationen. Zusätzlich besitzt er echte Zufallszahlengeneratoren zur Erstellung von Schlüsselmaterial und einen eigenen Speicher, um Zertifikate, Schlüssel oder andere schützenswerte Daten abzulegen. Secure Elements treten je nach Anwendungsgebiet in verschiedenen Formfaktoren und unter unterschiedlichen Bezeichnungen auf. Als kontaktlose oder kontaktbehaftete Smartcard (Chipkarte) ermöglichen sie zahlreiche Anwendungen für Kreditkarten, Personalausweis, Gesundheitskarten oder PKI- und Zutrittskarte im Unternehmensumfeld. Als UICC (SIM-Karte) oder SD-Karte finden sich Secure Elements zum Einstecken. Der allgemeine Trend im Mobilfunkmarkt geht hin zu den integrierten eUICC (embedded UICC) und eSE (embedded Secure Elements), die von den Telekommunikationsanbietern beziehungsweise den Geräteherstellern verwaltet werden. Der Markt wird von einem knappen Dutzend etablierten Unternehmen dominiert, die alle ihre eigenen proprietären Betriebssysteme nutzen. In der Regel wird je nach Chip eine Vielzahl von kryptografischen Algorithmen für Verschlüsselung und Signatur mit symmetrischen und asymmetrischen Schlüsseln unterstützt. Ein überwiegender Teil der Secure Elements kann auch nachladbaren und interoperablen Code als Java Card Applet ausführen, der über eine im Chip implementierte Java Card Runtime Environment interpretiert wird (Chen 2000). Über den GlobalPlatform-Standard wird die Verwaltung und Installation der Java Card Applets ermöglicht, die Schlüssel zur Autorisierung liegen hier meist beim Hersteller. Java Card ermöglicht es, eigene Logik und Protokolle in einem Secure Element abzubilden, und bietet somit mehr Handlungsspielraum als die vorgegebenen APIs der übrigen Sicherheitschips. Secure Elements gehören seit mehr als 20 Jahren zu den sichersten Systemen überhaupt. Dies verdanken sie in erster Linie einem sehr strengen Zertifizierungsprozess nach Common Criteria, bei dem die Hardware und Software gemäß standardisierten Anforderungen von spezialisierten und zertifizierten Prüferinnen und Prüfern abgenommen wird.

Abseits der vorgestellten Schlüsselspeicher gibt es noch Hardware Security Modules (HSM) für den Serverbereich und Trusted Platform Modules (TPM) für den Desktop- und Notebook-Markt, die jedoch für eine mobile, native Wallet-Architektur nur eine untergeordnete Rolle spielen.

Zusammenfassend kann man festhalten, dass die Marktabdeckung mit zunehmendem Sicherheitslevel sinkt. TEEs als Basis für ein mittleres Sicherheitslevel sind auf fast allen Geräten vorhanden. Secure Elements, die für das Erreichen eines hohen Sicherheitslevels notwendig wären, sind aber nur in den Premiummodellen der Handyhersteller verbaut. Abhilfe können hier mittelfristig auch die eUICCs schaffen, aber auch damit ist zum heutigen Zeitpunkt keine allumfassende Marktabdeckung möglich. Diesen Herausforderungen stellt sich auch die Smart-eID, die die Online-Ausweisfunktion des Personalausweises aufs Smartphone bringen soll (BMI 2021).

Die Hauptaufgabe der wallet ist die Verwaltung der credentials und des dazugehörigen, kryptografischen Schlüsselmaterials. Während die Signatur des issuers die Integrität und Authentizität der ausgestellten Attribute im credential sicherstellt, beinhaltet dieses einen weiteren Schlüssel, um es an die wallet des holders zu binden. Der öffentliche Teil des Schlüssels kann im credential selbst hinterlegt, über ein im credential referenziertes DID document⁴ abgelegt oder über ein Zero-Knowledge-Proof-gesichertes link secret abgebildet sein. Der private Schlüsselteil wird in der wallet des holders gemanagt. Mit diesem wird eine vom verifier angeforderte presentation signiert. Dieses Schlüsselpaar ist es auch, über das eine Gerätebindung an das Smartphone des holders geschehen kann.

Für die Gerätebindung stehen grundsätzlich zwei Ansätze zur Auswahl: Der Ansatz trusted storage geht davon aus, dass die wallet als Ganzes in einer sicheren Umgebung betrieben wird, die die Integrität und Authentizität sicherstellt, und damit die übermittelten Daten der credentials auch vertrauenswürdig sind. Dieser Ansatz wird beispielsweise vom EAC-Protokoll des neuen Personalausweises angewandt. Zunächst wird mittels terminal und chip authentication die Authentizität des verifiers und der wallet sichergestellt und ein sicherer Kanal aufgebaut. Anschließend werden die angefragten Daten unsigniert innerhalb des secure messaging übertragen. Während dieser Ansatz gute Privatsphäreneigenschaften bietet, erfordert er vom Gerät ein Secure Element, um die Protokolllogik innerhalb der sicheren Umgebung abzubilden. Die APIs einer Strongbox, Secure Enclave oder TEE geben diese Funktionalität nicht her.

Die präferierte Lösung zur Gerätebindung ist deshalb das cryptographic key binding. Hierbei wird das credential an einen sicheren Schlüssel gebunden, der innerhalb der sicheren Umgebung liegt, das credential selbst aber im (verschlüsselten) Speicher der Wallet-App verwaltet. Dieser Ansatz wird heute von allen dezentralen Identitätsökosystemen verfolgt. Der Vorteil dieses Ansatzes ist, dass er mit allen vorgestellten mobilen Sicherheitsumgebungen kompatibel ist und somit eine hohe Marktabdeckung erreicht. Der Nachteil ist jedoch, dass die unlinkable, privatsphärenorientierten Signaturalgorithmen auf Basis von CL (Camenisch und Lysyanskaya 2004; Khovratovich und Lodder 2018; Curran et al. 2022) und BBS+ (Boneh et al. 2004; Looker und Steele 2021) mit selektiver Offenlegung von keiner heute verfügbaren Hardware unterstützt werden und auch in absehbarer Zukunft nicht flächendeckend ausgerollt sind⁵. Stattdessen ergibt eine Auswahl der am weitesten verbreiteten Algorithmen Sinn, um den Implementierungsaufwand gering zu halten und zudem eine kryptografische Agilität⁶ zu garantieren. Da RSA von Regulierungsbehörden zunehmend kritischer gesehen wird und auf der Secure Enclave nicht verfügbar ist, sind die vielversprechendsten hierfür⁷:

Auf dieser Basis wird ein simples Challenge-Response-Schema zur Authentisierung der credentials genutzt. Die auf dem jeweiligen Endgerät verfügbaren Sicherheitsmechanismen sollten ausgenutzt werden und der Typ des genutzten Sicherheitschips sollte im credential selbst vermerkt werden. Optional ist es auch möglich, das damit erreichbare level of assurance selbst mit im credential zu vermerken.

Eine Nutzerbindung in einer nativen, mobilen wallet erfolgt über den zweiten Faktor Wissen (PIN/Passwort) oder Inhärenz (Biometrie). Eine Authentisierung des holders ist eine Kernanforderung für identity credentials, während attestation credentials in der Regel die Nutzerin oder den Nutzer nicht authentisieren müssen.

Im On-site-Anwendungsfall kann eine Nutzerbindung verhältnismäßig einfach realisiert werden, indem der verifier eine manuelle Identifizierung des holders durchführt, mittels Abgleich des Lichtbilds oder anderer biometrischer Daten, die vom issuer überprüft und im credential als Attribute hinterlegt wurden. Dabei ist zu beachten, dass die Übermittlung geprüfter und signierter biometrischer Daten ein gewisses Risiko für die Privatsphäre darstellt. Die die wallet nutzende Person muss dabei durch die physische Nähe darauf vertrauen können, dass der verifier direkt vor ihr steht und keine Relay- oder Phishing-Attacken möglich sind. Diese Vertrauensbeziehung kann über ein Offline-Kommunikationsprotokoll mit beschränkter Reichweite oder über eine lokale Initiierung der Kommunikation, beispielsweise mittels QR-Code, unterstützt werden. Darüber hinaus sollte eine Authentisierung des verifiers (siehe Abschn. 6.4) derart stattfinden, dass der holder diese in seiner wallet kontrollieren kann.

Im Gegensatz dazu bringt eine Nutzerbindung im Remote-Anwendungsfall, insbesondere mittels biometrischer Authentisierung, erhebliche technische Komplexität und Risiken für Datenmissbrauch und Privatsphäre mit sich. Eine wallet muss je nach Anwendungsfall die Authentisierung des holders selbst durchführen oder einem vertrauenswürdigen verifier überlassen. Der präferierte, nutzerzentrierte und datenschutzorientierte Ansatz für den Remote-Anwendungsfall speichert die Referenzdaten des holders nur in der wallet, ebenso erfolgt der Abgleich nur lokal auf dem Gerät, eine technische Lösung autorisiert die Nutzung des (gerätegebundenen) Besitzfaktors durch eine erfolgreiche Nutzerauthentisierung. Diese Architektur erfordert gleichzeitig eine Vertrauensbeziehung zur wallet als Identifizierungsmittel, da issuer und verifier eine Zusicherung der lokal erfolgten Nutzerbindung benötigen. Die daraus resultierende nachweisbare Authentizität der wallet wird im folgenden Kapitel beschrieben. Zunächst werden die Details zur Nutzerbindung ausgeführt.

Biometrie ermöglicht die Nutzerauthentisierung auf der Grundlage von Verhaltens- und körperlichen Merkmalen wie Fingerabdrücken, Gesicht, Iris, Stimme oder Gang und bietet den Komfort einer einfachen Authentifizierung, da sich die Nutzerin oder der Nutzer keine PINs oder Passwörter merken muss. Auf fast allen Smartphones finden sich deshalb heute biometrische Sensoren für die biometrischen Modalitäten Finger und Gesicht und der Trend zu deren Nutzung nimmt seit Jahren konstant zu. Um die Anforderungen für ein Vertrauensniveau einer biometrischen Authentifizierung zu systematisieren und die technischen Lösungen vergleichbar zu machen, sind Definitionen für biometrische Performanzwerte wie auch eine Präsentationsangriffsdetektion notwendig. Das BSI hat zu diesem Thema die „Technical Guideline for Biometric Authentication Components in Devices for Authentication“ (BSI 2021) herausgebracht, die Vorgaben und Empfehlungen bezüglich Biometrie gibt. Die verschiedenen Implementierungen der Hersteller wurden jedoch in den vergangenen Jahren regelmäßig angegriffen und sind mit meist trivialen Methoden überwindbar. So gut wie alle Smartphones sind deshalb nach dem Stand der Technik für regulierte Anwendungsfälle unzureichend, zu den wenigen Ausnahmen gehört beispielsweise Apples Face ID.

Für den Nachweis der Authentizität muss die wallet zwei Beweise erbringen:

Eine Attestierung der wallet soll beweisen, dass es sich bei der App tatsächlich um die authentische, unmanipulierte und zertifizierte Version eines Wallet-Herstellers handelt. Da die App auf dem „unsicheren“ Betriebssystem des Smartphones läuft, stellt das Sicherheitslevel einen bestmöglichen Mitigationsansatz dar. Die Wallet-App muss nach dem Stand der Technik Maßnahmen gegen emulation, debugging, code injection, cloning und andere Angriffe implementieren. Zusätzlich sollte sie ihre Authentizität beweisen. Die besten Mittel hierfür sind die von der Plattform bereitgestellten APIs. Android bietet mit der Play Integrity API (Google 2022c) (und dem Vorgänger SafetyNet Attestations API (Google 2022d)) eine Schnittstelle zur Integritätsbewertung und Authentifizierung der App, die die Software- und Hardwareumgebung auf Manipulationen überprüft. Die Überprüfung wird an eine nonce geknüpft, die die App zusammen mit aktuellen Zustandsdaten des Smartphones an einen Google-Server schickt. Dieser wertet die Daten aus und erzeugt eine kryptografische signierte Attestierung, die die App an das Backend des Wallet-Herstellers weiterleitet und dort ausgewertet wird. Apple bietet für sein Ökosystem eine ähnliche Schnittstelle namens iOS DeviceCheck (Apple 2022a). Dessen primäre Funktion ist die Wiedererkennung von Geräten, sodass die Funktion lediglich eine Authentizität feststellen kann und keine Aussagen zur Integrität des Smartphones macht. iOS als geschlossenes Apple-Ökosystem bietet jedoch grundsätzlich ein höheres Sicherheitslevel als die offene Android-Plattform, sodass eine zusätzliche Integritätsprüfung nicht zwingend notwendig ist.

Beide Mechanismen sind lediglich eine Unterstützung der Authentizitätsprüfung der App und müssen mit anderen Maßnahmen komplettiert werden. Eine der größten Herausforderungen besteht darin, beim Nachweis der Authentizität der wallet die Unkorrelierbarkeit gegenüber verifiern zu wahren.

Für die Erfüllung der regulatorischen Anforderungen ist in der Regel zudem auch eine Zertifizierung des Identifizierungsmittels notwendig. Dabei werden die Software und Entwicklungsprozesse von unabhängigen Prüferinnen und Prüfern auditiert und bestätigt. Die Zertifizierungen verschiedener zugelassener wallets sollten in einem Identitätsökosystem dann in einer trust registry oder trusted list, beispielsweise einer verifiable data registry, zusammengetragen werden. Dieser Punkt dient dann für issuer und verifier als Anlaufstelle, um die Vertrauenswürdigkeit einer mittels Wallet-Authentisierung identifizierten wallet festzustellen.

Die Nutzenden benötigen in der Praxis Sicherheit im Umgang mit der wallet, insbesondere durch klar erkennbare Mechanismen bei der Authentisierung eines issuers oder eines anfragenden verifiers.

Auch mit Anfragenden, die ihre Identität nicht hinreichend beweisen können (beispielsweise Privatpersonen), sollte es in einem selbstbestimmten Identitätsökosystem möglich sein, Daten zu teilen; dabei werden diese mit deutlichen Warnhinweisen markiert (Lissi 2022).

Darüber hinaus ist eine Registrierung der anfragenden Partei in einem Vertrauensregister möglich. Diese Register können für das ganze Ökosystem oder für bestimmte Anwendungen und credentials gelten. Eine wallet darf presentations nur an verifier herausgeben, die sie mittels dieser vertrauenswürdigen Listen geprüft hat. Der Vertrauensanker kann hierbei in der verifiable data registry oder in existierenden Listen wie der EU Trusted List realisiert werden.

Die Ausstellung beginnt mit dem Aufbau eines Kommunikationskanals zwischen issuer und wallet. Der issuer führt eine Identifizierung der Nutzerin oder des Nutzers⁸ durch und bietet daraufhin die Ausstellung als credential offer an. Die wallet holt sich nun die sicherheitstechnischen Anforderungen von den öffentlich erreichbaren Metadaten des issuers ab. Darin gibt der issuer an, welche Anforderungen er an die wallet bezüglich Gerätebindung und Nutzerbindung stellt. Die wallet kann so selbst prüfen, ob sie den regulatorischen Anforderungen gerecht werden kann. Sie fordert anschließend die Zustimmung des holders an, um mit der Ausstellung des credentials fortzufahren.

Die wallet fordert anschließend eine attestation von ihrem attestation service an. Der attestation service ist ein backend service, der vom Hersteller und Betreiber der wallet selbst betrieben wird oder beispielsweise an einen trust service provider ausgelagert ist. Seine Aufgabe ist es, die Gerätebindung und Wallet-Authentisierung einer Wallet-Instanz zu validieren und zu bestätigen. Die Attestierung der wallet und der hardwaregebundenen Schlüssel erfolgt dabei on demand auf eine Ausstellungsanfrage. Die Vorteile der Ad-hoc-Ausstellung liegen in der erhöhten Sicherheit (Aktualität der Attestierung, verringertes Zeitfenster für potenzielle Angriffe) und in der Skalierung des Systems (es werden nur so viele Attestierungen durchgeführt wie tatsächlich benötigt). Als Format wird ein W3C verifiable credential vorgeschlagen, sodass für issuer und verifier keine zusätzliche Protokolllogik zur Validierung der Attestierungen notwendig ist.

Der attestation service und die wallet erstellen einen sicheren Kanal⁹ und die wallet übermittelt ihre Anfrage. Der attestation service generiert und übermittelt die zur Attestierung notwendigen challenges und die wallet weist mittels Android Integrity API, iOS DeviceCheck oder ähnlicher Mechanismen ihre Authentizität und Integrität nach. Anschließend generiert sie einen hardwaregebundenen Schlüssel und übermittelt den öffentlichen Schlüssel samt key attestation. Die Autorisierung der privaten Schlüssel wird dabei von der wallet entsprechend den Vorgaben des issuers konfiguriert. Der attestation service verifiziert alle Daten und stellt am Ende ein sogenanntes device attestation credential an die wallet aus. Dieses beinhaltet die validierten Informationen aus Gerätebindung, Nutzerbindung und Wallet-Authentisierung:

Optional kann der attestation service auch ein erreichbares level of assurance direkt verlinken. Da der attestation service den Anwendungsfall nicht kennt und eine Vielzahl verschiedener Vertrauensniveaus exisitieren, ist dieser Weg jedoch nicht zwangsweise sinnvoll. Es folgt ein Beispiel als JSON-LD W3C VC:

Die wallet kann nun das credential offer des issuers mit einem credential request beantworten, der eine (W3C verifiable) presentation des device attestation credentials beinhaltet und so den Besitz des Hardwareschlüssels (und damit indirekt die Nutzerauthentisierung) nachweist. Der issuer fragt bei der trust registry den Status der Zertifizierung anhand des eindeutigen Namens¹⁰ der authentifizierten wallet nach und kann somit sicherstellen, dass die regulatorischen Anforderungen erfüllt werden. Als Letztes stellt er sein credential an die wallet aus und koppelt dieses an das device attestation credential. Im Kontext von W3C Verifiable Credentials wird dieser Mechanismus unter dem Begriff holder binding diskutiert (Curran, Stephen 2021; Bastian et al. 2023). Dabei stehen dem issuer zwei Möglichkeiten zur Verfügung: In der präferierten Variante kann er auf das bestehende device attestation credential verlinken und beispielsweise dessen issuer und die id angeben. Als Alternative kann der issuer den hardwaregebundenen Schlüssel selbst in sein credential integrieren und optional weitere Teile der Attestierung kopieren.

Der Verifizierungsprozess startet analog mit dem Etablieren eines sicheren Kommunikationskanals und der verifier übermittelt seine Anfrage für das angeforderte credential und das nötige Vertrauensniveau. Das Vertrauensniveau sollte explizit im credential oder implizit in der trust registry verankert sein, damit die wallet die Anforderungen des verifiers vor der presentation abgleichen kann, andernfalls übermittelt der holder ein credential und der verifier stellt erst nach der Validierung fest, dass das credential für seine regulatorischen Prozesse unzureichend ist, was für die user experience des holders nachteilig wäre. Die wallet erzeugt daraufhin zwei verifiable presentations, eine für das angeforderte credential des issuers (W3C VC, AnonCreds oder andere Formate) und eine für das device attestation credential, das den hardwaregebundenen Schlüssel im Smartphone zur Erstellung einer presentation nutzt¹¹. Die wallet zeigt dem holder die zu übermittelnden Daten sowie die Identität des verifiers (siehe Abschn. 6.4) an und holt die Autorisierung des holders durch den an die Gerätebindung gekoppelten Mechanismus zur Nutzerauthentisierung ein. Hierbei sollte die wallet den Hinweis geben, dass durch den eindeutigen, hardwaregebundenen, öffentlichen Schlüssel ein zusätzliches nachverfolgbares Attribut offengelegt wird. Die zweiteilige presentation wird nun an den verifier übermittelt, dieser überprüft die beiden Signaturen und validiert die Verlinkung der credentials. Der verifier kann bei der trust registry die Zertifizierung der wallet abfragen und so das Vertrauensniveau des credentials bestätigen.

Das in Abb. 5 dargestellte Vertrauensmodell in diesem System verfolgt die Ausstellungskette zurück: Der verifier vertraut dem issuer, dass dieser das device attestation credential im Ausstellungsprozess richtig validiert und verlinkt hat, der issuer vertraut dem attestation service, dass dieser das Gerät richtig geprüft hat und die Angaben des device attestation credentials stimmen, und der attestation service vertraut auf die Zertifizierung und Auditierung der wallet. Eine Einbettung der Attestierungen selbst in die credentials ist redundant und würde zusätzliche Datenschutzprobleme mit sich bringen.