De eerste echte audit van open-source wallets: lessen voor verifiers

De kop en de realiteit

"EU-leeftijdsverificatie-app kan in 2 minuten worden gehackt" was de kop die tussen 15 en 17 april 2026 trendde op Reddit en in de techpers. Meer dan 6.500 upvotes verspreid over r/europe, r/privacy, r/technology en r/BuyFromEU kaderden het verhaal als een mislukking — de EU levert een privacytool, een onderzoeker breekt hem, critici storten zich erop.

Wij lezen dit anders. De openbaarmakingscyclus die deze kop heeft opgeleverd, is precies wat publieke digitale infrastructuur hoort te doen. Het is het sterkste argument dat we dit jaar hebben gezien voor waarom kritieke, overheidsgerelateerde software open source moet zijn, en waarom elke verifier die integreert met de EUDI-wallet dezelfde weg zou moeten volgen.

Voor de technische analyse van wat Paul Moore daadwerkelijk heeft gevonden, zie onze gedetailleerde uiteenzetting van de onthulling rond de EU-leeftijdsverificatie-app. Deze post is het argument een niveau hoger.

Hoe de cyclus daadwerkelijk verliep

Dag 0 — De Europese Commissie kondigt aan dat de leeftijdsverificatie-app technisch klaar is. Von der Leyen benadrukt dat de code volledig open source is en dat iedereen hem kan inspecteren.

Dag 1 — Een onafhankelijke beveiligingsonderzoeker (Paul Moore) leest de publieke Android-repository, identificeert drie ontwerpfouten in het beheer van de lokale status, en publiceert een korte demonstratie op X.

Dag 2 — Reddit en de vakpers versterken het verhaal. De privacy- en securitygemeenschappen duiken zelf in de broncode. Andere onderzoekers reproduceren de bevindingen, verduidelijken de kanttekeningen, en scheiden FUD van legitieme zorgen.

Dag 3 en verder — De fix-cyclus begint. Bij het EU-referentieteam worden publieke issues ingediend. Fixes komen terecht in de main branch, worden publiekelijk beoordeeld, en verschijnen in de volgende release.

Dat is een functionerende auditlus, en het kostte drie dagen. Closed-source software beweegt niet zo snel, brengt fouten niet zo publiekelijk aan het licht, en laat de gemeenschap niet toe geleidelijk vertrouwen op te bouwen door te lezen wat er wordt gerepareerd en waarom.

Hoe een onthulling bij een gesloten wallet er in plaats daarvan uitziet

Vergelijk de cyclus van de EUDI-wallet met hoe datalekken bij aanbieders van identiteitsverificatie zich historisch hebben ontvouwen. Blader door willekeurig welk spraakmakend incident in de verificatiesector van de afgelopen jaren, en een patroon dient zich aan:

• De aanbieder ontdekt of vermoedt intern een probleem.
• Er verstrijken weken of maanden voordat een externe partij ervan weet.
• De remediëring begint achter gesloten deuren, zonder publieke details over wat er wordt gerepareerd.
• De onthulling, als die al plaatsvindt, is ofwel een regelgevende melding achteraf ofwel een persverklaring die de omvang bagatelliseert.
• Eindgebruikers en integrators hebben geen manier om te verifiëren of de fix de oorzaak aanpakt, omdat de bron niet publiek is.

Dit is het tegenfeitelijke scenario. Een closed-source EU-leeftijdsverificatie-app zou zijn uitgeleverd met dezelfde drie fouten die Paul Moore vond. Niemand buiten het ontwikkelteam zou het weten. De fouten zouden onbenut blijven liggen (of stilletjes worden misbruikt door goed uitgeruste tegenstanders) totdat een publiek datalek onthulling zou afdwingen. De fix-cyclus zou langzamer zijn. Het vertrouwen in het systeem zou lager zijn.

De specifieke beweringen die overeind bleven

