Version en français

Steeds meer gevoelige persoonsgegevens worden digitaal bewaard, terwijl cyberaanvallen steeds geavanceerder worden. Het verbeteren van de bescherming van persoonsgegevens geniet dan ook permanente aandacht.

Een waardevolle aanvullende maatregel is om persoonsgegevens niet onder een rijksregisternummer te bewaren, maar onder een pseudoniem. Voor bestaande toepassingen die dit nog niet doen, in productie alsook in test- en ontwikkelomgevingen, kan het nuttig en zelfs noodzakelijk zijn dat deze pseudoniemen dezelfde structuur hebben als rijksregisternummers. Dit is immers wat de bestaande toepassing en database verwachten en mee om kunnen.

Vandaar dus de nood aan een techniek die rijksregisternummers omzet in pseudoniemen met dezelfde structuur, en terug. Dit is onmogelijk met klassieke vercijfering, maar wordt wel mogelijk m.b.v. ofwel data tokenization, ofwel format-preserving encryption. 

Bij data tokenization wordt, in zijn meest eenvoudige vorm, een tabel bijgehouden met paren van de vorm (rijksregisternummer, pseudoniem), wat met infrastructurele uitdagingen komt, onder meer op het vlak van backup, synchronisatie en het veilig bewaren van de tabel.    

Het zou eenvoudiger en veiliger zijn indien we niet een steeds groeiende tabel, met potentieel miljoenen records moeten bijhouden, maar in de plaats daarvan gewoon één enkele, onveranderlijke symmetrische sleutel met een lengte van (maximaal) 32 bytes. Dit is exact wat format-preserving encryptie (FPE) doet. Deze techniek werd voor het eerst voorgesteld in 2001 en werd in 2016 gestandaardiseerd door het NIST. Na het ontdekken van zwakheden werden in 2019 de standaarden weliswaar gereviseerd.

De FPE standaarden richten zich op de eerste plaats op de financiële sector, waarbij bijvoorbeeld kredietkaartnummers vervangen worden door pseudoniemen met dezelfde structuur. Bij Smals Research vroegen we ons af of deze techniek ook op rijksregisternummers kan toegepast worden. Dit artikel bespreekt onze analyse en ervaringen.

Werking

In essentie is FPE een permutatie, ofwel een herordening zoals geïllustreerd in onderstaande figuur waarbij de nummers 1 tot 5 herordend worden. De permutatie wordt bepaald door de FPE sleutel en de tweak. De sleutel is geheim, de tweak is een vrij te kiezen nummer (byte array) dat publiek gekend mag zijn en dat key management vereenvoudigd [1]. Hoe kunnen we op basis hiervan rijksregisternummers omzetten in pseudoniemen met de structuur van een rijksregisternummer?

De string 83.06.21-123-62 heeft de structuur van een rijksregisternummer, dat wil zeggen dat het van de vorm YY.MM.DD-III-CC is, waarbij YY.MM.DD de geboortedag aanduidt, III een dagteller is waarin ook het geslacht geëncodeerd zit, en CC een controlegetal is, berekend op basis van zowel al het voorgaande als de geboorte-eeuw. Uw auteur beschikt (helaas/gelukkig) niet over de mogelijkheid om na te gaan of 83.06.21-123-62 effectief aan een burger toegekend is en weet dus enkel dat dit een string is met de correcte structuur van een rijksregisternummer.

Vertrekkende vanaf een vrij te kiezen startdatum – bijvoorbeeld 01/01/1911 – kennen we aan elke correct gevormde string een unieke index toe, startend bij 0 en oplopend, zoals aangegeven in onderstaande figuur. We kunnen ophouden bij, bijvoorbeeld, 31/12/2022. In dat geval zijn we zeker dat de rijksregisternummers van alle personen ingeschreven in het Rijksregister die eind 2022 in leven waren een conversie van en naar een getal hebben. Niemand in dit land is immers ouder dan 112.

De omzetting van een rijksregisternummer naar een structuurbewarend pseudoniem wordt geïllustreerd in onderstaande figuur. Het rijksregisternummer wordt eerst geconverteerd naar een getal, zoals net aangegeven. Dat getal wordt door FPE gepermuteerd (=geëncrypteerd) naar een ander getal dat vervolgens terug geconverteerd wordt naar de bijhorende structuurbehoudende string. Deze string is het uiteindelijke pseudoniem.  

[1] Met een enkele geheime sleutel en verschillende tweaks heb je dus verschillende permutaties (encrypties). De tweak kan gezien worden als het niet geheime deel van de sleutel. 

