Jouw nationale eID draait op crypto uit 1999. En dat is niet het ergste.

Toen ik de getallen voor het eerst las, dacht ik dat ik iets verkeerd begrepen had. 2,5 miljard queries per jaar. De centrale autoriteit van het Oostenrijkse eID-systeem verwerkt jaarlijks 2,5 miljard verzoeken om sector-specifieke pseudoniemen te genereren. Burgers, overheidsdiensten, banken, zorgverleners — elke authenticatie loopt via één centrale instantie.

En dat allemaal op 3DES en SHA-1.

Voor wie niet dagelijks met cryptografie bezig is: 3DES werd in 2005 officieel deprecated verklaard door NIST. Sinds 2023 is het expliciet verboden in nieuwe systemen onder NIST SP 800-131A. SHA-1 is sinds 2017 praktisch gebroken — het SHAttered-onderzoek toonde aan dat je met voldoende rekenkracht twee verschillende documenten met dezelfde hash kunt produceren.

Dit is geen academisch randprobleem. Dit is een in productie zijnde nationale identiteitsinfrastructuur die draait op cryptografische primitieven die al twee decennia als onveilig gelden. En ik durf te wedden dat Nederland niet significant beter is.

Het echte probleem: de centrale autoriteit als metadata-magneet

Een nieuw paper van het AIT Austrian Institute of Technology — gepubliceerd op ACM Asia CCS 2026 — stelt een fundamentele herziening voor. De auteurs Krenn, Lesaignoux en Ramacher introduceren bPk#, een gedistribueerd raamwerk voor delegatable pseudonyms in nationale eID-systemen.

Het Oostenrijkse bPk-systeem ("bereichsbezogene Personenkennzeichen") is op papier een goed idee: in plaats van één universele persoonsidentifier (zoals een BSN) krijgt elke burger per sector een uniek pseudoniem. De Belastingdienst ziet een andere identifier dan de zorgverzekeraar. Dat is privacy-by-design in de meest fundamentele zin — dataminimalisatie en purpose limitation, precies zoals de GDPR voorschrijft.

Het probleem is de architectuur. De huidige bPk wordt berekend als Hash(SymEnc(sk, uid), SP) — de centrale autoriteit versleutelt je burgerservicenummer, hasht het resultaat samen met een service provider-identifier, en stuurt het pseudoniem terug. Simpel, elegant, en volledig gecentraliseerd.

Daarmee wordt de centrale autoriteit een metadata honeypot. Die ene instantie ziet élke authenticatiepoging: wie authenticeert zich bij welke dienst, wanneer, hoe vaak. Een kwaadwillende met read-only toegang tot die database kan gedragsprofielen van miljoenen burgers samenstellen. Dat is geen theoretisch risico — het is een architectural inevitability van gecentraliseerd design.

Daarnaast is het een single point of failure. Een DDoS-aanval of niet-kwaadaardige storing bij de centrale autoriteit betekent dat er géén publieke of private dienst pseudoniemen meer kan ophalen. Met 2,5 miljard queries per jaar is dat een nationaal continuïteitsrisico geworden.

bPk#: drie operationele patronen in plaats van één

Wat het paper voorstelt is architectonisch verfijnder dan "laten we de centrale autoriteit afschaffen." Dat is precies waarom het interessant is voor publieke sector-architecten. bPk# introduceert een federated trust model met drie operationele patronen:

1. De gebruiker berekent zelf. Burgers krijgen cryptografisch key-materiaal en kunnen lokaal een pseudoniem voor elke service provider berekenen. De centrale autoriteit hoeft niet te zien dát iemand bij een bepaalde dienst inlogt. Metadata-observatie daalt drastisch.

2. Trusted service providers berekenen binnen hun domein. Publieke instanties mogen onder regulering — mét HSM-logging, purpose binding, en juridische grondslag — pseudoniemen genereren voor gebruikers binnen hun eigen domein. Dat verlaagt de beschikbaarheidsafhankelijkheid van de centrale autoriteit zonder de controle te verliezen.

