Comment les pseudonymes protègent-ils davantage les données personnelles ?

Smals a développé trois techniques permettant de protéger les données sensibles des citoyens à l’aide de pseudonymes.

Dans le secteur public, de nombreux systèmes traitent des informations sensibles sur les personnes, notamment des données médicales et sociales. Ces données sont très précieuses, y compris pour les parties malveillantes internes et externes, et doivent donc être protégées de manière adéquate.

La cybersécurité consiste en un vaste ensemble de mesures et de techniques, dont les politiques, les pare-feu, le contrôle d’accès et le cryptage. La pseudonymisation des identifiants se situe au même niveau que le cryptage : dans la couche de données qui protège directement les données elles-mêmes. Il s’agit d’une technique qui permet de ne plus traiter les données sous des identifiants tels que les numéros de registre national, mais sous des pseudonymes. Il s’agit de codes uniques qui ne peuvent être reconvertis en numéro de registre national d’origine qu’à l’aide d’une clé. En outre, ils ne peuvent être utilisés que par une application spécifique ou dans un contexte spécifique.

Smals Research a développé trois systèmes différents d’identification pseudonymisation : pseudonymisation aveugle, pseudonymisation préservant la structure et “Oblivious Join”. Ces systèmes sont également utiles pour la mise en conformité avec le GDPR. Kristof Verslype, inspirateur de ces systèmes, s’est penché sur les besoins concrets du secteur de la sécurité sociale et de la santé à cet égard lors d’un webinaire.

Le 10 octobre 2024, Smals fera une présentation à Devoxx de 9h30 à 10h20. Vous trouverez de plus amples informations à ce sujet à l’adresse suivante ici.

Pseudonymisation préservant la structure

Le développement d’un logiciel comporte plusieurs phases dans des environnements distincts : la phase de test est généralement suivie de la phase d’acceptation et, enfin, de la phase de production. Cette procédure vise à garantir que tout fonctionne parfaitement une fois l’application mise en service et qu’elle est reconduite à chaque mise à jour.

Dans la pratique, les données personnelles des citoyens sont régulièrement utilisées dans les phases de test et d’acceptation. Cette pratique n’est pas souhaitable et comporte inévitablement des risques pour la sécurité. Grâce à la pseudonymisation préservant la structure, la vie privée des citoyens est mieux protégée lors des phases de test et d’acceptation des applications existantes.

Il est courant de prendre régulièrement un instantané des données dans l’environnement de production, puis de l’importer dans l’environnement d’acceptation ou de test. Le tableau ci-dessus montre un instantané fictif contenant des données personnelles provenant de l’environnement de production. Pour améliorer la confidentialité, deux opérations sont effectuées avant l’importation dans l’environnement d’acceptation ou de test.

Une première opération, la pseudonymisation, consiste à remplacer les numéros de registre national par des pseudonymes. Ces pseudonymes ont la même structure que les numéros de registre nationaux originaux. Cette préservation de la structure est nécessaire car l’application et la base de données sous-jacente ne peuvent traiter que des données ayant la structure d’un numéro de registre national. Pour les identifiants non structurés, tels que le nom et le prénom, une permutation (dans le sens des colonnes) est effectuée, en mélangeant littéralement les noms et les prénoms. Le “mélange” est effectué localement par l’organisation, tandis qu’un service de Smals est utilisé pour la pseudonymisation.

La communication entre l’application acceptée et le monde extérieur doit rester possible. Cela se fait par l’intermédiaire d’un proxy qui, avec l’aide du service de pseudonymisation de Smals, remplace les pseudonymes dans les messages sortants par les numéros d’enregistrement gouvernementaux originaux et remplace les numéros d’enregistrement gouvernementaux dans les messages entrants par des pseudonymes.

