Security
Chiffrement et tokenisation : ce n’est pas la même protection
Le chiffré reste la donnée, sous une autre forme. Le token aléatoire, non. Cette différence décide de ce qu’une copie volée aujourd’hui pourra encore révéler plus tard.
On les traite souvent comme deux façons de dire « les données sont protégées ». Ce n’est pas le cas. Le chiffrement transforme une valeur pour la rendre illisible sans clé. La tokenisation par coffre retire cette valeur du système qui travaille avec elle, et la remplace par un substitut qui n’est pas calculé à partir d’elle.
Le RGPD range cette seconde opération dans la pseudonymisation, à condition que l’information qui permet de revenir à la personne soit tenue à part. Ni le chiffrement ni la pseudonymisation ne sont une anonymisation.
Un chiffré volé est une donnée en attente de clé. Un token aléatoire volé est un identifiant sans donnée.
Le même email, suivi jusqu’au bout
Cinq étapes. La lecture enchaîne. On peut aussi avancer à la main. Les chaînes affichées sont des symboles, pas un calcul cryptographique réel.
Même email, deux protections
Chiffrement
Base applicative
marie.durand@example.fr
point de départ
Tokenisation de coffre
Base applicative
marie.durand@example.fr
point de départ
Symboles illustratifs, pas un calcul AES réel. example.com est un domaine réservé. Le token montre la forme d’un identifiant opaque, pas un jeton en production.
Trois opérations, pas trois synonymes
Chiffrement. Une fonction et une clé transforment le clair P en chiffré C. Avec la même clé, l’opération inverse retrouve P. AES-256-GCM, utilisé correctement, fait cela : un vecteur d’initialisation aléatoire, un tag d’authenticité, un chiffré. C reste une forme de P. Qui réunit C et la clé réunit la donnée.
Pseudonymisation. L’article 4.5 du RGPD la définit comme le traitement qui empêche d’attribuer les données à une personne précise sans informations supplémentaires, à condition que ces informations soient conservées séparément et protégées par des mesures techniques et organisationnelles. Le considérant 26 ajoute que des données pseudonymisées qui peuvent encore être rattachées à quelqu’un grâce à ces informations restent des données concernant une personne identifiable.
Tokenisation de coffre. Terme d’ingénierie, pas un mot du RGPD. On remplace la valeur par un identifiant aléatoire, le token (on dit aussi jeton). La valeur, elle, est chiffrée dans un coffre, et c’est le coffre qui fait le lien. Pour le responsable qui peut ouvrir ce coffre, c’est une pseudonymisation : réversible, donc toujours personnelle. Pour un système qui ne voit que le token et n’a aucun moyen raisonnable de revenir à la valeur, le token ne lui donne pas la personne.
Ce que chaque méthode laisse dans le système
| Chiffrement | Tokenisation de coffre | Anonymisation | |
|---|---|---|---|
| Dans la base métier | Le chiffré, donc la donnée | Un token sans lien avec la valeur | Une donnée qui ne permet plus d’identifier |
| Où est le secret | Dans chaque copie du chiffré | Dans le coffre, pas dans les copies métier | Il n’est plus là |
| Retour au clair | Oui, avec la clé | Oui, via le coffre et un accès contrôlé | Non, si le critère du considérant 26 est vraiment tenu |
| Pour qui c’est personnel | Pour quiconque pourra réunir chiffré et clé | Pour le responsable qui peut ré-identifier. Pas automatiquement pour un destinataire qui ne le peut pas | Ce n’est plus une donnée personnelle |
| Copie volée aujourd’hui | Un secret en attente | Un identifiant inexploitable | Pas de secret à ouvrir |
Récolter aujourd’hui, déchiffrer plus tard
L’expression anglaise est harvest now, decrypt later, parfois store now, decrypt later. Le geste opérationnel est le même : copier maintenant ce qui est protégé, l’ouvrir quand les moyens existent. On peut l’appeler drain today, decrypt later. L’ANSSI parle d’attaques rétroactives, et écrit que cette menace est déjà constituée.
Le scénario ne vise pas tous les algorithmes de la même façon.
- Shor casse, sur un ordinateur quantique cryptographiquement pertinent, les problèmes derrière RSA, Diffie-Hellman et les courbes elliptiques. Ce sont les échanges de clés et une grande partie des signatures. Pas AES.
- Grover accélère la recherche exhaustive d’une clé symétrique d’un facteur racine carrée. AES-256 retombe sur un coût de l’ordre de 128 bits, niveau que le NIST tient encore pour acceptable. AES-128 n’a pas cette marge.
- Le matériel intéressant à stocker aujourd’hui, c’est donc un échange de clés classique enregistré, une clé enveloppée avec RSA, une session TLS, un chiffré dont la clé dépend de cet échange. Pas « n’importe quel disque chiffré en AES-256 ».
La date de l’ordinateur n’est pas la date à laquelle il faut commencer. Si une donnée doit rester confidentielle après l’arrivée de la machine, il fallait qu’elle ne soit pas copiable sous une forme ouvrable avant. Les estimations publiques de cette arrivée divergent. Les échéances utiles sont celles que les autorités ont déjà posées pour planifier, pas une prédiction du jour où RSA tombe.
L’ANSSI demande d’inventorier les données dont la confidentialité ou l’authenticité doit encore tenir après 2030, et indique qu’il ne sera pas raisonnable d’acheter, après 2030, des produits qui n’intègrent pas de cryptographie post-quantique. Elle recommande l’hybridation, classique plus post-quantique, là où une protection contre la menace quantique est nécessaire. Hors informations classifiées, Diffusion Restreinte, opérateurs d’importance vitale et visas de sécurité, ce n’est pas aujourd’hui une obligation légale générale. C’est une consigne de risque.
Côté Union européenne, la recommandation de la Commission du 11 avril 2024 a été suivie, le 23 juin 2025, d’une feuille de route du groupe de coopération NIS, co-pilotée par la France, l’Allemagne et les Pays-Bas. Les États membres devraient avoir engagé la transition d’ici fin 2026. Les cas d’usage à haut risque, et la protection des infrastructures critiques, dès que possible et au plus tard fin 2030.
Les premiers standards NIST sont publiés depuis le 13 août 2024 : FIPS 203 (ML-KEM, établissement de clé), FIPS 204 (ML-DSA, signature), FIPS 205 (SLH-DSA, signature). Attendre « que les standards existent » n’est plus une raison de remettre l’inventaire.
Ce que la tokenisation change dans ce scénario
Si la base applicative, ses sauvegardes, ses logs et son entrepôt analytique ne contiennent qu’un token aléatoire, la copie n’est pas un chiffré. Il n’y a pas d’algorithme, quantique ou non, qui recalcule marie.durand@example.fr à partir de tok_7f3a9c2e. Le token n’a pas été produit par RSA, ni par une courbe elliptique, ni par AES.
Le coffre, lui, reste un problème de chiffrement. S’il est exfiltré avec de quoi obtenir la clé, le clair revient. AES-256-GCM n’est pas la cible de Shor. Le risque résiduel sur le coffre est le vol de clé, la compromission opérationnelle, et tout enveloppement ou transport de clé qui dépend encore d’un algorithme à clé publique cassable. Réduire le périmètre ne dispense pas de protéger ce périmètre, ni de préparer sa cryptographie à la même échéance que le reste.
La tokenisation ne rend pas le coffre invincible. Elle retire la donnée récupérable des systèmes qu’on copie le plus souvent.
C’est aussi pour cela que chiffrement et tokenisation se complètent au lieu de se remplacer. Le transport vers le coffre, la clé, le coffre lui-même : chiffrement, puis cryptographie post-quantique hybride là où la durée de secret l’exige. Les systèmes métier : token, parce qu’un chiffré qui circule dans vingt outils est vingt archives en attente de clé.
Ce que le droit distingue déjà, et ce qui se précise
L’article 32 du RGPD cite, dans la même phrase, la pseudonymisation et le chiffrement comme exemples de mesures de sécurité. Le texte ne dit pas que l’un tient lieu de l’autre. L’article 25 demande une protection dès la conception, proportionnée au risque. Une base chiffrée au repos, dont l’application détient la clé en permanence, répond mal au risque d’une compromission applicative : au moment de l’usage, la donnée est de nouveau en clair, et le chiffré dort à côté.
Les lignes directrices 01/2025 du Comité européen de la protection des données, adoptées pour consultation le 16 janvier 2025, rappellent qu’une donnée pseudonymisée reste une donnée personnelle, y compris lorsque l’information supplémentaire est détenue par une autre personne. Effacer cette information ne produit pas, à soi seul, une donnée anonyme. L’effet de la mesure dépend du domaine de pseudonymisation : qui est empêché de ré-identifier, et comment l’information supplémentaire en est isolée.
L’arrêt de la Cour de justice du 4 septembre 2025, affaire C-413/23 P, EDPS contre Conseil de résolution unique, porte sur le règlement 2018/1725 (institutions de l’Union). Les définitions de donnée personnelle et de pseudonymisation y sont alignées sur le RGPD. La Cour dit que des données pseudonymisées ne sont pas, dans tous les cas et pour toute personne, des données personnelles. Un destinataire qui n’a aucun moyen raisonnablement susceptible d’être utilisé pour ré-identifier peut ne pas traiter de donnée personnelle. Le responsable qui détient l’information supplémentaire, si. Et l’obligation d’information de la personne s’apprécie au moment de la collecte, du point de vue de ce responsable, avant le transfert.
L’anonymisation est une autre barre : plus aucun moyen raisonnablement susceptible d’être utilisé, par le responsable ou par un autre, pour identifier la personne. Un coffre que l’organisation peut encore ouvrir ne franchit pas cette barre. Les autorités continuent de travailler ce critère à part. Il ne faut pas le déduire de l’arrêt sur la pseudonymisation.
Ce que la technique va exiger
- Un inventaire : où sont les chiffrés, quels algorithmes, quelle durée de secret. L’ANSSI demande ce travail maintenant, en commençant par les données qui doivent rester secrètes après 2030.
- De la crypto-agilité : pouvoir changer les paramètres, puis l’algorithme, sans reconstruire le système. Les standards de 2024 ne seront pas les derniers ajustements.
- De l’hybridation sur l’établissement de clé pour tout secret qui doit tenir au-delà de 2030. Un mécanisme classique et un mécanisme post-quantique, pour ne pas dépendre d’un seul des deux tant que le recul sur les nouveaux algorithmes reste limité. C’est la position de l’ANSSI.
- Arrêter de compter le chiffrement au repos comme une réponse complète à la donnée en usage. L’application, le log et l’analytics détiennent encore le secret, sous forme de chiffré ou, pire, de clair.
- Là où la valeur claire ne sert que rarement, et sous contrôle d’accès, la sortir de ces systèmes. Le token circule. Le coffre, petit et séparé, porte le chiffré.
- Ne pas appeler identifiant anonymisé un chiffré à format préservé, ni un hash d’email.
Les deux calendriers se superposent. Le calendrier cryptographique dit : moins de chiffré ouvrable dans dix ans, et des échanges de clés qui ne reposent plus seulement sur RSA ou les courbes. Le calendrier de protection des données dit : moins de donnée personnelle récupérable dans les systèmes compromis. Le premier sans le second laisse des archives AES dans chaque sauvegarde. Le second sans le premier laisse un coffre dont la clé voyage encore sous un algorithme déjà enregistré par l’attaquant.
Dans Veilio
Le substitut qui circule dans les systèmes du client est un token aléatoire. Il n’est pas dérivé de la valeur. La valeur est stockée dans un coffre, chiffrée en AES-256-GCM, que ces systèmes ne détiennent pas. Un index HMAC-SHA256 permet une recherche par égalité exacte sans replacer le clair dans la base applicative. Cet index n’est pas le token, et il n’est pas réversible. Quand l’entrée du coffre et l’index sont détruits, le token ne se résout plus.
C’est une pseudonymisation au sens de l’article 4.5 : la réversibilité est volontaire, contrôlée et auditée. Ce n’est pas une anonymisation, et ce n’est pas un substitut au chiffrement du coffre ni à la migration post-quantique des échanges de clés.
Sources
- Règlement (UE) 2016/679, articles 4.5, 25 et 32, considérant 26.
- CEPD, lignes directrices 01/2025 sur la pseudonymisation, version adoptée pour consultation le 16 janvier 2025.
- Cour de justice, communiqué du 4 septembre 2025, affaire C-413/23 P, et arrêt.
- G29, avis 05/2014 sur les techniques d’anonymisation.
- ANSSI, cryptographie post-quantique et FAQ.
- Commission européenne, feuille de route post-quantique, recommandation du 11 avril 2024, feuille de route du 23 juin 2025.
- NIST, 13 août 2024, FIPS 203, 204 et 205.