De technische reactie op Reddit verdient aandacht, omdat die het niet simpelweg eens was met de onderzoeker. Ze was het eens met delen van zijn bewering, oneens met delen van de framing, en voegde observaties toe die hij had gemist.

Terechte kritiek, correct gerapporteerd. Drie ontwerpfouten in het beheer van de lokale status op een gerooted, fysiek gecompromitteerd apparaat. Deze zijn reëel en zullen worden gerepareerd.

Weerstand tegen de framing vanuit het technische publiek. Meerdere hoog gewaardeerde reacties op verschillende subreddits wezen erop dat "gerooted apparaat met fysieke toegang" een aanzienlijk enger dreigingsmodel is dan "in 2 minuten gehackt" suggereert. De reactie met 832 upvotes op r/europe merkte simpelweg op: "zo hoort open-source software te werken."

Bijkomende zorgen naar boven gebracht door de gemeenschap. De vereiste om te vertrouwen op platformattestatie (wat iOS of Android afdwingt), de afhankelijkheid van Google Play Services in de Android-build, en het ontbreken van een pad voor libre clients — allemaal naar voren gebracht door community-leden die dezelfde broncode lazen. Dit zijn strategisch ernstiger kwesties dan de bugs in de lokale status, en ze zouden onzichtbaar zijn geweest in een gesloten implementatie.

Geïnformeerde technische lof. De Hongaarse ontwikkelaarsthread op r/programmingHungary bevatte de technisch meest onderlegde discussie die we zagen: correcte identificatie van de onderliggende stack van OpenID Verifiable Credentials plus selectieve openbaarmaking via OpenID4VP, erkenning dat de privacyarchitectuur een van de betere ontwerpen is in de leeftijdsverificatiesector, en tegelijkertijd kritiek op de afhankelijkheid van Google Play Services. Dat soort genuanceerde publieke evaluatie kan simpelweg niet plaatsvinden tegenover gesloten code.

Waarom dit specifiek belangrijk is voor verifiers

Als u een verifier bouwt die in productie EUDI-wallet-attestaties zal verwerken, is de openbaarmakingscyclus die u zojuist heeft gezien de cyclus waarop uw klanten u zullen beoordelen. Handelaren en eindgebruikers zullen uw broncode niet lezen. Ze zullen lezen over datalekken, fixes, en hoe snel die plaatsvonden. Een open-source verifier-SDK dat bugs publiekelijk repareert, erft de vertrouwenopbouwende eigenschappen van het wallet-ecosysteem waaraan het deelneemt.

We hebben OpenEUDI op dit principe gebouwd. Elke regel van de verifier-logica is MIT-gelicentieerd en publiekelijk auditeerbaar. Wanneer iemand een fout vindt, kan hij die indienen, repareren wij die publiekelijk, en ziet elke integrator de fix. Wanneer iemand wil begrijpen hoe wij een lastig randgeval in OpenID4VP afhandelen, kan hij de code lezen in plaats van op ons marketingverhaal te vertrouwen. De OpenEUDI SDK-quickstart-tutorial doorloopt dezelfde implementatie die een beveiligingsonderzoeker zou auditeren.

Het soevereiniteitsargument

Er is een tweede argument dat niets met bugs te maken heeft. De EU heeft jarenlang gewerkt aan het onderbouwen van digitale soevereiniteit: de identiteitsgegevens van Europese burgers, de cryptografische sleutels van Europese instellingen, en de auditrechten van Europese regelgevers zouden niet afhankelijk moeten zijn van software waarvan niemand buiten een buitenlandse leverancier de broncode kan lezen.

De enige eerlijke conclusie vanuit dit standpunt is dat alle door de EU verplichte identiteitsinfrastructuur open source moet zijn. Niet open source als marketingterm, maar code die beschikbaar is als broncode, reproduceerbaar te bouwen is, en door de gemeenschap auditeerbaar is. Alles minder daarvan laat een soevereiniteitskloof achter die geen enkele hoeveelheid certificeringspapierwerk kan opvullen.

