d-you: App und Backend im Test, vier Bausteine folgen

Die staatliche digitale Brieftasche d-you soll am 2. Januar 2027 starten. Bis dahin lässt das Bundesministerium für Digitales und Staatsmodernisierung (BMDS) unabhängige Sicherheitsforschende nach Schwachstellen suchen. Entscheidend ist, welche Teile der Identitätskette sie tatsächlich testen dürfen: Nach dem am 10. Oktober 2026 eingesehenen HackerOne-Programm gehören die Smartphone-Apps und mehrere zentrale Backend-Dienste dazu. Der Anbieter für die Ausstellung von Personenidentifizierungsdaten (PID-Provider), der EUDI Hub DE, die Prüf-App EUDI Check DE und die Website zum Widerruf von Wallets sollen erst später hinzukommen. Das ist ein Unterschied im öffentlichen Testumfang, kein Nachweis für einen Sicherheitsmangel dieser vier Komponenten.

Das BMDS teilte am 9. Oktober mit, das Programm sei Mitte September in einer Testumgebung mit virtuellen Identitäten angelaufen. Gemeldete Lücken sollen vor dem geplanten Start behoben werden. Für bestätigte Schwachstellen außergewöhnlicher Schwere nennt das Ministerium derzeit Prämien von 15.000 bis 40.000 US-Dollar. Solche Zahlungen setzen einen Anreiz für nachvollziehbare Befunde. Aus der Existenz des Programms lässt sich weder ableiten, dass die Wallet sicher ist, noch dass sie unsicher ist.

Was heute öffentlich geprüft werden darf

Der verbindliche Programmtext auf HackerOne ist genauer als die Kurzform „App und Backend“. Er nennt die Android- und iOS-App, einen entfernten Dienst für kryptografische Vorgänge samt geschützter Schlüsselverwaltung, das Wallet-Provider-Backend, die Prüfung des Gerätesicherheitszustands, einen Statuslisten-Dienst und den Push-Dienst für Hinweise auf Statusänderungen. Forschende sollen unter anderem versuchen nachzuweisen, ob eine fremde Wallet geschützte Schlüssel nutzen, eine manipulierte App als vertrauenswürdig gelten oder eine gesperrte Wallet weiter akzeptiert werden könnte. Das sind ausdrücklich gewünschte Testfälle, keine veröffentlichten Feststellungen, dass diese Angriffe funktionieren.

Der Test ist auch nicht auf isolierte App-Oberflächen beschränkt. Die Test-Apps enthalten laut Programm eine virtuelle Identität, mit der sich die Ausstellung und Vorlage von Personenidentifizierungsdaten, kurz PID, im vorgesehenen Testablauf erproben lassen. Damit können Forschende Fehler an den bereits freigegebenen Schnittstellen und Abläufen untersuchen. Der PID-Provider selbst ist aber noch kein freigegebenes Angriffsziel. Gleiches gilt für den EUDI Hub DE, die EUDI Check DE App und die Widerrufswebsite. Wer einen kompletten Ablauf testet, hat deshalb nicht automatisch jede beteiligte Komponente im öffentlichen Prüfprogramm getestet.

Für einen Dienst, der sich später auf eine d-you-Identifizierung verlässt, hat diese Grenze eine konkrete Bedeutung. Die PID müssen der richtigen Person und Wallet ausgestellt, mit Zustimmung der betreffenden Person vorgelegt und im jeweiligen Prüfkontext als echt und gültig erkannt werden. Nach einem Geräteverlust muss außerdem ein Widerruf an den maßgeblichen Prüfstellen ankommen. Das Projekt erklärt in seinen FAQ, dass eine verlorene Wallet-Instanz dauerhaft widerrufen und auf einem neuen Gerät neu eingerichtet werden muss. Der Statuslisten-Dienst für Wallet-Bestätigungen ist bereits Teil des Bounty-Umfangs; die separate Widerrufswebsite soll später folgen. Beide Funktionen gleichzusetzen würde den aktuellen Umfang falsch darstellen.

Eine andere Frage: die Architektur

Bei der Bundestagsanhörung über das Digitale Identitätengesetz am 6. Oktober kritisierte die Sachverständige Bianca Kastl in ihrer schriftlichen Stellungnahme die gewählte Cloud-Architektur. Ihrer Einschätzung nach kann ein Ausfall des entfernten kryptografischen Sicherheitsankers die Ausstellung und Vorlage von PID beeinträchtigen. Sie sieht zudem Risiken für die Privatsphäre, wenn signierte Identitätsdaten abfließen. Das sind ihre fachlichen Bewertungen einer Architekturentscheidung, keine durch das Bug-Bounty-Programm belegten Defekte.

