Presentation

Avec la popularité des applications d’IA dotées d’une interface conversationnelle, un “vieux casse-tête” refait surface : comment protéger les données personnelles communiquées, souvent sans méfiance, à un système automatisé de conversation ? Par extension, cette question se pose pour toute application où des données personnelles doivent être partagées avec des tiers. Les dépendances externes d’une application peuvent toutefois constituer un enchevêtrement complexe. Il n’est pas non plus toujours possible (ou économiquement viable) d’éviter les grands acteurs d’infrastructures informatiques d’IA – du moins pas si vous souhaitez rester à jour avec les dernières capacités de manière rentable.

Une solution possible est connue sous le nom de PII Filtering. En l’occurrence, PII est l’acronyme anglais de Personal(ly) Identifiable/Identifying Information, c’est-à-dire les informations par lesquelles une personne peut être identifiée. L’idée est assez simple : un filtre supplémentaire est placé devant l’application, qui élimine les informations à caractère personnel des données d’entrée, avant que celles-ci ne soient transmises à l’application. Si cela fonctionne bien, alors ce que l’application fait de ces données en coulisses n’a pas d’importance.

PII vs. Personal Data

Avant toute chose, il est crucial de comprendre que les PII ne peuvent être assimilées à des “Personal Data” telles que définies par le RGPD et d’autres législations européennes. Les PII sont un concept ancré dans le droit états-unien. Elles font généralement référence à un ensemble fini d’informations d’identification qui peuvent être utilisées dans le but de distinguer ou de confirmer l’identité d’un individu, comme les numéros de registre national, les adresses et les numéros de téléphone. Aux États-Unis, les réglementations sont souvent prescriptives à cet égard : par exemple, HIPAA (réglementation sur la protection des données relatives à la santé) comprend une liste de 18 identifiants définis comme PII. Cela présente le grand avantage d’être relativement facile à implémenter : une fois que la liste est entièrement cochée, il n’y a plus guère de débat juridique possible.

En revanche, la RGPD européenne adopte une approche de principe : elle définit un concept plus large de Personal Data (données à caractère personnel). Ce concept englobe “toute information se rapportant à une personne physique identifiée ou identifiable”. Cela signifie que même des informations en apparence anodines, comme la couleur “rouge”, peuvent être considérées comme des données à caractère personnel si elles se rapportent, par exemple, à la couleur préférée d’une personne. Cette définition des données à caractère personnel dépendante du contexte rend toutefois pratiquement impossible le développement de détecteurs ou de filtres génériques et polyvalents pour ces données. Ce qui est considéré comme des données personnelles ou non doit être évalué au cas par cas. Les développeurs sont donc confrontés à une personnalisation plus importante qu’ils ne le souhaiteraient, mais les juristes, les DPO et les autorités de protection des données ont également fort à faire avec de telles évaluations dans chaque pays de l’UE.

Ainsi, les solutions de filtrage des PII considérées comme conformes aux États-Unis risquent toujours de ne l’être que partiellement dans l’Union européenne. Étant donné que le terme PII semble s’être imposé sur le marché mondial, nous ferons dans le présent article uniquement référence aux PII. Gardez toujours à l’esprit que le Personal Data doit être le point de départ dans le contexte de l’UE.

Détection et filtrage des PII

Afin de filtrer des informations textuelles, nous utilisons généralement des modèles techniques de reconnaissance de formes et de traitement automatique des langues (Natural Language Processing ou NLP). Ces modèles analysent les données non structurées, à la recherche de formes telles que des formats d’adresses e-mail ou des chaînes numériques similaires à un registre national ou encore à des numéros de téléphone, afin de les modifier ou de les anonymiser par la suite. En outre, des formes d’expression régulières (regex) personnalisées sont souvent ajoutées afin de reconnaître les formes d’informations sensibles spécifiques à l’application en question.

Un filtrage efficace des PII repose en grande partie sur la reconnaissance d’entités nommées (Named Entity Recognition ou NER), une méthode NLP qui identifie les entités telles que les noms, les dates et les lieux dans un texte. Nous avons déjà publié des articles plus détaillés à ce sujet – voir les articles sur NLP et NER.  L’essor de l’IA générative n’a pas encore changé grand-chose à la conception des techniques de NER. Aujourd’hui encore, de nombreux outils de filtrage de PII utilisent des outils NLP sous-jacents bien développés tels que NLTK, SpaCy ou Flair.

Toutefois, les PII peuvent également apparaître dans des images : scans de documents, photos de visages ou de plaques d’immatriculation, … Le filtrage de ces images nécessite une approche plus sophistiquée, car les données sensibles peuvent apparaître sous diverses formes, de notes écrites à la main à des reflets sur des photos. La reconnaissance optique de caractères (Optical Character Recognition ou OCR) permet d’extraire le texte des images et de le convertir dans un format qui peut être analysé de la même manière que des données textuelles. Une fois le texte extrait, il est soumis au même processus de filtrage des PII à l’aide de techniques NLP. Des algorithmes de reconnaissance d’objets sont utilisés pour reconnaître les éléments visuels sensibles (tels que des visages ou des documents personnels) contenus dans l’image elle-même.

Une fois identifiées, vous devez décider de ce qu’il convient de faire avec les PII détectées. Les options possibles sont les suivantes :

• Remplacement/substitution par une autre valeur. Celle-ci peut éventuellement être créée à l’aide d’un outil de génération de données synthétiques, de sorte que l’original est remplacé par une alternative d’apparence réaliste.
• Masquage / obfuscation : remplacement par un caractère ou une barre. Cela peut être partiel, afin de ne pas perdre des informations plus générales utiles : par exemple, nous pouvons toujours voir que +32********* est un numéro de téléphone belge.
• Suppression
• Hashage (mieux encore avec salage en prévention des attaques par force brute)
• Chiffrement, éventuellement préservant le format des données
• …

D’autres fonctions sont possibles pour les images, notamment :

• Flouter (blurring) ou d’autres filtres. Il convient de noter ici que certains filtres sont réversibles.
• Couvrir ou écraser, par exemple avec un rectangle noir.
• …

