Les données personnelles numériques constituent une source d’informations qui favorise l’innovation, le bien-être et la formulation de politiques. Ces données personnelles se trouvent dispersées dans de nombreuses organisations : l’une détient des données sur le cancer, une autre sur la consommation de médicaments et une autre encore sur les revenus. Dans la pratique, les données personnelles provenant de différentes organisations sont régulièrement regroupées afin de répondre à des questions spécifiques posées par des chercheurs et des décideurs politiques.

Les processus actuels garantissent que le respect de la vie privée dans ce contexte. Il s’agit malheureusement trop souvent d’une opération complexe, coûteuse et chronophage. En collaboration avec des universités de renommée internationale, Smals Research a donc travaillé à l’élaboration d’un prototype visant à simplifier considérablement ces processus à l’aide d’une cryptographie avancée.

Problématique basée sur un cas concret

Nous sommes partis d’une question de recherche concrète :

Les patients atteints de SEP (sclérose en plaques) sous traitement à base de molécules de tériflunomide ou d’alemtuzumab courent-ils un risque accru de cancer par rapport aux patients atteints de SEP traités avec d’autres médicaments ?

Pour répondre à cette question, simple en soi, il est nécessaire de croiser les données médicales relatives aux patients atteints de SEP provenant de deux organisations, à savoir le Registre belge du cancer (BCR) et l’Agence InterMutualiste (AIM).

Les deux organisations gèrent les données sous des pseudonymes distincts pour plus de confidentialité ; des codes uniques remplacent les numéros de registre national.

• Le BCR gère les données relatives au cancer concernant les personnes qui ont reçu un diagnostic de cancer. Le BCR ne sait pas quels enregistrements concernent des patients atteints de SEP.
• L’AIM dispose de données relatives aux médicaments prescrits et peut sélectionner les enregistrements des patients atteints de SEP.

Les chercheurs doivent avoir accès, dans un environnement sécurisé (SPE = Secure Processing Environment), aux données provenant du BCR et de l’AIM concernant tous les patients atteints de SEP. Les données relatives à un même patient mais issues de sources différentes doivent pouvoir être reliées entre elles sur la base d’un pseudonyme unique utilisé uniquement dans le cadre de cette question de recherche spécifique. Ceci est représenté dans l’illustration 1.

La question centrale est la suivante :

Comment le BCR peut-il fournir uniquement des enregistrements sur les patients atteints de SEP à l’environnement sécurisé sans savoir qui est atteint de SEP ou quels enregistrements qu’il gère concernent des patients atteints de SEP ?

Dans une approche classique, soit le BCR enverra trop d’informations à l’environnement sécurisé – notamment des données sur chaque patient atteint d’un cancer –, soit des informations seront divulguées au BCR – qui découvrira alors quels enregistrements concernent des patients atteints de SEP. Une dernière possibilité consiste à faire appel à une entité centrale de confiance qui, certes, aura connaissance des données à caractère personnel, mais à qui l’on peut faire confiance pour ne pas en faire un usage illicite.

Aucune de ces approches n’est idéale. Aujourd’hui, tant au niveau national qu’international, on fait appel à des intermédiaires centraux fortement réglementés ou on opte pour des solutions sur mesure coûteuses et lentes, dans lesquelles un nouveau flux est défini, validé et mis en œuvre pour chaque question de recherche afin de protéger au maximum la vie privée.

De plus, le chercheur a généralement besoin d’accéder aux données brutes, ce qui rend les solutions basées sur le secure multi-party computation inadaptées. 

Notre proposition de solution

Partons d’un scénario fictif dans lequel nous travaillons avec un intermédiaire de confiance et où, pour simplifier, l’AIM et le BCR ne gèrent pas les données à caractère personnel sous des pseudonymes, mais sous des numéros de registre national. L’AIM et le BCR envoient tous deux toutes les données potentiellement pertinentes à l’intermédiaire de confiance.

Le BCR envoie à l’intermédiaire les données identifiées relatives au cancer de tous les citoyens qui ont reçu un diagnostic de cancer, ce qui est bien sûr beaucoup plus que ce dont le chercheur a besoin. L’intermédiaire reçoit également toutes les données identifiées relatives aux médicaments prescrits aux patients atteints de SEP de l’AIM et sait ainsi, sur cette base.

L’intermédiaire reçoit également toutes les données identifiées relatives aux médicaments prescrits aux patients atteints de SEP de l’AIM. Il sait ainsi quels enregistrements fournis par le BCR concernent des patients atteints de SEP et donc quels enregistrements sont pertinents dans le cadre de la question de recherche. L’intermédiaire entreprend alors les étapes suivantes :

1. Il supprime les enregistrements non pertinents, c’est-à-dire les enregistrements concernant tous les citoyens qui ont reçu un diagnostic de cancer mais qui ne sont pas atteints de SEP.
2. Il fusionne les enregistrements concernant les mêmes citoyens et remplace les numéros de registre national par des pseudonymes uniques dans les enregistrements fusionnés.
3. Il envoie le résultat – uniquement les enregistrements fusionnés – vers l’environnement sécurisé.
4. Il supprime toutes les données reçues et dérivées.

Dans ce scénario, il n’y a pas de fuite involontaire de données vers les sources de données et l’environnement sécurisé ne reçoit que les données personnelles pseudonymisées minimales nécessaires.

Notre prototype fait exactement cela, mais sans l’intermédiaire de confiance. Le rôle de l’intermédiaire de confiance est distribué : les détenteurs de données – dans ce cas, l’AIM et le BCR – et un collecteur de données – dans ce cas, l’environnement sécurisé – interagissent pour assumer ensemble le rôle de l’intermédiaire de confiance. Les caractéristiques de sécurité mentionnées dans le paragraphe précédent sont conservées ; aucune information n’est donc divulguée involontairement aux détenteurs de données et le collecteur de données ne prend connaissance que des données pseudonymisées strictement nécessaires. La solution reste néanmoins pratique et efficace. Tout cela est possible grâce à une cryptographie avancée.

Comme nous l’avons mentionné précédemment, l’AIM et le BCR conservent les données sous des pseudonymes. Il existe des procédures permettant de les convertir de manière contrôlée en numéros de registre national. L’entité qui gère les données n’a jamais connaissance des registres nationaux et l’entité qui peut associer les pseudonymes aux numéros de registre national n’a à aucun moment accès aux données à caractère personnel proprement dites. Par souci de simplicité et pour la suite de cet article, nous partons du principe que les détenteurs de données connaissent les données identifiées par les numéros de registre national plutôt que par les pseudonymes. Notre concept peut également s’appliquer de manière sécurisée à des situations plus réalistes où ce n’est pas le cas.

Dans la pratique

Smals Research a développé ce concept en collaboration avec des partenaires universitaires. Initialement baptisé Oblivious Join, il a été renommé LetheLink dans le contexte universitaire. Lethe (Λήθη) est, dans la mythologie grecque, la déesse de l’oubli et l’un des cinq fleuves des enfers, au bord duquel les morts s’abreuvent pour oublier leur vie terrestre. Malgré cet oubli – ou plutôt ce manque de connaissance –, les entités en interaction parviennent à relier entre elles les données nécessaires. La convivialité et l’efficacité ont été au cœur du développement de ce concept.

Smals Research a développé un prototype démontrable qui donne déjà un aperçu du fonctionnement d’une solution entreprise-ready. L’utilisation du prototype est présentée dans l’illustration 2 et comprend les étapes suivantes :

