Masks are being used for thousands of years, all across the physical world, for reasons such as physical protection, rituals and hiding the identity of the bearer. Physical masks are probably the oldest privacy protection technology.

When writing and printing, authors of books and articles used pseudonyms to hide their identity. Voltaire, Lenin and Banksy are well known pseudonyms: modern, written versions of the physical mask. In the digital age we now replace citizens’ identifiers by unique codes – having remarkably powerful and even counter-intuitive properties when based on cryptography.

The public sector has two seemingly contradictory tasks: protecting citizens and their privacy, while maximizing value and efficiency for individuals and society. So should we minimize or maximize data?

The Belgian public sector increasingly adopts cryptography for pseudonymization – a crucial, and yet sufficiently practical element in realizing the seemingly impossible.

In this talk, Kristof introduces three practical cryptographic systems for pseudonymization. He has designed them, based on specific needs within social security and healthcare. If you live in Belgium, your personal data is probably already protected by one of these systems, today.

Presentation

Le nouveau service de pseudonymisation d’eHealth offre des garanties de sécurité élevées. Il est actuellement utilisé pour protéger la vie privée des citoyens, notamment lors du stockage et du traitement des ordonnances électroniques. Ce service se prête en outre particulièrement bien au croisement et à la pseudonymisation de données à caractère personnel dans le cadre de projets de recherche. Le présent article expose la manière dont cela serait possible d’un point de vue conceptuel.

Le service de pseudonymisation à l’aveugle d’eHealth

Le service de pseudonymisation à l’aveugle d’eHealth a déjà été décrit en détail dans un article précédent. Nous reprenons ici le scénario où un médecin (client) demande au service interne de prescription (owner) d’enregistrer une prescription électronique.

L’illustration 1 expose le flux de base: le médecin demande au service de pseudonymisation de convertir un identifiant en pseudonyme. Le médecin envoie ensuite le pseudonyme avec les données de l’ordonnance au service internet de prescription, qui stocke les données de la prescription sous ce pseudonyme.

Illustration 1. Flux de base pour le scénario où un médecin (client) demande au service de prescription (owner) d’enregistrer une prescription électronique.

Afin d’atteindre un niveau de sécurité élevé, les dispositifs de sécurité suivants sont essentiels :

1. Le client est hypermétrope: il ne voit que les identifiants globaux (numéros de registre national).
2. Le owner (propriétaire) est myope: il ne voit que les identifiants locaux (pseudonymes).
3. Le service de pseudonymisation est aveugle: il ne voit ni les identifiants ni les pseudonymes.

L’illustration 2 présente comment cela est possible en ajoutant un certain nombre d’étapes au flux de l’illustration 1.

1. La caractéristique de sécurité service de pseudonymisation aveugle (3) est réalisée à l’aide des opérations blind et unblind (indiqué en violet). Le numéro de registre national du patient est masqué, ce qui correspond à un chiffrement de courte durée avec une clé qui n’est utilisée qu’une seule fois. Le service de pseudonymisation convertit le numéro de registre national masqué en un pseudonyme masqué, sans voir ni le numéro de registre national d’origine ni le pseudonyme résultant (oubliez les opérations indiquées en bleu et orange pour le moment ; nous y reviendrons plus tard). Seul le client peut lever l’occultation effectuée par blind à l’aide de l’opération unblind.
2. Dans le flux de base de l’illustration 1, le owner ne connaît aucun numéro de registre national, de sorte que la caractéristique de sécurité owner myope (2) est déjà réalisée.
3. Enfin, grâce aux opérations encrypt et decrypt (indiquées en orange), la caractéristique de sécurité client hypermétrope (1) est réalisée: le service de pseudonymisation chiffre le pseudonyme occulté de sorte que seul le owner puisse le déchiffrer.

Enfin, la réutilisation non autorisée des pseudonymes chiffrés – que le client obtient après l’opération unblind – est évitée parce que le service de pseudonymisation utilise l’opération add context (en bleu) pour ajouter des informations contextuelles au pseudonyme chiffré, telles que l’heure de création. Le owner vérifiera ces informations à l’aide de l’opération verify context (en bleu) et n’acceptera que les pseudonymes chiffrés reçus qui ont été créés récemment.

Illustration 2. Flux High security pour le scénario où un médecin (client) demande au service de prescription (owner) d’enregistrer une prescription électronique.

L’opération convert

Dans la section précédente, le service de pseudonymisation a appliqué spécifiquement l’opération pseudonymise pour convertir les numéros de registre national en pseudonymes. Dans certains scénarios, l’opération inverse est également nécessaire, à savoir l’opération d’identification, où un pseudonyme connu du owner est reconverti en numéro de registre national d’origine du côté d’un client.

Les systèmes (owner) communiquent également les uns avec les autres. Un service sur la plateforme eHealth pourrait demander au service TherLink si un patient a une relation thérapeutique avec un médecin en particulier. Si TherLink utilise également des pseudonymes, le pseudonyme d’un service/owner devra être converti en pseudonyme de l’autre service/owner. Cela s’effectue à l’aide de l’opération convert. En effet, afin de minimiser le risque d’identification, il convient de ne pas réutiliser les pseudonymes dans plusieurs services.

Ainsi, les trois opérations que le service de pseudonymisation doit prendre en charge sont pseudonymise, identify et convert. Nous verrons que les opérations pseudonymise et convert sont toutes deux utiles pour croiser et pseudonymiser des données à caractère personnel. À l’inverse, l’opération identify nous permet de procéder à l’identification contrôlée des citoyens. Cela peut être souhaitable dans certaines situations, par exemple lorsque des chercheurs découvrent que certains citoyens courent un risque très élevé de souffrir de certaines maladies, ou qu’ils en sont déjà atteints sans le savoir.

Croisement des données à caractère personnel – l’approche actuelle

Pour les besoins de la recherche, les données à caractère personnel provenant de différentes sources sont régulièrement croisées et pseudonymisées. Cette dernière mesure est nécessaire pour empêcher le chercheur d’établir un lien entre les données à caractère personnel et les personnes physiques.

Prenons comme exemple concret la délibération 13/093 du 22 octobre 2013, qui donne à Sciensano l’accès à des données médicales provenant de différents hôpitaux, dans le but d’obtenir des informations sur l’épidémiologie des patients atteints de diabète. Ce faisant, Sciensano ne découvre pas de numéro de registre national, mais uniquement des pseudonymes.

L’illustration 3 montre – de manière quelque peu abstraite – comment cela est fait à ce jour en utilisant eHealth Batch Codage, un service de pseudonymisation qui existe depuis un peu plus longtemps que notre service de pseudonymisation à l’aveugle. data^A_id est la donnée relative au citoyen avec le numéro de registre national id fourni par l’hôpital A.

Pour chaque citoyen concerné, les hôpitaux envoient les données demandées directement à Sciensano et le numéro de registre national à eHealth Batch Codage. Ce dernier convertit le numéro de registre national en un pseudonyme spécifique au projet, le pseudonym^link_id, et envoie ce pseudonyme à Sciensano. Sciensano reçoit donc les données provenant d’un hôpital par un canal et les pseudonymes provenant de Batch Codage par un autre canal. Grâce à un pseudonyme de transit temporaire (par exemple nym^A_id), qui est caché à Batch Codage, Sciensano est en mesure de relier les données aux pseudonymes spécifiques au projet. Enfin, grâce à ces pseudonymes spécifiques au projet, Sciensano peut relier des données concernant le même citoyen mais provenant de sources différentes.

