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.

Intro

Les citoyens possèdent généralement de nombreux certificats : carte d’identité, permis de conduire, diplômes, certificats d’aptitudes pédagogiques, cartes bancaires, carte d’assurance maladie, prescriptions médicales, extrait de casier judiciaire, carte de stationnement pour personnes handicapées, titres de propriété, billets de concert… Ces documents peuvent être physiques ou numériques et contiennent des données personnelles souvent sensibles.

Lorsque vous présentez un tel certificat, vous divulguez souvent plus d’informations à propos de vous que celles strictement nécessaires. Or, cela peut poser problème, notamment dans un monde numérique. Les données sont lues en une fraction de seconde et peuvent ensuite être conservées pendant de nombreuses années, ce qui permet de dresser votre profil de manière plus complète.

Voici deux exemples :

• Pour acheter de l’alcool ou des feux d’artifice, ou pour accéder à des sites web à contenu érotique, il suffit en principe de prouver que l’on est majeur. Pour participer à des jeux de hasard ou à des paris, l’âge minimal est de 21 ans. La date de naissance exacte, sans parler du lieu de naissance ou du numéro de registre national, n’ont pas d’importance. Ce n’est qu’en cas d’abus, tel que la tricherie, que l’identité de la personne concernée doit pouvoir être révélée.
• Pour participer à un sondage organisé par la ville de Louvain, il suffit en principe de prouver que l’on réside effectivement dans cette ville et que l’on n’a pas encore participé, éventuellement en communiquant des informations supplémentaires telles que la tranche d’âge et la commune, à des fins statistiques.

Les technologies de certification couramment utilisées aujourd’hui ne permettent pas une divulgation sélective des données personnelles ; soit vous montrez le certificat complet avec toutes les données personnelles qu’il contient, soit vous ne montrez rien. Au cours des dernières décennies toutefois, de nombreux travaux de recherche et de développement ont été menés pour mettre au point une technologie capable de remédier à cela facilement. Cette technologie, appelée “titres numériques anonymes”, a déjà été abordée dans un précédent article de blog.

Il s’agit d’une technologie favorisant la confidentialité qui recourt aux preuves à divulgation nulle de connaissance (zero-knowledge (ZK) proof) pour divulguer de manière sélective des informations personnelles. Les preuves ZK permettent à une partie de prouver une affirmation (par exemple, être âgé de plus de 18 ans) à une autre partie sans divulguer plus de détails sur cette affirmation (par exemple, la date de naissance exacte). Bien que le titre numérique lui-même soit délivré par un émetteur autorisé, la divulgation sélective ne nécessite plus le recours à un tiers de confiance.

David Chaum a réalisé en 1985 les premiers travaux novateurs et révolutionnaires en proposant une monnaie numérique anonyme. Chaum mettait déjà en garde à l’époque contre l’impact des évolutions technologiques sur la vie privée des citoyens. Sur cette base, les deux premières propositions de titres numériques anonymes ont suivi rapidement. En 2000, Stefan Brands a publié sa solution U-Prove, et en 2001, Jan Camenisch (IBM) et Anna Lysyanskaya (MIT) ont proposé Idemix, une solution plus avancée.

Au cours de ces années, j’ai manié cette technologie dans le cadre de mon doctorat, ce qui m’a valu, entre autres, un best paper award à SECRYPT 2009 à Milan, avec une solution permettant aux détenteurs de titres numériques d’utiliser un service de manière anonyme, mais pas plus d’un nombre déterminé de fois par période, par exemple pas plus de 10 fois par mois.

Caractéristiques

Tout comme pour les certificats numériques classiques, un titre numérique anonyme est délivré par un émetteur autorisé (issuer ou identity provider) au détenteur (holder).
Au moyen de preuves ZK, ce dernier peut ensuite prouver de manière sélective des informations issues du titre numérique à un vérificateur (verifier).

Les caractéristiques de base des titres numériques anonymes sont les suivantes :

• Infalsifiabilité (Unforgeability). Il est impossible de falsifier un titre numérique anonyme. Seul l’émetteur peut créer des titres numériques anonymes.
• Divulgation sélective d’attributs (selective attribute disclosure). Seule une partie sélectionnée des informations contenues dans le titre numérique anonyme est divulguée. Il peut s’agir de valeurs d’attributs, telles que la date de naissance, mais aussi d’informations dérivées, telles que la majorité. Toutes les autres informations contenues dans le titre numérique restent cachées au vérificateur. Idemix et U-Prove prennent tous deux en charge cette fonctionnalité.
• Non-corrélabilité (Unlinkability). Des présentations multiples d’un même titre numérique anonyme à un vérificateur (identique ou différent) ne peuvent pas être reliées entre elles. U-Prove ne disposait pas encore de cette fonctionnalité, contrairement à Idemix.

