Protection des données par la pseudonymisation préservant la structure des numéros de registre national

Cet article a déjà été publié sur smalsresearch.be et itdaily.be.
Nederlandstalige versie

De plus en plus de données personnelles sensibles sont stockées sous forme numérique, tandis que les cyberattaques deviennent de plus en plus avancées. Aussi l’amélioration de la protection des données à caractère personnel fait-elle l’objet d’une attention de tous les instants.

Une mesure complémentaire précieuse consiste à stocker les données à caractère personnel non pas sous un numéro de registre national, mais sous un pseudonyme. Pour les applications existantes qui ne procèdent pas encore de la sorte, dans les environnements production comme dans les environnements de test et de développement, il peut être utile, voire nécessaire, que ces pseudonymes aient la même structure que les numéros de registre national. Ceci de manière à ce qu’ils puissent être traités par l’application et la base de données existantes.

D’où la nécessité d’une technique permettant de convertir les numéros de registre national en pseudonymes avec la même structure et vice versa. Si le chiffrement classique ne le permet pas, il en va autrement avec la tokenisation des données (data tokenization en anglais) ou le chiffrement préservant le format (format-preserving encryption en anglais).

La tokenisation des données dans sa forme la plus simple, implique de tenir un tableau contenant des paires de la forme (numéro de registre national, pseudonyme), ce qui pose des problèmes infrastructurels, notamment en matière de sauvegarde, de synchronisation et de sécurisation du tableau.

Plutôt que de tenir un tableau sans cesse croissant, comportant potentiellement des millions d’enregistrements, une solution plus simple et plus sûre consisterait en une clé symétrique unique et immuable d’une longueur de 32 bytes (au maximum). C’est exactement ce que fait le chiffrement préservant le format (FPE). Cette technique a été présentée pour la première fois en 2001 et a été normalisée par le NIST. À la suite de la découverte de faiblesses, les normes ont été révisées en 2019.

Les normes FPE sont principalement axées sur le secteur financier où, par exemple, les numéros de cartes de crédit sont remplacés par des pseudonymes ayant la même structure. L’équipe Smals Research s’est demandé si cette technique pouvait également être appliquée aux numéros de registre national. Cet article présente notre analyse et nos expériences.

Fonctionnement

Par essence, le FPE consiste en une permutation, soit une réorganisation, comme l’illustre la figure ci-dessous où les chiffres 1 à 5 sont réorganisés. La permutation est déterminée par la clé FPE et le tweak. La clé est secrète, le tweak est un nombre à choisir librement (byte array) qui peut être connu du public et qui simplifie la gestion des clés [1]. Comment convertir sur cette base les numéros de registre national en pseudonymes ayant la structure d’un numéro de registre national ?

La chaîne 83.06.21-123-62 revêt la structure d’un numéro de registre national, c’est-à-dire qu’elle se présente sous la forme YY.MM.DD-III-CC, où YY.MM.DD représente la date de naissance, III est un compteur de jours dans lequel est également encodé le sexe, et CC est un chiffre de contrôle, calculé sur la base de tous les éléments précédents et du siècle de naissance. Votre auteur n’est (hélas/heureusement) pas en mesure de vérifier si le numéro 83.06.21-123-62 a réellement été attribué à un citoyen et sait donc uniquement qu’il s’agit d’une chaîne revêtant la structure d’un numéro de registre national.

À partir d’une date de départ à choisir librement – par exemple 01/01/1911 – nous attribuons à chaque chaîne correctement formée un index unique, qui commence par 0 et augmente ensuite, comme le montre la figure ci-dessous. Nous pouvons nous arrêter, par exemple, au 31/12/2022. Dans ce cas, nous avons la certitude que les numéros de registre national de toutes les personnes inscrites au Registre National qui étaient en vie à la fin de l’année 2022 ont une conversion de et vers un nombre. En effet, personne dans ce pays n’a plus de 112 ans.

La conversion d’un numéro de registre national en un pseudonyme préservant la structure est illustrée dans la figure ci-dessous. Le numéro de registre national est d’abord converti en un nombre, comme indiqué précédemment. Ce nombre est permuté (= chiffré) par FPE en un autre nombre qui est ensuite reconverti en la chaîne préservant la structure correspondante. Cette chaîne est le pseudonyme final.