1. Création d’un fichier JSON. Une organisation pouvant servir de point de contact (par exemple, la HDA ou la BCSS) reçoit une demande d’un chercheur. Lorsque la base juridique pour ce traitement de données existe, cette organisation établit un fichier JSON signé numériquement. Ce fichier JSON contient, sous une forme structurée, toutes les informations nécessaires à l’exécution correcte du protocole pour le croisement sécurisé des données des détenteurs de données : les données de connexion des clients des détenteurs de données et du collecteur de données, les paramètres cryptographiques, les clés publiques, les informations sur les données que chaque détenteur de données doit fournir, etc. Dans la pratique, on partira de templates à partir desquels on pourra dériver des fichiers JSON avec un minimum d’effort.
2. Distribution du fichier JSON. Ce fichier JSON est envoyé à la fois au collecteur de données et aux détenteurs de données. Tous vérifient la signature numérique. Toutes les entités concernées savent désormais comment exécuter le protocole et comment contacter les autres entités concernées en toute sécurité.
3. Téléchargement du client. Si ce n’est pas déjà fait, le collecteur de données et les détenteurs de données téléchargent le client LetheLink.
4. Création de fichiers CSV. Sur la base du fichier JSON, chaque détenteur de données génère un fichier CSV contenant toutes les données identifiées potentiellement pertinentes. Dans le scénario décrit précédemment, cela inclurait, pour le BCR, toutes les informations identifiées demandées concernant tous les citoyens ayant reçu un diagnostic de cancer. La création de ce fichier ne relève pas du champ d’application de LetheLink. Notre prototype ne prend en charge que les fichiers CSV, mais cette fonctionnalité peut être étendue.
5. Importation du client. Chaque participant fournit le fichier JSON à son client LetheLink local. Les détenteurs de données fournissent également leur fichier CSV généré localement à leur client. Les données sont livrées en clair et le client se charge du chiffrement.
6. Exécution du protocole. Le protocole est exécuté. Du côté du collecteur (SPE) des données, cela donne un fichier CSV qui ne contient que les données pseudonymisées et minimales nécessaires.

L’avantage de cette approche réside dans sa flexibilité d’utilisation. Certains détenteurs de données ne sont impliqués que très occasionnellement dans de tels projets croisés et tous les détenteurs de données ne disposent pas des mêmes ressources. Grâce à l’approche LetheLink, nul besoin de réaliser d’importants investissements ou préparatifs. Il suffit d’installer le client et de créer le fichier CSV.

L’illustration 3 présente un exemple fictif de tels fichiers CSV. En haut figurent des extraits de fichiers CSV que les détenteurs de données (trois dans le cas présent) fournissent chacun en entrée à leur client LetheLink. Au bas de l’illustration, un extrait du fichier CSV généré en sortie par le client du collecteur de données à la suite de l’exécution du protocole est présenté. Dans notre exemple fictif, le chercheur s’intéresse uniquement aux données transversales, c’est-à-dire aux données relatives aux 50 000 patients atteints de SEP qui ont reçu un diagnostic de cancer et présentent un profil de risque élevé. La personne dont le numéro de registre national est 60.01.05-045.05 appartient à ce groupe. Le collecteur de données voit les informations combinées sur ce citoyen, non pas sous ce numéro de registre national, mais sous le pseudonyme “153807…”.

Performance

Dans le cadre de la collaboration académique, la performance a été considérablement améliorée au cours de plusieurs itérations, tant au niveau de l’algorithme qu’au niveau de la mise en œuvre. Les principaux résultats des tests sont présentés dans le tableau 1. Quelques précisions :

• Les tests ont été effectués sur des machines virtuelles AWS EC2 r7i.8xlarge, avec 32 vCPU (Intel Xeon Platinum 8588C @ 3,2 GHz) et 256 Go de RAM.
• Une distinction est opérée entre une exécution sur un LAN à une vitesse de 1 Gbps et sur un WAN à une vitesse de 150 Mbps.
• La variable m représente le nombre d’enregistrements fournis par chacune des sources de données. Dans nos tests, elle est comprise entre un minimum de 2¹⁶= 65.536 et maximum de 2²⁴= 16.777.216. En réalité, le nombre d’enregistrements varie bien sûr selon la source de données, mais ces résultats fournissent déjà une limite supérieure.
• La variable κ (kappa) représente le niveau de sécurité computationnel. Une sécurité de 128 bits est suffisante aujourd’hui, mais une sécurité de 192 ou même de 256 bits est recommandée pour les données qui restent sensibles pendant une longue période. La variable λ (lambda) représente le paramètre de sécurité statique correspondant. 
• La variable n représente le nombre de détenteurs de données. Nous avons effectué des tests avec 3, 5 et 7 détenteurs de données, mais il n’y a aucune limitation technique pour un nombre beaucoup plus important.

Maintenant que nous savons comment interpréter ce tableau, nous constatons par exemple qu’il faut 25 secondes pour exécuter le protocole lorsque trois sources de données fournissent chacune 1 million (2²⁰) d’enregistrements sur un WAN. La quantité de données fournies a également un impact sur le temps d’exécution, mais pour cela, nous vous renvoyons au tableau 3 de notre publication commune. En résumé, tant le protocole que sa mise en œuvre sont particulièrement efficaces. Pour conclure, l’illustration 4 donne une idée générale de la réalisation des tests.

Relation avec le service de pseudonymisation à l’aveugle d’eHealth

Smals Research a développé le service de pseudonymisation à l’aveugle pour eHealth au cours de la période 2021-2022. Ce service permet de convertir les numéros de registre national en pseudonymes (codes uniques) et vice versa. Cette conversion est effectuée par un service de pseudonymisation qui est toutefois aveugle : il ne voit ni les numéros de registre national ni les pseudonymes. Ce service peut également être utilisé pour pseudonymiser et croiser des données. Quelles sont les différences ?

• Statut. Le service de pseudonymisation à l’aveugle est déjà en production, tandis que LetheLink n’est qu’un prototype.
• Fuite de données. Pour les projets de recoupement plus complexes, tels que ceux évoqués dans cet article, le service de pseudonymisation à l’aveugle ne pourra pas toujours empêcher les fuites de données. Il y aura notamment des fuites de données lorsqu’une source de données ne peut pas déterminer de manière autonome quels enregistrements sont pertinents pour répondre à la question de recherche. Selon le use case, il peut s’agir d’une fuite de données résiduelle acceptable ou de fuites de données plus substantielles, qui portent effectivement atteinte à la vie privée des personnes concernées. D’autre part, LetheLink présente des risques lorsqu’une seule entité est à la fois détentrice et collectrice de données.
• Rapidité. Le service de pseudonymisation à l’aveugle d’eHealth est certes très rapide – il peut effectuer des milliers de conversions par seconde -, mais LetheLink est ultra-rapide – il effectue des dizaines de milliers de conversions par seconde et, dans certaines circonstances, peut dépasser les cent mille. Tout dépendra bien sûr de l’infrastructure utilisée.
• Infrastructure. Le service de pseudonymisation à l’aveugle d’eHealth est dans tous les cas une entité centrale qui doit disposer d’une capacité suffisante. LetheLink, en revanche, est distribué, ce qui rend inutile une telle entité centrale : il suffit que chaque entité exécute le client LetheLink sur ses machines existantes. Il peut même s’agir d’ordinateurs portables classiques.
• Intégration. Afin d’utiliser le service de pseudonymisation à l’aveugle, une organisation doit intégrer une logique dans son application client. Nous savons par expérience que cela est relativement simple, mais cela reste néanmoins un investissement. LetheLink est un client autonome et ne nécessite donc aucun processus d’intégration.
• Types de demandes. Le service de pseudonymisation à l’aveugle d’eHealth peut traiter tant les demandes en batch que les demandes qui doivent être traitées en temps réel. LetheLink ne prend en charge que les traitements en batch.

Ce positionnement respectif de LetheLink et du service de pseudonymisation à l’aveugle d’eHealth devrait aider les organisations à déterminer la technologie la plus adaptée à leurs use cases.

Extensions

Un certain nombre d’extensions de LetheLink seront nécessaires pour pouvoir l’utiliser dans la pratique. Toutes les extensions proposées sont déjà conceptuellement possibles, mais ne sont pas toujours intégrées dans le prototype. Cela ne se fera que si une demande concrète est formulée.