En fonction de la technologie spécifique, des fonctionnalités supplémentaires peuvent être prises en charge, notamment :

• Durée de validité limitée. Le détenteur prouve au vérificateur que la date d’expiration du titre numérique anonyme n’est pas encore atteinte, sans divulguer d’autres informations sur cette date d’expiration.
• Révocation. Un titre numérique anonyme peut être révoqué, par exemple après que la clé privée correspondante a été compromise ou parce que les données personnelles ont été modifiées, par exemple en cas de déménagement ou de retrait du permis de conduire. Chaque fois qu’un détenteur présente un titre numérique à un vérificateur, il prouve également que l’identifiant du titre numérique figure sur une liste blanche ou qu’il ne figure pas sur une liste noire. Ces listes peuvent être compressées en une seule valeur compacte, laquelle est actualisée à chaque nouvelle révocation. C’est ce que l’on appelle un accumulateur dynamique.
• Anonymat conditionnel. En cas d’abus, l’anonymat du détenteur du titre numérique peut être levé, avec la coopération d’un tiers de confiance, et son identité est alors révélée. La justice peut ainsi faire son travail et éventuellement engager des poursuites.
• Délégation. Un détenteur de titres numériques peut déléguer des titres numériques anonymes. Une personne pourrait ainsi déléguer son droit (ou son obligation) de vote à son partenaire, ce qui équivaut alors à une procuration. Pour des raisons juridiques, la délégation ne sera généralement possible que pour des individus ayant une capacité juridique et donc pas pour des mineurs, par exemple.
• Combinabilité. Une divulgation sélective peut être dérivée de plusieurs titres numériques anonymes, potentiellement émis par différents émetteurs. Par exemple, un détenteur de titres numériques peut prouver avec une seule preuve ZK qu’il est titulaire d’un permis de conduire valide et qu’il est assuré, sans pour autant divulguer d’identifiant commun, tel que son numéro de registre national. Il prouve simplement que les deux titres numériques anonymes contiennent le même identifiant, comme illustré dans un précédent article.

Il est évident que les titres numériques anonymes constituent une technologie particulièrement puissante et recèlent un potentiel considérable. Malheureusement, cela ne signifie pas nécessairement qu’ils sont adoptés à grande échelle. Les sections suivantes traitent 1) des initiatives destinées à parfaire cette technologie et à la faire adopter, 2) de son utilisation dans la pratique et 3) des défis liés à la résistance à l’informatique quantique.

Initiatives

Lorsque j’ai commencé à travailler avec Idemix il y a environ vingt ans, la signature d’un accord de confidentialité était indispensable. Depuis, la situation s’est complètement inversée et il existe désormais divers projets open source. Les principaux sont IBM Idemix, Microsoft U-prove, Yivi et Hyperledger AnonCreds. Ces deux derniers proposent actuellement leurs propres implémentations d’Idemix.

La Commission européenne a déjà investi des dizaines de millions d’euros dans la recherche et le développement de technologies de titres numériques anonymes à travers des projets tels que PRIME (2004-2008), PrimeLife (2008-2011) et ABC4Trust (2011-2014).

Le battage médiatique autour de la blockchain (entre 2015 et 2019 environ) s’est accompagné d’un regain d’intérêt pour les titres numériques anonymes, en tant que concrétisation technologique du paradigme de l’identitié auto-souveraine (Self-sovereign identity – SSI). La blockchain et les titres numériques anonymes promettaient en effet quelque chose de très similaire : redonner le contrôle aux citoyens, en le retirant des mains des autorités et des intermédiaires. Beaucoup ont alors supposé à tort que la SSI nécessitait la blockchain. Ce n’est pas nécessairement le cas, mais la blockchain peut néanmoins jouer un rôle, notamment pour répertorier de manière distribuée les émetteurs reconnus et donc dignes de confiance.

Hyperledger est un projet open source sous l’égide de la Linux Foundation destiné à développer une technologie pour les réseaux blockchain autorisés (fermés et contrôlés). Hyperledger a adopté le paradigme SSI ; Hyperledger AnonCreds, actuellement un projet en incubation, met spécifiquement en œuvre une technologie de titres numériques anonymes.

Sovrin était le pionnier le plus influent dans le domaine de la SSI utilisant la blockchain et recourrait notamment à Hyperledger AnonCreds comme base. Malheureusement, le réseau Sovrin est passé à la trappe au début de cette année. Les raisons invoquées étaient une baisse de l’utilisation, une incertitude législative, des défis techniques et un engagement limité de la part de la communauté.