De EU heeft die conclusie serieus genomen met de wallet en de leeftijdsverificatie-app. Verifier-infrastructuur zou dat net zo serieus moeten nemen. Een verifier die vertrouwt op open-source wallet-attestaties, maar zelf closed-source code draait, is in het beste geval inconsistent en in het slechtste geval strategisch fragiel.

Wat "open source" zou moeten betekenen voor een verifier

Om duidelijk te zijn: "open source" is een noodzakelijke maar geen voldoende voorwaarde. Een open-source verifier zou ook het volgende moeten doen:

Auditeerbaar zijn, niet alleen leesbaar. Code zonder testdekking of met ondoorzichtige afhankelijkheidsketens is technisch leesbaar, maar in de praktijk niet auditeerbaar. Het concept van het ENISA-certificeringsschema legt dit onderscheid vast in de context van wallets, en dezelfde norm geldt voor verifiers.

Fouten publiekelijk repareren. Een privéfix in een publieke repository is maar de halve waarde. Issue-trackers, publieke pull requests, en transparante changelogs zijn wat de auditlus laat werken.

Bijdragen accepteren. Externe onderzoekers toestaan om fixes door te voeren, houdt de maintainer eerlijk en de gemeenschap betrokken.

Een permissieve licentie behouden. MIT, Apache 2.0, of een vergelijkbaar permissieve licentie. Copyleft-licenties zijn filosofisch verdedigbaar, maar beperken in de praktijk wie zich met uw code zal integreren.

Lessen voor de verifier-kant

De onthulling van april 2026 laat drie blijvende lessen na voor iedereen die bouwt bovenop het EUDI-wallet-ecosysteem.

Gebruik auditeerbare code. Of u nu ons OpenEUDI SDK gebruikt, een andere open implementatie, of uw eigen oplossing bouwt: kies een stack die beveiligingsonderzoekers kunnen lezen. Als uw verifier in closed source wordt uitgeleverd, accepteert u het eerder beschreven faalmodel: langzamere fixes, minder vertrouwen, geen pad voor externe bijdragen.

Laat het ecosysteem een deel van uw securityreview voor u doen. Lezen wat onderzoekers vinden in verwante open-sourceprojecten — de wallet, de leeftijdsverificatie-app, de referentie-verifiers — is een van de meest hefboomwerkende securityactiviteiten die een verifier-team ter beschikking staan. U krijgt bevindingen voordat ze incidenten worden.

Scheid privacyarchitectuur van implementatiefouten. De critici die zeggen "de EU-leeftijdsverificatie-app heeft bugs, dus de hele privacybeschermende aanpak is stuk" hebben ongelijk. Het cryptografische ontwerp is solide. De bugs zitten in het beheer van de lokale status, niet in het protocol. Zie Privacy-first leeftijdsverificatie met OpenEUDI voor hoe u kunt bouwen op dezelfde privacybeschermende primitieven.

De stille overwinning

Als er één zin is om uit deze hele episode mee te nemen, is het de zin die de meest gewaardeerde commentator op r/europe schreef: "zo hoort open-source software te werken." Dat is geen verdediging van de bugs. Het is een beschrijving van het systeem dat ze vindt en repareert. Dat systeem is beter dan het alternatief, met een marge die groter wordt elke keer dat een closed-source leverancier een datalek heeft en dat op de oude manier afhandelt.

De EU heeft zich ertoe verbonden haar identiteitsinfrastructuur in het openbaar te bouwen. Bouwers van verifiers zouden dezelfde verbintenis moeten aangaan. Voor de huidige stand van die infrastructuur over de 27 lidstaten heen, zie onze uitroltracker van april 2026, en voor het regelgevende kader eronder, zie onze uitleg over Uitvoeringsverordening 2026/798.

---

OpenEUDI is MIT-gelicentieerd, auditeerbaar en gratis. Voor productieverificatie met beheerde WRPAC-certificaten en een volledig open-source codebase, zie de beheerde plannen van eIDAS Pro.