Le remplacement par une valeur alternative du même type peut toutefois créer des effets étranges, parce que l’entité n’est pas toujours estimée correctement ou parce que trop peu ou pas de contexte peut être pris en compte. Certains outils peuvent ainsi ne pas tenir compte du genre si un nom aléatoire doit être choisi pour remplacer un nom réel, alors qu’il peut être nécessaire de rester cohérent sur le plan grammatical ou sur celui du contenu. Il arrive également que des noms de lieux comme Saint-Nicolas soient anonymisés en Saint-Kevin, par exemple, parce que Nicolas est considéré comme un prénom. Les modèles de langage utilisés pour la NER ne sont donc certainement pas sans faille.

En théorie, il devrait être possible d’obtenir de meilleurs résultats en activant des LLM modernes comme le GPT-4 avec des requêtes construites de manière intelligente. Des mesures dans ce sens verront probablement le jour sous peu, mais aujourd’hui, les besoins en puissance de calcul, la consommation d’énergie et le coût sont encore trop élevés, et le temps de réponse trop lent, pour que l’on puisse également faire évoluer cette méthode.

Outils courants

Les personnes qui recherchent des systèmes de filtrage de PII à grande échelle, et qui souhaitent pouvoir analyser des bases de données, des réseaux ou des systèmes de fichiers entiers, se retrouvent avec des outils du domaine de Data Loss Prevention. Ceux-ci devraient empêcher les PII de quitter l’entreprise sans les autorisations nécessaires. Vous trouverez une vue d’ensemble du marché en consultant Gartner. Les géants de l’internet proposent également des solutions à cette fin, telles que Amazon Macie, Google SDP, ou IBM Guardium. Les techniques utilisées dans ces outils sont quelque peu liées à celles utilisées dans les enquêtes judiciaires – ce que l’on appelle l’eDiscovery, que nous avons déjà évoquée.

Les créateurs d’applications sont plus susceptibles d’être intéressés par des outils sous forme de bibliothèques, de SDK ou d’API. Les projets intéressants sont les suivants :

• Pour le texte :
  • Microsoft Presidio (démo) (également disponible sous la forme de Docker containers), ou le service PII detection sur Azure
  • Amazon Comprehend (démo)
  • Les EU Language Services pour NLP (login requis) : pour l’anonymisation des documents dans les langues de l’UE, basé sur le projet MAPA-EU, qui peut également être utilisé via Docker Compose.
  • PIICatcher (pour les bases de données et les systèmes de fichiers)
• Pour les images :
  • Google Magritte (pour les visages)
  • Meta Research EgoBlur (Pour les visages et les plaques d’immatriculation)
  • OctoPII (Uniquement la détection, pas la modification. Pour les documents et les systèmes de fichiers, avec Tesseract pour OCR engine)

De nouvelles recherches sont également en cours dans les universités. Par exemple, PII-Codex est le résultat d’un projet universitaire qui présente une caractéristique intéressante : il utilise Presidio ou Comprehend, mais ajoute également son propre score de risque, qui devrait être en mesure d’indiquer dans quelle mesure la non modification des PII reconnues pourrait poser un risque (pour la protection de la vie privée). En outre, la plupart des outils permettent d’utiliser vos propres modèles ou ceux des autres. Vous pouvez éventuellement les peaufiner vous-même pour la détection personnalisée d’entités, si vous disposez des données d’entraînement nécessaires à cet effet.

Si nous nous appuyons sur la NER ou la reconnaissance d’images pour la détection des PII, il est certain que certaines PII ne seront pas détectées et qu’à l’inverse, des éléments non PII pourraient également être classés à tort comme des PII. En effet, aucune de ces technologies ne garantit une précision de 100 %. Le taux de réussite variera également en fonction de la langue et du type d’entité que l’on tente de détecter. Il n’est jamais possible de garantir complètement le remplacement ou la suppression de chaque entité dans un document. Il est donc préférable de vérifier le résultat dans les cas où cela s’avère crucial.

Conclusion

Les solutions de filtrage de PII peuvent certainement contribuer à la protection de données à caractère personnel dans un contexte européen. Les techniques sont simples à comprendre et faciles à mettre en œuvre. Cependant, il n’y a jamais de garantie de détection totalement précise de toutes les données à caractère personnel et, dans la plupart des cas, leur utilisation devra donc faire partie d’un éventail plus large de mesures visant à promouvoir la conformité avec la RGPD et d’autres législations.

La technologie sous-jacente est “classique”, en ce sens que la NER et la reconnaissance d’images existent depuis longtemps et sont désormais bien développées. Aujourd’hui, elles bénéficient de l’attention portée à l’intelligence artificielle, et toutes sortes d’étalons leur permettent de rester à la pointe du progrès. Dans la pratique, nous constatons que le texte anonymisé qui en résulte peut parfois sembler un peu aliénant, car certains problèmes tout aussi classiques auxquels la NER est généralement confrontée ne sont pas encore totalement écartés.

______________________

Cette contribution a été soumise par Joachim Ganseman, consultant IT chez Smals Research. Elle a été rédigée en son nom propre et ne prend pas position au nom de Smals.

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.

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

Doordat PETs een elegant alternatief kunnen bieden op meer omslachtige traditionele aanpakken, kan hun gebruik bovendien leiden tot een vereenvoudiging van bestaande procedures, niet alleen op technisch, maar ook op juridisch vlak. In deze gevallen worden de procedures dan ook sneller en goedkoper, terwijl ook de veiligheidsrisico’s afnemen. Een aantal redenen daartoe kunnen zijn:

• Een reductie van het aantal informatiestromen
• Een reductie van het aantal TTPs (Trusted Third Parties)
• Een reductie van het vertrouwen dat in TTPs gelegd dient te worden
• Maatwerk maakt plaats voor een meer uniforme aanpak.

Dit artikel wil een leidraad zijn bij het selecteren van de juiste PET. Wel moet beseft worden dat dit maar een selectie van PETs en use cases is, dat niet alle PETs vandaag volledig matuur zijn en dat steeds nagedacht moet worden over de correcte toepassing ervan. Dit artikel is een aanzet en zal, met voortschrijdend inzicht en voortschrijdende technologische evoluties in de toekomst verder verfijnd worden.

In het buitenland werden reeds gelijkaardige, uitgebreidere oefeningen gedaan. We verwijzen graag onder meer naar Privacy Enhancing Technologies Adoption Guide door het Centre for Data Ethics and Innovation, naar Protecting privacy in practice van The Royal Society en naar het meer academische A taxonomy for privacy enhancing technologies door Johannes Heurix, Peter Zimmermann, Thomas Neubauer en Stefan Fenz.