Le portefeuille d’identité numérique de l’UE (EU digital identity wallet ou EUDIW en anglais), défini dans la réglementation eiDAS 2.0 (en vigueur depuis mai 2024), offre en principe une nouvelle occasion d’exploiter le potentiel des titres numériques anonymes (avec ou sans blockchain). Malheureusement, il semble que l’on ne s’oriente pas dans cette direction. En juin 2024, un groupe de cryptographes éminents a formulé  des critiques à l’égard de la conception actuelle de l’EUDIW et estime qu’une nouvelle conception, avec un soutien explicite aux titres numériques anonymes, s’impose pour améliorer la confidentialité. La conception actuelle de l’EUDIW n’autorise par exemple pas la non-corrélabilité. L’intégration de titres numériques anonymes est l’un des “sujets en suspens”, mais aucun plan d’action n’a encore été établi à ce jour.

Depuis 2012, un projet appelé IRMA, qui signifie “I Reveal My Attributes” est en cours aux Pays-Bas. Il a été développé à l’université Radboud de Nimègue. En 2023, il a été rebaptisé Yivi. Yivi entend redonner aux citoyens le contrôle de leurs données, sans recourir à la technologie blockchain. 

Dans la pratique

Yivi dispose notamment de sa propre implémentation du protocole Idemix ainsi que de sa propre app, qui serait utilisée par des centaines de milliers de Néerlandais. Elle est proposée par la ville de Nimègue comme solution d’identité respectueuse de la vie privée. La ville l’utilise notamment pour mener des enquêtes anonymes auprès de ses habitants.

Parallèlement, les compagnies d’assurances soutiennent Yivi, étant donné que les autres solutions d’identité numérique aux Pays-Bas ne sont pas utilisables dans ce contexte ; DigiD n’est possible qu’auprès des institutions gouvernementales, iDIN passe par une banque et n’est utilisable que par les personnes titulaires d’un compte bancaire aux Pays-Bas. Les considérations pratiques semblent ici primer sur l’aspect de la vie privée.

L’administration de la province canadienne de Colombie-Britannique a investi massivement dans le développement et l’adoption de titres numériques anonymes. Elle a consacré plus d’un million de lignes de code au projet Hyperledger Aries. La Colombie-Britannique utilise également cette technologie dans la pratique, notamment avec Hyperledger AnonCreds :

• 

  OrgBook BC met à disposition de nombreuses informations sur les entreprises de la province : numéros d’entreprise, adresses, certificats d’enregistrement, licences de vente de cannabis… Afin d’accroître la confiance dans leur exactitude, ces données sont mises à disposition sous la forme de titres numériques anonymes révocables, délivrés par des organismes du secteur public. Les citoyens peuvent obtenir, stocker et présenter des titres numériques vérifiables les concernant ou concernant leur entreprise grâce à leur BC Wallet.
• Le Justice Project permet aux juges et aux avocats de consulter en ligne des documents judiciaires sensibles, auxquels seuls les juristes agréés ont accès, sans révéler leur identité.

Les applications ci-dessus se situent au niveau local. Cependant, il ne faut pas oublier que les titres numériques anonymes sont également utilisés à l’échelle mondiale.

Signal, l’application de messagerie sécurisée populaire qui compte quelque 70 millions d’utilisateurs, utilise des titres numériques anonymes pour gérer des groupes privés ; les serveurs de Signal ne voient pas quels sont les membres d’un groupe privé. Lorsqu’un membre du groupe ajoute ou supprime quelqu’un du groupe, les serveurs de Signal ne voient pas qui exécute cette action, mais seulement que cette personne en a le droit. Signal utilise pour cela des Keyed-Verification Anonymous Credentials (KVAC), i.e. des titres numériques anonymes, où l’émetteur et le vérificateur partagent une clé secrète, ce qui permet de gagner en efficacité.

Un TPM (Trusted Platform Module) est une puce de sécurité intégrée à un ordinateur. Il est notamment capable de prouver l’intégrité du système à une entité externe dans le respect de la vie privée. Pour ce faire, il utilise la technologie Direct Anonymous Attestation (DAA). Celle-ci utilise une sorte de titre numérique anonyme, lié à la puce TPM. La technologie SGX d’Intel utilise une variante de la DAA, appelée Enhanced Privacy ID (EPID). À ce jour, plus de 2,5 milliards de titres numériques EPID ont été émis. Il s’agit probablement aujourd’hui de l’application la plus réussie de la technologie des titres numériques anonymes.

Malgré ces quelques cas d’usage à l’échelle mondiale, nous ne constatons à ce jour qu’une adoption très limitée des titres numériques anonymes dans le contexte où nous les attendons le plus, à savoir la gestion des identités.

Résistance à l’informatique quantique