• Taille minimale de l’ensemble de résultats. Si l’ensemble de résultats pseudonymisés pour le collecteur de données ne contient pas suffisamment d’enregistrements, il existe un risque pour la vie privée des personnes concernées et il est impossible de mener des recherches statistiquement pertinentes. C’est pourquoi le prototype prend déjà en charge la possibilité d’indiquer une taille minimale dans le fichier JSON.
• Réidentification contrôlée. Si les chercheurs constatent qu’un citoyen donné présente un risque élevé de développer une certaine maladie, il doit être possible d’en informer ce citoyen. De même, lorsqu’une enquête sur une fraude révèle une forte suspicion de fraude de la part de certains citoyens, il doit être possible d’en informer l’autorité compétente. Il doit donc être possible, dans des situations exceptionnelles, de vérifier l’identité d’un citoyen de manière contrôlée.
• Pseudonymes des détenteurs de données. Comme indiqué précédemment dans cet article, les détenteurs de données n’ont souvent pas eux-mêmes accès au numéro de registre national des citoyens dont ils gèrent les données. Dans de tels cas également, le protocole doit pouvoir être mis en œuvre efficacement.
• Divulgation sélective. Actuellement, le prototype se concentre sur des moyennes ; ce n’est que si tous les détenteurs de données fournissent des enregistrements sur un même citoyen que l’enregistrement composite devient visible pour le collecteur de données. Dans la pratique, une plus grande flexibilité est requise, comme l’indique l’illustration 5. Dans le cas d’utilisation présenté en introduction de cet article, le chercheur avait besoin de données pseudonymisées sur tous les patients atteints de SEP, alors que notre prototype ne fournit actuellement que des données pseudonymisées sur tous les patients atteints de SEP ayant également reçu un diagnostic de cancer.
• Transfert multi-batch. Dans certains cas, les détenteurs de données doivent fournir des données à plusieurs reprises au collecteur de données, par exemple dans le cadre d’une étude longitudinale. Le collecteur de données doit être capable de relier entre elles les données relatives à un même citoyen au fil du temps.
• Communication simplifiée. Dans le prototype, tous les détenteurs de données concernés communiquent entre eux, puis envoient individuellement des données cryptées au collecteur de données. Dans un protocole adapté, les détenteurs de données n’échangeraient des données qu’avec et via le collecteur de données, par exemple via une interface REST. Dans la pratique, cette approche est plus souhaitable.

Veuillez nous faire part de toute autre extension utile que vous pourriez envisager.

Références

Le concept initial ainsi que le prototype et les tests de performance ont été réalisés par Smals Research. Les partenaires universitaires, notamment le groupe COSIC et le groupe DistriNet de la KU Leuven, ainsi que le groupe CrySP de l’université de Waterloo au Canada, se sont concentrés sur l’élaboration théorique. Cela a donné lieu à deux publications en 2025 :

• Publication de Springer :Privacy-By-Design in the Belgian Public Sector Ce document accessible traite de deux solutions innovantes conçues par Smals Research pour la pseudonymisation et le croisement des données à caractère personnel : Lethelink et le service de pseudonymisation à l’aveugle d’eHealth.
• Publication de Springer :Privacy-By-Design in the Belgian Public Sector Ce document accessible traite de deux solutions innovantes conçues par Smals Research pour la pseudonymisation et le croisement des données à caractère personnel : Lethelink et le service de pseudonymisation à l’aveugle d’eHealth.

Je vous invite également à consulter ma contribution à la conférence Devoxx et mon webinaire de 2024 intitulé “Privacy in Practice with Smart Pseudonymisation”. LetheLink/Oblivious Join est l’une des trois techniques de pseudonymisation que j’y aborde.

Enfin, des slides sont disponibles pour ceux qui souhaitent se faire rapidement une idée intuitive des principes de base de l’Oblivious Join. Les notes correspondantes fournissent des explications supplémentaires.

Conclusion

L’utilisation secondaire des données à caractère personnel peut nous fournir de nombreuses informations qui soutiennent l’élaboration des politiques et stimulent la recherche scientifique. Pour exploiter ces informations, les données provenant de différentes sources doivent pouvoir être collectées de manière efficace, dans le respect de la vie privée. Cela signifie que seules les données à caractère personnel nécessaires sont pseudonymisées et croisées et que les autres entités participant à ce processus n’ont pas accès aux données à caractère personnel. Dans la pratique, cela était loin d’être évident.

En collaboration avec des universités de renommée internationale, Smals Research a donc élaboré un concept qui, grâce à une cryptographie avancée, permet de le faire de manière efficace. Un prototype démontrable a également été construit, ce qui constitue une première étape vers une mise en œuvre effective dans la pratique.

Au cours des dernières années, nous avons rencontré de nombreuses entités. Tout le monde considère qu’il s’agit d’un outil très utile, mais nous ne disposons pour l’instant pas de l’engagement de nos partenaires pour le mettre en pratique.

Le défi principal aujourd’hui est donc de rendre cette solution prête à la production. N’hésitez pas à nous contacter si cette solution vous intéresse et si vous souhaitez éventuellement y contribuer.

Digitale persoonsgegevens vormen binnen een overheidscontext een bron van inzichten die innovatie, welzijn en beleidsvorming ten goede komen. Die persoonsgegevens zijn over heel wat organisaties verspreid; de ene organisatie heeft informatie over kanker, de andere over medicijngebruik en nog een andere bewaart inkomensgegevens. In de praktijk worden geregeld persoonsgegevens afkomstig van verschillende organisaties samengevoegd om op specifieke vragen van onderzoekers en beleidsmakers te kunnen antwoorden.

De huidige processen garanderen dat dit met respect voor de privacy gebeurt. Helaas is het – mede daardoor – ook te vaak een complexe, dure en tijdrovende aangelegenheid. In samenwerking met internationaal toonaangevende universiteiten werkte Smals Research daarom aan een prototype om met behulp van geavanceerde cryptografie deze processen aanzienlijk te vereenvoudigen.

Probleemstellig op basis van concrete case

We vertrokken van een concrete onderzoeksvraag:

Lopen MS-patiënten die medicijnen met de moleculen teriflunomide of alemtuzumab gebruiken een verhoogd risico op kanker in vergelijking met MS-patiënten die met andere medicijnen worden behandeld?

Om die – op zich eenvoudige – vraag te kunnen beantwoorden moeten medische gegevens over MS-patiënten afkomstig van twee organisaties, met name het Belgisch Kankerregister (BCR) en het InterMutualistisch Agentschap (IMA) gekruist worden.

Beide organisaties beheren de gegevens onder aparte pseudoniemen voor meer privacy; unieke codes ter vervanging van rijksregisternummers.

• Het BCR beheert gegevens met betrekking tot kanker over mensen die een kankerdiagnose kregen. Het BCR weet niet welke records betrekking hebben op MS-patiënten.
• Het IMA kent gegevens m.b.t. voorgeschreven medicijnen en kan de records selecteren van MS-patiënten.

De onderzoekers dienen in een beveiligde omgeving (SPE = Secure Processing Environment) toegang te krijgen tot gegevens afkomstig van het BCR en het IMA, over alle MS-patiënten. Gegevens over dezelfde patiënt maar afkomstig van verschillende bronnen moeten aan elkaar gekoppeld kunnen worden op basis van een uniek pseudoniem dat enkel gebruikt wordt in het kader van die specifieke onderzoeksvraag. Dit wordt geïllustreerd in figuur 1.

De centrale vraag luidt als volgt:

Hoe kan het BCR enkel records over MS-patiënten aanleveren aan de beveiligde omgeving zonder te weten te komen wie MS heeft of welke records die het beheert betrekking hebben op MS-patiënten?

In een klassieke benadering zal ofwel het BCR te veel informatie naar de beveiligde omgeving sturen – met name gegevens over elke kankerpatiënt – ofwel lekt er informatie naar het BCR – waarbij het BCR te weten komt welke records betrekking hebben op MS-patiënten. Een laatste mogelijkheid is het inschakelen van een vertrouwde centrale partij die weliswaar persoonsgegevens te weten komt, maar vertrouwd wordt daar niets onrechtmatigs mee te doen.

Geen van deze aanpakken is ideaal. Vandaag wordt in binnen- en buitenland ofwel beroep gedaan op – sterk gereguleerde – centrale partijen ofwel is duur en traag maatwerk vereist, waarbij voor elke onderzoeksvraag een nieuwe flow uitgetekend, gevalideerd en uitgevoerd wordt om de privacy maximaal te beschermen.

We geven nog mee dat de onderzoeker doorgaans toegang nodig heeft tot de ruwe data, waardoor oplossingen gebaseerd op secure multi-party computation ongeschikt zijn. 

Ons voorstel tot oplossing

Laat ons even vertrekken van een fictief scenario waarbij gewerkt wordt met een vertrouwde intermediaire partij en het – voor de eenvoud – IMA en BCR de persoonsgegevens niet onder pseudoniemen beheren, maar onder rijksregisternummers. IMA en BCR sturen beiden alle gegevens die potentieel relevant zijn naar de vertrouwde tussenpartij.