PETs selectieboom

Onderstaande figuur geeft onze eigen, adviserende PET-selectieboom weer, die focust op behoeften vanuit de publieke sector. De boom heeft (momenteel) acht bladeren, die elk een groep van use cases voorstellen. Elk van deze bladeren wordt onder de figuur toegelicht. Voor details over de PETS zelf voorzien we doorverwijzingen/links.

1. Burger wil controle over prijsgave eigen persoonsgegevens bij authenticatie

De burger moet zich geregeld, zowel online als offline, authentiseren, wat wil zeggen dat ze bepaalde eigenschappen over haarzelf dient te bewijzen. Een aantal voorbeelden:

• Om alcohol te kopen moet ze bewijzen dat zij volwassen is
• Om een auto te huren moet ze bewijzen dat ze over een rijbewijs van het juiste type beschikt en verzekerd is.
• Om recht te hebben op korting bij een museumbezoek, moet ze bewijzen dat ze in die bepaalde gemeente woont.

In elk van voorgaande voorbeelden wordt in de praktijk m.b.v. de identiteitskaart en/of andere documenten veel meer informatie prijsgegeven dan strikt noodzakelijk. Om alcohol te kopen moet de burger bijvoorbeeld enkel kunnen bewijzen dat zij volwassen is. Om korting te krijgen in het museum volstaat te bewijzen dat haar postcode behoort tot de postcodes van die gemeente. Haar exacte geboortedatum, haar identiteit, exacte postcode, geslacht en andere informatie op de eID doen er niet toe en blijven vanuit een privacy-standpunt beter verborgen. Dergelijke selectieve prijsgave van attribuutinformatie wordt mogelijk dankzij zero-knowledge proofs, wat we terugvinden in self-sovereign identity (SSI) oplossingen, zoals attribute-based credentials. Ook zijn er oplossingen, zoals Sovrin, die zero-knowledge proofs integreren in blockchain technologie.

2. Onderzoeker wil inzichten verkrijgen uit persoonsgegevens die gefragmenteerd zijn over meerdere organisaties.

Dit kan gaan over een combinatie van gezondheidsdata, socio-economische data, etc. die gefragmenteerd zijn over meerdere organisaties. Gegeven de huidige stand der techniek, geven we er de voorkeur aan om eerst de data te kruisen (zie puntje 4), en vervolgens ter beschikking te stellen van de onderzoeker (zie puntje 3). Indien dit kruisen (samenbrengen van gegevens) omwille van strikte privacy- of andere redenen echt niet mogelijk is, moeten we echter terugvallen – als laatste redmiddel – op een andere aanpak.

Bij die andere aanpak worden de scripts/queries van de onderzoeker gedistribueerd uitgevoerd, wat wil zeggen dat de verschillende participanten met elkaar interageren, zonder een centrale partij. De (persoons)gegevens beheerd door de verschillende organisaties worden daarbij op geen enkel moment prijsgegeven. De onderzoeker krijgt enkel het resultaat van zijn script/query te zien en voor de rest lekken er geen persoonsgegeven, noch naar de onderzoeker, noch naar andere data bronnen.

Dit is in theorie mogelijk met secure multiparty computation (SMC). Vandaag is deze aanpak eerder experimenteel en blijft het doorgaans nog erg moeilijk om dit ook in de praktijk om te zetten. 

3. Onderzoeker wil inzichten verkrijgen uit persoonsgegevens die zich bij één organisatie bevinden.

De onderzoeker die inzichten wil bekomen uit gezondheidsdata, socio-economische data, etc. van burgers kan niet zomaar toegang gegeven worden tot de ruwe geïdentificeerde persoonsgegevens. Het vervangen van de identifiers door codes (pseudoniemen) zal niet volstaan, gezien records via combinaties van attribuutwaarden te herleiden kunnen zijn naar unieke personen. Er zijn een aantal benaderingen om hiermee om te gaan, waaronder de volgende:

• De onderzoeker krijgt slechts toegang tot een vervaagde (gegeneraliseerde) versie van de dataset. Daarbij gaat onvermijdelijk informatie verloren: de data wordt in het beste geval minder nuttig maar blijft wel bruikbaar, terwijl de identificatierisico’s significant dalen. In het slechtste geval wordt de data compleet nutteloos indien we de identificatierisico’s aanzienlijk willen reduceren. De voornaamste technologieën hiervoor zijn k-anonymity en l-diversity. 
• De onderzoeker krijgt geen toegang tot de data zelf, maar kan wel queries uitvoeren. Het resultaat van de query wordt vervaagd voor het aan de onderzoeker doorgegeven wordt. Gezien het voorzien van ruis later gebeurt dan in voorgaande bullet zal het effect op het uiteindelijk resultaat beperkter zijn. Deze aanpak steunt op differential privacy.
• De scripts/queries van de onderzoeker worden in een beveiligde omgeving uitgevoerd en de onderzoeker krijgt enkel toegang tot het uiteindelijke resultaat. Dit vereist geen PET, maar leek ons desondanks het vermelden waard.

4. Publieke instelling wil persoonsgegevens afkomstig van meerdere bronnen kruisen

Dit kan noodzakelijk zijn voor de uitvoering van de opdracht van de publieke instelling zelf, of het kan gebeuren naar aanleiding van een specifieke vraag van een onderzoeker. In dit tweede geval krijgt de onderzoeker in een volgende stap op een gecontroleerde manier toegang tot de gekruiste persoonsgegevens (zie puntje 3).

Cruciaal bij het kruisen is dat het resultaat enkel de minimaal noodzakelijke gepseudonimiseerde gegevens bevat en dat er verder geen ongewenste lekken van persoonsgegevens zijn. Traditionele aanpakken zijn inefficiënt, en daardoor traag en duur.

Privacy-preserving record linkage technieken trachten hier een antwoord op te bieden, al focussen ze doorgaans op situaties waarbij er geen gedeelde burger identifiers zijn – zoals het rijksregisternummer – en er aan string matching gedaan wordt, bijvoorbeeld van – mogelijks verschillend gespelde – persoonsnamen in combinatie met een geboortedatum. Oblivious join – een innovatie van Smals Research – gaat wel uit van gedeelde identifiers en kreeg vorm op basis van businessvereisten in de context van de Belgische gezondheidszorg en sociale zekerheid.