Le service de pseudonymisation préservant la structure de Smals a été développé comme un service générique. Cela signifie qu’un grand nombre d’organisations peuvent l’utiliser, si elles le souhaitent, pour un large éventail d’applications. Les opérations nécessaires au niveau local dépendent de l’application spécifique. Chez le client avec lequel Smals travaille, un “mélange” a suffi, mais ce n’est pas toujours le cas. L’aspect plus générique, à savoir la conversion d’identifiants en pseudonymes et vice versa, a été pris en compte dans le service Smals.

Si ce service utilisait une technologie traditionnelle, il devrait maintenir une table de paires de pseudonymes de registre de domaine pour chaque environnement de test ou d’acceptation utilisant le service. Il en résulterait un grand nombre de tables, pouvant contenir des centaines de milliers de lignes ou plus. Ces tableaux devraient alors être conservés pièce par pièce, ce qui nécessiterait beaucoup d’espace de stockage. En outre, les tables changent constamment car des citoyens sont régulièrement ajoutés (ou supprimés). Cela ajoute à la complexité et pose des problèmes de stockage et de synchronisation.

Le service de Smals ne fonctionne pas avec des tableaux, mais avec des clés cryptographiques compactes de 32 octets, qui restent constantes sur une longue période. Les pseudonymes sont calculés à la volée sur la base des numéros de registre d’État reçus (ou vice versa). Les clés peuvent être mieux protégées que les grandes tables en les stockant et en les gérant dans des modules de sécurité matériels (HSM). Ces modules sont spécialement conçus pour sécuriser ces clés cryptographiques. En outre, l’entité qui stocke les données sécurisées est différente de l’organisation qui gère la clé(séparation des tâches). Il en résulte un niveau de sécurité supplémentaire. Un autre avantage d’un service centralisé est que les organisations qui l’utilisent ne doivent pas se préoccuper de la gestion des clés.

La pseudonymisation préservant la structure est très simple en termes d’infrastructure, de stockage et de synchronisation.

Kristof Verslype, Smals Research

Cette pseudonymisation préservant la structure peut accroître considérablement la protection de la vie privée des citoyens dans l’environnement d’acceptation et de test des applications existantes, mais elle est encore dans une phase expérimentale. Smals étudie actuellement la manière de mettre en place ce service.

Pseudonymisation aveugle dans le domaine de la santé en ligne

Pour les nouvelles applications, Smals va encore plus loin grâce au concept de “privacy-by-design”, qui consiste à prendre en compte la vie privée des citoyens lors de la conception de l’application. Ainsi, les données personnelles sont mieux protégées par la pseudonymisation, non seulement dans les environnements de test et d’acceptation, mais aussi dans l’environnement de production. Telle était l’approche du service de pseudonymisation aveugle d’eHealth, qui est aujourd’hui déjà utilisé en pratique par les médecins pour protéger les données médicales personnelles, dans le contexte des prescriptions de référence, entre autres. Avec une ordonnance de référence, un prestataire de soins de santé prescrit différents types de soins au patient, autres que les soins pharmaceutiques (par exemple, les soins dispensés par un kinésithérapeute, une infirmière à domicile…).

Comme pour la pseudonymisation préservant la structure, il y a séparation des tâches: le service de pseudonymisation connaît les clés de pseudonymisation mais n’a pas accès aux données à caractère personnel. Le service d’arrière-plan voit les données personnelles pseudonymisées mais n’a pas accès aux clés de pseudonymisation.

Une approche utilisée dans le passé consistait à crypter entièrement les données personnelles, à l’exception du numéro de registre national. D’une part, ce système est très sûr ; d’autre part, ce cryptage intégral limite la fonctionnalité. Par exemple, il n’était pas possible de valider les données, d’en extraire des statistiques ou de les analyser.

Pour conserver ces fonctionnalités sans compromettre la protection de la vie privée, une nouvelle approche a été définie. La figure ci-dessus illustre le scénario dans lequel un médecin délivre une ordonnance et où les données de l’ordonnance sont conservées sous un pseudonyme par un service central.

