De populariteit van AI-toepassingen met chat-interface, doet een “oud zeer” opnieuw bovendrijven: hoe beschermen we persoonsgegevens die, vaak nietsvermoedend, via chat worden meegedeeld aan een geautomatiseerd systeem? Bij uitbreiding stelt zich deze vraag voor elke toepassing waar persoonsgebonden gegevens gedeeld moeten worden met derde partijen. De externe afhankelijkheden van een toepassing kunnen echter een ingewikkeld kluwen zijn. Het is ook niet altijd mogelijk (of economisch haalbaar) om de grote spelers op het vlak van cloud- en AI-diensten te ontwijken – toch niet als je mee wil zijn met de nieuwste mogelijkheden op een kostenefficiënte manier.

Een mogelijke oplossing staat bekend als PII Filtering. PII is daarbij het Engels acroniem voor Personal(ly) Identifiable/Identifying Information, i.e. de informatie waarmee iemand geïdentificeerd kan worden. Het idee is eenvoudig genoeg: we plaatsen een extra filter voor de applicatie, die de persoonlijke gegevens uit de input filtert, voordat die input aan de applicatie wordt doorgegeven. Als dat goed lukt, dan maakt het in principe niet meer uit wat de applicatie achter de schermen met die gegevens doet.

PII vs. Personal Data

Het is allereerst cruciaal om te begrijpen dat “PII” niet gelijkgesteld kan worden aan “Personal Data” zoals de GDPR en andere Europese wetgeving die definieert. PII is een concept dat geworteld is in Amerikaanse wetgeving. Het doelt meestal op een eindige set identificatiegegevens die kunnen worden gebruikt om de identiteit van een individu te onderscheiden of te achterhalen, zoals rijksregisternummers, adressen en telefoonnummers. Amerikaanse regelgeving is op dat vlak vaak prescriptief van aard: zo bevat de HIPAA (privacywetgeving m.b.t. gezondheidsgegevens) een lijst met 18 identifiers die als PII worden gedefinieerd. Dat heeft als groot voordeel dat het relatief gemakkelijk te implementeren is: wanneer het lijstje helemaal afgevinkt kan worden, is er ook juridisch weinig discussie meer.

Daarentegen hanteert de Europese GDPR (AVG) een principiële benadering: ze definieert een breder concept van Personal Data (persoonsgegevens). Dat omvat “alle informatie met betrekking tot een geïdentificeerde of identificeerbare natuurlijke persoon”. Dit betekent dat zelfs schijnbaar onschuldige informatie, zoals de kleur “rood”, beschouwd kan worden als persoonsgegeven, als deze bijvoorbeeld betrekking heeft tot iemands lievelingskleur. Deze contextafhankelijke definitie van persoonsgegevens, maakt het echter ook nagenoeg onmogelijk om generieke, algemeen inzetbare detectoren of filters ervoor te ontwikkelen. Wat beschouwd wordt als persoonsgegeven of niet, moet geval per geval beoordeeld worden. Niet alleen ontwikkelaars worden daardoor geconfronteerd met meer maatwerk dan hen lief is, ook juristen, DPO’s en Gegevensbeschermingsautoriteiten hebben met zulke beoordelingen in elk EU-land de handen vol.

Oplossingen voor PII-filtering die voldoen voor gebruik in de VS, lopen dus altijd een risico om in de EU slechts gedeeltelijk tegemoet te komen aan de vereisten. Omdat de term PII echter algemeen ingang gevonden lijkt te hebben in de globale markt, spreken we verder in dit artikel enkel nog over PII. Houd wel permanent in het achterhoofd dat Personal Data altijd het uitgangspunt moet zijn in EU-context.

PII Detectie en Filtering

Om tekstuele input te filteren gebruiken we doorgaans patroonherkenningstechnieken en Natural Language Processing (NLP)-modellen. Deze modellen scannen ongestructureerde gegevens, op zoek naar patronen zoals e-mailformaten of numerieke reeksen die lijken op rijksregister- of telefoonnummers, om deze nadien te kunnen redigeren of anonimiseren. Daarnaast worden aangepaste regex-patronen vaak toegevoegd om vormen van gevoelige informatie te herkennen die specifiek zijn voor de betrokken toepassing.