5. Publieke instelling wil persoonsgegevens voor testen / software development

Bij het ontwikkelen en testen van systemen kan de verleiding bestaan om met echte persoonsgegevens te werken, wat uiteraard risico’s inhoudt. In werkelijkheid volstaan misschien gegevens die daarop lijken, maar geen echte persoonsgegevens zijn. Een dergelijke dataset noemt men synthetic data. Het bewaart de structuur van de individuele records, maar ook bepaalde statistische eigenschappen van de gehele dataset.

Indien de systemen in test- of ontwikkelomgevingen moeten interageren met systemen in productie, zal synthetic data alleen vaak niet volstaan gezien de overeenkomsen (vb. gelijk rijksregisternummer) tussen de interne (synthetische) data en de echte data op de externe systemen vernietigd is. In dat geval kan format preserving encryption als een schil rond de test- of ontwikkelomgeving helpen om rijksregisternummers en andere ‘echte’ persoonsgegevens afkomstig van systemen in productie die de schil binnenkomen om te zetten in pseudoniemen die dezelfde structuur hebben als rijksregisternummers. Daarbij kunnen eventueel ook bepaalde eigenschappen behouden blijven binnen de schil (zodat bijvoorbeeld een meerderjarige een meerderjarige blijft). Ook de omgekeerde operatie is mogelijk, waarbij bijvoorbeeld fake-rijksregisternummers (dus eigenlijk pseudoniemen) die binnen de schil bestaan terug omgezet worden in het echte rijksregisternummer wanneer er vanuit de test- of ontwikkelomgeving een vraag gesteld wordt aan een extern systeem in productie over de betrokken burger.

6. Publieke instelling wil extra gegevens opvragen over één of beperkt aantal geïdentificeerde burgers

Er kunnen vanuit justitie onderzoeken gevoerd worden naar specifieke burgers, bijvoorbeeld in het kader van terrorismebestrijding of fraudeopsporing. Persoonsgegevens die beheerd worden door derden moeten daarbij opgevraagd kunnen worden. Denk daarbij bijvoorbeeld aan metagegevens over telefoongesprekken gekend door telecomoperatoren of aan de verschillende officiële verblijfplaatsen doorheen de tijd, wat gekend is door het Rijksregister.

Dergelijke data opvragen bij een andere (private of publieke) organisatie over een specifieke burger is op zich geen uitdaging, althans niet op technisch vlak. Helaas lekt de vragende organisatie daarbij de identiteit van de betrokken burger naar de aanleverende organisatie. Dit brengt zowel de privacy van de betrokkenen als de confidentialiteit van het onderzoek in het gedrang.  Dit is op te lossen met behulp van oblivious transfer.

7. Publieke instelling wil burgers selecteren a.d.h.v. eigenschappen gekend door andere organisatie

Stel dat een wetshandhavingsdienst A wil weten welke van de verdachten die het volgt ook door wetshandhavingsdienst B met hoge prioriteit gevolgd worden. Een naïeve aanpak is dat B een lijst bezorgt aan A met alle verdachten die het met hoge prioriteit volgt en dat A dan eenvoudigweg de doorsnede berekent van haar eigen verdachtenlijst met die van B. B geeft zo echter veel te veel gevoelige persoonsgegevens aan A, dat inderdaad de volledige lijst van personen te weten komt die door B met hoge prioriteit gevolgd worden, terwijl de doorsnede volstaat. Dit wordt opgelost met behulp van private set intersection (PSI).

8. Publieke instelling wil berekeningen op gevoelige persoonsgegevens outsourcen

Bij overwegingen om opslag van en berekenen op gevoelige persoonsgegevens te outsourcen, typisch naar de cloud, is een garantie dat de (cloud) provider zelf op geen enkel moment toegang tot de data zelf kan verkrijgen een noodzaak. 

De sterkste garanties worden geleverd door Trusted execution environments (TEEs) en, meer nog, door homomorphic encryption (HE).

• Een TEE biedt een door hardware beveiligde, afgeschermde omgeving aan op een processor, waarbinnen de confidentialiteit en integriteit van de data en correcte uitvoering van code wordt gewaarborgd. TEE blijft helaas gevoelig voor side-channel attacks.
• HE laat toe om berekeningen te doen op de vercijferde data in plaats van op de data zelf. HE is vandaag doorgaans erg inefficiënt. In het bijzonder blijkt het erg lastig te zijn om ondersteuning te voorzien voor o.a. vergelijkingen condities en array lookups.

Conclusies

Privacy-enhancing technologies (PETs) zijn vandaag vaak nog emerging, waarmee we bedoelen dat de ontwikkeling tot enterprise-ready producten nog bezig is en/of dat praktische toepassingen nog zeldzaam zijn. Toch bieden ze heel wat opportuniteiten, zeker in een publieke sector die de privacy van de burger au serieux neemt. In de komende jaren zullen we dan ook ongetwijfeld een boom in de uptake van deze technologieën zien. Het lijkt uw auteur logisch dat de publieke sector hier een voortrekkersrol in speelt.

De PETs die in dit artikel vermeld worden zijn natuurlijk niet de enige. Bovendien moeten we de meeste hier vermeldde PETs eerder zien als afzonderlijke categorieën van PETs. Zo is oblivious transfer reeds een levend onderzoeksdomein op zich, waarbinnen heel wat verschillende protocollen met uiteenlopende eigenschappen voorgesteld werden en worden.

Smals Research heeft gelukkig reeds heel wat kennis in huis, met zelfs eigen innovaties en implementaties. Ook daarbuiten wordt hard aan de weg getimmerd, onder meer binnen de academische wereld, waarmee Smals Research goede contacten onderhoudt.

Ten slotte geven we nog mee dat PETs ook voor heel wat andere — soms verrassende — toepassingen kennen. Zo kan je met private set intersection (PSI) testen of je paswoord gelekt is, zonder je paswoord zelf prijs te geven. Of je kunt ermee nagaan of je een erfelijke ziekte hebt, zonder je genetische informatie zelf prijs te geven.

We kijken er alvast naar uit om samen met u na te gaan hoe PETs kunnen helpen bij het realiseren of optimaliseren van uw concrete use case.

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.

