Je bent hier · Sleutels — het custody-dossier · sessie 08-08-2026 · PDF v1.2 offline gehaald 14-08-2026 — sprak nog over "beide sleutels" terwijl het model er drie kent; naar archief/downloads/
Wat is dit Het sleuteldossier: wie welke sleutel heeft, waar die ligt, en wat “wij kunnen er zelf niet in” vandaag echt betekent.
Voor wie Voor het gesprek met de advocaat over bewaring, en voor jezelf om de belofte eerlijk te houden.
Wat doe je hier Lees eerst wat er vandaag waar is; wat nog gebouwd moet worden staat er apart bij.
Deze pagina draagt de PRE-LAUNCH-GATE D11 en was tot vandaag alleen via kruisverwijzingen te vinden — vanaf v0.96.0 staat ze als 🔑 in het hoofdmenu van elke pagina.
De hartader van R4M is één belofte: niemand kan twee keer intekenen, en de identiteit gaat alleen open onder gerechtelijk bevel. Die belofte hangt af van waar de geheime sleutels bewaard worden. Vandaag staan ze allebei gewoon bij onszelf op de server: dat maakt de belofte beleid, geen techniek. En let op de precisie, ook ná de verbouwing: voor de sleutel op het bewijs wordt "openen kan niet zonder een tweede partij" een architectuurfeit, maar voor de afleidingssleutel blijft het toegangscontrole — zie 4a. Wie die twee door elkaar haalt, doet een half-ware claim. Deze pagina legt vast wat er moet veranderen, bij wie de sleutels moeten komen te liggen, welke vragen naar advocate Nele gaan, en wat er vandaag al gecontroleerd en gefixt is.
De kern in één beeld — van "beide sleutels bij ons" naar "sleutels het huis uit"
Simpel gezegd: onderzoekers lieten een AI proberen sloten te kraken. Ons soort slot (SHA-256) kraakte niet. Maar het gesprek erover deed ons beseffen: het slot is prima — alleen ligt de sleutel onder onze eigen deurmat.
Simpel gezegd: een hash is een gehaktmolen voor gegevens: identiteit erin, altijd hetzelfde "gehakt" (een code) eruit — maar van gehakt kan je nooit meer de koe terugbouwen. Omdat dezelfde persoon altijd hetzelfde gehakt oplevert, zien we meteen: "die is hier al geweest" — zonder ooit te weten wie het is. En voor de politie ligt er een apart, verzegeld envelopje met de echte identiteit, dat alleen met een gerechtelijk bevel opengaat.
Er is dus geen extra "doorzoekbaarheid" nodig in de versleuteling. Het ontwerp levert alles al. Alleen de bewaring van de twee sleutels is fout.
Simpel gezegd: we beloven klanten dat we niet in hun dagboek kunnen kijken — maar de sleutel van het dagboekkastje hangt bij ons aan de muur. We kijken niet, maar we kúnnen wel. Dat moet worden: we hebben de sleutel niet eens meer.
4a · Sleutel 1 — IDENTITY_SALT → een KMS (Key Management Service). Een clouddienst waar de sleutel in beveiligde hardware (HSM) leeft. "Non-exportable" = de sleutel kan die hardware fysiek nooit verlaten — ook wijzelf niet, ook personeel van de provider niet. De app stuurt bij elke registratie de eID-code naar de KMS; de berekening gebeurt dáár, in de hardware; alleen het pseudoniem komt terug. Kostprijs: ± €1/maand per sleutel plus fracties van een cent per berekening.
⚠ Wat de KMS wél en niet oplost — zeg dit precies zo, ook als het minder sterk klinkt.
Wat je wint: de sleutel kan niet meer gestolen of gekopieerd worden, en elk doorrekenen is gelogd en gelimiteerd. Massaal of stiekem re-identificeren kan daardoor niet meer onopgemerkt gebeuren.
Wat blijft: wie onze KMS-toegang heeft, kan één kandidaat-identiteit gericht doorrekenen en de uitkomst tegen het register leggen. Dat blijft toegangscontrole, geen structurele onmogelijkheid — en dat zeggen we ook zo.
Waarom dit onderscheid ertoe doet: "wij kunnen structureel niet terug" is wél waar voor sleutel 2 hieronder, want daar heb je een tweede partij nodig die je niet kunt omzeilen. Die zin over sleutel 1 zeggen is een half-ware claim, en een half-ware claim haalt het hele verhaal onderuit bij de eerste technische vraag. Deel A zegt het al in dezelfde bewoording: toegangscontrole, niet structurele onmogelijkheid.
Simpel gezegd: een KMS is een kluis in een zwaarbewaakt gebouw. Wij mogen briefjes onder de deur schuiven ("bereken dit even") en krijgen het antwoord terug — maar de kluis zelf gaat voor niemand open, ook niet voor ons of hun eigen personeel. Het verschil met sleutel 2: de briefjes blíjven werken, ze worden alleen allemaal geteld. HSM = de gepantserde computerkast waarin dat gebeurt.
4b · Sleutel 2 — AUDIT_EVIDENCE_KEY → escrow / sleutelsplitsing. De evidence-sleutel gaat uit onze handen via splitsing 2-van-3: bv. R4M + ARTES (Nele) + een auditor of notaris. Openen kan alleen mét een tweede partij — exact de "enkel autoriteit"-eis.
Simpel gezegd: knip de sleutel in drie stukken en geef ze aan drie verschillende mensen. Het slot opent pas als er minstens twee hun stuk samenleggen. Eén iemand alleen — ook wijzelf — kan dus nooit stiekem openen.
4c · Sleutel 3 — de handtekeningsleutel van de uitgever (issuer signing key). Zodra R4M attestaties uitgeeft die anderen kunnen nakijken (SD-JWT / verifiable credentials, blokken D1 en D8), wordt elke attestatie ondertekend met een private sleutel. Die sleutel stond tot nu toe nergens in dit custody-verhaal, en dat was een gat. Zelfde regime als sleutel 1: niet-exporteerbaar, ondertekening gebeurt binnen de hardware, plus een rotatie- en intrekkingsplan — wat gebeurt er met alle uitgegeven attestaties als de sleutel toch verdacht raakt. Dit moet geregeld zijn vóór de eerste externe attestatie, niet vóór de lancering.
Simpel gezegd: dit is de stempel waarmee wij ondertekenen. Wie hem steelt, kan bewijzen namaken die er echt uitzien. Voor een klant is dat erger dan een lek van een identiteit: bij een lek raakt één mens bekend, bij een gestolen stempel vertrouwt hij een mens die helemaal niet bestaat — en dat is precies wat hij bij ons kwam kopen.
4d · Wat NIET kan: blockchain is het verkeerde instrument voor geheimen — een publieke chain kan niets geheim houden, alles erop is leesbaar.
Er draait vandaag nog géén enkele KMS. Er is geen account, geen sleutel, geen Duitse of Franse server. Die stap moet nog gezet worden — en de keuze van de provider is een juridische vraag, geen technische.
| Optie | Wat het is | Aandachtspunt |
|---|---|---|
| AWS KMS (Amazon) | De standaardkeuze. Datacenter kiesbaar in Frankfurt of Parijs (EU-regio), functie GenerateMac, sleutel non-exportable. | Amerikaans bedrijf → US CLOUD Act kan gelden, ook al staat de server in de EU. |
| Google Cloud KMS / Azure Key Vault | Zelfde type dienst, zelfde kwaliteit. | Zelfde CLOUD Act-vraag (Amerikaanse moederbedrijven). |
| OVHcloud KMS (of andere Europese partij) | Europees alternatief, geen Amerikaans moederbedrijf. | Kies dit als het verhaal "EU-soeverein" moet zijn — juridisch te bevestigen. |
De beslissing valt pas op het antwoord van Nele. Verkeerde provider kiezen = twee keer migreren.
Simpel gezegd: de US CLOUD Act is een Amerikaanse wet die zegt: een Amerikaans bedrijf moet gegevens afgeven aan de Amerikaanse overheid als die erom vraagt — zélfs als de server in Frankfurt staat. Daarom is "welk bedrijf" hier belangrijker dan "welk land de server staat". Of dat voor onze sleutel een echt probleem is, is precies de vraag aan Nele.
Simpel gezegd: GDPR-verwerker: als een ander bedrijf iets met persoonsgegevens voor jou doet, moet er een contract zijn dat vastlegt wat zij wel en niet mogen. Vraag 4 checkt of dat hier verplicht is.
De belangrijke bevinding: de identity-laag gebruikt een salted hash, geen echte HMAC-constructie. Vandaag geen lek (zolang de salt geheim is), máár: een KMS rekent uitsluitend HMAC. Overstappen naar KMS verandert dus álle pseudoniemen. Met nul echte klanten is dat gratis; na lancering is het een pijnlijke migratie. Daarom is de KMS-migratie een PRE-LAUNCH-GATE geworden (roadmap 11d): verplicht vóór de eerste echte registraties.
Simpel gezegd: salted hash vs. HMAC: twee recepten om hetzelfde gehakt te draaien — allebei veilig, maar ander gehakt. De kluis (KMS) kent alleen het tweede recept. Wisselen van recept betekent dat álle bestaande codes veranderen. Nu hebben we nul klanten, dus niemand merkt het. Na de lancering zou elke klant "onherkenbaar" worden — een ramp. Daarom: éérst wisselen, dán lanceren. Dat noemen we een pre-launch-gate: een poort waar je door móét voor je mag vertrekken.
Bestond al — goed nieuws:
Ontbrak — de drie gaten (nu gedicht):
Plus dit aparte menu-item 🔑 Sleutels, zodat dit verhaal altijd vindbaar is.
Simpel gezegd: de identity-adapter is een stekkerdoos: we bouwen nu één punt waar de berekening doorheen loopt, met twee stopcontacten — het oude (blijft aan, alles werkt exact zoals nu) en het nieuwe KMS-contact (zit er al, maar er zit nog geen stekker in). Zodra Nele zegt welke kluis het wordt, hoeven we alleen nog de stekker in te pluggen. "Fail-closed" betekent: zit er nog geen stekker in en probeert iets toch dat contact te gebruiken, dan stopt alles veilig in plaats van half te werken. De "regressietest" is het bewijs dat het oude contact ná de verbouwing nog exact dezelfde stroom geeft als ervoor.
Simpel gezegd: git bewaart van elk bestand álle oude versies, zoals een fotoalbum van je code. We hebben de namen uit de nieuwste foto geknipt, maar in de oude foto's staan ze nog. De "history-scrub" knipt ze ook uit alle oude foto's — met eerst een kopie van het hele album, voor als er iets misgaat. "Fail-open vs. fail-closed": een deur die bij een kapot slot openvalt (fout) versus een deur die dan juist op slot blijft (goed). Het dashboard stond op de foute stand.
⛔ Nog open — en niet langer "komt later". Beide moeten dicht vóór de eerste publieke demo. Herzien 14-08-2026 na externe audit; stonden hiervoor als "bekend, komt later, niet vergeten".
1 · IBAN-fragment op het publieke kasboek. Reden voor de promotie: dat kasboek-endpoint staat in élke verkoopmail als bewijsstuk. Het fragment moet dus weg vóór de eerste mail vertrekt, niet vóór de lancering — anders stuur je zelf een link naar persoonsgegevens van een uitbetaalde mens.
2 · De itsme-controle wordt niet afgedwongen bij uitbetalen. Zolang dat zo is, kan een uitbetaling langs de verificatie heen. In een demo is dat precies de vraag die een technische toehoorder stelt, en het antwoord "dat komt nog" ondermijnt de rest van het gesprek.
⚖️ Wat hier nog NIET beoordeeld is — en dit is een vraag voor u, mevrouw Somers. Wij hebben het lek gedicht, maar wij hebben niet beoordeeld of dit een meldingsplichtige inbreuk was. Het ging om volledige naam, thuisadres en e-mailadres van twee geïdentificeerde personen, op een endpoint dat publiek bereikbaar was. Onder de AVG loopt vanaf het moment dat wij ervan kennis kregen een termijn van 72 uur om de toezichthouder te informeren (artikel 33), met daarnaast een aparte plicht om de betrokkenen zelf in te lichten wanneer het risico hoog is (artikel 34). Bovendien geldt de registratieplicht van artikel 33 lid 5 ongeacht of er gemeld moet worden: elke inbreuk moet gedocumenteerd worden. Wij hebben die beoordeling niet gemaakt en die registratie niet aangelegd. Wij leggen dit hier bewust open neer in plaats van het te laten liggen.
⏱ Kennisname: 04-08-2026 06:33 — vastgesteld op onze eigen versiegeschiedenis (toegevoegd 14-08-2026). Wij vroegen hieronder aan mevrouw Somers wélke datum als kennisname geldt. Die vraag konden wij zelf beantwoorden en hadden wij niet mogen doorschuiven. Commit c9a790c van 4 augustus 2026, 06:33 voegt reports/UXTEST-2026-08-04.md toe; dat rapport beschrijft de treffer live opgehaald: /logboek.json, 631 KB, publiek downloadbaar, statuscode 200, met volledige naam, thuisadres en e-mailadres van twee geïdentificeerde personen. De 72-uurstermijn van artikel 33 AVG liep daarmee af op 07-08-2026 06:33. Er is niet gemeld, en dus niet binnen de termijn. Waarom niet: de bevinding is op 4 augustus als beveiligings- en UX-bevinding behandeld en technisch gedicht (fail-closed, sleutel als geheim, negentien vervangingen), maar niet als mogelijk meldingsplichtige inbreuk gekwalificeerd — die vraag is pas op 14-08-2026 gesteld. Dat is een beoordelingsfout van ons. Wij schrijven het op zoals het is, omdat een register dat zijn eigen versiegeschiedenis tegenspreekt geen register is.
De vijfde vraag, en die is dringender dan de vier hieronder: was deze inbreuk meldingsplichtig aan de Gegevensbeschermingsautoriteit en/of aan de twee betrokkenen, en zo ja — wat is nu, achteraf, de juiste handelwijze nu de termijn op 07-08-2026 verstreken is: meldt men alsnog, en met welke motivering voor de vertraging? En wat moet er minimaal in het inbreukenregister staan dat wij nog moeten aanleggen? Wij hebben liever dat u ons hierop corrigeert dan dat wij dit stil houden.
| Taak | Wat | Status |
|---|---|---|
| 1 | Datalek dichten (dashboard, logboek.json, .bak-bestanden) + history-scrub | Diffs akkoord; deploy + scrub in uitvoering |
| 2 | D11 aanvullen: code-bevinding, pre-launch-gate, huidige toestand (geen KMS), bouwplan | ✔ Gebeurd (09-08, zie D11) |
| 3 | Deel G: 2 provider-vragen erbij · apart menu-item "Sleutels" · roadmap 11d = pre-launch-gate | ✔ Gebeurd (vragen 58–59 + deze pagina) |
| 4 | Identity-adapter bouwen (twee standen, regressietest, niet deployen zonder review) | Pas na akkoord op 1–3 |
Bron: chatsessie 8 augustus 2026 · technische details in SLEUTELBEWARING_R4M.md (repo-root) · dit is de leesbare samenvatting, PDF v1.2 hierboven te downloaden.