Effectieve PII-filtering steunt sterk op Named Entity Recognition (NER), een NLP-methode die entiteiten zoals namen, data en locaties in een tekst identificeert. We publiceerden daar eerder al over in meer detail – zie deze artikels over NLP en NER. De opkomst van generatieve AI heeft aan de opzet van NER-technieken nog niet veel veranderd. Ook vandaag gebruiken veel PII filtering tools achterliggend goed ontwikkelde NLP-toolkits zoals NLTK, SpaCy of Flair.

PII kan echter ook in afbeeldingen opduiken: scans van documenten, foto’s van gezichten of nummerplaten, … Om dat weg te filteren is een geavanceerdere aanpak vereist, omdat de gevoelige gegevens kunnen verschijnen in uiteenlopende vormen, van handgeschreven notities tot reflecties in foto’s. Optical Character Recognition (OCR) wordt gebruikt om tekst uit afbeeldingen te extraheren en deze om te zetten in een formaat dat op dezelfde manier kan worden geanalyseerd als tekstuele gegevens. Zodra de tekst is geëxtraheerd, ondergaat deze hetzelfde PII-filterproces met behulp van NLP-technieken. In gevallen waarin de afbeelding zelf gevoelige visuele elementen bevat (zoals gezichten of persoonlijke documenten), worden algoritmen voor beeldherkenning gebruikt om dergelijke inhoud te herkennen.

Eenmaal geïdentificeerd, moet je besluiten wat er dient te gebeuren met de gedetecteerde PII. Opties kunnen zijn:

• Vervanging / substitutie door een andere waarde. Deze kan eventueel aangemaakt worden met een synthetic data tool, zodat het origineel vervangen wordt door een realistisch ogend alternatief.
• Masking / obfuscation: vervang door een karakter of balkje. Dit kan eventueel gedeeltelijk, om nuttige algemenere info niet te verliezen: zo zien we nog dat +32********* een Belgisch telefoonnummer is.
• Verwijdering
• Hashing (best met salt ter preventie van brute-force attacks)
• Encryptie, eventueel formaat-behoudend
• …

Voor afbeeldingen zijn andere functies mogelijk, waaronder:

• Vervagen (blurring) of andere filters. Hierbij moet men er wel op letten dat sommige filters omkeerbaar zijn.
• Bedekken of overschrijven, bijvoorbeeld met een zwarte rechthoek.
• …

De vervanging door een alternatieve waarde van dezelfde soort kan echter soms ook voor vreemde effecten zorgen, omdat de entiteit niet altijd correct wordt ingeschat of omdat er te weinig of geen rekening gehouden kan worden met de context. Zo kan het zijn dat sommige tools geen acht slaan op het geslacht als een willekeurige naam moet worden gekozen om een echte naam te vervangen, terwijl dat wel nodig kan zijn om grammaticaal of inhoudelijk consistent te blijven. We zien soms ook plaatsnamen zoals Sint-Niklaas geanonymiseerd worden als pakweg Sint-Kevin, omdat Niklaas als naam werd aanzien. De taalmodellen gebruikt voor NER zijn dus zeker niet feilloos.

Het zou in theorie mogelijk moeten zijn om betere resultaten te halen door recente LLMs zoals GPT-4 in te schakelen met slim geconstrueerde prompts. Waarschijnlijk zullen er binnenkort wel stappen in die richting worden gezet, maar vandaag zijn de rekenkrachtvereisten, energieconsumptie en kostprijs daarvan nog te hoog, en de responstijd te traag, om dat ook schaalbaar te maken.

Tools of the trade

Wie op zoek gaat naar grootschalige PII Filtering systemen, en volledige databases, netwerken of filesystems wil kunnen scannen, komt terecht bij Data Loss Prevention tools. Deze moeten verhinderen dat PII het bedrijf verlaat zonder de nodige toelatingen. Voor een marktoverzicht verwijzen we naar Gartner. Ook de internetgiganten bieden daarvoor oplossingen aan, zoals Amazon Macie, Google SDP, of IBM Guardium. De daarbij gebruikte technieken zijn enigszins verwant met diegene gebruikt bij forensisch onderzoek – de zogenaamde eDiscovery, waarover we ook al eerder schreven.

Applicatiebouwers zijn waarschijnlijk eerder geïnteresseerd in tools in de vorm van bibliotheken, SDK’s of API’s. Interessante projecten zijn:

• Voor tekst:
  • Microsoft Presidio (demo) (ook beschikbaar als Docker containers), of de PII detection dienst op Azure
  • Amazon Comprehend (demo)
  • De EU Language Services voor NLP (inloggen vereist): voor anonymisering van documenten in EU-talen, gebaseerd op het MAPA-EU project dat ook via Docker Compose gebruikt kan worden.
  • PIICatcher (voor databases en filesystems)
• Voor afbeeldingen:
  • Google Magritte (voor gezichten)
  • Meta Research EgoBlur (voor gezichten en nummerplaten)
  • OctoPII (enkel detectie en geen redactie. Voor documenten en filesystems, met Tesseract als OCR engine)

Ook in academia wordt er verder onderzoek gedaan. Zo is PII-Codex het resultaat van een universitair project, met een interessante feature: achterliggend maakt het gebruik van Presidio of Comprehend, maar het voegt ook een eigen risico-score toe, die moet kunnen aangeven in welke mate het niet-redigeren van de herkende PII een (privacy-)risico zou kunnen inhouden. Daarnaast laten de meeste tools ook toe om andere of eigen modellen in te pluggen. Deze kan je eventueel zelf gefinetuned hebben voor detectie van custom entiteiten, als je daarvoor de nodige trainingsdata hebt.

Als we vertrouwen op NER of beeldherkenning voor PII-detectie, dan kunnen we er zeker van zijn dat sommige PII niet gedetecteerd zal worden, en dat ook andersom niet-PII foutief als PII aangemerkt kan worden. Geen van deze technologieën garandeert immers 100% accuraatheid. Het succespercentage zal ook variëren afhankelijk van de taal en het entiteitstype dat men probeert te detecteren. Volledige vervanging of verwijdering van elke entiteit in een document kan nooit worden gegarandeerd. Daar waar dat cruciaal is, wordt het resultaat achteraf dus best nog gecontroleerd.

Conclusie

Oplossingen voor PII-filtering kunnen in Europese context zeker bijdragen aan de bescherming van persoonsgegevens. De techniek is eenvoudig te begrijpen en gemakkelijk inzetbaar. Er is echter nooit een garantie op volledige accurate detectie van alle persoonsgegevens, en dus zal hun gebruik in de meeste gevallen een onderdeel moeten zijn van een ruimere waaier aan maatregelen om compliance met GDPR en andere wetgeving te bevorderen.

De achterliggende technologie is “klassiek”, in de zin dat NER en beeldherkenning al lang bestaan en ondertussen goed ontwikkeld zijn. Vandaag profiteren ze mee van de aandacht voor artificiële intelligentie, en allerlei benchmarks laten toe om de state-of-the-art op te volgen. In de praktijk merken we wel dat de resulterende geanonymiseerde tekst soms wat bevreemdend kan overkomen, omdat enkele al even klassieke problemen waar NER typisch mee kampt, nog altijd niet helemaal van de baan zijn.

______________________

Dit is een ingezonden bijdrage van Joachim Ganseman, IT consultant bij Smals Research.  Dit artikel werd geschreven in eigen naam en neemt geen standpunt in namens Smals.

Légende – Legende

De plus en plus de données personnelles sensibles sont stockées sous forme numérique,
tandis que les cyberattaques deviennent de plus en plus avancées. Aussi l’amélioration de
la protection des données à caractère personnel fait-elle l’objet d’une attention de tous les
instants.

Une mesure complémentaire précieuse consiste à stocker les données à caractère
personnel non pas sous un numéro de registre national, mais sous un pseudonyme.
Pour les applications existantes qui ne procèdent pas encore de la sorte, dans les
environnements production comme dans les environnements de test et de développement,
il peut être utile, voire nécessaire, que ces pseudonymes aient la même structure que les
numéros de registre national. Ceci de manière à ce qu’ils puissent être traités par
l’application et la base de données existantes.

D’où la nécessité d’une technique permettant de convertir les numéros de registre national
en pseudonymes avec la même structure et vice versa. Si le chiffrement classique ne le
permet pas, il en va autrement avec la tokenisation des données (data tokenization en
anglais) ou le chiffrement préservant le format (format-preserving encryption en anglais).