Les termes “anonymisation” et “pseudonymisation” sont régulièrement mal utilisés, bien que le RGPD les définisse de manière précise. Cette confusion complique les discussions et peut en outre être lourde de conséquences. Par exemple, on parle souvent d’anonymisation alors qu’il subsiste d’importants risques d’identification et que le RGPD reste donc d’application. Cette présentation traite en détail de l’anonymisation et de la pseudonymisation et a été bien accueillie par les DPO de la sécurité sociale et des hôpitaux.

Presentation

Overheidsinstellingen verwerken in het kader van hun opdracht onvermijdelijk grote hoeveelheden – soms erg gevoelige – persoonsgegevens. Dit dient zowel op een efficiënte als op een veilige manier te gebeuren. Traditionele benaderingen, waaronder het gebruik van klassieke cryptografie, zijn helaas niet steeds afdoende.

Stel, bij wijze van voorbeeld, dat de FOD justitie in het kader van een terrorismedossier aan verschillende bedrijven en overheidsinstellingen informatie over een specifieke burger opvraagt. De bevraagde entiteiten komen allen te weten dat er een onderzoek loopt naar deze persoon, wat zowel de privacy van de burger als de confidentialiteit van het onderzoek in het gedrang kan brengen.

Geavanceerde cryptografie kan hiervoor op een elegante manier een oplossing bieden en stelt ons zelfs in staat om zaken te realiseren die intuïtief gewoon onmogelijk lijken. Ondanks het potentieel zijn de mogelijkheden van geavanceerde cryptografie vandaag nog te weinig gekend.

Deze infosessie wil dan ook een bewustzijn rond de mogelijkheden van geavanceerde cryptografie creëren zodat u voortaan cases zult herkennen waarin deze aanpak een uitweg kan bieden. Diverse cryptografische bouwblokken worden op een toegankelijke manier besproken, alsook het – zowel theoretische als praktische – werk dat Smals Research hierrond verricht heeft. Verder komen mogelijke en concrete cases aan bod waar geavanceerde cryptografie toegepast kan worden.

FRANCAIS

Dans le cadre de leur mission, les institutions publiques traitent inévitablement de grandes quantités de données à caractère personnel, lesquelles sont parfois très sensibles. Ce traitement doit être à la fois sûr et efficace. Malheureusement, les approches traditionnelles, notamment l’usage de la cryptographie classique, ne sont pas toujours suffisantes.

Supposons, par exemple, que le SPF Justice demande des informations à diverses entreprises et institutions publiques à propos d’un citoyen dans le cadre d’un dossier de terrorisme. Toutes les entités interrogées sauront ainsi que cette personne fait l’objet d’une enquête, ce qui peut compromettre tant la vie privée du citoyen que la confidentialité de l’enquête.

La cryptographie avancée peut offrir une solution élégante à ce problème et nous permet même de réaliser des choses qui semblent a priori impossibles. En dépit de ce potentiel, les possibilités de la cryptographie avancée sont encore trop peu connues aujourd’hui.

L’objectif de cette séance est donc de vous sensibiliser aux possibilités de la cryptographie avancée pour vous permettre d’identifier les cas où cette approche peut s’avérer utile. Différents composants cryptographiques y seront abordés en des termes simples. Vous y découvrirez également les travaux – théoriques et pratiques – que Smals Research a réalisés en la matière. En outre, des cas potentiels et concrets où la cryptographie avancée peut être appliquée seront abordés.

Presentation

De GDPR vermeldt nadrukkelijk pseudonimisatie als maatregel om persoonsgegevens te beschermen, wat tevens past in het privacy by design principe dat in diezelfde verordening gepromoot wordt. In artikel 32 lezen we er bijvoorbeeld:

“Rekening houdend met de stand van de techniek, de uitvoeringskosten, alsook met de aard, de omvang, de context en de verwerkingsdoeleinden en de qua waarschijnlijkheid en ernst uiteenlopende risico’s voor de rechten en vrijheden van personen, treffen de verwerkingsverantwoordelijke en de verwerker passende technische en organisatorische maatregelen om een op het risico afgestemd beveiligingsniveau te waarborgen, die, waar passend, onder meer het volgende omvatten: a)  de pseudonimisering en versleuteling van persoonsgegevens b) …

en in artikel 89:

“De verwerking met het oog op archivering in het algemeen belang, wetenschappelijk of historisch onderzoek of statistische doeleinden is onderworpen aan passende waarborgen in overeenstemming met deze verordening voor de rechten en vrijheden van de betrokkene. Die waarborgen zorgen ervoor dat er technische en organisatorische maatregelen zijn getroffen om de inachtneming van het beginsel van minimale gegevensverwerking te garanderen. Deze maatregelen kunnen pseudonimisering omvatten, mits aldus die doeleinden in kwestie kunnen worden verwezenlijkt. Wanneer die doeleinden kunnen worden verwezenlijkt door verdere verwerking die de identificatie van betrokkenen niet of niet langer toelaat, moeten zij aldus worden verwezenlijkt. …”

Pseudonimisatie impliceert dat persoonsgegevens niet langer rechtstreeks d.m.v. een identificatiesleutel zoals het rijksregister gekoppeld kunnen worden aan een natuurlijk persoon, maar enkel m.b.v. additionele informatie die elders bewaard wordt. Gepseudonimiseerde persoonsgegevens zijn een nieuwe categorie gegevens in de privacywetgeving.

Het idee van pseudonimisatie is dat eenzelfde burger in elke context slechts gekend is onder het context-specifieke pseudoniem. Persoonsgegevens uit de ene context zijn dus niet zomaar te koppelen aan gegevens over dezelfde persoon in een andere context of aan de natuurlijke persoon zelf. Dit maakt misbruik een pak moeilijker. Een context kan echter heel wat betekenen, zoals blijkt uit onderstaande voorbeelden.

• Online leerplatformen. Scholen maken in toenemende mate gebruik van online leerplatformen, waar de leerlingen allerlei materiaal ter beschikking krijgen en ook huiswerk maken en testen afleggen. Deze data kan commercieel erg waardevol zijn voor zowel de aanbieder van het platform als voor hackers, zeker als het te koppelen is aan andere informatie van die scholier. Mogelijks bevat het profiel van de leerling medische – en dus gevoelige – informatie; Een leerling kan bijvoorbeeld meer tijd krijgen voor een online test omwille van dyslexie.
  De school moet de leerling natuurlijk wel kunnen identificeren, maar er is geen enkele reden dat ook het online platform dit zou moeten kunnen. We willen niet dat eenzelfde platform over de jaren en vakken heen een erg uitgebreid profiel aan eenzelfde leerling kan koppelen. Per jaar en per vak zou een leerling door het platform slechts gekend kunnen zijn onder een apart pseudoniem, terwijl slechts de school in staat is pseudoniemen van eenzelfde scholier aan elkaar te koppelen. De context is hier dus een vak tijdens een bepaald schooljaar.