Het BCR stuurt naar de intermediaire partij geïdentificeerde kankergegevens over alle burgers die de kankerdiagnose kregen, wat uiteraard veel meer is dan nodig voor de onderzoeker. De intermediaire partij krijgt ook alle geïdentificeerde medicatiegegevens over MS-patiënten van het IMA en weet op basis daarvan welke door het BCR aangeleverde records betrekking hebben op MS-patiënten en dus relevant zijn in het kader van de onderzoeksvraag. De intermediaire partij voert nu de volgende stappen uit:

1. Het verwijdert de niet relevante records, dus de records over alle burgers die de kankerdiagnose kregen maar geen MS hebben.
2. Het voegt records over dezelfde burgers samen en vervangt in de samengevoegde records de rijksregisternummers door unieke pseudoniemen
3. Het stuurt het resultaat – enkel samengevoegde records – naar de beveiligde omgeving.
4. Het verwijdert alle ontvangen en afgeleide gegevens.

In dit scenario zijn er geen onbedoelde datalekken naar de databronnen en ontvangt de beveiligde omgeving enkel de minimaal noodzakelijke, gepseudonimiseerde persoonsgegevens.

Ons prototype doet exact dit, maar dan zonder de vertrouwde partij. De rol van de vertrouwde partij wordt gedistribueerd: Data holders – in dit geval het IMA en het BCR – en een data collector – in dit geval de beveiligde omgeving – interageren met elkaar om samen de rol van de vertrouwde partij over te nemen. Daarbij worden de veiligheidseigenschappen uit de vorige paragraaf behouden; er lekt dus niet onbedoeld informatie naar de data holders en de data collector komt enkel de minimaal noodzakelijke gepseudonimiseerde gegevens te weten. De oplossing blijft niettemin praktisch en efficiënt. Dit alles is mogelijk dankzij geavanceerde cryptografie.

We schreven eerder dat het IMA en het BCR de data bewaren onder pseudoniemen. Er bestaan procedures om die op een gecontroleerde wijze om te zetten in rijksregisternummers. De partij die data beheert komt daarbij nooit rijksregisternummers te weten en de partij die pseudoniemen kan koppelen aan rijksregisternummers heeft op geen enkel moment toegang tot de eigenlijke persoonsgegevens. Om redenen van eenvoud gaan we er de rest van dit artikel vanuit dat de data holders de data kennen onder rijksregisternummers. Ons concept kan ook op een veilige manier overweg weg met de meer realistische situaties waarbij dit niet het geval is.

In de praktijk

Smals Research werkte samen met academische partners het concept uit. Initieel luisterde het naar de naam Oblivious Join, maar in academische context werd het herdoopt naar LetheLink. Lethe (Λήθη) is in de Griekse mythologie de godin van de vergetelheid en een van de vijf rivieren in de onderwereld, waaruit de doden drinken om hun aardse leven te vergeten. Ondanks die vergetelheid – of beter, gebrek aan kennis – slagen de interagerende partijen er toch in de noodzakelijke data aan elkaar te linken. Centraal in de ontwikkeling van dit concept stonden gebruiksvriendelijkheid en efficiëntie.

Smals Research heeft een demonstreerbaar prototype uitgewerkt dat alvast een zicht geeft op hoe een enterprise-ready oplossing zou kunnen werken. Het gebruik van het prototype wordt geïllustreerd in figuur 2 en bestaat uit de volgende stappen:

1. Creatie JSON-bestand. Een organisatie die als aanspreekpunt kan dienen (vb, de HDA of de KSZ) krijgt een vraag binnen van een onderzoeker. Wanneer de juridische basis voor deze gegevensverwerking er is, stelt deze organisatie een digitaal ondertekend JSON-bestand op. Dat bestand bevat in een gestructureerde vorm alle informatie om het protocol voor het beveiligd kruisen van de gegevens van de data holders op een correcte manier uit te kunnen voeren: connectiegegevens van de clients van zowel data holders als de data collector, de cryptografische parameters, publieke sleutels, informatie over welke data holder welke data moet aanleveren, etc. In de praktijk zal men vertrekken van templates, van waaruit met een minimale inspanning JSON-bestanden afgeleid kunnen worden.
2. Distributie JSON-bestand. Dit JSON-bestand wordt bezorgd aan zowel de data collector als de data holders. Allen verifiëren de digitale handtekening. Alle betrokken partijen weten nu hoe ze het protocol moeten uitvoeren en hoe ze de andere betrokken partijen veilig kunnen contacteren.
3. Downloaden client. Indien dit nog niet gebeurd is, downloaden de data collector en data holders de LetheLink client.
4. Creatie CSV-bestanden. Op basis van het JSON-bestand genereert elke data holder een CSV-bestand die alle potentieel relevante geïdentificeerde data bevat. In de eerder geschetste use case zou dit voor het SKR alle gevraagde geïdentificeerde informatie bevatten over alle burgers die de kankerdiagnose kregen. De creatie van dit bestand valt buiten de scope van LetheLink. In ons prototype worden enkel CSV-bestanden ondersteund, maar dit kan uitgebreid worden.
5. Invoer client. Elke participant geeft het JSON-bestand als invoer aan zijn lokale LetheLink client. De data holders geven daarnaast ook hun lokaal gegenereerde CSV-bestand aan hun client. Data worden in klaar aangeleverd en de client neemt de versleuteling op zich.
6. Uitvoering protocol. Het protocol wordt uitgevoerd. Dit resulteert aan de kant van de data collector (SPE) in een CSV bestand dat enkel de gepseudonimiseerde, minimaal noodzakelijke gegevens bevat.  

Het voordeel van deze benadering is de flexibele inzetbaarheid. Er zijn data holders die maar heel af en toe in dergelijke kruisingsprojecten betrokken zijn en niet alle data holders beschikken over evenveel middelen. Dankzij de LetheLink benadering zijn geen grote investeringen of voorbereidingen nodig. De installatie van de client en creatie van de CSV file volstaan.

Figuur 3 geeft een fictief voorbeeld van dergelijke CSV bestanden. Bovenaan staan extracten van CSV bestanden  die de – in dit geval drie – data holders elk als invoer aan hun LetheLink client geven. Onderaan de figuur is een extract te zien van het CSV bestand dat de client van de data collector als output genereert als resultaat van de protocoluitvoering. In ons fictieve voorbeeld is de onderzoeker enkel geïnteresseerd in data in de doorsnede; dus in data over de 50 000 MS-patiënten die de kankerdiagnose kregen en een hoog risicoprofiel hebben. De persoon met rijksregisternummer 60.01.05-045.05 behoort tot die groep. De data collector ziet de gecombineerde informatie over deze burger, niet onder dit rijksregisternummer, maar onder het pseudoniem “153807…”.

Performantie

In het kader van de academische samenwerking werd de performantie in meerdere iteraties grondig verbeterd, zowel op het niveau van het algoritme, als op het niveau van de implementatie. De voornaamste testresultaten zijn weergegeven in tabel 1. Een beetje duiding:

• De testen werden uitgevoerd op op AWS EC2 r7i.8xlarge VMs, met 32 vCPU’s (Intel Xeon Platinum 8588C @ 3.2 GHz) en 256 GB RAM.
• Er wordt een onderscheid gemaakt tussen een uitvoering op een LAN aan een snelheid van 1 Gbps en op een WAN aan een snelheid van 150 Mbps.
• De variable m representeert het aantal records dat door elk van de databronnen meegegeven wordt. Het is in onze testen minimaal 2¹⁶ = 65 536 en maximaal 2²⁴ = 16 777 216. In werkelijkheid is het aantal records uiteraard verschillend per databron, maar deze resultaten geven alvast een bovengrens.
• De variable κ (kappa) representeert het computationele veiligheidsniveau. 128 bit security volstaat vandaag, al wordt voor data die lange tijd gevoelig blijft toch 192 of zelfs 256 bit security aanbevolen. De variable λ (lambda) representeert de corresponderende statistische veiligheidsparameter. 
• De variabele n representeert het aantal data holders. We deden testen met 3, 5 en 7 data holders, maar er zijn geen technische beperkingen voor een veel groter aantal.