La tokenisation des données dans sa forme la plus simple, implique de tenir un tableau
contenant des paires de la forme (numéro de registre national, pseudonyme), ce qui pose
des problèmes infrastructurels, notamment en matière de sauvegarde, de synchronisation
et de sécurisation du tableau.

Plutôt que de tenir un tableau sans cesse croissant, comportant potentiellement des
millions d’enregistrements, une solution plus simple et plus sûre consisterait en une clé
symétrique unique et immuable d’une longueur de 32 bytes (au maximum).
C’est exactement ce que fait le chiffrement préservant le format (FPE). Cette technique a
été présentée pour la première fois en 2001 et a été normalisée par le NIST. À la suite de la
découverte de faiblesses, les normes ont été révisées en 2019.

Les normes FPE sont principalement axées sur le secteur financier où, par exemple, les
numéros de cartes de crédit sont remplacés par des pseudonymes ayant la même
structure. L’équipe Smals Research s’est demandé si cette technique pouvait également
être appliquée aux numéros de registre national. Cet article présente notre analyse et nos
expériences.

Fonctionnement

Par essence, le FPE consiste en une permutation, soit une réorganisation, comme l’illustre
la figure ci-dessous où les chiffres 1 à 5 sont réorganisés. La permutation est déterminée
par la clé FPE et le tweak. La clé est secrète, le tweak est un nombre à choisir librement
(byte array) qui peut être connu du public et qui simplifie la gestion des clés [1]. Comment
convertir sur cette base les numéros de registre national en pseudonymes ayant la
structure d’un numéro de registre national ?

La chaîne 83.06.21-123-62 revêt la structure d’un numéro de registre national, c’est-à-dire
qu’elle se présente sous la forme YY.MM.DD-III-CC, où YY.MM.DD représente la date de
naissance, III est un compteur de jours dans lequel est également encodé le sexe, et
CC est un chiffre de contrôle, calculé sur la base de tous les éléments précédents et du
siècle de naissance. Votre auteur n’est (hélas/heureusement) pas en mesure de vérifier si
le numéro 83.06.21-123-62 a réellement été attribué à un citoyen et sait donc uniquement
qu’il s’agit d’une chaîne revêtant la structure d’un numéro de registre national.

À partir d’une date de départ à choisir librement – par exemple 01/01/1911 – nous attribuons
à chaque chaîne correctement formée un index unique, qui commence par 0 et augmente ensuite, comme le montre la figure ci-dessous. Nous pouvons nous arrêter, par exemple,
au 31/12/2022. Dans ce cas, nous avons la certitude que les numéros
de registre national de toutes les personnes inscrites au Registre National qui étaient en vie
à la fin de l’année 2022 ont une conversion de et vers un nombre. En effet, personne dans
ce pays n’a plus de 112 ans.

La conversion d’un numéro de registre national en un pseudonyme préservant la structure
est illustrée dans la figure ci-dessous. Le numéro de registre national est d’abord converti
en un nombre, comme indiqué précédemment. Ce nombre est permuté (= chiffré) par FPE
en un autre nombre qui est ensuite reconverti en la chaîne préservant la structure
correspondante. Cette chaîne est le pseudonyme final.

[1] Avec une seule clé secrète et différents tweaks, nous avons donc différentes
permutations (chiffrements). Le tweak peut être considéré comme la partie non secrète de
la clé.

Dans la pratique

Pour utiliser le FPE afin de convertir des numéros de registre national en pseudonymes
préservant la structure, nous avons donc besoin à la fois d’un chiffrement FPE (et d’un
algorithme de déchiffrement) et d’une méthode de conversion.

Pour le chiffrement FPE, nous avons recouru à la bibliothèque cryptographique bien
connue BouncyCastle, qui prend en charge les deux normes du NIST, FF1 et FF3-1.
En coulisses, le FPE utilise toujours un algorithme existant pour le chiffrement par blocs
symétriques. Le choix logique était donc AES. Par conséquent, les clés FPE sont
simplement des clés AES.

L’équipe Smals Research a elle-même réalisé la conversion en Java, en tenant compte de
toutes les complexités liées aux numéros de registre national (voir, par exemple les arrêtés
royaux du 3 avril 1984 et du 25 novembre 1997). En cas d’intérêt concret, ce code de
recherche peut évoluer vers quelque chose qui soit utilisable en production.