• Wetenschappelijke onderzoek. Geregeld is er in het kader van een specifiek wetenschappelijke onderzoek nood aan een – rijk of minder rijk – gegevensbestand met bijvoorbeeld specifieke medische gegevens van bepaalde burgers. Een context komt hier overeen met een specifiek onderzoek. Zelfs indien de wetenschappers (of hackers) zouden willen, zijn ze niet in staat op basis van het pseudoniem gegevens van eenzelfde persoon aan elkaar of aan publiek beschikbare gegevens over die burger te koppelen.
• Data warehouse.  Zowat elke overheidsinstelling beheert een specifieke set burgergegevens, wat onder meer kan gaan over pensioen-, medische, professionele of fiscale gegevens.  Echter, om zinvolle analyses te kunnen doen moeten vaak gegevens afkomstig van meerdere bronnen – zoals overheidsinstellingen en medische sensoren – gekruist (gecombineerd) worden.  Om praktische redenen zou geopteerd kunnen worden voor een data warehouse dat alle persoonsgegevens bevat die eventueel ter beschikking gesteld kunnen worden voor analyses of wetenschappelijk onderzoek (zie vorig puntje). Een wetenschapper krijgt dan uiteraard enkel toegang tot die gegevens die strikt noodzakelijk zijn voor het onderzoek in kwestie. Maar indien in dit data warehouse alle gegevens van eenzelfde burger triviaal aan elkaar en aan een natuurlijk persoon gekoppeld kunnen worden – bijvoorbeeld m.b.v. het rijksregisternummer -, ontstaat uiteraard een onaanvaardbaar groot privacyrisico. Daarom zou geopteerd kunnen worden om de gegevens van eenzelfde burger te verspreiden over heel wat verschillende compartimenten in het data warehouse. In het ene compartiment kunnen fiscale gegevens bewaard worden, in een ander basisgegevens zoals geboortedatum, geslacht en woonplaats. Op elk van die compartimenten is eenzelfde burger gekend onder een ander pseudoniem. Slechts wanneer de organisaties en bedrijven die de data aanleveren meewerken, kunnen bepaalde gegevens gekoppeld worden. Elk compartiment is een afzonderlijke context. Het profiel van een burger wordt dus in heel wat stukjes gebroken, die quasi onmogelijk in elkaar gepast kunnen worden door onbevoegden. Bovendien zijn kleinere stukjes sowieso moeilijker aan een natuurlijk persoon te koppelen dan grotere stukken data.

Bovenstaande toepassingen in de praktijk brengen zal al snel vrij omslachtig worden wanneer gebruik gemaakt wordt van traditionele pseudonimisatietechnieken, dus op basis van willekeurig gegenereerde pseudoniemen, cryptografische hashing of (symmetrische of asymmetrische) cryptografische vercijfering. Daarom wordt het best gekeken naar meer geavanceerde cryptografische pseudoniemistatietechnieken. Deze technieken zijn vrij jong en vandaag nog te weinig gekend, maar maken een onwaarschijnlijke flexibiliteit en bescherming mogelijk.

Smals Research was in 2015 een van de eersten die een dergelijk cryptografische pseudonimiseringssysteem ontwikkelde en succesvol toepaste in een proof of concept. Ondertussen publiceerden onder meer de Radboud Universiteit van Nijmegen en het onderzoekslab van IBM in Zürich reeds erg waardevolle bijdragen, de eerste op een meer praktisch, de tweede op een meer theoretisch niveau.

Het idee dat telkens terugkomt is dat een natuurlijke persoon in elke context gekend is onder een ander pseudoniem. Met een geheime sleutel worden rijksregisternummers omgezet in pseudoniemen, die eventueel op hun beurt weer omgezet kunnen worden in andere pseudoniemen. De operatie kan dus transitief zijn. Twee verschillende pseudoniemen van eenzelfde persoon kunnen eventueel met de juiste sleutels na hun respectievelijke converties resulteren in één en hetzelfde pseudoniem. Daardoor kan de bijhorende data onder bepaalde condities aan elkaar gekoppeld worden zonder te weten over welke natuurlijke persoon het gaat. Eventueel kan een derde partij een pseudoniem onder bepaalde voorwaarden, bijvoorbeeld na akkoord van de gegevensbeschermingsautoriteit, opnieuw koppelen aan het oorspronkelijke rijksregisternummer. Bovendien kunnen dergelijke systemen transparantie bieden aan – en enkel aan – de betrokken burger. (Ter volledigheid geven we mee dat niet elk pseudoniemsysteem alle in deze paragraaf beschreven eigenschappen bezit.)

De Radboud universiteit heeft i.s.m. de Nederlandse provincie Gelderland reeds een onderzoeksproject opgezet met een budget van 1,6 miljoen euro. Het project gaat specifiek over het op een privacy-vriendelijke wijze uitwisselen van medische gegevens voor onderzoeksdoeleinden. Er werd reeds succesvol een concrete piloot opgezet, waarbij 650 Parkinson-patiënten over een periode van 2 jaar gevolgd worden en waarbij allerlei gegevens aangeleverd worden door draagbare toestellen (wearable devices). Bovendien zou  hun pseudoniem- en encryptiesysteem ondersteund worden door de toekomstige Nederlandse eID kaart.

In al de bovenstaande voorbeelden heeft de betrokken burger geen controle over wat er met zijn rijksregister en pseudoniemen gebeurt. Er zijn echter andere systemen – Attribute-based credentials – waarbij de pseudoniemen onder de controle van de burger zelf blijven. De burger kan dan zelf beslissen om zich tegenover verschillende entiteiten kenbaar te maken onder verschillende, onlinkbare pseudoniemen, eventueel gekoppeld aan bepaalde gecertifieerde persoonsgegevens zoals leeftijd. Hier zal in een toekomstige blogpost dieper op ingegaan worden.