Nu we weten hoe deze tabel te interpreteren, zien we dat er bijvoorbeeld 25 seconden nodig zijn om het protocol uit te voeren waarbij drie databronnen elk 1 miljoen (2²⁰) records aanleveren over een WAN, met een veiligheidsniveau van 256 bits. De hoeveelheid meegeleverde data heeft eveneens impact op de uitvoeringstijd, maar daarvoor verwijzen we naar tabel 3 in onze gemeenschappelijke publicatie. Samengevat zijn zowel het protocol als de implementatie ervan bijzonder efficiënt. Figuur 4 geeft, ter afronding, een sfeerbeeld van het uitvoeren van de testen.

Verhouding tot eHealths Blinde Pseudonimiseringsdienst

Smals Research ontwikkelde in de periode 2021-2022 de blinde pseudonimiseringsdienst voor eHealth. Daarmee kunnen rijksregisternummers omgezet worden in pseudoniemen – unieke codes – en vice versa. Die omzetting gebeurt door een pseudonimiseringsdienst die echter blind is: het ziet rijksregisternummers noch pseudoniemen. Deze dienst kan eveneens gebruikt worden om gegevens te pseudonimiseren én te kruisen. Wat zijn dan de verschillen?

• Status. De blinde pseudonimiseringsdienst staat reeds in productie, terwijl LetheLink slechts een prototype is.
• Datalekkage. Voor complexere kruisingsprojecten, zoals diegene waar in dit artikel van vertrokken wordt, zal de blinde pseudonimiseringsdienst niet altijd kunnen verhinderen dat er datalekken optreden. Met name zal er sprake zijn van gegevenslekkage wanneer een databron niet autonoom kan bepalen welke records relevant zijn om de onderzoeksvraag te kunnen beantwoorden. Afhankelijk van de use case kan dit gaan om een aanvaardbaar residuele datalekkage, of het kan gaan over meer substantiële datalekken, die effectief de privacy van betrokkenen aantasten. Anderzijds ontstaan er bij LetheLink risico’s wanneer één entiteit zowel data holder als data collector is.
• Snelheid. eHealths blinde pseudonimiseringsdienst is weliswaar erg snel – het kan duizenden conversies per seconde aan -, maar LetheLink is bliksemsnel – het doet tienduizenden conversies per seconde en onder bepaalde omstandigheden kan het over de honderduizend gaan. Veel zal natuurlijk afhangen van de gebruikte infrastructuur.
• Infrastructuur. eHealths blinde pseudonimiseringsdienst is sowieso een centrale entiteit die over voldoende capaciteit moet beschikken. LetheLink daarentegen is gedistribueerd, waardoor een dergelijke centrale partij niet langer vereist is: het volstaat dat elke partij de LetheLink client draait op zijn bestaande machines. Dat kunnen zelfs reguliere laptops zijn.
• Integratie. Om gebruik te maken van de blinde pseudonimiseringsdienst moet een organisatie logica integreren in zijn clienttoepassing. Uit ervaring weten we dat dit gelukkig relatief eenvoudig is, maar het blijft niettemin een investering. LetheLink is een standalone client en dus is er geen integratietraject nodig.
• Type aanvragen. eHealths blinde pseudonimiseringsdienst kan overweg met zowel batch aanvragen als met aanvragen die in real-time afgehandeld moeten worden. LetheLink kan enkel overweg met verwerkingen in batch.

Deze positionering van LetheLink en eHealths blinde pseudonimiseringsdienst ten opzichte van elkaar zou organisaties moeten helpen om te bepalen welke technologie het meest geschikt is voor hun use cases.

Uitbreidingen

Er zullen een aantal uitbreidingen van LetheLink nodig zijn om het ook daadwerkelijk in de praktijk te kunnen inzetten. Alle voorgestelde uitbreidingen zijn conceptueel alvast mogelijk, maar niet steeds in het prototype geïntegreerd. Dit zal enkel gebeuren indien er een concrete vraag komt.

• Minimale grootte resultaatset. Indien de gepseudonimiseerde resultaatset voor de data collector onvoldoende records bevat is er een risico voor de privacy van de betrokkenen en is het onmogelijk om statistisch relevant onderzoek te doen. Daarom ondersteunt het prototype vandaag reeds de mogelijkheid om een minimale grootte mee te geven in het JSON bestand.
• Gecontroleerde re-identificatie. Indien onderzoekers merken dat een bepaalde burger een hoog risico heeft om een bepaalde ziekte te ontwikkelen, moet het mogelijk zijn deze burger daarvan op de hoogte te stellen. Ook wanneer bij een fraudeonderzoek er een sterk vermoeden van fraude is door bepaalde burgers, moet het mogelijk zijn de bevoegde instantie op de hoogte te brengen. Er moet dus in een mogelijkheid voorzien worden om in uitzonderlijke situaties op gecontroleerde wijze de identiteit van een burger te achterhalen.
• Data holder pseudoniemen. Zoals eerder in dit artikel aangegeven, hebben data holders vaak zelf geen toegang tot het rijksregisternummer van de burgers waarover ze data beheren. Ook in dergelijk gevallen moet het protocol efficiënt uit te voeren zijn.
• Selectieve prijsgave. Momenteel focust het prototype op doorsnedes; enkel indien alle data holders records over eenzelfde burger aanleveren, wordt het samengestelde record zichtbaar voor de data collector. In de praktijk is er meer flexibiliteit nodig, zoals aangegeven in figuur 5. In de use case waarmee we dit artikel begonnen had de onderzoeker gepseudonimiseerde gegevens nodig over alle MS-patiënten, terwijl ons protoype op dit moment enkel gepseudonimiseerde gegevens aanlevert over alle MS-patiënten die ook de kankerdiagnose kregen. 
• Multi-batch transfer. In sommige gevallen moeten data holders meermaals data aanleveren aan de data collector, bijvoorbeeld in het kader van longitudinaal onderzoek. De data collector moet in staat zijn doorheen de tijd data over eenzelfde burger aan elkaar te koppelen.
• Vereenvoudigde communicatie. In het prototype communiceren alle betrokken data holders met elkaar, om vervolgens individueel vercijferde data naar de data collector te sturen. In een aangepast protocol zouden data holders enkel data uitwisselen met en via de data collector, bijvoorbeeld via een REST-interface. In de praktijk is dit de meer wenselijke benadering.

Laat ons weten indien u andere nuttige uitbreidingen ziet.

Referenties

Het initiële concept alsook het prototype en de performantietesten werden uitgevoerd door Smals Research. De academische partners, met name de COSIC groep en de DistriNet groep aan de KU Leuven, alsook de CrySP groep aan Waterloo University in Canada, focusten zich op de theoretische uitwerking. Dit resulteerde in 2025 in twee publicaties:

• Springer publicatie – Privacy-By-Design in the Belgian Public Sector. Dit toegankelijke document bespreekt twee innovatieve oplossingen bedacht door Smals Research voor het pseudonimiseren en kruisen van persoonsgegevens; Lethelink en eHealths blinde pseudonimiseringsdienst.
• Arxiv publicatie – Labeled Delegated PSI and its Applications in the Public Sector.  Dit academisch artikel beschijft formeel LetheLink, bewijst de correctheid, bespreekt de performantie en positioneert het werkt t.o.v. bestaand academisch werk.

Daarnaast verwijs ik graag naar mijn Devoxx talk en Webinar uit 2024 getiteld “Privacy in Practice with Smart Pseudonymisation”. LetheLink/Oblivious Join is één van de drie pseudonimiseringstechnieken die ik er bespreek.

Ten slotte zijn er nog slides beschikbaar voor diegenen die graag snel een intuïtief beeld ontwikkelen over de basisprincipes van Oblivious Join. De bijhorende nota’s geven extra uitleg.

Conclusie

Secundair gebruik van persoonsgegevens kan ons heel wat inzichten verschaffen die beleidsvorming ondersteunen en wetenschappelijk onderzoek stimuleren. Om die inzichten te ontsluiten moeten gegevens afkomstig van verschillende bronnen op een efficiënte wijze verzameld kunnen worden, met respect voor de privacy. Dat wil zeggen dat enkel de noodzakelijke persoonsgegevens gepseudonimiseerd en gekruist worden en dat participerende partijen in dit proces geen persoonsgegevens te weten komen. Dit was in de praktijk verre van evident.

In samenwerking met internationaal toonaangevende universiteiten werkte Smals Research daarom een concept uit dat met behulp van geavanceerde cryptografie dit op een efficiënte wijze mogelijk maakt. Verder werd een demonstreerbaar prototype gebouwd, wat een eerste stap is om dit effectief in de praktijk te kunnen gaan inzetten.

We hebben de voorbije jaren met heel wat partijen samen gezeten. Iedereen vindt het een zeer nuttige tool, maar vooralsnog missen we de commitment van onze partners om dit in de praktijk om te zetten.

De voornaamste uitdaging vandaag is dan ook het productieklaar krijgen van deze oplossing. Neem dus zeker contact met ons op indien u interesse heeft in deze oplossing en eventueel mee uw schouders hieronder wil zetten.

General description

Our health is precious. And our personal health data is among the most precious information. So we need to protect it! Smals – the main IT provider for the Belgian public sector – already had strong security measures in place, such as firewalls, hardware security modules, SIEM systems and database encryption. Yet we do more.

eHealth’s blinded pseudonymization service (Intro in Dutch or French) adds an extra layer of security. It enables Smals to manage for example electronic prescriptions without ever learning to whom they belong, without knowing the social security number. Instead, Smals only sees unique codes (pseudonyms). Even if leaked, a hacker won’t be able to do much with the data.

The blinded pseudonymization service – managed by the Belgian eHealth-platform – ensures that only an authorized health care professional, such as your GP, can link a prescription to you. It’s blind, because it doesn’t see any pseudonyms or social security numbers.

We can’t simply encrypt all the data before sending it to the backend, because the latter has functional responsibilities, such as input validation and generation of statistics. Our approach enables the selective encryption of some of the data fields (e.g., free text by the GP), such that the backend only has access to the data it needs in order to fulfil its assigned tasks, without ever seeing social security numbers.

This elegant and versatile approach greatly reduces identification risks in case unauthorized (internal or external) entities obtain access to centrally stored medical data. This approach is the default choice for new e-health applications in Belgium. It is already in use today for electronic prescriptions and information about vaccines, prosthetic devices, fertility, allergies and intolerances. The latest application to use this service is TRIO to assist disabled persons. It is a successful example of privacy by design in the Belgian public sector.

Can you briefly describe the solution, product, technology, approach, or project?

The Belgian eHealth ecosystem consists of multiple backend services which store different types of medical data. Some examples are prescriptions, vaccinations and therapeutic relations. These backend services are contacted by citizens, health care professionals and other eHealth backend services. While Smals manages the backend services, eHealth manages security services (e.g. access control).

On top of the existing security measures, we introduced a new security layer guaranteeing that social security numbers are no longer exposed to backend services or their underlying infrastructure. The blinded pseudonymization service, managed by eHealth, was introduced.

The solution cryptographically guarantees that:

• Backend services learn backend-specific pseudonyms, but never social security numbers.
• Authorized health care providers (such as your GP) learn social security numbers, but never pseudonyms.
• The pseudonymisation service learns neither.

Hence, each party only learns the strictly minimal identifier-related information it needs to know.

The system is versatile; It also enables selective encryption to ensure that the backend service only sees the minimal required personal (yet pseudonymized) medical data to fulfil its responsibilities. Additionally, our approach enables to flexibly and securely pseudonymize and join (intro in NL and FR) data originating from different sources for scientific purposes (e.g. epidemiology) by research institutes (such as Sciensano in Belgium).

Can you demonstrate its innovative character?

Storing the unencrypted data and the social security number in databases is a bad yet common practice. Unauthorized access could have detrimental consequences.

Experience taught us that full encryption of all data by the client, and storage of the resulting ciphertexts by the backend under the unencrypted social security number, comes with serious functional limitations. The backend could indeed no longer validate the correctness of incoming values (e.g. medication codes) or extract statistics.

Therefore, we need a finer-grained approach that hides social security numbers as well as some of the medical data (e.g. free text written by the doctor).

Adjacent academic work exists. Notably, there is the polymorphic encryption and pseudonymization by Verheul et. al. While this pseudonymization service is located between the health care professional and the backend service, ours sits at the sideline. Consequently, our solution respects existing communication flows. Moreover, in contrast to the solution proposed by Verheul, the blinded pseudonymization service is unable to convert pseudonyms or ciphertexts into something decryptable by unauthorized entities. In summary, our service is less intrusive and requires less trust.

Springer Nature accepted in its 2025 volume Public Governance and Emerging Technologies our chapter discussing the blinded pseudonymisation service.

What is the added value of this security innovation in terms of security: how resilient and protective is it?

Security & Privacy

The solution greatly reduces the identification risk in case of an internal adversary (administrator) or external adversary (hacker) having access to or publishing the medical data stored by the backend service. The social security numbers, as well as a subset of the actual medical data in each separate record, remain hidden. It enables Smals to implement the principle that it should nowhere in the process have access to social security numbers. It is adopted as the default approach for new IT projects in Belgian healthcare and social security.

Our solutions greatly reduce identification risks, but does not reduce them to zero. It should be seen as an extra – but strong – layer of security, on top of the existing ones (such as access control, database encryption and firewalls).

High availability

The high availability of the pseudonymization service is guaranteed by the deployment of multiple instances and HSMs in multiple datacenters. Moreover, a backup solution is foreseen, offering limited functionality when the pseudonymization service is unavailable.

Correctness

The correctness of our solution has been validated by academic partners.

This is a submitted contribution by Kristof Verslype, cryptographer at Smals Research. It was written in his own name and does not take a position on behalf of Smals.

Featured image by Cybersec Europe

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

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

Oblivious transfer

Er wordt vanuit justitie onderzoek gevoerd naar specifieke burgers, bijvoorbeeld in het kader van terrorismebestrijding. Persoonsgegevens die beheerd worden door derden moeten daarbij opgevraagd kunnen worden. Denk daarbij bijvoorbeeld aan metagegevens over telefoongesprekken gekend door telecomoperatoren of aan de verschillende officiële verblijfplaatsen doorheen de tijd, wat gekend is door het Rijksregister. In een traditionele benadering vraagt justitie aan een organisatie om gegevens x, y en z over een specifieke burger aan te leveren. Er zijn echter twee bezwaren tegen een dergelijke naïeve benadering. Ten eerste is de privacy van de burger geschaad. Elke organisatie die informatie over hem of haar moet aanleveren komt immers te weten dat er een onderzoek loopt naar deze persoon. Een tweede bezwaar dat daaruit voortvloeit is dat dit de confidentialiteit van het onderzoek kan schaden. Er zijn dus goede redenen voor een andere benadering.

Oblivious transfer werd reeds in een afzonderlijke blogpost besproken en biedt hier een antwoord op. Er zijn in dit verhaal twee betrokkenen: een zender en een ontvanger. De technologie laat toe dat de ontvanger (justitie)  toegang krijgt tot een zelf gekozen record uit een set van records die door de zender (telco) gekend zijn. De ontvanger krijgt slechts toegang tot dit ene record. De zender weet niet hetwelke. Oblivious transfer beschermt aldus de privacy van de burger, alsook de confidentialiteit van het onderzoek.

Attribute-based credentials

Stel dat je als burger vuurwerk of alcohol wil aankopen. Wettelijk is dit enkel toegelaten vanaf een bepaalde minimumleeftijd. De burger kan m.b.v. haar elektronische identiteitskaart wel bewijzen dat daaraan voldaan is. Helaas geeft ze daarmee veel meer informatie prijs dan strikt noodzakelijk: haar geslacht, exacte geboortedatum, rijksregisternummer, etc. Attribute-based credentials kunnen exact dezelfde informatie bevatten, maar laten wel toe dat de burger zelf kiest welke informatie ze selectief prijsgeeft. In feite geeft de burger nooit haar attribute-based credentials zelf prijs, maar genereert ze op basis daarvan lokaal een bewijs met daarin enkel de minimum noodzakelijke informatie. Dit bewijs wordt vervolgens getoond. In ons voorbeeld bewijst de burger dus dat ze ouder is dan 16 jaar, terwijl haar exacte geboortedatum en andere attributen verborgen blijven. Bovendien kan de burger vermijden dat verschillende aankopen van haar aan elkaar gelinkt kunnen worden. Attribute-based credentials zijn een krachtige technologie die past in de filosofie van self-sovereign identity, waarbij de burger eigenaar is van en de controle heeft over haar gegevens.

Format-preserving encryption

Encryptie laat toe data te verbergen voor partijen die niet beschikken over de juiste geheime sleutel. Het is dan ook een basisbouwsteen bij het beschermen van gegevens. Toch heeft het een nadeel. Vercijferde data behoudt namelijk niet de structuur van de oorspronkelijke data. Het rijksregisternummer ‘84.04.21-154.44’ vercijferen zal met AES resulteren in iets dat niet te onderscheiden is van, typisch 32 of 64, willekeurige gekozen bytes en ziet er dus (hexadecimaal) uit als ‘3b 03 fc 37 5f 3e ea 2c 64 92 8b 3c 43 e0 33 b8 08 2b fa b8 9d f1 28 1e d5 a6 76 73 4e 74 2e a7’. Dit kan erg vervelend zijn. Indien een overheidsinstelling namelijk zou beslissen om voortaan rijksregisternummers enkel geëncrypteerd op te slaan, moet ze dus van elke database de structuur aanpassen. Format-preserving encryption onderscheidt zich van klassieke symmetrische encryptie doordat het die structuur bewaart. Het vercijferen van het rijksregisternummer van daarnet zal dus resulteren in iets dat er opnieuw uitziet als een rijksregisternummer. De database structuur hoeft dus niet aangepast te worden. Eigenlijk maakt het voor de database niet uit of de rijksregisternummers wel of niet geëncrypteerd zijn. FPE kan hier dus gezien worden als schil rond de database die de gevolgen bij een data breach sterk beperkt. Er kan voor geopteerd worden bepaalde informatie in het rijksregisternummer ongewijzigd te laten. Zo zou het rijksregisternummer van een vrouw er geëncrypteerd nog steeds uit kunnen zien als een rijksregisternummer van een vrouw, wat op het moment van publicatie van deze blogpost nog steeds wil zeggen dat het negende decimale cijfer even blijft.

Ringhandtekeningen

Stel dat een ethisch bestuurslid, genaamd Aristoteles, in een onethisch geworden bedrijf, genaamd Evil Corp, confidentiële informatie aan de pers wil lekken, maar toch wil kunnen aantonen dat de informatie wel degelijk afkomstig is van één van de bestuursleden, zonder uiteraard zijn naam prijs te geven. Een klassieke elektronische handtekening, waarbij Aristoteles ondertekent met zijn private sleutel en de pers de handtekening verifieert met de overeenkomstige publieke sleutel, volstaat hier niet, gezien dit Aristoteles zou identificeren. Aristoteles genereert in de plaats daarvan dus een ringhandtekening in naam van het bestuur. De pers – of eigenlijk om het even wie die de handtekening verifieert – komt daarbij enkel te weten dat iemand uit het bestuur de gelekte data ondertekend heeft, maar kan onmogelijk aan de hand van de handtekening achterhalen wie. Om zo’n handtekening te creëren gebruikt Aristoteles zijn eigen private sleutel en de publieke sleutels van de andere bestuursleden. Om de handtekening te verifiëren zijn de publieke sleutels vereist van alle bestuursleden. Niemand kan uit de (ring)handtekening achterhalen dat Aristoteles achter het lek zat, maar de verifieerder weet wel dat het een bestuurslid was.

Homomorphic encryption

Kunnen we een externe partij, zoals een cloud aanbieder, operaties laten uitvoeren op gegevens zonder dat die externe partij toegang krijgt tot die gegevens zelf? Dit lijkt misschien onmogelijk, maar is het niet dankzij homomorfe encryptie. Laat ons even kijken naar één specifieke operatie, namelijk de optelling. Homomorfe encryptie laat, ietwat vereenvoudigd, toe dat de optelling van twee vercijferde waardes resulteert in de vercijfering van de optelling van die twee waardes: encryptie(10) + encryptie(5) = encryptie(15). De externe partij die deze operatie uitvoert komt noch de twee invoerwaardes noch de uitvoerwaarde te weten. Deze informatie komt enkel de entiteit te weten die beschikt over de decryptiesleutel. Die waardes kunnen natuurlijk ook gevoelige persoonsgegevens zijn en de berekeningen kunnen veel complexer zijn. Zo zou met homomorfe encryptie berekend kunnen worden op hoeveel pensioen u recht heeft en of u een erfelijke aandoening heeft. Dit alles zonder dat de externe partij die dit berekent ook maar iets te weten komt over u. Uw privacy wordt aldus veel beter beschermd.

Er wordt een onderscheid gemaakt tussen partiële homomorfe encryptie en volledige homomorfe encryptie. De eerste is maar homomorf over één operatie (vb. de optelling), terwijl de laatste elke mogelijke operatie ondersteunt. Volledige homomorfe encryptie lijkt dus aangewezen, ware het niet dat ze heel wat rekenkracht vereist. Daardoor is ze in de praktijk in vele gevallen vandaag nog onbruikbaar. Het is voorlopig wachten op nieuwe doorbraken in dit veelbelovende domein. Partiële homomorfe encryptie is nuttig, maar dan eerder indirect, namelijk voor het bouwen van cryptografische protocollen en algoritmes die dan op hun beurt weer een businessbehoefte afdekken.

Conclusie

Zoals bovenstaande voorbeelden aantonen, laat cryptografie zaken toe die voor velen op het eerste zicht intuïtief onmogelijk kunnen lijken. Daardoor worden haar krachtige mogelijkheden helaas al te vaak zelfs niet eens in overweging genomen. Het doel van deze en andere blogposts (hier en hier) rond cryptografie is dan ook om een zeker bewustzijn te creëren rond het potentieel van geavanceerde cryptografische tools.

Toch zitten er mogelijks addertjes onder het gras. Ten eerste kan sleutelbeheer lastig worden. Ten tweede vereisen cryptografische protocols meer resources (zoals rekenkracht en bandbreedte), wat dus de efficiëntie aantast. Ten derde kan cryptografie, doordat het soms weinig intuïtief is, met argwaan bekeken worden. Hoewel het een rigoureuze wetenschap is, lijkt het door zijn complexiteit – geheel ten onrechte – voor sommigen wat op zwarte magie waar je beter niet op vertrouwt.

Het zou het jammer zijn ons daardoor al bij voorbaat te laten afschrikken. Niet zelden zijn verbazend elegante oplossingen mogelijk dankzij cryptografie en worden zelfs nieuwe mogelijkheden gecreëerd. Momenteel werkt Smals Research in samenwerking met anderen binnen de sector aan een aantal innovatieve toepassingen waar we te gepasten tijde over zullen communiceren.

Ziet u ondertussen zelf mogelijke toepassingen van cryptografie dan horen of lezen we dit graag en bekijken we samen met u en uw organisatie de mogelijkheden.

Noteer alvast in uw agenda 28 november 2019 of 5 december, telkens vanaf 13:30 voor onze infosessie die uitgebreider ingaat op de mogelijkheden van geavanceerde cryptografie ter bescherming van persoonsgegevens. 

______________________

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

Het spanningsveld

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

In een traditionele benadering vraagt justitie aan een organisatie om gegevens x, y en z over een specifieke burger aan te leveren. Er zijn echter twee bezwaren tegen een dergelijk naïeve benadering. Ten eerste is de privacy van de burger geschaad. Elke organisatie die informatie over hem of haar moet aanleveren komt immers te weten dat er een onderzoek loopt naar deze persoon. Dit kan risico’s inhouden. Een tweede bezwaar dat daaruit voortvloeit is dat dit de confidentialiteit van het onderzoek kan schaden. Er zijn dus goede redenen voor een andere benadering.

Deze zou eruit kunnen bestaan dat justitie gegevens x, y en z vraagt, niet enkel over Kristof Verslype, maar over alle burgers geboren in 1982, of nog extremer, over alle burgers tout court. De geconsulteerde organisaties zullen op die manier inderdaad de identiteit van de betrokkene niet te weten komen, maar anderzijds is er wel mogelijks sprake van een disproportionele verwerking van persoonsgegevens door justitie en moeten we justitie vertrouwen dat het de nodige procedures in acht neemt om alle records, behalve het relevante, onmiddellijk na ontvangst te verwijderen.