Illustration 3. Croiser et pseudonymiser les données à caractère personnel provenant de plusieurs hôpitaux et destinées à Sciensano, comme décrit dans la délibération 13/093.

Cette approche présente un certain nombre d’inconvénients :

• Le Batch Codage doit être fiable. Il s’agit d’un tiers de confiance (Trusted Third Party TTP) ; il voit à la fois les numéros de registre national entrants et les pseudonymes sortants. Il sait à quel projet de croisement il collabore et peut donc théoriquement établir des profils pour chaque citoyen ; par exemple, après deux projets, il sait quels citoyens ont participé à la fois à la recherche sur le diabète et sur la sclérose en plaques. Ces profils pourraient éventuellement contenir un grand nombre d’informations sensibles.
• Deux canaux de communication. Sciensano devrait être en mesure de relier les données reçues directement des hôpitaux aux pseudonymes reçus du Batch Codage. Bien qu’il existe une solution, il serait plus élégant que toutes les informations soient envoyées directement de l’hôpital à Sciensano par un seul canal.
• Mauvaise intégration lorsque les données sont pseudonymisées. Ce système ne peut pas traiter de manière élégante les situations où une ou plusieurs sources de données utilisent déjà le service de pseudonymisation à l’aveugle décrit plus haut et n’ont donc pas elles-mêmes de numéro de registre national.

Croiser des données personnelles avec le service de pseudonymisation à l’aveugle

Les trois inconvénients décrits dans le paragraphe précédent pourraient être résolus en utilisant dès à présent le service de pseudonymisation à l’aveugle.

Le scénario dans lequel toutes les sources de données conservent les données à caractère personnel sous le numéro de registre national est représenté dans l’illustration 4. Le flux entre un hôpital (data source) et Sciensano (collector) est exactement le même que celui de l’illustration 1, les trois propriétés de sécurité formulées précédemment étant évidemment maintenues :

• Les sources de données (data source, par exemple les hôpitaux) sont hypermétropes et ne voient donc que les numéros de registre national
• Le collector (par exemple Sciensano) est myope et ne voit donc que les pseudonymes spécifiques au projet
• Le service de pseudonymisation est aveugle et ne voit donc aucun des deux.

Si plusieurs sources de données fournissent des données sur le même citoyen, elles communiquent le même numéro de registre national au flux de pseudonymisation (ligne pleine), ce qui donne le même pseudonyme spécifique au projet du côté du collecteur. Cela permet au collecteur de relier les données sur le même citoyen provenant de différentes sources de données.

Illustration 4. Croisement et pseudonymisation de données provenant de différentes sources de données, qui stockent toutes des données à caractère personnel sous des numéros de registre national.

L’illustration 5 présente pour finir un scénario mixte, dans lequel au moins une source de données stocke des données à caractère personnel sous des numéros de registre nationaux et au moins une source de données stocke des données à caractère personnel sous des pseudonymes obtenus à l’aide du service de pseudonymisation à l’aveugle. Cette dernière source de données pourrait, par exemple, être le service interne de prescription de l’illustration 1.

Nous obtenons donc deux variantes du flux de pseudonymisation (ligne pleine) :

• Le service de pseudonymisation reçoit un pseudonyme en aveugle de la source de données A et effectue une opération convert (voir la section “L’opération convert“) pour obtenir un pseudonyme à l’aveugle spécifique au projet.
• Le service de pseudonymisation reçoit un numéro de registre national en aveugle de la source de données B et effectue une opération pseudonymise pour obtenir un pseudonyme à l’aveugle spécifique au projet.

Dans le cas où le pseudonyme que la source de données A a donné en entrée correspond au numéro de registre national que la source de données B a donné en entrée, il en résultera le même pseudonyme spécifique au projet chez Sciensano.

Dans le cas contraire, les deux flux sont identiques. Rien ne change ni pour les sources de données (par exemple, les institutions publiques) ni pour le collector (par exemple, Sciensano).  Le collector n’a même pas besoin de savoir si une source de données utilise des pseudonymes ou non.

Illustration 5. Croiser et pseudonymiser les données provenant de deux sources de données, l’une stockant les données à caractère personnel sous des numéros de registre national et l’autre sous des pseudonymes.

Les inconvénients de l’approche actuelle mentionnés précédemment sont supprimés :

• Le service de pseudonymisation ne voit ni les identifiants ni les pseudonymes et ne peut donc plus créer de profils. En outre, le fait d’effectuer plusieurs fois une opération en aveugle sur le même numéro de registre national (ou pseudonyme) donne lieu à une opération en aveugle différente à chaque fois. Le service de pseudonymisation ne peut donc pas non plus utiliser les identifiants ou les pseudonymes masqués pour relier les informations de profil.
• Le collector (par exemple Sciensano) reçoit toutes les informations provenant de la même source de données (par exemple, l’hôpital) par un seul canal direct.
• Nous pouvons traiter de manière particulièrement élégante les situations dans lesquelles une ou plusieurs sources de données utilisent déjà le service de pseudonymisation à l’aveugle.

Conclusion

Grâce au service de pseudonymisation à l’aveugle d’eHealth, nous pouvons élégamment et en toute sécurité croiser et pseudonymiser des données provenant de différentes sources de données à des fins de recherche.

En outre, un autre avantage est qu’aucune infrastructure supplémentaire n’est nécessaire ; beaucoup plus de prescriptions sont émises et traitées pendant la journée que pendant la nuit. Par conséquent, la capacité de pseudonymisation est largement excédentaire pendant la nuit. C’est donc le moment idéal pour réaliser de tels projets de croisement, qui ne sont pas critiques en termes de temps. Bien entendu, les missions critiques en termes de temps sont toujours prioritaires.

Pour chaque projet de croisement, le service de pseudonymisation utiliserait une clé différente, ce qui entraînerait l’impossibilité de relier les pseudonymes au niveau du collecteur ; il ne serait alors pas en mesure de relier les données relatives au même citoyen, mais provenant de projets différents, sur la base des pseudonymes. 

Si cela s’avère nécessaire, la réidentification est possible grâce à l’opération identify, mais uniquement avec l’autorisation et la coopération du service de pseudonymisation, ce qui permet d’éviter l’arbitraire et les abus. Ces demandes doivent également être enregistrées. Le service de pseudonymisation peut également, si nécessaire, retirer la clé de pseudonymisation à un moment convenu, rendant ainsi impossible toute réidentification par ce moyen.

Bien entendu, les opérations blind et unblind doivent être prévues dans le logiciel utilisé par les sources de données, tandis que du côté du collecteur, les opérations decrypt et verify context doivent être prévues. L’expérience montre que cette intégration se fait sans problème.

