Zero-trust architectuur
Een technische uitleg van hoe benjegelekt.nl jouw privacy wiskundig garandeert.
Wat is zero-trust?
Zero-trust betekent dat je ons niet hoeft te vertrouwen. Het systeem is zo ontworpen dat zelfs als wij (de beheerders) kwaadwillend zouden zijn, we wiskundig niet kunnen achterhalen wat je hebt ingevoerd, zolang je gegevens niet in het datalek voorkomen.
Dit gaat verder dan encryptie of hashing. Het gaat erom dat er op geen enkel moment herkenbare informatie onze server bereikt bij een negatief resultaat.
Hoe werkt het?
De zero-trust modus combineert twee cryptografische technieken: een Oblivious Pseudorandom Function (OPRF) en een Bloom filter. Samen zorgen ze ervoor dat negatieve resultaten volledig lokaal worden bepaald.
OPRF: Oblivious Pseudorandom Function
Een OPRF (RFC 9497) is een cryptografisch protocol waarmee een server een geheime sleutel kan toepassen op jouw invoer, zonder ooit te weten wat die invoer is.
Het werkt als volgt: je browser plaatst je invoer op een elliptische curve (P-256) en vermenigvuldigt dit punt met een willekeurig getal r. Dit 'verblinde' punt wordt naar de server gestuurd. De server vermenigvuldigt het met zijn geheime sleutel k en stuurt het resultaat terug. Je browser deelt vervolgens door r om het blinderingsfactor te verwijderen.
Belangrijk: de server kent de geheime sleutel k en ziet het verblinde punt B. Maar om te controleren of B correspondeert met een specifieke invoer, zou de server het DDH-probleem op de P-256 curve moeten oplossen. Dit wordt als onoplosbaar beschouwd met huidige technologie.
Bloom filter: lokale controle
Een Bloom filter is een compacte datastructuur die kan antwoorden op de vraag: 'zit dit element in de verzameling?' Het antwoord is ofwel 'zeker niet' of 'waarschijnlijk wel'. Het kan geen false negatives produceren: als de Bloom filter zegt dat iets er niet in zit, dan is dat gegarandeerd zo.
Bij de eerste zoekopdracht in zero-trust modus downloadt je browser eenmalig een Bloom filter (~18 MB per gegevenstype). Deze bevat alle OPRF-versleutelde hashes uit de gelekte database. Je browser controleert de hash lokaal tegen deze filter, zonder een verzoek naar onze server te sturen.
Als de Bloom filter aangeeft dat de hash er niet in zit, weet je zeker dat je gegevens niet in het lek voorkomen. Er is geen enkele communicatie met onze server nodig en er is dus niets dat wij zouden kunnen onderscheppen.
Kan de Bloom filter gekraakt worden?
Nee. De Bloom filter bevat OPRF-versleutelde hashes, geen gewone SHA-256 hashes. Om een hash in de Bloom filter te controleren, moet je eerst het OPRF-protocol doorlopen met onze server. Dit betekent:
1. Elke poging vereist een verzoek aan de OPRF-server, die beperkt is tot 10 verzoeken per minuut per IP-adres.
2. Zelfs als iemand de Bloom filter downloadt, kan deze niet offline doorzoeken. De OPRF-sleutel is nodig om geldige hashes te berekenen, en die sleutel verlaat nooit de server.
3. Als iemand de OPRF-serversleutel zou stelen, zou die theoretisch zelf hashes kunnen berekenen. Maar zelfs dan is het onhaalbaar: er zijn miljarden mogelijke telefoonnummers, e-mailadressen en IBANs. De Bloom filter is ontworpen met een extreem lage foutmarge, waardoor brute-force onpraktisch blijft.
Vergelijk dit met een gewone SHA-256 hash van een Nederlands telefoonnummer: er zijn slechts ~80 miljoen mogelijke nummers. Een aanvaller kan alle hashes in minder dan een seconde berekenen. Met OPRF is dit onmogelijk zonder de serversleutel, en met rate limiting duurt zelfs een klein deel doorrekenen jaren.
Wat als je gegevens wel gevonden worden?
Als de Bloom filter aangeeft dat je gegevens mogelijk in het lek voorkomen (een 'hit'), stuurt je browser de OPRF-hash naar onze database om dit te bevestigen. Op dat moment verlaat er dus wel een hash de browser.
Dit is echter geen privacyrisico: als je gegevens daadwerkelijk in het lek voorkomen, is die informatie al gecompromitteerd. De bevestigingsstap onthult geen nieuwe informatie die niet al in de gelekte dataset staat.
In zeldzame gevallen (ca. 1%) kan een Bloom filter een false positive geven: je gegevens staan er niet in, maar de Bloom filter denkt van wel. In dat geval stuurt de browser een hash naar de server die toch geen resultaat oplevert. Dit is een minimale trade-off voor de compacte datastructuur.
Directe modus: snel maar niet zero-trust
Als alternatief biedt benjegelekt.nl ook een directe modus. In deze modus berekent je browser een SHA-256 hash van je invoer en stuurt deze naar onze server. De server past vervolgens een HMAC (Hash-based Message Authentication Code) toe met een geheime sleutel voordat de hash wordt vergeleken met de database.
Dit beschermt de database tegen directe reversering, maar de server ontvangt wel de SHA-256 hash van je invoer. Voor gegevens met weinig mogelijke waarden (zoals telefoonnummers) zou de SHA-256 hash in theorie omgekeerd kunnen worden. De directe modus is daarom sneller, maar biedt niet dezelfde privacygaranties als zero-trust.
In directe modus kan de server in theorie je invoer achterhalen voor gegevenstypen met weinig mogelijke waarden, zoals telefoonnummers. Gebruik zero-trust modus als dit een zorg is.
Overzicht: wie kan wat zien?
| Scenario | Directe modus | Zero-trust modus |
|---|---|---|
| Server ziet je invoer als platte tekst | Nee | Nee |
| Server ontvangt een hash van je invoer | Ja (SHA-256) | Alleen bij hit |
| Server kan je invoer terugrekenen (lage entropie) | In theorie mogelijk | Nee, wiskundig onmogelijk |
| “Niet gevonden” query bereikt server | Ja | Nee, lokaal bepaald |
| Bloom filter offline kraakbaar | n.v.t. | Nee (OPRF-sleutel vereist) |
| Snelheid | Snel (1 verzoek) | Langzamer (2 verzoeken + download) |
Technische specificaties
Voor onderzoekers en ontwikkelaars: