Das erste echte Audit quelloffener Wallets: Lehren für Verifier

Die Schlagzeile und die Realität

"EU-Altersverifikations-App in 2 Minuten hackbar" — das war die Schlagzeile, die zwischen dem 15. und 17. April 2026 auf Reddit und in der Tech-Presse trendete. Mehr als 6.500 Upvotes verteilten sich auf r/europe, r/privacy, r/technology und r/BuyFromEU, und die Erzählung lautete: Scheitern. Die EU bringt ein Datenschutz-Werkzeug heraus, ein Forscher knackt es, Kritiker legen nach.

Wir lesen das anders. Der Offenlegungszyklus, der diese Schlagzeile produziert hat, ist exakt das, was öffentliche digitale Infrastruktur leisten soll. Er ist das stärkste Argument, das wir dieses Jahr dafür gesehen haben, warum kritische, staatsnahe Software quelloffen sein muss — und warum jeder Verifier, der sich an die EUDI Wallet anbindet, denselben Weg gehen sollte.

Für die technische Analyse dessen, was Paul Moore tatsächlich gefunden hat, siehe unsere ausführliche Aufarbeitung der Offenlegung zur EU-Altersverifikations-App. Dieser Beitrag ist das Argument eine Ebene darüber.

Wie der Zyklus tatsächlich verlief

Tag 0 — Die Europäische Kommission kündigt an, dass die Altersverifikations-App technisch bereit ist. Von der Leyen betont, dass der Code vollständig quelloffen ist und jeder ihn einsehen kann.

Tag 1 — Ein unabhängiger Sicherheitsforscher (Paul Moore) liest das öffentliche Android-Repository, identifiziert drei Design-Schwachstellen im Management des lokalen Zustands und veröffentlicht eine kurze Demonstration auf X.

Tag 2 — Reddit und die Fachpresse verstärken die Geschichte. Die Datenschutz- und Sicherheits-Communities vertiefen sich selbst in den Quellcode. Weitere Forscher reproduzieren die Befunde, präzisieren die Vorbehalte und trennen FUD von berechtigten Bedenken.

Tag 3 und folgende — Der Fix-Zyklus beginnt. Das EU-Referenzteam hat öffentlich eingereichte Issues. Fixes landen im Main-Branch, werden öffentlich reviewt und mit dem nächsten Release ausgeliefert.

Das ist ein funktionierender Audit-Kreislauf, und er hat drei Tage gebraucht. Proprietäre Software bewegt sich nicht so schnell, legt Schwachstellen nicht so öffentlich offen und erlaubt der Community nicht, Vertrauen schrittweise aufzubauen, indem sie liest, was warum behoben wird.

Wie eine Offenlegung bei einer geschlossenen Wallet stattdessen aussieht

Stellen Sie den EUDI-Wallet-Zyklus den Breach-Fällen gegenüber, die Identitätsverifikationsanbieter in den letzten Jahren durchlaufen haben. Blättert man die namhaften Vorfälle im Verifikationsmarkt durch, zeigt sich ein Muster:

• Der Anbieter entdeckt oder vermutet das Problem intern.
• Wochen oder Monate vergehen, bevor Außenstehende davon wissen.
• Die Behebung beginnt hinter verschlossenen Türen ohne öffentliche Details zu dem, was behoben wird.
• Die Offenlegung, wenn sie überhaupt erfolgt, ist entweder eine regulatorische Meldung im Nachgang oder eine Pressemitteilung, die den Umfang kleinredet.
• Endnutzer und Integratoren haben keine Möglichkeit zu prüfen, ob der Fix die Ursache adressiert, weil der Quellcode nicht öffentlich ist.

Das ist der Kontrafaktor. Eine geschlossene EU-Altersverifikations-App wäre mit denselben drei Fehlern ausgeliefert worden, die Paul Moore gefunden hat. Niemand außerhalb des Entwicklungsteams hätte davon gewusst. Die Fehler blieben unausgenutzt (oder von gut ausgestatteten Gegnern still ausgenutzt), bis ein öffentlicher Breach die Offenlegung erzwungen hätte. Der Fix-Zyklus wäre langsamer, das Vertrauen in das System geringer.

Welche konkreten Behauptungen Bestand hatten