Il convient toutefois de noter que cette approche n’est utile que si toutes les sources de données peuvent déterminer de manière autonome quels enregistrements sont pertinents et lesquels ne le sont pas. Ce n’est pas toujours le cas, comme par exemple dans le projet de croisement des données approuvé pendant la délibération 20/020 du 14 janvier 2020, où la Fondation Registre du Cancer est le seul à pouvoir fournir des données sur les citoyens atteints de sclérose en plaques (SEP), mais ne peut pas savoir qui est atteint de SEP. Smals Research a également trouvé une solution efficace et flexible pour cela. Cette solution est accessible à tous, ce qui élimine la nécessité d’un service de pseudonymisation pour assurer la sécurité de la pseudonymisation. Cela dépasse toutefois le cadre de cet article.

Si notre solution ou d’autres solutions de pseudonymisation et de référencement croisé des données à caractère personnel vous intéressent, n’hésitez pas à nous contacter.

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.

Image source: Pixabay

De nieuwe pseudonimiseringsdienst van eHealth biedt hoge veiligheidsgaranties en wordt momenteel ingezet om de privacy van de burger te beschermen onder meer bij de opslag en verwerking van elektronische voorschriften. Deze dienst leent zich daarnaast ook bijzonder goed voor het kruisen en pseudonimiseren van persoonsgegevens in het kader van onderzoeksprojecten. Dit artikel licht toe hoe dit conceptueel mogelijk zou zijn.

De blinde pseudonimiseringsdienst van eHealth

De blinde pseudonimiseringsdienst van eHealth werd reeds uitgebreid beschreven in een eerdere blogpost. We hernemen het scenario waarbij een huisarts (client) vraagt aan de voorschriften backend (owner) om een elektronisch voorschrift te registreren.

Figuur 1 toont de basisflow; de dokter (client) vraagt aan de pseudonimiseringsdienst om een identifier om te zetten in een pseudoniem. De dokter stuurt vervolgens het pseudoniem, samen met de voorschriftendata naar de voorschriften backend, die de voorschriftendata onder dit pseudoniem bewaart.

Figuur 1. Basisflow voor het scenario waarbij een arts (client) vraagt aan de voorschriften backend (owner) om een elektronisch voorschrift te registreren.

Om een hoog niveau van veiligheid te bereiken, zijn de volgende veiligheidseigenschappen cruciaal:

1. De client is verziend; ze ziet enkel globale identifers (rijksregisternummers).
2. De owner is bijziend; het ziet enkel de lokale identifiers (pseudoniemen).
3. De pseudonimiseringsdienst is blind; het ziet noch identifiers, nog pseudoniemen.

Figuur 2 illustreert hoe dit gerealiseerd wordt door een aantal stappen aan de flow uit Figuur 1 toe te voegen.

1. De veiligheidseigenschap blinde pseudonimiseringsdienst (3) wordt gerealiseerd m.b.v. de blind en unblind-operaties (paars). Het rijksregisternummer van de patient wordt geblindeerd, wat een kortstondige encryptie is met een sleutel die slechts eenmaal gebruikt wordt. De pseudonimiseringsdienst zet het geblindeerde rijksregisternummer om in een geblindeerd pseudoniem en ziet daarbij noch het originele rijksregisternummer, noch het resulterende pseudoniem (vergeet even de blauwe en oranje operaties; die bespreken we dadelijk). Enkel de client kan de blindering ongedaan maken m.b.v. de unblind-operatie.
2. In de basisflow in Figuur 1 komt de owner geen rijksregisternummers te weten, waardoor de veiligheidseigenschap bijziende owner (2) sowieso reeds gerealiseerd is.
3. Dankzij de encrypt- end decrypt-operaties (oranje) wordt, ten slotte, de veiligheidseigenschap verziende client (1) gerealiseerd; de pseudonimiseringsdienst encrypteert het geblindeerde pseudoniem, zodat enkel de owner kan decrypteren.

Ten slotte wordt ongeoorloofd hergebruik van de geëncrypteerde pseudoniemen – die de client bekomt na de unblind-operatie – vermeden doordat de pseudonimiseringsdienst met de add context-operatie (blauw) context-informatie aan het vercijferde pseudoniem toevoegt, zoals het moment van creatie. De owner zal deze informatie controleren m.b.v. de verify context-operatie (blauw) en aanvaardt enkel binnenkomende vercijferde pseudoniemen die recent gecreëerd zijn.

Figuur 2. High-security flow voor het scenario waarbij een arts (client) vraagt aan de voorschriften backend (owner) om een elektronisch voorschrift te registreren.

De convert-operatie

In voorgaande sectie paste de pseudonimiseringsdienst specifiek de pseudonymise-operatie toe om rijksregisternummers om te zetten in pseudoniemen. In bepaalde scenario’s is ook de inverse operatie vereist, met name de identify-operatie, waarbij een pseudoniem gekend door de owner terug omgezet wordt in het oorspronkelijke rijksregisternummer aan de kant van een client.

Systemen (owners) communiceren ook onderling met elkaar. Een dienst op het eHealth platform zou bijvoorbeeld kunnen vragen aan de TherLink service of een patiënt een therapeutische relatie heeft met een bepaalde arts. Indien TherLink ook met pseudoniemen werkt, zal een pseudoniem van de ene dienst/owner omgezet moeten worden naar het pseudoniem van de andere dienst/owner. Dit gebeurt met behulp van de convert-operatie. Om het identificatierisico zo klein mogelijk te houden is het immers aangewezen om dezelfde pseudoniemen niet over meerdere diensten te hergebruiken.

De drie operaties die de pseudonimiseringsdienst moet ondersteunen zijn dus pseudonymise, identify en convert. We zullen zien dat zowel de pseudonymise– als de convert– operaties nuttig zijn bij het kruisen en pseudonimiseren van persoonsgegevens. De identify laat ons dan weer toe om gecontroleerd burgers te identificeren. Dit kan in bepaalde situaties wenselijk zijn, bijvoorbeeld wanneer onderzoekers merken dat bepaalde burgers een wel erg hoog risico lopen op bepaalde aandoeningen, of misschien onbewust reeds hebben.

Kruisen van persoonsgegevens – de huidige aanpak

Voor onderzoeksdoeleinden worden geregeld persoonsgegevens afkomstig van verschillende bronnen gekruist en gepseudonimiseerd. Dat laatste is een noodzakelijke maatregel die helpt te verhinderen dat de onderzoeker persoonsgegevens kan koppelen aan natuurlijke personen.

Als concreet voorbeeld nemen we beraadslaging 13/093 van 22 oktober 2013, dat Sciensano toegang geeft tot medische data afkomstig van verschillende ziekenhuizen, met als doel inzichten te verkrijgen in de epidemiologie van patiënten met diabetes. Sciensano komt daarbij geen rijksregisternummers te weten, maar enkel pseudoniemen.

Figuur 3 toont – enigszins geabstraheerd – hoe dit tot op vandaag verloopt m.b.v. eHealth Batch Codage, een pseudonimiseringsdienst die al wat langer bestaat dan onze blinde pseudonimiseringsdienst. data^A_id is de data m.b.t. de burger met rijksregisternummer id die aangeleverd wordt door ziekenhuis A.