[1] Avec une seule clé secrète et différents tweaks, nous avons donc différentes permutations (chiffrements). Le tweak peut être considéré comme la partie non secrète de la clé.

Dans la pratique

Pour utiliser le FPE afin de convertir des numéros de registre national en pseudonymes préservant la structure, nous avons donc besoin à la fois d’un chiffrement FPE (et d’un algorithme de déchiffrement) et d’une méthode de conversion.

Pour le chiffrement FPE, nous avons recouru à la bibliothèque cryptographique bien connue BouncyCastle, qui prend en charge les deux normes du NIST, FF1 et FF3-1. En coulisses, le FPE utilise toujours un algorithme existant pour le chiffrement par blocs symétriques. Le choix logique était donc AES. Par conséquent, les clés FPE sont simplement des clés AES.

L’équipe Smals Research a elle-même réalisé la conversion en Java, en tenant compte de toutes les complexités liées aux numéros de registre national (voir, par exemple les arrêtés royaux du 3 avril 1984 et du 25 novembre 1997). En cas d’intérêt concret, ce code de recherche peut évoluer vers quelque chose qui soit utilisable en production.

Des contraintes cruciales doivent néanmoins être prises en compte lors du choix de la taille du domaine. Le FPE a été présenté pour la première fois en 2001, dans un article intitulé Ciphers with arbitrary finite domains. Comme l’indique le titre, la taille du domaine peut être choisie arbitrairement. C’est également ce que nous avons fait dans notre exemple précédent.

Toutefois, les normes du NIST s’en écartent et stipulent que la taille du domaine doit avoir la forme radixlen, c’est-à-dire le nombre racine radix élevé à la puissance lenradix et len peuvent être choisis librement, tant que radix n’est pas supérieur à 216 = 65 536. Cette approche fonctionne bien pour, par exemple, les numéros de cartes de crédit. Ces numéros sont composés de 16 chiffres décimaux. Nous choisissons donc radix = 10 et len = 16. Ainsi, si nous suivons les normes du NIST – ce que je recommande vivement – nous ne pouvons plus choisir la taille du domaine arbitrairement.

En outre, la taille minimale du domaine, qui était encore de 100 dans la publication du NIST de 2016, a été portée à 1 000 000, dans la révision de 2019 pour des raisons de sécurité. Autrement dit, il est exigé que radixlen ≥ 1 000 000. Entre autres conséquences de cette exigence, il n’est plus possible de conserver l’année de naissance dans le pseudonyme d’un numéro de registre national. En effet, il n’y a que quelque 365 000 chaînes correctement formées par an (365 ou 366 jours par an x 998 possibilités pour le compteur de jours III).

Revenons à nos expériences. Comment déterminer le domaine (et donc sa taille) ? Dans notre exemple précédent, ce domaine était composé de toutes les chaînes dotées de la structure d’un numéro de registre national pour les personnes nées entre 1911 et 2022, soit plus de 40,8 millions de chaînes. Il s’agit bien évidemment d’utiliser le système pendant plusieurs années, de sorte qu’il est logique que le domaine soit plus grand. En effet, de nouveaux numéros de registre national sont émis en permanence, et il ne s’agit pas d’oublier les anciens.

Pour nos tests, nous avons choisi le 1er janvier 1912 comme date de départ et
226 = 67 108 864 comme taille de notre domaine. Ensemble, la date de départ et la taille du domaine déterminent également la date de fin, soit le 7 février 2096 dans notre cas. Comme nous l’avons déjà mentionné, le FPE est une permutation sous-jacente sur l’ensemble du domaine, de sorte que le pseudonyme d’une personne vivante peut être converti en un pseudonyme préservant la structure avec une date de naissance située plusieurs dizaines d’années dans le futur. Il se peut également que, dans dix ans, le numéro de registre national d’une personne vivante à cette époque soit converti en un pseudonyme avec une date de naissance qui est de toute façon trop éloignée dans le temps pour être celle d’une personne vivante à ce moment-là.

En résumé, le FPE peut être utilisé pour convertir des numéros de registre national en pseudonymes avec la même structure, mais toutes les informations contenues dans le numéro de registre national seront perdues au cours du processus. Les contrôles de la date de naissance et du sexe (contenu dans la 9e décimale) deviennent donc impossibles. Ceci peut affecter certaines applications qui exécutent ces contrôles de toute façon.