Die technische Reaktion auf Reddit ist beachtenswert, weil sie dem Forscher nicht einfach zugestimmt hat. Sie stimmte Teilen seiner Behauptung zu, widersprach Teilen der Einordnung und ergänzte Beobachtungen, die er ausgelassen hatte.

Valide Kritik, korrekt berichtet. Drei Design-Schwachstellen im Management des lokalen Zustands auf einem gerooteten, physisch kompromittierten Gerät. Real und werden behoben.

Einordnungs-Pushback aus dem technischen Publikum. Mehrere hoch-upgevotete Kommentare quer durch die Subreddits wiesen darauf hin, dass "gerootetes Gerät mit physischem Zugriff" ein deutlich engeres Bedrohungsmodell ist als "in 2 Minuten gehackt" impliziert. Der Kommentar mit 832 Upvotes auf r/europe stellte schlicht fest: "So soll Open-Source-Software funktionieren."

Zusätzliche Anliegen aus der Community. Die Verpflichtung, auf Plattform-Attestierung zu setzen (was iOS oder Android erzwingt), die Abhängigkeit von Google Play Services im Android-Build, das Fehlen eines Pfads für freie Clients — all das haben Community-Mitglieder aus demselben Quellcode herausgelesen. Das sind strategisch ernstere Themen als die Local-State-Bugs, und in einer geschlossenen Implementierung wären sie unsichtbar gewesen.

Informiertes technisches Lob. Der ungarische Entwickler-Thread auf r/programmingHungary trug die technisch fundierteste Diskussion, die wir gesehen haben: korrekte Identifikation des zugrundeliegenden Stacks aus OpenID Verifiable Credentials plus selektiver Offenlegung via OpenID4VP, Anerkennung, dass die Datenschutz-Architektur zu den besseren Designs im Altersverifikationsraum zählt, und gleichzeitig Kritik an der Abhängigkeit von Google Play Services. Eine derart nuancierte öffentliche Bewertung ist gegen geschlossenen Code schlicht nicht möglich.

Warum das speziell für Verifier relevant ist

Wer einen Verifier baut, der produktiv EUDI-Wallet-Attestierungen konsumieren wird, dessen Kunden werden den Offenlegungszyklus, den Sie gerade beobachtet haben, zum Maßstab machen. Händler und Endnutzer lesen Ihren Quellcode nicht. Sie lesen über Breaches, Fixes und wie schnell diese erfolgten. Ein quelloffenes Verifier-SDK, das Fehler öffentlich behebt, erbt die vertrauensbildenden Eigenschaften des Wallet-Ökosystems, in dem es mitspielt.

Wir haben OpenEUDI auf genau diesem Prinzip gebaut. Jede Zeile der Verifier-Logik ist MIT-lizenziert und öffentlich auditierbar. Findet jemand einen Fehler, kann er ihn melden, wir beheben ihn öffentlich, und jeder Integrator sieht den Fix. Wer verstehen möchte, wie wir einen kniffligen Grenzfall in OpenID4VP handhaben, liest den Code statt unserem Marketing zu vertrauen. Das OpenEUDI SDK Quickstart-Tutorial führt durch dieselbe Implementierung, die ein Sicherheitsforscher auditieren würde.

Das Souveränitätsargument

Es gibt ein zweites Argument, das nichts mit Bugs zu tun hat. Die EU hat über Jahre eine Position zur digitalen Souveränität artikuliert: Die Identitätsdaten europäischer Bürger, die kryptografischen Schlüssel europäischer Institutionen, die Audit-Rechte europäischer Regulierer sollten nicht von Software abhängen, deren Quellcode niemand außerhalb eines ausländischen Anbieters einsehen kann.

Die einzige ehrliche Schlussfolgerung aus dieser Position: Jede von der EU mandatierte Identitätsinfrastruktur muss quelloffen sein. Nicht Open Source als Marketing-Floskel, sondern quelloffener, reproduzierbar baubarer und community-auditierbarer Code. Alles darunter hinterlässt eine Souveränitätslücke, die kein Zertifikatsstapel schließt.