Samengevat bieden cryptografische pseudoniemen een krachtig instrument om persoonsgegevens, en daarmee ook de privacy van de betrokkenen, beter te beveiligen. Het is dan ook niet enkel een nuttig, maar op termijn noodzakelijk instrument om toepassingen in overeenstemming te brengen met de GDPR.

Aarzel niet ons te contacteren om toepassingen binnen de context van de overheid in België te bespreken!

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

Introduction

We focus on the following situation. What if a research team wants to analyse large sets of personal data? Say it needs medical, financial and demographic data of all citizens with a wage of at least € 40.000, born in or after 1990 and who are self-employed as a secondary activity. Data sets managed by different government organizations would need to be linked together. Such requests are common, and any government should be able to answer them. Yet is it possible with due respect for the privacy of citizens in an era of big data?

Before answering this question, let’s first clarify the distinction between the three categories of data defined in the GDPR: Anonymous data, identified data and the new category, pseudonymous data.

• Anonymous data can impossibly be linked to a natural person. An example are statistical medical data. The GDPR is not applicable on anonymous data.
• Identified data are linkable to a natural person without additional information. An example are medical records that contain the citizen’s social security number. The GDPR fully applies on identified data.
• Pseudonymous data is linkable to a natural person, but only with extra information that is stored elsewhere. An example are medical records where the citizen’s social security number is replaced by a unique code. The mapping between these codes and the citizens’ social security numbers is stored separately. The GDPR still applies, but some provisions are relaxed. The GDPR encourages the use of pseudonymous data.

By replacing identifiers by pseudonyms, we convert identified data into pseudonymous data. However, completely removing the identifiers does not necessarily result in anonymous data and should in many cases still be considered as pseudonymous data. Imagine, for instance, that the medical records contain the social security number, the gender, date of birth, the ZIP code and some medical data, such as the disease the citizen is suffering from. Imagine that only the identifiers are removed. If Bob knows the date of birth, gender and ZIP code of Alice, he is often able to link this de-identified medical record uniquely to Alice, and is, hence, able to learn sensitive medical data about her.

In a traditional approach, the data-delivering government organizations send the required data on a regular basis to a central data warehouse that stores the personal data. Data of the same citizen are trivially linkable to each other. If a research team wants to analyse data, it receives a pseudonymized subset of the data. Although linking of data originating from different sources becomes trivial, the approach comes with several risks:

• The data-delivering government organizations lose all control over the personal data for which they are still legally accountable. These government organizations have, as data controllers, indeed still responsibilities and duties according to the GDPR. How is it sure that the data are not used for purposes incompatible with the purpose for which they have been initially collected?
• In case of a data breach of the data warehouse, the consequences are dramatic, not only for the institution managing the data warehouse, but also for the millions of citizens whose privacy is severely affected. We see indeed that hacking attempts become increasingly professional and that the amount of personal data amassed by organizations and companies explodes. Both aspects contribute to the increase in risk.
• Even when pseudonimized, the data entrusted to the research team generally remain sensitive. If these data are stolen or made public, the consequences for citizens’ privacy can still be considerable.

Can we do better? Can we use technology to reduce these risks? How well can we protect personal data by using cryptographic pseudonyms? By answering these questions, we also shed light on what future analysis on personal data originating from multiple sources might look like.

The Data Archipelago – Central Ideas

The core idea is to have, instead of one big data warehouse, several ‘data islands‘ which are maximally isolated. As illustrated in the figure below, we distinguish between the long-term domain islands, with strong isolation, and the short-term project islands, with a somewhat weaker isolation.

Domain islands. Each data-providing organization controls its own domain island (or islands) and keeps the contained data up-to-date. It only uploads these personal data to the domain islands that might be made available for data analysis projects. The data in the domain island is, hence, a subset of all the personal data controlled by the government organization. We use two principles to maintain perfect isolation between domain islands:

1. Island-specific pseudonyms, instead of identifiers, are used for personal data on the domain islands. Different domain islands use a different, unlinkable pseudonym for the same citizen. Only after a procedure in which the involved government organizations give their consent with a secret cryptographic key, data about the same citizen can be linked together, without revealing any identifiers (see later).
2. Attribute partitions. There is no overlap between the attributes stored by the domain islands. If domain island A stores your gender, no other domain island will contain it. Hence, If an entity has access to multiple islands, (s)he will be unable to link any of the records to each other based on attributes.

Hence, an attacker cannot know whether a record in domain island A and another record in domain island B belong to the same citizen. Only with the proper cryptographic keys, which are controlled and kept secret by the data-providing government organizations, it is possible to do this linking.

Domain islands can be stored in the central data warehouse, or on infrastructure of the controlling government institution. However, the data warehouse should be able to communicate with the domain islands.

Project islands. For each approved project, personal data originating from different domain islands are selectively linked together and stored on a project island. The project island only contains relevant attributes of the involved citizens. The lifetime of a project island is restricted to the duration of the project. Also, the project islands stay under the exclusive control of the data warehouse. Researchers are allowed to do certain data queries on the project island, but are never allowed to have full access to the raw data. Hence, we bring the calculations to the data instead of the data to the calculations.

Also, for the project islands, isolation is maximized, although at a lower level than the domain islands. We again apply the concept of island-specific pseudonyms. For each (domain or project) island, the same citizen is known under a different pseudonym. Note, however, that based on shared attributes, it might be possible to link records on a project island to other (domain or project) islands. Therefore, it is still important to sufficiently protect the project islands and minimize not only their lifetime, but also the data they store. Maybe the project does not need the exact date of birth, but just an age category.

By applying this approach, we arrive at the situation shown in the figure below. Although records of the same citizen are known by organizations under the same social security number, the citizen’s personal data are known under a different pseudonym on each island.

This results in the following properties:

• Maximal control by organizations. We give the data-delivering government organizations full control over what happens with their data. They receive a description of the new analysis project and only if it is compatible with the purposes for which it has originally been collected, the data is delivered to the project.
• Smaller impact in case of data breach & better privacy. In case a hacker has access to data in several islands, or in case data are leaked into the public, the damage is limited. Data on the permanent domain islands are in any case unlinkable. The linkability of data on project islands is minimized, by the use of project-specific pseudonyms and by limiting the data on and the lifetime of project islands. This way, we maximize the isolation between the islands, and, hence, the privacy of the citizens. Indeed, the more data of the same citizen you can link, the easier it becomes to identify this person.