Die Projekt-FAQ liefern die Gegenposition und bestätigen zugleich eine Abhängigkeit: Für die sichere PID-Ausweisfunktion ist in der aktuellen Architektur eine Internetverbindung nötig. Das Projekt begründet das serverbasierte Hardware-Sicherheitsmodul mit breiter Gerätekompatibilität. Personenbezogene Nachweise liegen nach seiner Darstellung verschlüsselt auf dem Smartphone; der Wallet-Anbieter könne weder die Identitätsdaten noch die geschützten Schlüssel selbst für eine Vorlage nutzen. Signierte Nachweise sollen verhindern, dass die ausstellende Stelle jede spätere Verwendung mitverfolgt. Diese Erläuterungen beantworten das Grundprinzip, veröffentlichen aber in den hier geprüften Unterlagen keinen Belastungsnachweis für einen längeren Ausfall des zentralen Dienstes.

Ein Bounty kann einen konkreten Fehler an einem freigegebenen Dienst sichtbar machen, etwa eine unberechtigte Signatur oder eine manipulierte Statusliste. Ob der gesamte Ausweisprozess bei Ausfall eines entfernten Sicherheitsankers weiter verfügbar bleibt, ist dagegen eine Frage von Architektur, Betrieb und Wiederanlauf. Last- und Verfügbarkeitstests sind nach den HackerOne-Regeln sogar vom öffentlichen Programm ausgenommen. Auch Kastls Datenschutzkritik verlangt eine gesonderte Bewertung der Datenflüsse und möglicher Folgen eines Datenabflusses. Eine hohe Prämie ersetzt diese Prüfungen nicht.

Welche Nachweise vor dem Start fehlen

Das BMDS kündigt eine Ausweitung des Testumfangs „in den kommenden Wochen“ an. Der am 10. Oktober 2026 eingesehene HackerOne-Text nennt für die vier späteren Komponenten aber noch keinen einzelnen Aufnahmetermin. Er beschreibt, dass eine Behebung vor öffentlicher Offenlegung bestätigt werden soll. Eine veröffentlichte Schwelle, wie viele oder welche Funde vor dem Produktivstart behoben und erneut geprüft sein müssen, findet sich dort und in der BMDS-Meldung nicht. Ebenso ist in diesen Unterlagen kein öffentlich datierter, unabhängiger Gesamttest der Wege von PID-Ausstellung über Vorlage bis zum Widerruf als Freigabebedingung dokumentiert. Das heißt nicht, dass intern keine weiteren Prüfungen stattfinden.

Das Bundesamt für Sicherheit in der Informationstechnik verweist in seiner Stellungnahme für den Bundestag auf Aufgaben bei Informationssicherheit und Zertifizierung und begrüßt offenen Quellcode für unabhängige Prüfungen. Die Projekt-FAQ nennen außerdem eine noch nicht öffentlich einsehbare technische Richtlinie und beschreiben die Cybersicherheitszertifizierung der betreibenden Organisation nach ISO/IEC 27001 als Prozess. Ob die Zertifizierung bereits abgeschlossen ist, geht daraus nicht hervor. Beides ist wichtig, aber weder eine datierte Aussage zum Bounty-Umfang noch ein veröffentlichter Befund für alle End-to-End-Abläufe.

Für künftige prüfende Dienste liegt der nächste überprüfbare Schritt daher im Sandbox-Test mit eigenen Anwendungsfällen: Stimmen die angeforderten Daten mit der Einwilligung überein, werden Signatur und Gültigkeit korrekt geprüft, und wird eine gesperrte Wallet zurückgewiesen? Nutzerinnen und Nutzer können vor einer Freigabe prüfen, welcher Dienst welche Angaben verlangt; nach Geräteverlust müssen sie die Wallet-Instanz widerrufen und auf dem neuen Gerät neu einrichten. Ob die angekündigten vier Komponenten rechtzeitig in den öffentlichen Test kommen und wie Befunde behoben werden, sollte bis zum Start am laufend aktualisierten Programmumfang und an veröffentlichten Prüfergebnissen messbar sein. Der derzeitige Umfang ist ein Anfang dieser Beweiskette, nicht ihr Abschluss.