Comme déjà expliqué en détail dans des articles précédents de Smals Research, il existe un risque que de puissants ordinateurs quantiques puissent à l’avenir briser la cryptographie moderne à clé publique.

L’illustration ci-dessous présente les principales techniques en matière de titres numériques anonymes proposées par le monde académique. La première génération était basée sur RSA ou les courbes elliptiques. À partir de 2004, une génération basée sur les applications bilinéaires (pairings) a suivi. La troisième génération de titres numériques anonymes est basée sur les treillis et est la première génération à utiliser une cryptographie supposée résistante à l’informatique quantique.

Illustration 1 Chronologie des principales publications relatives aux titres numériques anonymes (source)

À l’heure actuelle, seuls quelques systèmes résistants à l’informatique quantique ont donc été proposés pour les titres numériques anonymes. Ces systèmes sont encore récents et leurs performances sont insuffisantes pour être utilisés dans la pratique. De plus amples recherches s’imposent donc pour trouver des solutions efficaces et résistantes à l’informatique quantique pour les titres numériques anonymes.

Nous avons mentionné plus haut qu’un groupe éminent de scientifiques spécialisés en cryptographie plaidait en faveur de la prise en charge des titres numériques anonymes dans le portefeuille d’identité numérique de l’UE (EUDIW).  Ils avancent deux arguments valables pour expliquer pourquoi la menace quantique n’est pas (encore) d’actualité.

• Les titres numériques anonymes sont utilisés pour l’authentification ; une session d’authentification n’est valable que pendant un très court laps de temps, quelques minutes tout au plus. Pensez par exemple à l’authentification avec itsme, à des années-lumière du chiffrement (par exemple, la communication), où un pirate dispose de plusieurs années pour déchiffrer les données chiffrées interceptées (harvest now decrypt later). On a ainsi beaucoup plus de temps (au moins une décennie, selon votre auteur).
• Les technologies de titres numériques anonymes les plus populaires aujourd’hui, comme celles proposées par Camenisch et Lysyanskaya en 2004, offrent une sécurité inconditionnelle ; même un pirate hypothétique disposant d’une puissance de calcul infinie (classique ou quantique) ne pourrait la briser, bien que la technologie – cela peut sembler contradictoire – utilise en coulisse des éléments constitutifs qui pourraient être brisés par de puissants ordinateurs quantiques.

Sur le plan technologique, rien n’empêche donc l’adoption de la technologie des titres numériques anonymes. Il existe toutefois un autre obstacle… la perception ! Emad Heydari Beni, chercheur en cryptographie au COSIC (KU Leuven) et chez Bell Labs, a récemment publié le message suivant sur LinkedIn : “Si ce n’est pas post-quantique, les acteurs de l’industrie ne veulent pas en entendre parler.”  La double argumentation évoquée plus haut n’est donc probablement pas suffisamment convaincante pour l’industrie.

Dans tous les cas, veillez à ce que votre solution soit crypto-agile si vous utilisez des titres numériques anonymes, afin de pouvoir migrer rapidement vers une technologie plus récente si nécessaire.

Conclusion

En résumé, après des décennies de recherche et de développement, et malgré leur nombreux avantages, les titres numériques anonymes ne sont encore que peu utilisés dans la pratique pour réellement protéger les données à caractère personnel. Leur potentiel est loin d’être pleinement exploité, même si des projets tels que Hyperledger leur donnent une impulsion positive. Grâce notamment à Signal et Intel SGX, certains types de titres numériques anonymes sont toutefois largement adoptés.

L’absence de normes constitue un obstacle à leur adoption dans le contexte de la gestion des identités. Grâce au travail préparatoire réalisé notamment par le W3C, la Decentralized Identity Foundation, l’IETF/IRTF et l’ISO, cela devrait être possible assez rapidement, à condition qu’il y ait une volonté politique, selon le groupe de cryptographes mentionné précédemment. La technologie doit toutefois relever un autre défi, à savoir devenir résistante à l’informatique quantique.

Il est donc encore trop tôt pour dire si cette technologie va s’imposer comme un outil de gestion des identités respectueux de la vie privée. Peut-être est-ce au secteur public de prendre l’initiative et de faire des titres numériques anonymes un succès.

N’hésitez pas à nous contacter si vous êtes intéressé !

Intro

Burgers hebben doorgaans heel wat certificaten. Voorbeelden zijn de identiteitskaart, rijbewijs, diploma’s, bekwaamheidsbewijzen, bankkaarten, de ziekteverzekeringskaart, medische voorschriften, een uittreksel uit het strafregister, een parkeerkaart voor personen met een handicap, eigendomsaktes en concerttickets. Deze kunnen een fysieke of digitale vorm aannemen en bevatten – vaak gevoelige – persoonsgegevens.