3. De centrale autoriteit behoudt uitzonderingsmacht. Voor cross-domain linking (bijvoorbeeld tussen gemeente en Belastingdienst) en deanonymisatie bij misbruik of overlijden blijft de centrale autoriteit de enige partij die kan linken of re-identificeren. Het model is: central authority as accountable trust anchor, not as always-online metadata broker.

Dit is géén naïef self-sovereign identity-verhaal waarin de overheid verdwijnt. Het is een federated trust model — precies de balans die publieke organisaties nodig hebben tussen privacy, rechtsstatelijke verantwoording en operationele continuïteit.

De cryptografische truc: een pseudoniem als gedeelde sleutel

Technisch is de kern verrassend elegant. Een pseudoniem is in bPk# niets anders dan een gedeelde sleutel uit een non-interactive key exchange (NIKE) tussen gebruiker en service provider. De gebruiker combineert zijn geheime sleutel met de publieke sleutel van de service provider — en de service provider combineert zijn geheime sleutel met de publieke sleutel van de gebruiker. Ze komen allebei op dezelfde waarde uit. Die commutativiteit is de fundamentele eigenschap die het systeem laat werken.

Voor authenticiteit krijgt de gebruiker een handtekening van de centrale autoriteit op zijn publieke sleutel. Bij elke pseudoniemgeneratie levert hij een zero-knowledge proof die bewijst: "ik heb een geldige handtekening én ik heb de juiste NIKE-sleutel gebruikt" — zonder zijn identiteit te onthullen.

De concrete instantiatie gebruikt BLS12-381 pairings (dezelfde curve als Ethereum 2.0), Groth1 structure-preserving signatures, Diffie-Hellman key exchange, en Schnorr-style NIZK proofs. De benchmarks zijn overtuigend: gemiddeld 4,94 ms voor pseudoniemgeneratie en 7,61 ms voor verificatie op een Intel i7-1265U uit 2022. Alle operaties onder 20 ms.

Wat nog ontbreekt: de governance-laag

Het paper is cryptografisch sterk, maar geen productieblauwdruk. Ik zie vijf open risico's:

Key lifecycle governance. Het huidige systeem voorziet geen opt-out, revocation of key rotation. De auteurs noemen tijdsafhankelijke epochs en stabiele user-identifiers als mogelijk mechanisme, maar werken dat niet uit. Voor nationale eID met levenslange identiteiten is key rotation geen nice-to-have — het is een harde eis. Wat gebeurt er bij device loss, overlijden, curatele, compromis, en cross-border portability?

Trusted service provider abuse. Als service providers zelf pseudoniemen mogen berekenen, kunnen ze in theorie pseudoniemen voor álle gebruikers binnen hun domein genereren. HSM-logging is noodzakelijk maar niet voldoende. Je hebt ook policy-as-code, purpose binding, rate limits, anomaly detection, en onafhankelijk auditeerbare transparency logs nodig.

Centrale autoriteit blijft een trust anchor. De metadata-observatie daalt, maar de machtsconcentratie verdwijnt niet. Dat is waarschijnlijk correct voor nationale eID — maar moet expliciet in DPIA's, threat models en wetgeving worden vastgelegd.

Post-quantum readiness. De BLS12-381 pairing-curve is niet post-quantum veilig. De auteurs noemen post-quantum bouwblokken als toekomstig werk. Voor een nationale eID-architectuur met een levensduur van tientallen jaren is dat geen detail maar een strategische migratie-eis.

Wallet usability en recovery. Burgers kunnen niet verantwoordelijk worden gemaakt voor het backuppen van fundamentele identity-keys — de paper erkent dit en kiest bewust voor centrale key generation. Maar de recovery-vragen (device loss, kind-volwassene transitie, cross-border portability) zijn nog onbeantwoord.

Nederlandse relevantie: eIDAS 2.0 en de EUDI Wallet

Nederland staat aan de vooravond van eIDAS 2.0. De herziene European Digital Identity Regulation (EU 2024/1183) verplicht lidstaten tot een European Digital Identity Wallet. Nederland bouwt de NL wallet.