De ziekenhuizen sturen voor elke betrokken burger de gevraagde data rechtstreeks naar Sciensano en het rijksregisternummer naar eHealth Batch Codage. Die laatste zet het rijksregisternummer om naar een projectspecifiek pseudoniem pseudonym^link_id en stuurt dit pseudoniem naar Sciensano. Sciensano ontvangt dus data afkomstig van een ziekenhuis via het ene kanaal en pseudoniemen afkomstig van de Batch Codage via een ander kanaal. Dankzij een tijdelijk transit-pseudoniem (vb. nym^A_id), dat verborgen blijft voor Batch Codage, is Sciensano in staat om de data aan de projectspecifieke pseudoniemen te koppelen. Via die projectspecifieke pseudoniemen, ten slotte, is Sciensano in staat om data over dezelfde burger maar afkomstig van verschillende bronnen aan elkaar te koppelen.

Figuur 3. Kruisen en pseudonimiseren van persoonsgegevens afkomstig van meerdere ziekenhuizen, bestemd voor Sciensano, zoals beschreven in beraadslaging 13/093.

Deze aanpak heeft een aantal minpunten:

• Batch Codage moet vertrouwd worden. Het is een Trusted Third Party (TTP); het ziet zowel de binnenkomende rijksregisternummers als de buitengaande pseudoniemen. Het weet aan welk kruisingsproject het meewerkt en kan dus in theorie profielen per burger aanleggen; bijvoorbeeld weet het na twee projecten welke burgers zowel betrokken waren in zowel het onderzoek rond diabetes als het onderzoek rond Multiple Sclerose. Dergelijke profielen kunnen op termijn vrij veel gevoelige informatie bevatten.
• Twee communicatiekanalen. Sciensano moet in staat zijn om de data die het rechtstreeks ontvangt van de ziekehuizen te koppelen aan de pseudoniemen die het ontvangt van Batch Codage. Er is weliswaar een oplossing, maar het zou eleganter zijn indien alle informatie rechtstreeks van het ziekenhuis naar Sciensano gestuurd werd via één enkel kanaal.
• Slechte integratie bij gepseudonimiseerde input. Dit systeem kan niet op een elegante manier overweg met situaties waarbij één of meerdere databronnen reeds gebruik maken van de eerder beschreven blinde pseudonimiseringsdienst en dus zelf geen rijksregisternummers kennen.

Kruisen van persoonsgegevens met de blinde pseudonimiseringsdienst

De drie nadelen beschreven in de vorige sectie zouden verholpen kunnen worden door voortaan beroep te doen op de blinde pseudonimiseringsdienst.

Het scenario waarbij alle databronnen de persoonsgegevens bewaren onder het rijksregisternummer wordt geïllustreerd in Figuur 4. De flow van een ziekenhuis (databron) naar Sciensano (collector) is exact dezelfde flow als die in Figuur 1, waarbij de drie eerder geformuleerde veiligheidseigenschappen uiteraard behouden blijven:

• De databronnen (vb. ziekenhuizen) zijn verziend en zien dus enkel rijksregisternummers
• De collector (vb. Sciensano) is bijziend en ziet dus enkel project-specifieke pseudoniemen
• De peudonimiseringsdienst is blind en ziet dus geen van beiden.

Indien meerdere databronnen data aanleveren over eenzelfde burger, geven ze hetzelfde rijksregisternummer als input aan de pseudonimisatieflow (volle lijn), wat resulteert in eenzelfde projectspecifieke pseudoniem aan de kant van de collector. Dat laat de collector dan weer toe om data over eenzelfde burger, afkomstig van verschillende databronnen, aan elkaar te koppelen.

Figuur 4. Kruisen en pseudonimiseren van data afkomstig van verschillende databronnen, die allen persoonsgegevens bewaren onder rijksregisternummers

Figuur 5, ten slotte, illustreert een gemengd scenario, waarbij minstens één databron persoonsgegevens onder rijksregisternummers bewaart en minstens één databron persoonsgegevens bewaart onder pseudoniemen die m.b.v. de blinde pseudonimiseringsdienst bekomen werden. Die laatste databron zou bijvoorbeeld de prescription backend uit Figuur 1 kunnen zijn.

We krijgen dus twee varianten op de pseudonimiseringsflow (volle lijn):

• De pseudonimiseringsdienst ontvangt een geblindeerd pseudoniem van databron A en voert er een convert-operatie op uit (zie sectie “De convert-operatie“) wat resulteert in een geblindeerd projectspecifiek pseudoniem.
• De pseudonimiseringsdienst ontvang een geblindeerd rijksregisternummer van databron B en voert er een pseudonymise-operatie op uit wat eveneens resulteert in een geblindeerd projectspecifiek pseudoniem.

Indien het pseudoniem dat databron A als input gaf overeenkomt met het rijksregisternummer dat databron B als input gaf, zal dat resulteren in eenzelfde projectspecifiek pseudoniem bij Sciensano.

Voor de rest zijn beide flows identiek. Noch voor de databronnen (vb. publieke instellingen) noch voor de collector (vb. Sciensano) verandert er iets. De collector hoeft niet eens op de hoogte te zijn of een databron al dan niet met pseudoniemen werkt.

Figuur 5. Kruisen en pseudonimiseren van data afkomstig van twee databronnen, waarbij de ene databron persoonsgegevens bewaart onder rijksregisternummers en de andere onder pseudoniemen.

De eerder geformuleerde minpunten bij de huidige aanpak zijn bij deze van de baan:

• De pseudonimiseringsdienst ziet identifiers noch pseudoniemen en kan dus geen profielen meer aanleggen. Meerdere malen een blind-operatie uitvoeren op eenzelfde rijksregisternummer (of pseudoniem) resulteert bovendien telkens in een andere blindering. De pseudonimiseringsdienst kan dus evenmin geblindeerde identifiers of pseudoniemen gebruiken om profielinformatie aan te koppelen.
• De collector (vb. Sciensano) ontvangt alle informatie afkomstig van eenzelfde databron (vb. ziekenhuis) via één rechtstreeks kanaal.
• We kunnen op een bijzonder elegante manier overweg met situaties waarbij een of meerdere databronnen reeds gebruik maken van de blinde pseudonimiseringsdienst.

Conclusie

Dankzij de blinde pseudonimiseringsdienst van eHealth, kunnen we op een elegante en erg veilige wijze data afkomstig van verschillende databronnen kruisen en pseudonimiseren voor onderzoeksdoeleinden.

Een bijkomend voordeel is bovendien dat er geen bijkomende infrastructuur vereist is; overdag worden veel meer voorschriften uitgegeven en verwerkt dan ’s nachts. ’s Nachts is er bijgevolg heel wat pseudonimisatiecapaciteit op overschot. Dat is dan ook het ideale moment om dergelijke kruisingsprojecten, die niet tijdskritisch zijn, uit te voeren. Uiteraard krijgen tijdskritische opdrachten steeds voorrang.

Voor elk kruisingsproject zou de pseudonimiseringsdienst een andere sleutel gebruiken, wat resulteert in pseudoniem-onlinkbaarheid bij de collector; deze is dan niet in staat om gegevens over eenzelfde burger, maar uit verschillende projecten, aan elkaar te linken op basis van pseudoniemen. 

Mocht dit nodig zijn is met de identify-operatie heridentificatie mogelijk, maar enkel mits autorisatie en medewerking van de pseudonimiseringsdienst, wat willekeur en misbruik tegengaat. Dergelijke aanvragen dienen bovendien gelogd te worden. De pseudonimiseringsdienst kan ook – mocht dit vereist zijn – de pseudonimiseringssleutel op een afgesproken moment verwijderen, waardoor heridentificatie langs deze weg onmogelijk wordt.