Wanneer we een dergelijk certificaat tonen, geven we vaak meer gegevens over onszelf prijs dan strikt noodzakelijk. Vooral in een digitale wereld kan dit problematisch worden. De data worden in een fractie van een seconde uitgelezen en vervolgens misschien vele jaren bewaard, waarbij mogelijk een ruimer profiel over jou aangelegd wordt.

Een tweetal voorbeelden:

• Om alcohol of vuurwerk te kopen, of om toegang te krijgen tot websites met erotische inhoud, moet je in principe enkel aantonen dat je meerderjarig bent. Om deel te nemen aan kansspelen of weddenschappen is de minimumleeftijd 21 jaar. De exacte geboortedatum, laat staan de geboorteplaats of rijksregisternummer, doen er niet toe. Enkel in geval van misbruik, zoals valsspelen, moet de identiteit van de persoon in kwestie onthuld kunnen worden.
• Om deel te nemen aan een bevraging georganiseerd door de stad Leuven, moet je in principe enkel aantonen dat je effectief in die stad woont, en nog niet eerder gestemd hebt, eventueel aangevuld met extra info zoals leeftijdscategorie en deelgemeente, voor statistische doeleinden.

De vandaag gangbare certificaattechnologieën laten een dergelijke selectieve prijsgave van persoonsgegevens niet toe; je toont ofwel het volledige certificaat met al de persoonsgegevens die erin vervat zitten, ofwel niets. Toch is er in de laatste decennia al heel wat onderzoek en ontwikkeling gebeurd naar een technologie die daar wel vlot mee overweg kan. Die technologie luistert naar de naam anonieme credentials en kwam reeds in een vorige blogpost aan bod.

Het is een privacy bevorderende technologie die beroep doet op zero-knowledge proofs (ZKPs) om selectief persoonsinformatie prijs te geven. ZKPs laten een partij toe een bewering (vb. ouder dan 18 jaar) aan een andere partij te bewijzen zonder verdere details over die bewering (vb. exacte geboortedatum) prijs te geven. Hoewel de credential zelf wordt uitgegeven door een geautoriseerde uitgever, hoeft bij een selectieve prijsgave verder geen beroep meer gedaan te worden op een vertrouwde partij.

David Chaum deed reed in 1985 het eerste baanbrekend en visionair werk met een voorstel voor anoniem digitaal geld. Chaum waarschuwde toen reeds voor het effect van de technologische ontwikkelingen op de privacy van burgers. Daarop verder bouwend volgden kort op elkaar de twee eerste voorstellen voor anonieme credentials. In 2000 publiceerde Stefan Brands zijn oplossing U-Prove, en in 2001 werd het geavanceerdere Idemix voorgesteld door Jan Camenisch (IBM) en Anna Lysyanskaya (MIT).

In die jaren werkte ik tijdens mijn doctoraat met die technologie, wat me onder meer een best paper award opleverde op SECRYPT 2009 in Milaan, met een oplossing die credential houders toelaat anoniem van een dienst gebruik te maken, maar niet vaker dan een vast aantal keer per tijdsvenster, bijvoorbeeld niet vaker dan 10 keer per maand.

Eigenschappen

Net zoals bij klassieke digitale certificaten, wordt een anoniem credential uitgegeven door een geautoriseerde uitgever (de issuer of identity provider) aan de eigenaar (de holder). De laatste kan vervolgens, m.b.v. ZKPs selectief informatie uit de credential bewijzen aan een verifier.

De basiseigenschappen van anonieme credentials zijn:

• Onvervalsbaarheid (Unforgeability). Het vervalsen van een anonieme credential is onmogelijk. Enkel met behulp van de issuer kunnen anonieme credentials aangemaakt worden.
• Selectieve attribuutprijsgave (selective attribute disclosure). Slechts een geselecteerd deel van de informatie die in het anonieme credential vervat zit, wordt prijsgegeven. Dit kunnen attribuutwaarden zijn, zoals geboortedatum, maar ook afgeleide informatie, zoals meerderjarigheid. Alle andere informatie in de credential blijft verborgen voor de verifier. Zowel Idemix als U-Prove ondersteunen dit.
• Onlinkbaarheid (Unlinkability). Meerdere vertoningen van eenzelfde anonieme credential aan (eenzelfde of andere) verifier kunnen niet aan elkaar gekoppeld worden. U-Prove had deze eigenschap nog niet, Idemix wel.

Afhankelijk van de specifieke technologie kunnen bijkomende eigenschappen ondersteund worden, waaronder:

• Beperkte geldigheidsduur. De holder bewijst aan de verifier dat de vervaldatum van de anonieme credential nog niet bereikt is, zonder verdere info over die vervaldatum prijs te geven.
• Revocatie. Een anoniem credential kan gerevoceerd worden, bijvoorbeeld nadat de bijhorende private sleutel gecompromitteerd werd of omdat de persoonsgegevens gewijzigd zijn, bijvoorbeeld door een verhuis of intrekken rijbewijs. Telkens wanneer een holder een credential toont aan een verifier, bewijst hij ook dat de identifier van de credential zich op een whitelist bevindt of dat deze identifier zich niet op een blacklist bevindt. Die lijsten kunnen gecomprimeerd worden tot één compacte waarde, die geactualiseerd wordt bij elke nieuwe revocatie. Dit noemt met een dynamische accumulator.
• Conditionele anonimiteit. In geval van misbruik kan de anonimiteit van de credential holder, met medewerking van een vertrouwde partij, opgeheven worden en wordt de identiteit dus onthuld. Op die manier kan het gerecht zijn werk doen en eventueel tot vervolging overgaan.
• Delegatie. Een credential holder kan anonieme credentials delegeren naar andere personen. Een persoon zou zo bijvoorbeeld haar recht (of plicht) om te stemmen kunnen delegeren naar haar partner. Dit is dan het equivalent van een volmacht. Delegatie zal omwille van juridische redenen veelal enkel door handelingsbekwame personen uitgevoerd kunnen worden, en dus niet door vb. minderjarigen.
• Combineerbaarheid. Een selectieve prijsgave kan afgeleid worden uit meerdere anonieme credentials, potentieel uitgegeven door verschillende issuers. Een credential holder kan bijvoorbeeld met één enkel ZKP bewijzen dat hij over een geldig rijbewijs beschikt en verzekerd is, zonder daarbij een gemeenschappelijke identifier, zoals rijksregisternummer, prijs te gegeven. Hij bewijst enkel dat beide anonieme credentials dezelfde identifier bevatten, zoals ook geïllustreerd in een eerder artikel.

Het is duidelijk dat anonieme credentials een bijzonder krachtige technologie zijn en heel wat potentieel hebben. Dit betekent helaas niet per se dat er ook brede adoptie is. De volgende secties bespreken 1) de initiatieven om de technologie verder te ontwikkelen en ingang te doen vinden, 2) het gebruik ervan in de praktijk en 3) de uitdagingen m.b.t. kwantumresistentie.

Initiatieven

Toen ik ongeveer twintig jaar geleden met Idemix aan de slag ging, kon dit enkel mits het ondertekenen van een geheimhoudingsverklaring. Ondertussen is de situatie helemaal omgekeerd en zijn er diverse open source projecten. De voornaamste zijn IBM Idemix, Microsoft U-prove, Yivi en Hyperledger AnonCreds. Die twee laatsten bieden momenteel eigen implementaties van Idemix aan.

Vanuit de Europese Commissie werden via projecten zoals PRIME (2004-2008), PrimeLife (2008-2011) en ABC4Trust (2011-2014) reeds tientallen miljoenen euro’s geïnvesteerd in onderzoek en ontwikkeling naar anonieme credential technologie.

De blockchain hype (ruwweg 2015-2019) ging gepaard met een hernieuwde interesse in anonieme credentials, als technologische invulling van het Self-sovereign identity (SSI) paradigma. Blockchain en anonieme credentials beloofden immers iets zeer gelijkaardig; de controle teruggeven aan de burger, uit de handen van de allerlei autoriteiten en men-in-the-middle. Velen gingen er toen onterecht vanuit dat SSI blockchain vereist. Dat is niet noodzakelijk, maar toch kan blockchain een rol spelen, onder meer om op een gedistribueerde wijze bij te houden welke issuers erkend zijn, en dus vertrouwd kunnen worden.

Hyperledger is een open-source project onder de vleugels van de Linux Foundation dat bouwt aan technologie voor permissioned (gesloten, gecontroleerde) blockchain netwerken. Hyperledger omarmde het SSI-paradigma; Hyperledger AnonCreds, momenteel een incubatieproject, implementeert specifiek anonieme credential technologie.

Sovrin was de meest toonaangevende pionier in SSI m.b.v. blockchain en gebruikte onderliggend onder meer Hyperledger AnonCreds. Helaas werd het Sovrin netwerk begin dit jaar uitgedoofd. De redenen die gegeven werden waren een dalend gebruik, wetgevende onzekerheid, technische uitdagingen en beperkte betrokkenheid vanuit de community.