Het risico is dat EUDI Wallets in de praktijk alsnog metadata-intensief worden. Authenticatie, credential presentation, relying-party logging, issuer-dependencies — als die niet architectonisch worden geminimaliseerd, bouw je gewoon een nieuwe centrale correlatielaag met een moderne UI.

bPk# biedt een conceptueel tegenmodel: laat de burger of wallet lokaal domeinspecifieke pseudoniemen berekenen, met cryptografische verifieerbaarheid en zonder centrale online correlatie bij elke transactie. Het is geen vervanging van OIDC4VP of de EUDI Wallet ARF — maar wel een waardevolle bouwsteen voor privacy-preserving relying-party identifiers, sectorale pseudoniemen, en offline verifieerbare credential-presentaties.

De architectuur die ik hier voor me zie is:

• EUDI Wallet of NL wallet als user-facing container
• OIDC4VP, SD-JWT VC of ISO mdoc voor credential presentation
• bPk#-achtig mechanisme voor sectorale pseudoniemen per relying party
• Centrale autoriteit alleen voor issuance, legal opening en exceptional processing
• HSM of confidential computing voor service-provider-side pseudonym generation
• Transparency log voor alle niet-user-initiated pseudonym computations
• Policy engine voor purpose, legal basis, sector en dataminimalisatie
• Post-quantum migration lane vanaf dag één

Van Own your ID naar Own your AI

Deze paper raakt aan een fundamenteler principe dat ik al langer uitwerk: "Own your ID." Maar met een belangrijke nuance.

"Own your ID" moet niet betekenen dat de burger alle cryptografische en juridische verantwoordelijkheid draagt. Dat is operationele last dumpen op mensen die daar niet voor zijn toegerust. De juiste definitie is: Own your ID = controle over gebruik, zichtbaarheid en delegatie van identiteit, niet volledige operationele last van identity-infrastructuur.

bPk# belichaamt dit. Gebruikers krijgen meer lokale controle over pseudoniemgeneratie — maar publieke waarborgen blijven in stand. De centrale autoriteit verdwijnt niet, maar verschuift van always-online metadata broker naar accountable trust anchor.

Voor "Own your AI" is de analogie even krachtig. Net zoals identiteit niet volledig centraal en niet volledig individueel moet zijn, moet AI-autorisatie ook niet volledig in één platform of volledig bij losse agents liggen. Je wilt delegation with verifiable constraints.

Vertaald naar agentic AI in de publieke sector:

• Een agent krijgt géén universele identity-token
• Een agent krijgt domeinspecifieke, doelgebonden pseudonieme bevoegdheid
• Elke actie is cryptografisch of auditbaar aan een mandaat gekoppeld
• De centrale policy authority ziet niet alles, maar kan onder voorwaarden openen
• Service providers mogen alleen binnen hun domein handelen

Dat is het patroon voor soevereine agentic AI in overheid en gereguleerde sectoren. Geen anarchistisch AI-model waarin agents vrij rondzwerven, geen panopticon waarin één partij alles ziet. Een federated trust model voor AI — precies wat bPk# doet voor digitale identiteit.

Mijn oordeel

8,5/10 als academische en architecturale bijdrage. 6,5/10 als directe productieblauwdruk.

De echte waarde van deze paper zit niet in de cryptografie — hoe elegant die ook is. De waarde zit in het ontwerpprincipe: central authority as accountable trust anchor, not as always-online metadata broker. Dat is het architecturale inzicht dat Nederlandse eID-architecten nu moeten internaliseren, terwijl we aan de vooravond staan van eIDAS 2.0.

De vervolgvraag is niet "kunnen we dit cryptografisch?" — die is met dit paper beantwoord. De vervolgvraag is: welke governance-, audit-, key lifecycle- en legal opening-processen maken dit betrouwbaar genoeg voor publieke productie?

Daar ligt het echte werk. En daar ligt ook precies waarom ik dit soort analyses maak. Niet om papers samen te vatten — maar om de architectuurprincipes te extraheren die bepalen of een systeem over tien jaar nog veilig is.

---

Wilt u weten hoe de cryptografische architectuur van uw eID-systeem zich verhoudt tot de state-of-the-art? Neem contact op voor een vrijblijvend gesprek.