Uiteraard moet de blind– en unblind-operatie voorzien worden in de software die de databronnen gebruiken, terwijl aan de kant van de collector de decrypt– en verify context-operaties voorzien moeten worden. De ervaring leert ons dat deze integratie vrij vlot verloopt.

Bemerk wel dat deze aanpak enkel nuttig is indien alle databronnen autonoom kunnen bepalen welke records relevant zijn en welke niet. Dit is niet steeds het geval, zoals bijvoorbeeld in het datakruisingsproject dat goedgekeurd werd met beraadslaging 20/002 van 14 januari 2020, waarbij het Belgisch Kankerregister enkel data mag aanleveren over burgers met Multiple Sclerose (MS), maar zelf niet te weten mag komen wie MS heeft. Ook daarvoor heeft Smals Research een efficiënte en flexibele oplossing bedacht. Die oplossing is bovendien gedistribueerd, waardoor niet langer een pseudonimiseringsdienst nodig is om veilig te pseudonimiseren. Dit valt echter buiten de scope van dit artikel.

Aarzel niet ons te contacteren bij interesse in onze oplossingen voor het pseudonimiseren en kruisen van persoonsgegevens.

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.

Image source: Pixabay

Lors du webinaire, Kristof Verslype présente trois systèmes de pseudonymisation des numéros de registre national qu’il a lui-même conçus sur base des besoins concrets des secteurs de la sécurité sociale et des soins de santé:

– le service de pseudonymisation aveugle d’eHealth pour protéger les données médicales personnelles en production ; – la pseudonymisation préservant la structure pour protéger les données à caractère personnel dans les environnements de non-production existants ; – “Oblivious Join” pour le croisement distribué et la pseudonymisation des données fournies par différentes instances à des fins de recherche.

Articles de blog pertinents – Introduction au nouveau service de pseudonymisation eHealth – Protection des données par la pseudonymisation préservant la structure des numéros de registre national

In dit webinar presenteert Kristof Verslype drie systemen voor pseudonimisering van rijksregisternummers die hij zelf geconcipieerd heeft op basis van concrete behoeften binnen de sociale zekerheid en de gezondheidssector:

– De blinde eHealth pseudonimiseringsdienst voor het beschermen van medische persoonsgegevens in productie; – Structuurbehoudende pseudonimisering voor de bescherming van persoonsgegevens in bestaande non-productieomgevingen; – “Oblivious Join” voor het gedistribueerd kruisen en pseudonimiseren van gegevens aangeleverd door verschillende instanties voor onderzoeksdoeleinden.

Relevante blogposts – Introductie tot de nieuwe eHealth pseudonimiseringsdienst – Gegevensbescherming m.b.v. structuurbehoudende pseudonimisatie van rijksregisternummers

Recording

Presentation

Bon nombre de systèmes dans le secteur public stockent des données personnelles, parfois très sensibles. Il s’agit entre autres de données sociales, fiscales et médicales. Il faut éviter que quiconque – de l’extérieur ou de l’intérieur – accédant illégalement à ces systèmes puisse établir un lien entre ces données et des personnes physiques. Une mesure précieuse à cet égard consiste à ne plus stocker les données sous des numéros de registre national, mais sous des pseudonymes. Ces pseudonymes sont des codes uniques qui ne peuvent être reconvertis en numéro de registre national qu’à l’aide d’une clé.

Afin de maximiser la sécurité et la confiance, cette clé ne doit être connue que par une partie indépendante du système stockant les données personnelles pseudonymisées. Nous appelons cette partie le service de pseudonymisation. Une telle approche permet également à un grand nombre de systèmes d’utiliser ce service. Nous obtenons ainsi un service de pseudonymisation générique.

Cet article est une introduction à un tel service de pseudonymisation conçu par Smals Research, qui offre un niveau de sécurité particulièrement élevé. Le service est opérationnel depuis décembre 2023 en tant que nouveau service de eHealth. 

Disclaimer: Les numéros de registre national étant mieux connus que la catégorie plus large des numéros NISS, nous nous référons uniquement aux numéros de registre national dans cet article, bien que le type d’identifiant considéré ne constitue pas une limitation pour le service de pseudonymisation.

Rôles et opérations

Sans service de pseudonymisation, il y a deux rôles : le propriétaire qui stocke les données à caractère personnel et les clients qui envoient des demandes au propriétaire. Nous présentons trois scénarios à titre illustratif :

• Scénario 1 : Un médecin (client) demande au service de prescription (propriétaire) d’enregistrer une prescription électronique.
• Scénario 2 : Un pharmacien (client) demande une ordonnance au service de prescription (propriétaire) pour un citoyen en particulier.
• Scénario 3 : Une médecin (client) demande au service de prescription (propriétaire) de consulter les ordonnances électroniques qu’il a émises la veille.

Le troisième rôle est celui du service de pseudonymisation, qui est chargé de convertir le numéro de registre national du patient en pseudonyme correspondant (opération pseudonymize) ou, inversement, le pseudonyme en numéro de registre national (opération identify). Le numéro de registre national du médecin ou son numéro INAMI peuvent également être pseudonymisés de la même manière.

Les systèmes (propriétaires) communiquent également entre eux. Un service sur la plateforme eHealth pourrait demander au service TherLink si un patient a une relation thérapeutique avec un médecin en particulier. Si TherLink utilise également des pseudonymes, le pseudonyme d’un service/propriétaire devra être converti en pseudonyme de l’autre service/propriétaire (opération convert). En effet, afin de minimiser le risque d’identification, il convient de ne pas réutiliser les pseudonymes dans plusieurs services.

Ainsi, les trois opérations que le service de pseudonymisation doit prendre en charge sont pseudonymize, identify et convert. Le présent article se concentre sur l’opération pseudonymize.

Interactions

En cas d’utilisation d’un service de pseudonymisation, il convient de déterminer comment il sera possible de communiquer avec lui. À un niveau élevé, on a le choix entre le mode relay (relais) et le mode reply (réponse), illustré dans la figure ci-dessous.

• Le mode relay est le plus courant. Dans ce mode, le service de pseudonymisation agit comme un relais entre le client et le propriétaire : il reçoit du client les numéros de registre national, ainsi que d’autres données, effectue des opérations sur ces numéros (par exemple, la pseudonymisation) et transmet le résultat au propriétaire. Le service TTP eHealth est un service de pseudonymisation dans ce mode. Healthdata.be – partie de Sciensano – utilise ce service. Le système de pseudonymisation avancé conçu par le professeur néerlandais Verheul utilise également ce mode.
• En mode reply, le service de pseudonymisation reçoit une demande du client et renvoie la réponse au même client. Ce client peut, par exemple, demander qu’un pseudonyme soit converti en un numéro de registre national (identify). Entre autres, le service eHealth WS SEALS utilise ce mode

Mode reply et mode relay

Les deux approches ont leurs avantages et inconvénients. Le mode reply répond mieux aux besoins des client de Smals dans le cadre de la protection des données médicales à caractère personnel. Après tout, le mode reply a un impact moins intrusif sur des interactions existantes ; le client et le propriétaire (ou propriétaire et propriétaire en cas d’une opération convert) communiquent encore en direct et ne doivent pas se reposer sur un tiers intermédiaire afin d’envoyer les bonnes données à la bonne partie par le biais d’un canal de communication sécurisé. Les interactions de bas niveau se trouvent ainsi plus proches des interactions fonctionnelles.

