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 len où radix 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.
Cette contribution a été soumise par Kristof Verslype, cryptographe chez Smals Research.
Elle a été rédigée en son nom propre et ne prend pas position au nom de Smals.
Source featured image: Pixabay
Leave a Reply