Des contraintes cruciales doivent néanmoins être prises en compte lors du choix de la taille
du domaine. Le FPE a été présenté pour la première fois en 2001, dans un article intitulé Ciphers with arbitrary finite domains. Comme l’indique le titre, la taille du domaine peut être choisie arbitrairement. C’est également ce que nous avons fait dans notre exemple précédent.

Toutefois, les normes du NIST s’en écartent et stipulent que la taille du domaine doit avoir
la forme radix^len, c’est-à-dire le nombre racine radix élevé à la puissance len où radix et len
peuvent être choisis librement, tant que radix n’est pas supérieur à 2¹⁶ = 65 536.
Cette approche fonctionne bien pour, par exemple, les numéros de cartes de crédit.
Ces numéros sont composés de 16 chiffres décimaux. Nous choisissons donc radix = 10 et
len = 16. Ainsi, si nous suivons les normes du NIST – ce que je recommande vivement –
nous ne pouvons plus choisir la taille du domaine arbitrairement.

En outre, la taille minimale du domaine, qui était encore de 100 dans la publication du NIST
de 2016, a été portée à 1 000 000, dans la révision de 2019 pour des raisons de sécurité.
Autrement dit, il est exigé que radix^len ≥ 1 000 000. Entre autres conséquences de cette
exigence, il n’est plus possible de conserver l’année de naissance dans le pseudonyme
d’un numéro de registre national. En effet, il n’y a que quelque 365 000 chaînes
correctement formées par an (365 ou 366 jours par an x 998 possibilités pour le compteur
de jours III).

Revenons à nos expériences. Comment déterminer le domaine (et donc sa taille) ?
Dans notre exemple précédent, ce domaine était composé de toutes les chaînes dotées de
la structure d’un numéro de registre national pour les personnes nées entre 1911 et 2022,
soit plus de 40,8 millions de chaînes. Il s’agit bien évidemment d’utiliser le système pendant
plusieurs années, de sorte qu’il est logique que le domaine soit plus grand. En effet, de
nouveaux numéros de registre national sont émis en permanence, et il ne s’agit pas
d’oublier les anciens.

Pour nos tests, nous avons choisi le 1er janvier 1912 comme date de départ et
226 = 67 108 864 comme taille de notre domaine. Ensemble, la date de départ et la taille du
domaine déterminent également la date de fin, soit le 7 février 2096 dans notre cas.
Comme nous l’avons déjà mentionné, le FPE est une permutation sous-jacente sur
l’ensemble du domaine, de sorte que le pseudonyme d’une personne vivante peut être
converti en un pseudonyme préservant la structure avec une date de naissance située
plusieurs dizaines d’années dans le futur. Il se peut également que, dans dix ans, le
numéro de registre national d’une personne vivante à cette époque soit converti en un
pseudonyme avec une date de naissance qui est de toute façon trop éloignée dans le
temps pour être celle d’une personne vivante à ce moment-là.

En résumé, le FPE peut être utilisé pour convertir des numéros de registre national en
pseudonymes avec la même structure, mais toutes les informations contenues dans le
numéro de registre national seront perdues au cours du processus. Les contrôles de la date
de naissance et du sexe (contenu dans la 9e décimale) deviennent donc impossibles.
Ceci peut affecter certaines applications qui exécutent ces contrôles de toute façon.

Une mise en garde à cet égard s’impose toutefois. Nous ne devons pas considérer qu’un
numéro de registre national contient ces informations par définition. Il existe en effet des
exceptions, où la date de naissance exacte n’est pas contenue dans le numéro national
(voir les AR susmentionnés). La meilleure pratique consiste dès lors à utiliser le numéro de registre national comme identifiant uniquement et à demander au Registre national les
données à caractère personnel dont l’application a besoin. Dans un tel contexte, le FPE
pour les pseudonymes préservant la structure peut constituer une mesure de sécurité
précieuse.

Membrane de confidentialité

La membrane de confidentialité est un concept commun – il n’y a pas encore de code – du service Sécurité de l’information de Smals et de l’équipe Smals Research. L’idée est qu’un
environnement, par exemple une application en acceptation, est entouré d’une membrane
virtuelle, la membrane de confidentialité. Tous les numéros de registre national qui entrent
sont convertis en pseudonymes préservant la structure lorsqu’ils traversent la membrane de
confidentialité. Et tous les pseudonymes préservant la structure qui sortent sont reconvertis
en numéros de registre original lorsqu’ils traversent cette membrane. À l’intérieur de la
membrane, seul le pseudonyme est donc connu. Cette approche est transparente à la fois
pour la ou les applications qui se trouvent à l’intérieur de la membrane et pour les
applications/services avec lesquels s’effectue une communication.