Pour empêcher le service de pseudonymisation de profiler des informations sur les citoyens sur la base des métadonnées, nous masquons les numéros de registre national entrants et sortants ainsi que les pseudonymes pour ce service. Pour ce faire, nous utilisons les opérations “purple”(blind et unblind). L’aveuglement est un cryptage momentané à l’aide d’une clé à usage unique connue uniquement du médecin. Le médecin rend aveugle le numéro de registre national et l’envoie au service de pseudonymisation. Ce service convertit l’identifiant masqué en un pseudonyme masqué(pseudonymisation) et renvoie le résultat au médecin, qui est le seul à pouvoir le débanaliser.

Bien qu’il s’agisse d’un modèle solide en soi, nous ne voulons pas non plus que les pseudonymes soient visibles par le médecin. Après tout, il s’agit d’un risque d’identification supplémentaire : idéalement, chaque partie ne voit que ce qu’elle est censée voir sensu stricto. C’est pourquoi deux étapes supplémentaires sont ajoutées (cases orange) : Le service de pseudonymisation crypte le pseudonyme masqué et le renvoie au médecin. Le médecin ne peut supprimer que le pseudonyme masqué. Il ne reste alors qu’un pseudonyme crypté. Celui-ci est ensuite envoyé au service central de prescription, qui est le seul à pouvoir le décrypter. En résumé, le médecin ne voit que le numéro de registre national, le service qui stocke les données personnelles ne voit que le pseudonyme et le service de pseudonymisation ne voit ni l’un ni l’autre.

Pour ajouter une couche de sécurité supplémentaire, le service de pseudonymisation ajoute un contexte au pseudonyme masqué avant qu’il ne soit crypté. Cette opération est vérifiée par le service sous-jacent (cases bleues). Au minimum, le service de pseudonymisation ajoute un horodatage. Cela permet aux pseudonymes cryptés reçus par le prestataire de soins de santé de n’être utilisés que pendant une durée limitée, ce qui empêche toute utilisation abusive.

La pseudonymisation aveugle garantit donc que chaque partie ne peut accéder qu’aux informations strictement nécessaires et qu’aucune information ne fuit vers le service de pseudonymisation. En outre, du côté du prestataire de soins de santé, ce système n’utilise pas de clés qui doivent être conservées pendant de longues périodes. C’est un grand avantage, car la gestion adéquate des clés est difficile et personne n’aime vraiment le faire. Le système offre un niveau de sécurité élevé et peut jouer un rôle important dans la réduction des violations de données.

Oblivious Join

À des fins de recherche, par exemple dans les universités, les données à caractère personnel provenant de différentes sources doivent régulièrement être recoupées et pseudonymisées. Cette dernière est une mesure nécessaire qui permet d’éviter qu’un chercheur n’établisse un lien entre des données personnelles et des personnes physiques. Ces projets de croisement peuvent devenir très complexes, en particulier lorsque les sources de données elles-mêmes ne peuvent pas décider de manière autonome des citoyens sur lesquels fournir des données. Par exemple, dans un projet de recoupement antérieur, le registre belge du cancer a dû fournir des données sur des citoyens atteints de sclérose en plaques (SEP), sans savoir lui-même qui était atteint de cette maladie.

Pour aborder ces projets de croisement de manière élégante, rentable et sûre, Smals a mis au point le système “Oblivious Join”. Il n’y a pas de fuite de données ; les sources de données n’apprennent pas de nouvelles données personnelles en participant à ces projets, et le destinataire des données (le collecteur) n’apprend que les données pseudonymisées qui sont nécessaires dans le contexte de la recherche. Le collecteur n’est pas encore le chercheur lui-même, mais doit être considéré comme une partie intermédiaire.