Linking records with cryptography

The use of cryptographic keys is sketched in the figure below. Organizations and islands have keys, which are used to convert identifiers into pseudonyms or pseudonyms into other pseudonyms. Pseudonym conversion is indicated by a dashed line near the corresponding key.

Each organization has a master key, each domain island has a key per project that it delivers data to, and each project island has one key per domain that it receives data from.

All government organizations in Belgium use the same social security number to identify a citizen. Using their master key, they convert it into a pseudonym that is used on the level of the domain island. Each government institution has its own master key. The same social security number converted with two different master keys results in two different, without the cryptographic keys unlinkable, domain pseudonyms. A subset of the data controlled by the data-providing government organization is sent to the domain island, whereby the social security numbers are replaced by these pseudonyms.

When a project is created, the involved domain islands each obtain a project-specific key, and the project island obtains a domain-specific key per involved domain island. Domain pseudonyms are converted with the project-specific key into unique transfer pseudonyms. When these transfer pseudonyms are received by the project island, they are converted with the domain-specific key into a project pseudonym. The transfer pseudonyms are deleted after the data transfer. Once all data is delivered by the domain islands to the project island, the associated keys in the project and the islands should be removed. The government organizations should, however, maintain their master keys.

By properly choosing the keys in the system, the following properties are achieved:

• Different domain pseudonyms corresponding to the same citizen are always converted into the same project pseudonym. Hence, different, unlinkable pseudonimized records of personal data received from different domain islands become again linkable on the project island.
• Domain pseudonyms of different citizens are converted into different project pseudonyms on the same project island.
• The same citizen is known under different, unlinkable pseudonyms on different project islands

In summary, a citizen is known under a different, unlinkable pseudonym on each island that contains personal data about him or her.

An example to illustrate the protocol

Let’s have a look at the example described in the introduction. A research team wants to analyse large sets of personal data. Say it needs medical, financial and demographic data of all citizens with a wage of at least EURO 40.000, born after 1990 and who are self-employed as a secondary activity. For the moment, we restrict our example to three domain islands and assume that the required personal data are stored in the second and third domain island:

• The first is the domain island of the National Register (Rijksregister) which contains for each citizen data about date of birth, gender, place of residence, nationality, etc.
• The second, the RSVZ island, contains data about independents in Belgium, and, hence, knows who is self-employed as secondary activity.
• The third one, the RSZ island, has the data about employees, and, hence knows the wage of each citizen.

In order to obtain the required data, the following steps, illustrated in the four pictures below, are performed:

1. The project island asks each of the involved domain islands for the relevant pseudonyms. It asks the domain island of the National Register to provide the pseudonyms of all citizens that are born in or after 1990, it asks the RSVZ island to provide pseudonyms of all citizens who are self-employed as secondary activity and it asks the RSZ island for the pseudonyms of citizens who have a salary of at least 40 000 €.
2. Each of the involved islands retrieves locally the relevant domain pseudonyms, converts them into transfer pseudonyms and sends them to the project island. The project island converts each of the received transfer pseudonyms with the proper key into project pseudonyms. For each involved domain island, the project island now has a separate set of project pseudonyms.
3. The project island now takes the intersection of the three pseudonym sets, resulting in the set of project pseudonyms of the citizens of which the project islands needs data.
4. For each domain island of which data are needed, these pseudonyms are again converted into transfer pseudonyms, sent to the domain island, which converts the transfer pseudonyms back into domain pseudonyms.
5. The domain islands now select for each of the resulting domain pseudonym the relevant data and sends for each of the pseudonyms the relevant data to the project island. Again, the domain pseudonyms are converted into transfer pseudonyms by the domain islands before the data is sent to the project island
6. Upon receipt of the data records, the transfer pseudonyms are again converted into project pseudonyms. Each received data record now has a project pseudonym. If and only if two data records have the same project pseudonym, they belong to the same citizen and they can be trivially linked.

The six steps in the protocol to link data in a project island. A dashed line above a key indicates a cryptographic pseudonym conversion. Click on the figures to enlarge.

Step 1	Step 2
Steps 3 and 4	Steps 5 and 6

In case data needs to be retrieved from other domain islands, besides the ones of the RSVZ and the RSZ, steps 4,5 and 6 are also executed between the project island and each involved domain island. This way, the project island can also obtain, for instance, medical data.

The proposed approach ensures that the data-providing government organizations maintain maximal control over what happens with the data, since they control the cryptographic keys of their domain islands. The approach also ensures that the domain island does not learn more personal data than strictly necessary.

The presented approach, however, has some drawbacks.

• Personal data leaks to the domain islands. In our example, the RSVZ island learns that the pseudonyms received in step 4 belong to people born in 1990 or later with a salary of over 40 000 €. Similarly, the RSZ learns new personal information.
• The project island can ask too much data from the domain islands. In step 4, the domain islands cannot know whether the received pseudonyms belong effectively to the intersection calculated in step 3. This enables the project island to request also data about pseudonyms that are not in the intersection.

Both drawbacks can be prevented. We refer to our detailed report for more details.

Conclusions

In this article, we sketched the main ideas of the Data Archipelago, which we invented three years ago. Since then the concept has only gained importance, especially given the upcoming GDPR. Indeed, this European regulation encourages the use of privacy by design, which is exactly what we did here, as well as the use of pseudonyms. We presented a very specific case, linking together personal data for data analysis purposes, but we are convinced that the use of cryptographic pseudonyms can and should also be applied in many other contexts to better protect the privacy of citizens. In that respect, in the meantime we also came up with a blockchain based prescription processing scheme, that uses one-time pseudonyms to protect not only the privacy of the involved citizens, but also the confidentiality of business information. Unfortunately, the use of cryptographic pseudonyms is less straightforward than traditional approaches, which poses to European governments the challenge of obtaining and developing the right competences.

Several aspects have not been discussed in this introductory article. We didn’t talk about key generation, re-identification in case of fraud, or less straightforward combinations such as family configurations. We emphasize that for each of these aspects, we have come up with solutions.

Further information

• The content of this article was presented at InfoSecurity Brussels on 25 March 2017. The slides can be downloaded here.
• We wrote a scientific document were everything is described in detail.
• We also published a more accessible report in Dutch.

If you have questions or suggestions regarding our approach, feel free to contact us.