Le flux de base pour le scénario 1 est représenté dans la figure ci-dessous. Les flux de base pour les deux autres scénarios sont analogues. Contrairement à la flèche épaisse, la flèche fine ne contient pas de numéro de registre national ou de pseudonyme.

Flux de base pour le scénario 1 : Un médecin (client) demande au service de prescription (propriétaire) d’enregistrer une prescription électronique.

Garanties de sécurité élevées

Le risque pour la vie privée est que l’une des parties concernées, ou un hacker, puisse d’une manière ou d’une autre extraire des données personnelles et les relier à une personne identifiée. Ce risque se trouve considérablement réduit si chaque partie est informée uniquement de ce qui est strictement nécessaire. Concrètement, il faudrait satisfaire exigences suivantes :

• Le propriétaire ne connaît que les pseudonymes.
• Le client ne connaît que les numéros de registre national.
• Le service de pseudonymisation ne connaît ni l’un ni l’autre.

En appliquant uniquement le flux de base illustré dans la figure précédente, seul le premier point est satisfait. Dans ce qui suit, nous examinons un certain nombre de mesures visant à renforcer la sécurité. Si ces mesures sont appliquées au flux de base du scénario 1, nous obtenons la figure ci-dessous. Une clé à côté d’une opération signifie qu’une clé secrète ou privée est nécessaire, un dé que l’opération est probabiliste, c-à-d que le résultat est différent à chaque fois, même avec la même entrée.

Flux de haute sécurité pour le scénario 1 : Un médecin (client) demande au service de prescription (propriétaire) d’enregistrer une prescription électronique.

Service de pseudonymisation à l’aveugle

Une première mesure est le service de pseudonymisation aveugle, qui est réalisé par les deux opérations violettes (blind et unblind). Il garantit que le service de pseudonymisation ne peut plus voir les pseudonymes et identifiants entrants et sortants, ce qui permet à un service de pseudonymisation curieux de collecter beaucoup moins d’informations et donc d’avoir moins besoin qu’on lui fasse confiance.

Pseudonymes confidentiels

Dans un flux comportant uniquement des opérations blind et unblind, le médecin (client) peut voir le pseudonyme après l’opération unblind. Ainsi, le médecin – ou un hacker – peut le lier à un numéro de registre national. Ce risque de sécurité est mitigé dans le flux de haute sécurité grâce aux pseudonymes confidentiels (orange), où une couche de chiffrement supplémentaire garantit que le client ne découvre jamais le pseudonyme, étant donné qu’il ne connaît pas la clé de déchiffrement.

En appliquant les pseudonymes aveugles aux pseudonymes confidentiels sur notre flux initial, nous réalisons les propriétés suivantes :

• Le client est hypermétrope ; il ne voit que les identifiants globaux (numéros de registre national).
• Le propriétaire est myope ; il ne voit que les identifiants locaux (pseudonymes).
• Le service de pseudonymisation est aveugle ; il ne voit ni les identifiants ni les pseudonymes.

Nous introduisons deux mesures supplémentaires pour renforcer la sécurité : l’autorisation explicite et la double pseudonymisation facultative.

Autorisation explicite

Bien entendu, tout le monde ne doit pas pouvoir utiliser le service de pseudonymisation. Le droit d’envoyer telle ou telle demande au service et à telle ou telle fin est donc strictement réglementé. En outre, ces règles changent constamment : de nouveaux prestataires de soins de santé (clients) et de nouveaux services (propriétaires) sont ajoutés, et d’anciens disparaissent. Par ailleurs, les clients des dizaines de milliers de prestataires de soins de santé de ce pays n’ont pas toujours le même niveau de sécurité ; l’utilisation du service de pseudonymisation par des clients compromis devrait donc être refusée dans certaines circonstances.

Dans cette optique, il est logique de limiter la durée de validité des codes de pseudonymisation (obtenus par le client dans la figure précédente après l’opération unblind). Plus généralement, le contexte dans lequel un pseudonyme chiffré peut être utilisé peut ainsi être limité. Cela permet d’éviter la réutilisation non autorisée des algorithmes de chiffrement des pseudonymes.  

C’est exactement ce que l’autorisation explicite empêche. La figure ci-dessus illustre cela à l’aide des opérations en bleu ; le service de pseudonymisation attache des règles d’autorisation (par exemple expiration time) au pseudonyme avant qu’il soit chiffré. Dès réception, le propriétaire vérifie à l’aide d’informations contextuelles (par exemple current time) si ces règles sont respectées. La capacité d’utilisation d’un chiffrement de pseudonyme peut par exemple être limitée à 5 minutes. Des règles plus avancées sont, bien évidemment, toujours possibles.

Double pseudonymisation

Malgré les règles de sécurité évoquées précédemment, il est toujours possible pour le service de pseudonymisation d’effectuer lui-même les attaques suivantes :

1. Il dresse une liste de toutes les séquences de caractères possibles qui ont la structure d’un numéro de registre national. Il y en a quelques dizaines de millions, ce qui permet une réalisation rapide.
2. Pour chacune de ces séquences, il effectue une opération pseudonymize.

Le service de pseudonymisation dispose maintenant d’un tableau composé de quelques dizaines de millions de paires. Environ 12 millions de ces paires contiennent un numéro de registre national effectivement attribué à un citoyen vivant.

Le fait que ce service connaisse le lien entre le numéro de registre national et le pseudonyme constitue un risque ; si un hacker peut établir un lien avec des données pseudonymisées ayant fait l’objet d’une fuite de la part du propriétaire, il peut facilement procéder à une réidentification

Ce risque peut être atténué par la double pseudonymisation (rouge). Afin de convertir un numéro de registre national en pseudonyme final ou, inversement, de reconvertir un pseudonyme en numéro de registre national, deux clés sont alors nécessaires : l’une n’est connue que du service de pseudonymisation, l’autre que du propriétaire. L’inconvénient est que le propriétaire doit maintenant sécuriser une clé et effectuer davantage d’opérations cryptographiques. Étant donné que cela n’est pas toujours évident et que le risque est limité, cette étape est facultative.

Conclusions

Le service de pseudonymisation décrit dans cet article offre des garanties de sécurité extrêmement élevées, tout en restant d’une complexité gérable. En particulier du côté du client (par exemple le médecin), elle reste très limitée, ce qui facilite l’intégration de la solution dans le logiciel client existant utilisé par plusieurs dizaines de milliers de prestataires de soins de santé dans notre pays.

En effet, le client n’a pas besoin de gérer de clé à long terme et effectue les mêmes opérations à chaque fois : un blind et un unblind avec un appel au service de pseudonymisation entre les deux. La complexité pour les prestataires de soins de santé est donc très limitée.

En outre, les interactions existantes sont respectées, ce qui limite les coûts de réorganisation des processus existants.

La solution évite la réidentification des données à caractère personnel sur la base des numéros de registre national. Il convient de noter que la réidentification peut également être possible dans certains cas sur la base des données elles-mêmes, même si elles ne sont connues que sous un pseudonyme. Dans ce cas, des mesures de sécurité supplémentaires, telles que le chiffrement, peuvent s’imposer.