Die EU hat diese Schlussfolgerung mit der Wallet und der Altersverifikations-App ernst genommen. Verifier-Infrastruktur sollte sie genauso ernst nehmen. Ein Verifier, der quelloffenen Wallet-Attestierungen vertraut, aber selbst geschlossenen Code betreibt, ist bestenfalls inkonsistent und schlimmstenfalls strategisch fragil.

Was "Open Source" für einen Verifier bedeuten sollte

Um Missverständnisse zu vermeiden: "Open Source" ist eine notwendige, aber nicht hinreichende Bedingung. Ein quelloffener Verifier sollte auch:

Auditierbar sein, nicht nur lesbar. Code ohne Testabdeckung oder mit undurchsichtigen Abhängigkeitsketten ist technisch lesbar, aber praktisch nicht auditierbar. Der Entwurf des ENISA-Zertifizierungsschemas fasst diesen Unterschied im Wallet-Kontext gut, und derselbe Maßstab gilt für Verifier.

Fehler öffentlich beheben. Ein privater Fix an einem öffentlichen Repository ist nur die halbe Miete. Issue-Tracker, öffentliche Pull Requests und transparente Changelogs sind das, was den Audit-Kreislauf am Laufen hält.

Beiträge annehmen. Externen Forschern das Einbringen von Fixes zu erlauben, hält die Maintainer ehrlich und die Community investiert.

Eine permissive Lizenz behalten. MIT, Apache 2.0 oder eine ähnlich permissive Lizenz. Copyleft-Lizenzen sind philosophisch verteidigbar, begrenzen aber praktisch, wer sich mit Ihrem Code integrieren wird.

Lehren für die Verifier-Seite

Die Offenlegung vom April 2026 hinterlässt drei dauerhafte Lehren für alle, die auf dem EUDI-Wallet-Ökosystem aufbauen.

Auditierbaren Code verwenden. Ob Sie unser OpenEUDI SDK, eine andere offene Implementierung oder eine eigene Lösung einsetzen: Wählen Sie einen Stack, den Sicherheitsforscher lesen können. Liefert Ihr Verifier geschlossenen Code aus, akzeptieren Sie den zuvor beschriebenen Fehlermodus: langsamere Fixes, geringeres Vertrauen, kein Pfad für externe Beiträge.

Lassen Sie das Ökosystem einen Teil Ihrer Sicherheitsarbeit übernehmen. Zu lesen, was Forscher in verwandten Open-Source-Projekten finden — die Wallet, die Altersverifikations-App, die Referenz-Verifier — gehört zu den Sicherheitsaktivitäten mit dem höchsten Hebel, die einem Verifier-Team zur Verfügung stehen. Sie bekommen Befunde, bevor daraus Vorfälle werden.

Datenschutz-Architektur und Implementierungsfehler trennen. Kritiker, die sagen "die EU-Altersverifikations-App hat Fehler, also ist der ganze datenschutzorientierte Ansatz kaputt", liegen falsch. Das kryptografische Design ist solide. Die Fehler liegen im Management des lokalen Zustands, nicht im Protokoll. Wie man auf denselben datenschutzfreundlichen Primitiven aufbaut, zeigt Datenschutzorientierte Altersverifikation mit OpenEUDI.

Der stille Gewinn

Wenn aus dieser ganzen Episode ein Satz bleiben soll, dann derjenige, den der meistgelikete Kommentator auf r/europe schrieb: "So soll Open-Source-Software funktionieren." Das ist keine Verteidigung der Bugs. Es ist die Beschreibung des Systems, das sie findet und behebt. Dieses System ist besser als die Alternative — und der Abstand wächst mit jedem geschlossenen Anbieter, der einen Breach nach altem Muster abarbeitet.

Die EU hat sich verpflichtet, ihre Identitätsinfrastruktur offen zu bauen. Verifier-Entwickler sollten dieselbe Verpflichtung eingehen. Den aktuellen Stand dieser Infrastruktur über alle 27 Mitgliedstaaten hinweg zeigt unser Rollout-Tracker für April 2026, und den regulatorischen Rahmen darunter unser Erklärstück zur Durchführungsverordnung 2026/798.

---

OpenEUDI ist MIT-lizenziert, auditierbar und kostenlos. Für produktive Verifikation mit verwalteten WRPAC-Zertifikaten und einer vollständig quelloffenen Codebasis siehe eIDAS Pros Managed Plans.