De EU digital identity wallet (EUDIW), gedefinieerd in de eiDAS 2.0 regulering (van kracht sinds mei 2024), biedt in principe opnieuw een kans om het potentieel van anonieme credentials te ontsluiten (met of zonder blockchain). Toch lijkt men helaas niet in die richting te kijken.  Een groep van vooraanstaande cryptografen formuleerde in juni 2024 kritieken op het huidige ontwerp van de EUDIW en menen dat een nieuw design, met expliciete ondersteuning voor anonieme credentials, nodig is om de privacy te verbeteren. Het huidige EUDIW-ontwerp laat bijvoorbeeld geen onlinkbaarheid toe. Integratie van anonieme credentials is één van de “open topics”, maar een roadmap ontbreekt vooralsnog.

Sinds 2012 loopt er in Nederland een project genaamd IRMA, wat staat voor I Reveal My Attributes. Het werd ontwikkeld aan de Radboud Universiteit in Nijmegen. In 2023 werd het omgedoopt naar Yivi. Yivi wil de controle over haar gegevens teruggeven aan de burger, zonder daarbij een beroep te doen op blockchain technologie.

In de praktijk

Yivi heeft onder meer zijn eigen implementatie van het Idemix protocol alsook een eigen app, die door honderdduizenden Nederlanders gebruikt zou worden. Het wordt aangeboden door de stad Nijmegen als privacy-vriendelijke identiteitsoplossing. De stad gebruikt het onder meer voor anonieme bevragingen van Nijmegenaren.

Daarnaast ondersteunen verzekeringsinstellingen Yivi, gezien de andere digitale  identiteitsoplossingen in Nederland in dit kader niet bruikbaar zijn; DigiD is alleen mogelijk bij overheidsinstellingen, iDIN verloopt via een bank en is enkel bruikbaar door mensen met een bankrekening in Nederland. Hier lijkt de praktische overweging belangrijker dan het privacy-aspect.

Het bestuur van de Canadese provincie British Columbia heeft stevig geïnvesteerd in de ontwikkeling en adoptie van anonieme credentials. Ze heeft meer dan een miljoen regels code gecommit naar het Hyperledger Aries project. British Columbia gebruikt de technologie, samen met onder meer Hyperledger AnonCreds ook in de praktijk:

• 

  OrgBook BC stelt heel wat informatie over bedrijven in de provincie ter beschikking: ondernemingsnummers, adressen, registratiebewijzen, licenties om cannabis te verkopen, etc. Om het vertrouwen in de juistheid ervan te verhogen, worden deze data ter beschikking gesteld onder de vorm van revoceerbare anonieme credentials, uitgegeven door publieke sectororganisaties. Burgers kunnen met hun BC Wallet verifiable credentials over henzelf of over hun onderneming verkrijgen, opslaan en tonen.
• Het Justice Project laat rechters en advocaten toe gevoelige gerechtelijke documenten, waar enkel erkende juristen toegang tot mogen hebben, online op te vragen zonder hun identiteit prijs te geven.

Bovenstaande toepassingen situeren zich op een lokaal niveau. Toch mogen we niet vergeten dat anonieme credentials ook op globale schaal toegepast worden.

Signal, de populaire beveiligde berichten app die ongeveer 70 miljoen gebruikers telt, maakt gebruik van anonieme credentials voor het beheer van private groepen. De Signal servers zien niet wie tot een private groep behoort. Wanneer een groepslid iemand aan de groep toevoegt of eruit verwijdert, zien de Signal servers niet wie dit doet, enkel dat die persoon het recht daartoe heeft. Signal gebruikt daarvoor Keyed-Verification Anonymous Credentials (KVACs), wat anonieme credentials zijn, waarbij de issuer en de verifier een geheime sleutel delen, wat leidt tot efficiëntiewinsten.

Een TPM (Trusted Platform Module) is een security chip in een computer. Het is, onder andere, in staat om op een privacyvriendelijke manier de integriteit van het system aan een externe entiteit te bewijzen. Daarvoor maakt het gebruik van Direct Anonymous Attestation (DAA). DAA gebruikt een soort anonieme credential, gekoppeld aan de TPM-chip. Intels SGX gebruikt een DAA-variant, genaamd Enhanced Privacy ID (EPID). Ondertussen werden meer dan 2,5 miljard EPID-credentials uitgegeven. Het is vandaag wellicht de meest succesvolle toepassing van anonieme credential technologie.

Ondanks deze enkele globale use cases zien we tot op vandaag slechts een zeer beperkte adoptie van anonieme credentials in de settings waar we het het meest zouden verwachten: identiteitsbeheer.

Kwantumresistentie

Zoals reeds uitvoerig in eerdere Smals Research artikels toegelicht, is er het gevaar dat krachtige kwantumcomputers in de toekomst moderne publieke sleutelcryptografie zouden kunnen breken.