Oblivious Join est également distribué ; il n’y a ni service central de pseudonymisation ni partie centrale coordinatrice impliquée dans la mise en œuvre des projets de croisement. Tout se fait par la collaboration entre les sources de données et le collecteur.

Oblivious Join fonctionne en trois étapes. La première étape est un protocole automatisé qui crée des accords cryptographiques entre les sources de données. Après cette première étape, les sources de données peuvent commencer à pseudonymiser et à crypter elles-mêmes les données qui, de leur point de vue, pourraient être pertinentes pour le projet de recherche, et envoyer le résultat au collecteur. Grâce aux accords conclus lors de la première étape, nous pouvons garantir qu’au cours de la troisième et dernière étape, le collecteur ne pourra décrypter et relier que les données pseudonymisées nécessaires dans le cadre du projet de recherche.

Dans l’exemple précédent, cela signifie que le registre belge du cancer prend d’abord des dispositions avec une source de données qui sait qui est atteint de la SEP. Il pseudonymise et crypte ensuite les données relatives à tous les citoyens ayant reçu ce diagnostic de cancer et envoie le résultat au collecteur. Le collecteur ne peut décrypter que les enregistrements provenant du registre belge du cancer qui concernent des personnes atteintes de SEP.

Dans un protocole Oblivious Join, les sources de données ne voient que les identifiants (numéros de registres nationaux) et aucun pseudonyme, le collecteur ne voit que les pseudonymes mais pas les identifiants. Il n’y a pas d’intervention d’un service de pseudonymisation. Il est déjà évident que le collecteur joue un rôle important ici et qu’il est donc censé supprimer immédiatement les cryptogrammes non pertinents. En outre, le collecteur effectuera des contrôles supplémentaires sur les données afin de vérifier que le risque d’identification des enregistrements individuels n’est pas trop élevé lors de la réalisation de l’étude. Il peut ensuite donner au chercheur un accès contrôlé aux données.

Comment cela fonctionne-t-il en pratique ? Les sources de données et le collecteur téléchargent d’abord un logiciel : le client Oblivious Join. En outre, ils reçoivent de la partie coordinatrice un fichier JSON spécifique au projet, qui contient toutes les informations nécessaires à l’exécution automatique du protocole. Chaque source de données crée en outre un fichier CSV contenant toutes les données personnelles identifiées potentiellement pertinentes pour l’étude. Les sources de données fournissent ensuite le fichier JSON et le fichier CSV au client, tandis que le collecteur ne fournit que le fichier JSON en entrée. Le protocole est ensuite exécuté, ce qui signifie que les différentes parties communiquent entre elles. Grâce au protocole, le collecteur obtient les données personnelles pseudonymisées minimales nécessaires dans le contexte de l’étude (le fichier CSV noir dans la figure). Ce fichier CSV groupé comprend les données pseudonymisées nécessaires provenant des trois sources de données pertinentes pour l’étude.

En résumé, Oblivious Join est respectueux de la vie privée, sûr, distribué et facile à utiliser. Il constitue un moyen sûr de déverrouiller les données, mais il en est encore à la phase expérimentale aujourd’hui.

De l’expérimentation à l’utilisation aujourd’hui

Les projets susmentionnés sont tous à des stades différents, allant d’une phase expérimentale à un outil déjà utilisé dans la pratique. Il n’existe pas de solution unique en matière de techniques de pseudonymisation. Le choix de la solution la plus appropriée dépend évidemment des besoins concrets.

Auparavant, Smals a publié deux articles sur la pseudonymisation sur ITdaily. Les personnes désireuses d’approfondir le projet eHealth peuvent se rendre ici. Il existe également le cryptage préservant le format (FPE) qui a été normalisé par le NIST. Pour en savoir plus, cliquez ici.

————————————————-
Ceci est un éditorial en collaboration avec Smals. Le 10 octobre 2024, Smals fera une présentation à Devoxx de 9h30 à 10h20. Vous trouverez plus d’informations à ce sujet ici.