In de praktijk

Om FPE te gebruiken voor het omzetten van rijksregisternummers naar structuurbehoudende pseudoniemen hebben we dus nood aan zowel een FPE cijfer (en decryptiealgoritme) als een conversiemethode.

Voor het FPE cijfer deden we beroep op de gekende crypto library BouncyCastle, dat beide NIST standaarden, FF1 en FF3-1, ondersteunt. Onderliggend maakt FPE steeds gebruikt van een bestaand algoritme voor symmetrische blokvercijfering. De logische keuze was dan ook AES. Bijgevolg zijn FPE sleutels gewoon AES sleutels. 

De conversie heeft Smals Research zelf in Java geïmplementeerd, waarbij alle  complexiteiten rond rijksregisternummers mee in rekening genomen werden (zie bijvoorbeeld de koninklijke besluiten van 3 april 1984 en 25 november 1997). Bij concrete interesse kan deze research code evolueren richting iets dat ook in productie bruikbaar is.   

Wel moet rekening gehouden worden met cruciale beperkingen bij het kiezen van de domeingrootte. FPE werd voor het eerst voorgesteld in 2001, in een artikel getiteld Ciphers with arbitrary finite domains. Zoals de titel suggereert kon de domeingrootte willekeurig gekozen worden. Dit is ook wat we in ons voorgaande voorbeeld gedaan hebben.

De NIST standaarden wijken daar echter van af en stellen dat de domeingrootte de vorm radix^len moet hebben, dus het grondtal radix verhoffen tot de macht len waarbij radix en len vrij gekozen kunnen worden, zolang radix niet groter is dan 2¹⁶ = 65 536. Deze benadering werkt goed voor bijvoorbeeld kredietkaartnummers. Dergelijke nummers bestaan uit 16 decimale cijfers. We kiezen dus radix = 10 en len = 16. Als we de NIST standaarden volgen – wat ik ten zeerste aanbeveel –, kunnen we de domeingrootte dus niet langer willekeurig kiezen.

Bovendien werd de minimumdomeingrootte, die in de NIST publicatie van 2016 nog 100 bedroeg, in de revisie van 2019 uit veiligheidsoverwegingen opgetrokken naar 1 000 000. Anders gezegd is er de vereiste dat radix^len ≥ 1 000 000. Een implicatie van dat laatste is dat het behoud van het geboortejaar in het pseudoniem van een rijksregisternummer niet langer een optie is. Per jaar zijn er immers slechts ongeveer 365 000 correct gevormde strings (365 of 366 dagen per jaar x 998 mogelijkheden voor de dagteller III).

Terug naar onze experimenten. Hoe bepalen we het domein (en dus de domeingrootte)? In ons eerdere voorbeeld bestond dit domein uit alle strings met de structuur van een rijksregisternummer voor personen geboren tussen 1911 en 2022, wat samen goed was voor ruim 40,8 miljoen strings. Het is uiteraard de bedoeling om het systeem ettelijke jaren te gebruiken. Daarom is het verstandig om het domein groter te nemen. Er worden immers steeds nieuwe rijksregisternummers uitgereikt, en de oude mogen we niet zomaar vergeten.

Voor onze testen kozen we als startdatum 1 januari 1912 en als grootte voor ons domein 2²⁶ = 67 108 864. De startdatum en domeingrootte bepalen samen ook de einddatum, wat in dit geval 7 februari 2096 is. Zoals eerder gezegd is FPE onderliggend een permutatie over het volledige domein, wat impliceert dat het pseudoniem van een levende persoon omgezet kan worden in een structuurbehoudend pseudoniem met een geboortedatum die decennia in de toekomst ligt. Het is eveneens mogelijk dat binnen 10 jaar een rijksregisternummer van een op dat moment levende persoon omgezet wordt naar een pseudoniem met een geboortedatum die sowieso te ver in het verleden ligt om van een dan nog levende persoon te zijn.

Samengevat kan FPE gebruikt worden om rijksregisternummers om te zetten in pseudoniemen met dezelfde structuur, maar gaat daarbij wel alle informatie verloren die in het rijksregisternummer vervat zit. Controles op geboortedatum en geslacht (wat vervat zit in de 9^e decimaal) worden dus onmogelijk. Dit kan gevolgen hebben voor bepaalde toepassingen die dergelijke controles toch doen.