Une proposition initiale de Smals Research pour un service de pseudonymisation générique a été affinée et étendue en étroite collaboration avec d’autres services de Smals, afin de l’adapter aux besoins de l’entreprise. Smals Research a développé à la fois le concept théorique et le PoC (Proof of Concept) en Java ; ce dernier a été utilisé par eHealth comme source d’inspiration pour la construction d’un service de santé en ligne mis en service en décembre 2023.

Enfin, nous mentionnons que Smals Research travaille également sur un autre type de pseudonymisation, visant un ensemble de use cases ; (la pseudonymisation préservant la structure présente l’avantage que les pseudonymes ont la même structure que les identifiants, mais ne peut malheureusement pas offrir les mêmes propriétés de haute sécurité).

Si cette solution ou d’autres solutions de pseudonymisation (et de référencement croisé) des données à caractère personnel vous intéressent, n’hésitez pas à nous contacter.

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 image présentée: Youngsang Hwang

Heel wat systemen in de publieke sector bewaren – soms erg gevoelige – persoonsgegevens. Het betreft onder meer sociale, fiscale en medische gegevens. We dienen te vermijden dat iemand – van buitenuit of binnenaf – die zich onrechtmatig toegang tot die systemen verschaft die gegevens kan koppelen aan natuurlijke personen. Een waardevolle maatregel daarbij is om de gegevens niet langer onder rijksregisternummers maar onder pseudoniemen te bewaren. Die pseudoniemen zijn unieke codes die enkel met een sleutel terug om te zetten zijn naar het oorspronkelijke rijksregisternummer. 

Om de veiligheid en het vertrouwen te maximaliseren is deze sleutel best enkel gekend door een partij die onafhankelijk is van het systeem dat de gepseudonimiseerde persoonsgegevens bewaart. Die partij noemen we de pseudonimiseringsdienst. Een dergelijke aanpak laat meteen ook toe dat heel wat systemen van deze dienst gebruik kunnen maken. We krijgen dus een generieke pseudonimiseringsdienst. 

Dit artikel is een introductie tot een dergelijke pseudonimiseringsdienst die uitgedacht werd door Smals Research en een bijzonder hoog niveau van veiligheid verschaft. De dienst gaat in december 2023 live als nieuwe eHealth dienst. 

Disclaimer: Omdat rijksregisternummers als term beter gekend zijn dan de ruimere categorie van INSZ-nummers, spreken we in dit artikel uitsluitend over rijksregisternummers, al vormt het type identifier geen enkele beperking.

Rollen en operaties

Zonder pseudonimiseringsdienst zijn er twee rollen: de owner die persoonsgegevens bewaart en de clients die requests naar de owner sturen. We geven drie scenario’s ter illustratie:

• Scenario 1: Een huisarts (client) vraagt aan de voorschriften service (owner) om een elektronisch voorschrift te registreren.
• Scenario 2: Een apotheker (client) vraagt voor een specifieke burger een voorschrift op aan de voorschriften service (owner).
• Scenario 3: Een arts (client) vraagt aan de voorschriften service (owner) om de elektronische voorschriften te bekijken die ze de dag ervoor uitgegeven heeft.

De derde rol is de pseudonimiseringsdienst die instaat voor de vertaling van het rijksregisternummer van de patiënt naar het overeenkomstige pseudoniem (pseudonymize operatie), of omgekeerd, van het pseudoniem naar het rijksregisternummer (identify operatie). Ook het rijksregisternummer of RIZIV-nummer van de arts kan op een gelijkaardige manier gepseudonimiseerd worden.

Systemen (owners) communiceren ook onderling met elkaar. Een dienst op het eHealth platform zou bijvoorbeeld kunnen vragen aan de TherLink service of een patient een therapeutische relatie heeft met een bepaalde arts. Indien TherLink ook met pseudoniemen werkt, zal een pseudoniem van de ene dienst/owner omgezet moeten worden naar het pseudoniem van de andere dienst/owner (convert operatie). Om het identificatierisico zo klein mogelijk te houden is het immers aangewezen om pseudoniemen niet over meerdere diensten te hergebruiken.

De drie operaties die de pseudonimiseringsdienst moet ondersteunen zijn dus pseudonymize, identify en convert. Dit artikel focust op de pseudonymize operatie.

Interacties

Indien gebruik gemaakt wordt van een pseudonimiseringsdienst moet bepaald worden op welke wijze ermee gecommuniceerd wordt. Op hoog niveau is er de keuze tussen de relay modus en de reply modus, die geïllustreerd worden in onderstaande figuur.

• De relay modus is de meest courante. In deze modus fungeert de pseudonimiseringsdienst als doorgeefluik: het ontvangt rijksregisternummers, samen met andere gegevens, van de ene partij, doet er operaties op (bijvoorbeeld pseudonymize) en geeft het resultaat door aan de ontvangende partij. De dienst TTP eHealth is een pseudonimiseringsdienst in deze modus. Healthdata.be – onderdeel van Sciensano – maakt gebruik van deze dienst. Ook het geavanceerde pseudonimiseringssysteem bedacht door de Nederlande professor Verheul hanteert deze modus.
• In de reply modus ontvangt de pseudonimiseringsdienst een request en stuurt het antwoord naar dezelfde partij terug. Deze partij kan bijvoorbeeld vragen om een pseudoniem om te zetten naar een rijksregisternummer (identify). Onder meer de eHealth dienst WS SEALS hanteert deze modus.

Reply modus en relay modus

Beide aanpakken hebben hun eigen voor- en nadelen. Niettemin komt de reply modus beter tegemoet aan de noden van onze klanten bij de bescherming van operationele medische persoonsgegevens. De reply modus heeft immers een minder intrusieve impact op bestaande interacties; client en owner (of owner en owner bij een convert operatie) communiceren nog steeds rechtstreeks met elkaar en hoeven niet te vertrouwen op een intermediaire partij om de juiste data door te sturen naar de juiste partij over een veilig communicatiekanaal. De low-level interacties liggen dus dichter bij de business interacties.

De basisflow voor scenario 1 van daarnet wordt in de figuur hieronder weergegeven. De basisflows voor de andere twee scenario’s zijn analoog. In tegenstelling tot de dikke pijl bevat de dunne pijl geen rijksregisternummers of pseudoniemen.

Basisflow voor scenario 1: Een arts (client) vraagt aan de voorschriften-backend (owner) om een elektronisch voorschrift te registreren.

Hoge veiligheidsgaranties

Een privacy risico is dat één van de betrokken partijen, of een hacker, op de één of andere manier ongewenst persoonsgegevens kunnen afleiden en kunnen koppelen aan een geïdentificeerde persoon. Dit risico vermindert aanzienlijk indien elke partij slechts het strikt noodzakelijke te weten komt. In concreto:

• De owner komt enkel de pseudoniemen te weten.
• De client komt enkel de rijksregisternummers te weten.
• De pseudonimiseringsdient komt geen van beiden te weten.