Une mise en garde à cet égard s’impose toutefois. Nous ne devons pas considérer qu’un numéro de registre national contient ces informations par définition. Il existe en effet des exceptions, où la date de naissance exacte n’est pas contenue dans le numéro national (voir les AR susmentionnés). La meilleure pratique consiste dès lors à utiliser le numéro de registre national comme identifiant uniquement et à demander au Registre national les données à caractère personnel dont l’application a besoin. Dans un tel contexte, le FPE pour les pseudonymes préservant la structure peut constituer une mesure de sécurité précieuse.

Membrane de confidentialité

La membrane de confidentialité est un concept commun – il n’y a pas encore de code – du service Sécurité de l’information de Smals et de l’équipe Smals Research. L’idée est qu’un environnement, par exemple une application en acceptation, est entouré d’une membrane virtuelle, la membrane de confidentialité. Tous les numéros de registre national qui entrent sont convertis en pseudonymes préservant la structure lorsqu’ils traversent la membrane de confidentialité. Et tous les pseudonymes préservant la structure qui sortent sont reconvertis en numéros de registre original lorsqu’ils traversent cette membrane. À l’intérieur de la membrane, seul le pseudonyme est donc connu. Cette approche est transparente à la fois pour la ou les applications qui se trouvent à l’intérieur de la membrane et pour les applications/services avec lesquels s’effectue une communication.

La membrane de confidentialité pourrait en fait être un serveur proxy par lequel passe tout le trafic entrant et sortant. Ce serveur proxy pourrait éventuellement être hébergé par un tiers.

Contrairement aux autres techniques de pseudonymisation avancées conçues par l’équipe Smals Research, ce tiers voit inévitablement à la fois le numéro de registre national et le pseudonyme. Il est donc impossible de proposer un service de pseudonymisation aveugle sur la base du FPE, de sorte qu’un degré de confiance supérieur s’impose à l’égard de ce tiers.

Conclusion

Le FPE autorise une belle approche pour convertir les numéros de registre national en pseudonymes avec la même structure. Cette approche peut améliorer la protection des données à caractère personnel sans qu’il soit nécessaire d’adapter l’application ou la base de données sous-jacente. En revanche, les informations contenues dans le numéro de registre national – en particulier la date de naissance et le sexe biologique – seront perdues. Cela ne devrait toutefois pas être problématique si les meilleures pratiques sont appliquées et si les informations sont récupérées à partir de la source authentique, à savoir le Registre national.

La même technique peut être appliquée à d’autres types d’identifiants numériques, tels que les numéros BCE, les numéros de téléphone et les numéros de compte bancaire. Aujourd’hui, dans son code de recherche, l’équipe Smals Research prend déjà en charge les numéros BIS, i.e. des numéros d’identification uniques pour les personnes qui ne sont pas inscrites au Registre national mais qui sont en relation avec les autorités belges, en plus des numéros de registre national. Les numéros de registre national et les numéros BIS constituent ensemble les numéros NISS, les numéros d’identification de la sécurité sociale.

L’introduction mentionne que le FPE est une mesure de protection complémentaire. Lorsque, par exemple, dans un enregistrement de base de données, le numéro de registre national est remplacé par un pseudonyme, mais que le nom et l’adresse restent en clair dans la base de données, l’identification du citoyen reste assez triviale. Dès lors, soit des mesures de protection complémentaires s’imposent, soit ces données à caractère personnel ne sont plus stockées localement, mais sont systématiquement extraites de la source authentique (en l’espèce le Registre national).

En décembre 2021, un sondage réalisé à la fin de mon webinaire consacré aux
technologies d’amélioration de la vie privée posait la question suivante : quelles sont les technologies d’amélioration de la vie privée qui, selon vous, ont le plus de potentiel et méritent donc plus d’attention ? Le vainqueur fut FPE (suivi d’Oblivious Join et de Synthetic data). Ce résultat nous a amenés à accorder davantage d’attention à cette technologie. Depuis, avec l’équipe Smals Research, nous avons réalisé les premières expériences réussies avec le FPE.

Si vous souhaitez appliquer le FPE, éventuellement sous la forme d’une membrane de confidentialité, ou convertir des identifiants en pseudonymes, n’hésitez pas à prendre contact avec nous.


Comments

Leave a Reply

Your email address will not be published. Required fields are marked *