Hierbij dient wel een kanttekening gemaakt te worden. We mogen er niet van uitgaan dat een rijksregisternummer sowieso deze informatie bevat. Er zijn inderdaad uitzonderingen, waarbij de exacte geboortedatum niet in het rijksregisternummer vervat zit (zie daarvoor de eerder vermeldde KB’s). Het is dan ook sowieso een best practice om het rijksregisternummer enkel te gebruiken als identifier, en de persoonsgegevens die de toepassing nodig heeft aan het rijksregister op te vragen. In een dergelijke context kan FPE voor structuurbehoudende pseudoniemen een waardevolle beveiligingsmaatregel zijn. 

Privacy membraan

Het privacy membraan is een gezamenlijk concept – er is nog geen code – van de dienst informatieveiligheid en de dienst onderzoek van Smals. Het idee is dat een omgeving, bijvoorbeeld een toepassing in acceptatie, omgeven wordt door een virtuele schil, het privacy membraan. Alle rijksregisternummers die het privacy membraan binnenkomen worden omgezet in een structuurbehoudend pseudoniem. Alle structuurbehoudende pseudoniemen die het membraan verlaten worden bij het passeren van het membraan opnieuw omgezet in het oorspronkelijke rijksregisternummer. Binnen het membraan is dus enkel het pseudoniem gekend. Een dergelijke aanpak is transparant voor zowel de toepassing(en) binnen het membraan, als de toepassingen/services waarmee gecommuniceerd wordt.

Het privacy membraan zou in werkelijkheid een proxy server kunnen zijn waarlangs al het inkomend en uitgaand verkeer passeert. Die proxy server kan eventueel gehost worden door een derde partij.  

In tegenstelling tot andere, door Smals Research bedachte, geavanceerde peudonimisatietechnieken, ziet deze partij onvermijdelijk zowel het rijksregisternummer als het pseudoniem. Een blinde pseudonimiseringsdienst is dus onmogelijk m.b.v. FPE en bijgevolg is wel een hogere graad van vertrouwen vereist in deze partij.

Conclusie

FPE laat een elegante aanpak toe om rijksregisternummers om te zetten in pseudoniemen met dezelfde structuur. Dit kan de bescherming van persoonsgegevens verbeteren, zonder dat de onderliggende toepassing of database aangepast dient te worden. De informatie die vervat zit in het rijksregisternummer – met name de geboortedatum en het biologische geslacht – gaat daarbij weliswaar verloren. Toch zou dit geen probleem mogen zijn indien de best practices gevolgd worden en de informatie dus opgevraagd wordt aan de authentieke bron, zijnde het Rijksregister.

Dezelfde techniek kan ook toegepast worden op andere types numerieke identifiers, zoals KBO nummers, telefoonnummers en bankrekeningnummers. Smals Research biedt vandaag in haar research code, naast rijksregisternummers, ook reeds ondersteuning voor BIS-nummers, wat unieke identificatienummers zijn voor personen die niet ingeschreven zijn in het Rijksregister, maar die toch een relatie hebben met de Belgische overheden. De rijksregisternummers en BIS-nummers vormen samen de INSZ nummers, de identificatienummers van de sociale zekerheid.

De inleiding vermeldde dat FPE een aanvullende beschermingsmaatregel is. Wanneer bijvoorbeeld in een database record het rijksregisternummer vervangen wordt door een pseudoniem, maar verder naam en adres gewoon in klaartekst in de database blijven staan, blijft identificatie van de burger vrij triviaal. Ofwel zijn dan bijkomende beschermingsmaatregelen nodig, ofwel worden deze persoonsgegevens niet langer lokaal bewaard, maar wel systematisch bij de authentieke bron (in dit geval het Rijksregister) opgevraagd.

In december 2021 werd op het einde van mijn webinar over privacy bevorderende technologieën via een peiling de volgende vraag gesteld: welke privacy bevorderende technologieën hebben volgens u het meest potentieel en verdienen dus meer aandacht? De winnaar was FPE (gevolgd door Oblivious Join en Synthetic data). Dit was voor ons een signaal om deze technologie meer aandacht te geven. Ondertussen hebben we met Smals research de eerste succesvolle experimenten met FPE achter de rug.

Mocht u interesse hebben in het toepassen van FPE, eventueel in de vorm van een privacy membraan, of in het omzetten van identifiers in pseudoniemen, gaan wij graag met u in gesprek.  

 

---

Dit is een ingezonden bijdrage van Kristof Verslype, cryptograaf bij Smals Research. Het werd geschreven in eigen naam en neemt geen standpunt in namens Smals.

Bron featured image: Pixabay