Door het toepassen van enkel de basisflow, die geïllustreerd werd in de vorige figuur, is enkel aan het eerste puntje voldaan. In wat volgt bespreken we een aantal veiligheidsverhogende maatregelen. Indien deze toegepast worden op de basisflow van scenario 1, krijgen we onderstaande figuur. Een sleutel naast een operatie betekent dat een geheime of private sleutel vereist is, een dobbelsteen dat de operatie probabilistisch is; het resultaat is telkens anders, ook bij dezelfde input.

High-security flow voor scenario 1: Een arts (client) vraagt aan de voorschriften-backend (owner) om een elektronisch voorschrift te registreren.

Blinde pseudonimiseringsdienst

Een eerste maatregel is de blinde pseudonimiseringsdienst, die gerealiseerd wordt door de twee paarse operaties (blind en unblind). Het zorgt ervoor dat de pseudonimiseringsdienst niet langer de binnenkomende en uitgaande pseudoniemen en identifiers kan zien, waardoor een nieuwsgierige pseudonimiseringsdienst veel minder informatie kan verzamelen en dus minder vertrouwd hoeft te worden.

Confidentiële pseudoniemen

In een flow met enkel blind en unblind krijgt de arts (client) na de unblind operatie het pseudoniem zelf te zien. De arts – of een hacker – kan dit dus koppelen aan een rijksregisternummer. Dit veiligheidsrisico wordt in de high-security flow gemitigeerd dankzij confidentiële pseudoniemen (oranje), waarbij een extra encryptielaag garandeert dat de client nooit het pseudoniem te weten komt, gezien het de decryptiesleutel niet kent.

Door het toepassen van blinde pseudoniemen en confidentiële pseudoniemen op onze initiële flow realiseren we de volgende eigenschappen:

• De client is verziend; ze ziet enkel globale identifers (rijksregisternummers).
• De owner is bijziend; het ziet enkel de lokale identifiers (pseudoniemen).
• De pseudonimiseringsdienst is blind; het ziet noch identifiers, nog pseudoniemen.

We voeren nog twee extra maatregelen in om de veiligheid verder te verhogen: expliciete authorizatie en de optionele dubbele pseudonimisatie.

Expliciete autorizatie

Uiteraard mag niet iedereen zomaar gebruik kunnen maken van de pseudonimiseringsdienst. Wie welke requests met welk doel naar die dienst mag sturen is dan ook strikt geregeld. Bovendien veranderen die regels constant; er komen nieuwe zorgverstrekkers (clients) en diensten (owners) bij, en oude verdwijnen. Bovendien zijn de clients van de vele tienduizenden zorgverstrekkers in dit land niet steeds even goed beveiligd; gebruik van de pseudonimiseringsdienst door gecompromitteerde clients moet dan ook onder bepaalde omstandigheden ontzegd kunnen worden.

In die optiek is het zinvol om de geldigheidsduur van pseudoniemvercijferingen  (die de client in de vorige figuur verkrijgt na de unblind operatie) te beperken. Meer algemeen kan de context waarin een pseudoniemvercijfering gebruikt mag worden beperkt worden. Op die manier wordt onrechtmatig hergebruik van pseudoniemvercijferingen vermeden.  

Dit is exact wat expliciete autorizatie verhindert. In bovenstaande figuur wordt dit gerealiseerd met behulp van de blauwe operaties; de pseudonimiseringsdienst hecht autorizatieregels (vb. expiration time) aan het pseudoniem voor het vercijferd wordt. Bij ontvangst verifieert de owner a.d.h.v. contextinformatie (vb. current time) of aan deze regels voldaan is. De bruikbaarheid van een pseudoniemvercijfering kan bijvoorbeeld beperkt worden tot 5 minuten. Geavanceerdere regels zijn uiteraard steeds mogelijk.

Dubbele pseudonimisatie

Ondanks de eerder besproken veiligheidsmaatregelen is het nog steeds mogelijk dat de pseudonimiseringsdienst op zijn eentje de volgende aanval uitvoert:

1. Het maakt een lijst van alle strings (opeenvolging van karakters) die de structuur van een rijksregisternummer hebben. Dat zijn er een paar tiental miljoen en kan dus snel gerealizeerd worden.
2. Voor elk van die strings doet het een pseudonymize operatie

De pseudonimiseringsdienst heeft nu een tabel bestaande uit een paar tiental miljoen koppels. Ongeveer 12 miljoen van die koppels bevatten een rijksregisternummer dat effectief toegekend is aan een in leven zijnde burger.

Dat die dienst de koppeling kent tussen rijksregisternummer en pseudoniem is een risico; indien een hacker dit kan koppelen aan gepseudonimiseerde gegevens die lekten uit de owner, kan hij eenvoudig reïdentificeren.

Dit risico kan gemitigeerd worden met behulp van dubbele pseudonimisatie (rood). Om een rijksregisternummer om te zetten naar het finale pseudoniem, of, omgekeerd, om een pseudoniem terug om te zetten naar een rijksregisternummer, zijn dan twee sleutels vereist: De ene is enkel gekend door de pseudonimiseringsdienst, de andere enkel door de owner. De keerzijde is dat de owner nu een sleutel moet beveiligen en meer cryptografische operaties moet uitvoeren. Gezien dit niet steeds evident is en gezien het beperkte risico, is deze stap optioneel.

Conclusies

De voorgestelde pseudonimiseringsdienst biedt extreem hoge veiligheidsgaranties, terwijl de complexiteit ervan beheersbaar blijft. In het bijzonder aan de kant van de clients (vb. arts) blijft die zeer beperkt, wat een integratie van de oplossing in de bestaande client software, die door vele tienduizenden zorgverstrekkers in ons land gebruikt wordt, vergemakkelijkt.

De client hoeft inderdaad geen long-term keys te beheren en voert telkens dezelfde operaties uit: een blind en unblind met tussenin een call naar de pseudonimiseringsdienst. De complexiteit aan de kant van de zorgverstrekkers blijft dus beperkt.

Bovendien worden bestaande interacties gerespecteerd, waardoor de re-engineering kost bij bestaande processen beperkt blijft.

De oplossing vermijdt heridentificatie van persoonsgegevens op basis van rijksregisternummers. Bemerk dat heridentificatie ook mogelijk kan zijn op basis van de data zelf, ook al zijn die enkel gekend onder een pseudoniem. In dat geval kunnen bijkomende veiligheidsmaatregelen, zoals encryptie, zich opdringen.

Een initieel voorstel door Smals Research tot generieke pseudonimiseringsdienst werd in nauwe samenwerking met andere diensten binnen Smals verder verfijnd en uitgebreid en is daarmee afgestemd op de business noden. Smals Research ontwikkelde zowel het theoretische concept als de Proof of Concept (PoC) in Java; die laatste werd door eHealth gebruikt als inspiratie voor het bouwen van een eHealth service die in de in december 2023 live gaat.

Ten slotte geven we mee dat Smals Research ook werkt aan een ander type pseudonimisatie, gericht op een andere set van use cases; structuurbehoudende pseudonimisatie heeft het voordeel dat pseudoniemen dezelfde structuur hebben als de identifiers, maar kan helaas niet dezelfde hoge security eigenschappen bieden.

Aarzel niet ons te contacteren bij interesse in deze of één van onze andere oplossingen voor het pseudonimiseren (en kruisen) van van persoonsgegevens.

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: Youngsang Hwang

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

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

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.