La membrane de confidentialité pourrait en fait être un serveur proxy par lequel passe tout
le trafic entrant et sortant. Ce serveur proxy pourrait éventuellement être hébergé par un
tiers.

Contrairement aux autres techniques de pseudonymisation avancées conçues par l’équipe
Smals Research, ce tiers voit inévitablement à la fois le numéro de registre national et le
pseudonyme. Il est donc impossible de proposer un service de pseudonymisation aveugle
sur la base du FPE, de sorte qu’un degré de confiance supérieur s’impose à l’égard de ce
tiers.

Conclusion

Le FPE autorise une belle approche pour convertir les numéros de registre national en
pseudonymes avec la même structure. Cette approche peut améliorer la protection des
données à caractère personnel sans qu’il soit nécessaire d’adapter l’application ou la base
de données sous-jacente. En revanche, les informations contenues dans le numéro de
registre national – en particulier la date de naissance et le sexe biologique – seront perdues.
Cela ne devrait toutefois pas être problématique si les meilleures pratiques sont appliquées
et si les informations sont récupérées à partir de la source authentique, à savoir le Registre
national.

La même technique peut être appliquée à d’autres types d’identifiants numériques, tels que
les numéros BCE, les numéros de téléphone et les numéros de compte bancaire.
Aujourd’hui, dans son code de recherche, l’équipe Smals Research prend déjà en charge
les numéros BIS, i.e. des numéros d’identification uniques pour les personnes qui ne sont
pas inscrites au Registre national mais qui sont en relation avec les autorités belges, en
plus des numéros de registre national. Les numéros de registre national et les numéros BIS
constituent ensemble les numéros NISS, les numéros d’identification de la sécurité sociale.

L’introduction mentionne que le FPE est une mesure de protection complémentaire.
Lorsque, par exemple, dans un enregistrement de base de données, le numéro de registre
national est remplacé par un pseudonyme, mais que le nom et l’adresse restent en clair
dans la base de données, l’identification du citoyen reste assez triviale. Dès lors, soit des
mesures de protection complémentaires s’imposent, soit ces données à caractère
personnel ne sont plus stockées localement, mais sont systématiquement extraites de la
source authentique (en l’espèce le Registre national).

En décembre 2021, un sondage réalisé à la fin de mon webinaire consacré aux
technologies d’amélioration de la vie privée posait la question suivante : quelles sont les
technologies d’amélioration de la vie privée qui, selon vous, ont le plus de potentiel et
méritent donc plus d’attention ? Le vainqueur fut FPE (suivi d’Oblivious Join et de Synthetic
data). Ce résultat nous a amenés à accorder davantage d’attention à cette technologie.
Depuis, avec l’équipe Smals Research, nous avons réalisé les premières expériences
réussies avec le FPE.

Si vous souhaitez appliquer le FPE, éventuellement sous la forme d’une membrane
de confidentialité, ou convertir des identifiants en pseudonymes, n’hésitez pas à
prendre contact avec nous.

Cette contribution a été soumise par Kristof Verslype, cryptographe chez Smals Research.
Elle a été rédigée en son nom propre et ne prend pas position au nom de Smals.

Source featured image: Pixabay

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

Légende – Legende

(Nederlandstalige tekst : zie onder)

Presentation

Using ‘real’ data may be tempting, yet under the GDPR it’s not a good idea when dealing with personal information. Unfortunately, testing or debugging software may be harder without having full access to all underlying data. A synthetic dataset can be a good solution: generating fictitious replacement data, that mimics the structure and distribution of the original data. Joachim Ganseman from Smals Research talks about how synthetic data can be generated, and especially about the practical concerns and limitations. How do we deal with rarely occurring values, correlations or dependencies? What about the balance between maximum privacy protection vs. retaining enough functional usability? Can we do reliable analytics on a synthetic dataset? He will share some practical examples using open source software in Python.

Video recording published on YouTube

Presentation