Er is dus een spanningsveld tussen enerzijds de privacy van de burger en de confidentialiteit van het onderzoek ten aanzien van de geconsulteerde organisaties en anderzijds de proportionele verwerking van persoonsgegevens door justitie. Dit spanningsveld lijkt op het eerste gezicht niet op te lossen.

Wat is Oblivious Transfer (OT)?

Gelukkig biedt cryptografie een krachtig hulpmiddel genaamd oblivious transfer (OT), of, vrij vertaald, vergeetachtige verzending. Het laat toe dat een ontvanger (zoals justitie) toegang krijgt tot een zelf gekozen record uit een set van records die door de verzender (zoals de telecomoperator) gekend zijn. De ontvanger krijgt slechts toegang tot dit ene record. De zender weet niet hetwelke. De zender komt enkel te weten dat de ontvanger toegang gekregen heeft tot één record uit de vooraf bepaalde set.

Oblivious transfer werd voor het eerst – in een wat zwakkere vorm – beschreven in 1981 en er is sindsdien veel onderzoek naar gebeurd in de academische wereld. Ondertussen is het – volgens de inschatting van de auteur – voldoende rijp om ook in overheidscontext gebruikt te worden. Het bestaat in verschillende varianten, waaronder 1 uit 2 oblivious transfer, 1 uit n oblivious transfer en k uit n oblivious transfer.  In de eerste variant krijgt de ontvanger toegang tot één uit een set van twee records. In de tweede en derde categorie krijgt de ontvanger toegang tot respectievelijk 1 en k records uit een set van n records. Het idee is vrij eenvoudig; de zender vercijfert alle records in de set, verstuurt alle vercijferde records naar de ontvanger, waarbij het oblivious transfer protocol cryptografisch (wiskundig) afdwingt dat de ontvanger er maar 1 (of k) kan decrypteren.

Eerste resultaten

Smals Research heeft op basis van twee academische papers (deze en deze) een eigen 1 uit n oblvious transfer Java library geschreven, gezien er voor zover wij weten nog geen dergelijke library publiek beschikbaar is. Vervolgens hebben we de performantie getest op een standaard laptop (Lenovo Thinkpad L570, Win 10, Intel Core i5-6300 CPU @ 2,40Ghz, 16GB), waarbij de gegevens zich reeds in het intern geheugen bevinden en er 256 bit security gegarandeerd wordt.  De rekentijd bij records van ongeveer 20 en 100KB en bij setgroottes van 1000, 10 000 en 25 000 wordt weergegeven in onderstaande tabel. Bemerk dat er wellicht nog ruimte is voor efficiëntiewinsten.

Indien een ontvanger toegang wil tot één record uit een set van 1000, waarbij het gemiddelde record 20KB groot is, zal er logischerwijs 20MB verstuurd moeten worden per query. Daarnaast zal de zender zo’n 0,7 seconden rekenwerk hebben, voornamelijk om alle data te vercijferen, terwijl de ontvanger 0,15 seconden zal moeten rekenen. 

Stel dat een organisatie over elke Belg een record heeft, dan betekent dit dat er ongeveer 11 350 000 records zijn. Uit bovenstaande blijkt dat een setgrootte van een paar miljoen toch niet haalbaar is. Idealiter delen we de bevolking dus op in verschillende sets die allen ongeveer even groot zijn. Deze opdeling kan in principe vrij eenvoudig door bijvoorbeeld alle rijksregisternummers met dezelfde minst beduidende decimalen (of bits) samen te nemen. 

Indien justitie informatie nodig heeft over de burger met rijksregisternummer 83.03.20-999.68, dan kan het bijvoorbeeld aan een aanleverende organisatie exact één record vragen uit de set van alle records waarvan het rijksregisternummer eindigt op ‘968’. Die set zal bestaan uit naar schatting 11 000 à 12 000 records. De aanleverende organisatie komt enkel te weten dat justitie toegang krijgt tot exact één record uit deze set.

Alternatief scenario voor grote sets

Een alternatieve aanpak voor grote datatsets is geïllustreerd in vier stappen in onderstaande figuur. De zender vercijfert op voorhand alle records, elk met een aparte, slechts door de zender gekende, symmetrische sleutel (stap 1). Dit kan erg efficiënt. Alle 11 350 000 vercijferde records
(alsook eventueel latere updates) worden vervolgens naar de ontvanger gestuurd (stap 2). De ontvanger beschikt zo over een volledige, weliswaar vercijferde, kopie van de gegevensset. Om toegang te krijgen tot een specifiek record wordt het oblivious transfer protocol uitgevoerd, niet zoals daarnet op de records zelf, maar op de bijhorende symmetrische sleutels (stap 3). Eén zo’n sleutel is (typisch) slechts 32 bytes groot, wat maar een fractie is van de grootte van de records zelf. Daardoor wordt het mogelijk een setgrootte van 11 350 000 te nemen bij het uitvoeren van het oblivious transfer protocol. De ontvanger krijgt zo toegang tot één van de 11 350 000 sleutels, waarmee vervolgens exact één record gedecrypteerd kan worden (stap 4). Bij een dergelijke uitvoering van het oblivious transfer protocol wordt zo’n 363MB, voornamelijk vercijferde sleutels, doorgestuurd, moet de zender een kleine 80 seconden rekenen, en de ontvanger 0,24 seconden (met onze eerder vermelde Lenovo L570).

De testresultaten van beide geschetste scenario’s geven in elk geval aan dat het gebruik van oblivious transfer haalbaar is in de geschetste context, dus voor het opvragen van gegevens over burgers in het kader van een onderzoek.

Kwantumresistente Oblivious Transfer

Toch is het niet onbelangrijk te vermelden dat onze implementatie steunt op, net zoals quasi alle publieke sleutelcryptografie vandaag, assumpties uit de klassieke cryptografie. Dergelijke assumpties zullen niet langer geldig zijn eens er voldoende sterke quantumcomputers beschikbaar zijn. Bijgevolg kan vanaf dan ook het geïmplementeerde OT protocol niet langer als veilig beschouwd worden. Wetenschappers werken ondertussen gelukkig wel aan kwantumresistente OT (QOT) protocollen (zoals vb. dit werk), die helaas ook wel beduidend minder efficiënt zijn. Schattingen wanneer een dergelijke kwantumcomputer gerealiseerd zal worden lopen uiteen van 10 tot 50 jaar, wat dus toch niet genegeerd kan worden bij het verwerken van gevoelige persoonsgegevens. Vandaar dat het toch noodzakelijk blijft dat de ontvanger de vercijferde records ook verwijderd en niet een aantal decennia bewaart. Dit zou gecontroleerd kunnen worden door een toezichthoudende autoriteit. QOT is dus op termijn een elegantere en robuustere oplossing die bij voldoende interesse vanuit onze klanten dan ook door Smals Research onderzocht zal worden.

Andere toepassingsmogelijkheden en conclusies

Ten slotte geven we nog mee dat OT een bouwblok is in diverse andere cryptografische protocollen, onder meer voor het simultaan ondertekenen van contracten over het internet (zie vb. dit werk), waarbij ofwel alle betrokkenen hun akkoord geven ofwel geen enkele. OT is eveneens een bouwblok voor multi-party computation (MPC), waarbij zonder centrale vertrouwde partij berekeningen gedaan worden op invoer afkomstig van verschillende deelnemers. De invoer van de verschillende deelnemers blijft geheim, maar iedereen leert wel de uitvoer.  Een groep individuen kan met behulp van MPC bijvoorbeeld het gemiddeld loon van de individuen berekenen terwijl elk van hen hun exacte loon verborgen kan houden.

Concluderend kunnen we stellen dat oblivious transfer zeer nuttige toepassingen heeft en dat het in de praktijk inzetbaar is. Het integreren van OT in bestaande toepassingen is trouwens een voorbeeld van het in de GDPR gepromootte principe van privacy by design. Ten slotte, wat voor alle publieke-sleutel cryptografie geldt, geldt ook voor oblivious transfer: als er ooit een kwantumcomputer komt, dan zijn we beter voorbereid.

Aarzel niet ons te contacteren om mogelijke toepassingen binnen de context van de overheid in België met ons 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.

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.