De onderstaande figuur geeft een overzicht van de belangrijkste technieken voor anonieme credentials die door de academische community voorgesteld werden. De eerste generatie was gebaseerd op RSA of elliptische krommen. Vanaf 2004 volgde een generatie gebaseerd op bilineaire afbeeldingen (pairings). De derde generatie anonieme credentials is gebaseerd op lattices en is de eerste generatie die gebruik maakt van cryptografie die verondersteld is kwantumresistent te zijn.

Figuur 1 Tijdlijn van belangrijkste publicaties m.b.t. anonieme credentials (bron)

Momenteel zijn er dus slechts enkele kwantumresistente systemen voor anonieme credentials voorgesteld. Deze systemen zijn nog jong en onvoldoende performant om in de praktijk inzetbaar te zijn. Er is dus meer onderzoek vereist naar efficiënte kwantumresistente oplossingen voor anonieme credentials.

Dit artikel vermeldde reeds dat een vooraanstaande groep wetenschappers in cryptografie ervoor pleiten om ondersteuning voor anonieme credentials  in de EU digital identity wallet (EUDIW) te voorzien. Ze geven twee geldige argumenten waarom de kwantumdreiging niet of nog niet van toepassing is.

• Anonieme credentials worden gebruikt voor authenticatie; een authenticatiesessie blijft maar een zeer korte tijd geldig; niet meer dan enkele minuten. Denk bijvoorbeeld aan authenticatie met ItsMe. Dit staat in schril contrast tot encryptie (bijvoorbeeld communicatie), waarbij een aanvaller vele jaren heeft om de onderschepte vercijferde data te decrypteren (harvest now decrypt later). We kunnen voor authenticatie dus veel korter op de bal spelen en hebben dus veel meer tijd (minstens een decennium, volgens jouw schrijver).
• De vandaag meest populaire anonieme credential-technologieën, zoals diegene voorgesteld door Camenisch en Lysyanskaya in 2004 bieden onvoorwaardelijke veiligheid; zelfs een hypothetische aanvaller met oneindige (klassieke of kwantum-) rekenkracht zou ze niet kunnen breken, hoewel de technologie – dit kan contradictorisch klinken – onderliggend gebruik maakt van bouwblokken die wel met krachtige kwantumcomputers gebroken zouden kunnen worden.

Er zijn dus geen technologische redenen die de adoptie van anonieme credential-technologie in de weg staan. Wel is er nog een ander obstakel… perceptie! Emad Heydari Beni, een onderzoeker cryptografie aan COSIC (KU Leuven) en Bell Labs, postte onlangs op LinkedIn het volgende bericht: “Indien het niet postkwantum is, willen de mensen uit de industrie niet eens naar je luisteren”. Bovenstaande tweeledige argumentatie is bijgevolg wellicht onvoldoende overtuigend voor de industrie.

Zorg er in elk geval voor dat je oplossing crypto-agile is als je met anonieme credentials aan de slag gaat, zodat je snel kan migreren naar een nieuwere technologie wanneer nodig.

Conclusie

Samengevat worden anonieme credentials na decennia onderzoek en ontwikkeling en ondanks hun potentieel in de praktijk nog maar in beperkte mate gebruikt om persoonsgegevens echt te beschermen. Haar potentieel wordt nog bijlange niet ten volle benut, al geven projecten zoals Hyperledger er wel een positieve stimulans aan. Ook worden dankzij onder meer Signal en Intel SGX specifieke types anonieme credentials wel degelijk breed geadopteerd.

Een obstakel voor de adoptie in de context van identiteitsbeheer is het gebrek aan standaarden. Dankzij het voorbereidend werk door onder meer W3C, de Decentralized Identity Foundation, IETF/IRTF en ISO zou dat, mits een politieke wil, vrij vlot mogelijk moeten zijn, aldus de eerder vermeldde groep cryptografen. De technologie heeft trouwens nog een andere uitdaging op haar pad, met name overtuigend kwantumresistent worden.

Het blijft momenteel dus koffiedik kijken of de technologie zal doorbreken als tool voor privacyvriendelijk identiteitsbeheer. Misschien is het aan de publieke sector om hier het voortouw in te nemen en anonieme credentials tot een succesverhaal te maken.

Aarzel niet ons te contacteren bij interesse!

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

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

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

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

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

PETs selectieboom

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

1. Burger wil controle over prijsgave eigen persoonsgegevens bij authenticatie

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

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

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

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

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

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

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

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

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

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

4. Publieke instelling wil persoonsgegevens afkomstig van meerdere bronnen kruisen

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

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

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

5. Publieke instelling wil persoonsgegevens voor testen / software development

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

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

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

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

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

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

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

8. Publieke instelling wil berekeningen op gevoelige persoonsgegevens outsourcen

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

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

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

Conclusies

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

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

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

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

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

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