Les clés d’un portefeuille d’identité : où elles vivent et pourquoi elles ne sortent pas

Une attestation d’identité numérique qui se copie ne vaut rien. Toute la différence entre un portefeuille d’identité et une photographie de carte d’identité tient à une clé privée qui ne quitte jamais un composant matériel, et à la capacité de prouver à distance que cette clé y est bien. Le règlement d’exécution (UE) 2024/2979 appelle ce composant le « dispositif cryptographique sécurisé de portefeuille » et lui consacre l’essentiel de ses obligations. C’est la pièce qui relie l’identité régalienne aux enclaves matérielles dont le site parle ailleurs.

→ Lire l’explication complète de la marmotte

Quatre objets que le règlement prend soin de distinguer

Le vocabulaire du règlement paraît tatillon, et il ne l’est pas : chaque terme désigne une pièce dont les obligations diffèrent. La solution de portefeuille est la combinaison de logiciels, de matériels, de services, de paramètres et de configurations proposée par un fournisseur. L’unité de portefeuille est une configuration unique de cette solution, fournie à un utilisateur donné. L’instance de portefeuille est l’application installée et configurée sur l’appareil de l’utilisateur, celle qu’il voit et manipule. L’application cryptographique sécurisée de portefeuille gère les actifs critiques en s’appuyant sur les fonctions du dispositif. Et le dispositif cryptographique sécurisé de portefeuille, que le texte abrège WSCD d’après son nom anglais, est défini comme « un dispositif inviolable qui fournit un environnement lié à l’application cryptographique sécurisée de portefeuille et utilisé par celle-ci pour protéger les actifs critiques et fournir des fonctions cryptographiques pour l’exécution sécurisée d’opérations critiques ».

La notion d’actif critique complète le dispositif, et sa définition est fonctionnelle plutôt que technique : des actifs « dont l’importance est tellement exceptionnelle que la capacité à utiliser l’unité de portefeuille serait très sérieusement affaiblie si leur disponibilité, leur confidentialité ou leur intégrité étaient compromises ». Les clés privées en sont le cas évident ; le règlement n’en donne pas la liste, ce qui laisse au fournisseur la charge de la dresser et la responsabilité de l’avoir mal dressée.

L’article 4 pose la règle de rattachement : les instances de portefeuille « utilisent au moins un dispositif cryptographique sécurisé de portefeuille pour gérer les actifs critiques », et le fournisseur garantit l’intégrité, l’authenticité et la confidentialité de la communication entre l’instance et l’application cryptographique sécurisée. L’instance, c’est-à-dire l’application mobile, ne détient donc rien de critique : elle demande. C’est la même séparation que celle d’un module matériel de sécurité et de l’application qui l’appelle, discipline dont les conséquences sont détaillées dans créer, vérifier et utiliser les clés dès le départ.

Ce que le dispositif doit garantir, article 5

L’article 5 énumère ce que l’application cryptographique sécurisée doit savoir faire, et la liste se lit comme un cahier des charges de module cryptographique. Elle doit être capable de générer de manière sécurisée de nouvelles clés, de procéder à l’effacement sécurisé des actifs critiques, de générer une preuve de la possession de clés privées, et de protéger les clés privées qu’elle a générées « pendant la durée d’existence des clés ». Le texte ne dit pas « les clés ne sortent pas » : il dit que l’application les protège pendant toute leur vie et qu’elle sait prouver qu’elle les détient, ce qui revient au même en pratique et laisse moins de place à l’interprétation.

Deux exigences de l’article 5 vont plus loin que ce qu’on attend d’un simple coffre. La première est une condition d’exclusivité : ces applications « sont les seuls composants capables d’exécuter des opérations cryptographiques de portefeuille et toute autre opération impliquant des actifs critiques dans le cadre d’une identification électronique à un niveau de garantie élevé ». Pas de chemin de contournement, pas de mode dégradé logiciel, pas de repli discret sur une clé stockée dans l’application. La seconde est une condition d’activation : ces applications n’effectuent d’opérations cryptographiques impliquant des actifs critiques, autres que celles nécessaires à l’authentification de l’utilisateur, « que dans les cas où lesdites applications ont dûment authentifié les utilisateurs de portefeuille ». L’article 3 énonce la même règle au niveau de l’unité entière : aucune fonctionnalité du portefeuille ne s’exécute tant que l’utilisateur n’a pas été authentifié, à la seule exception de cette authentification elle-même.

C’est le point qui distingue un portefeuille d’identité d’un trousseau de clés ordinaire, et il mérite d’être souligné parce qu’il est contraignant à l’usage : chaque présentation d’attestation suppose un geste de l’utilisateur. Une clé que l’on peut utiliser sans réveiller son porteur est une clé qu’un logiciel malveillant installé sur le téléphone peut utiliser aussi, comme le rappelle au passage le cas du second facteur contourné dans l’incident DGFiP. Le niveau de garantie élevé auquel renvoie l’article 5 est celui du règlement d’exécution (UE) 2015/1502, et c’est lui qui fixe les caractéristiques attendues des moyens d’identification électronique.

Quand le fournisseur choisit d’héberger cette application dans un élément sécurisé intégré, l’annexe I lui impose de fonder sa solution technique sur une liste de spécifications nommées, ou sur des spécifications équivalentes : la spécification SAM.01 de la GSMA pour l’hébergement d’appliquettes tierces sur eSIM et élément sécurisé intégré, et un jeu de spécifications GlobalPlatform, de la spécification de carte à la gestion confidentielle de contenu et aux protocoles de canal sécurisé, ainsi que l’interface OMAPI d’accès aux éléments sécurisés depuis les applications mobiles. On est très loin de l’abstraction : le droit de l’Union désigne ici des documents de consortium industriel, ce qui est une manière efficace de ne pas réinventer ce qui marche et une manière certaine de se lier à leurs évolutions. Les propriétés et les limites de ces environnements isolés sont détaillées dans SGX et TrustZone pour isoler du code sensible.

L’attestation de clé : prouver où la clé habite

Il ne suffit pas que la clé soit bien rangée : le vérificateur doit pouvoir le constater sans visiter le téléphone. C’est l’objet des attestations, et le règlement en distingue deux niveaux.

L’attestation d’unité de portefeuille décrit les composants de l’unité et permet leur authentification. L’article 6 exige que chaque unité en contienne, que ces attestations contiennent des clés publiques, et que « les clés privées correspondantes soient protégées par un dispositif cryptographique sécurisé de portefeuille ». Le fournisseur signe au moins une de ces attestations avec un certificat délivré sur la foi d’un certificat figurant sur une liste de confiance publiée, mécanique de chaînage classique et décrite dans relier une clé à une identité.

L’attestation de clé est plus intéressante, et c’est le règlement d’exécution (UE) 2026/1731 du 15 juillet 2026 qui en fixe le contenu. Elle comprend des revendications key_storage et user_authentification qui, précise le texte, « doivent avoir la valeur iso_18045_high lorsqu’une attestation de clé mentionne un WSCD ». Elle comprend en outre une revendication certification contenant une adresse où obtenir les informations sur la certification obtenue par le dispositif ou le magasin de clés, « à titre indicatif le schéma tel que Common Criteria ou GlobalPlatform, les exigences évaluées telles que le profil de protection applicable et le niveau d’évaluation ». Le règlement ajoute la phrase qui dit tout : « ces informations permettent de déterminer si le stockage de la clé est un WSCD ».

Autrement dit, l’affirmation « ma clé est dans un composant inviolable » devient une donnée signée, pointant vers une certification vérifiable, et non une déclaration commerciale. C’est précisément le modèle de l’attestation distante, appliqué à l’identité des personnes, et la raison pour laquelle les schémas de certification matérielle évoqués dans les certifications FIPS et Critères communs cessent ici d’être une affaire de spécialistes : ils entrent dans le protocole. L’attestation de clé porte aussi un key_storage_status référençant une liste d’états, afin que le vérificateur puisse constater la révocation d’un type de dispositif, ou d’un dispositif individuel, et une date jusqu’à laquelle cet état sera maintenu.

Le revers : perte, révocation, et ce qui ne migre pas

Un dispositif dont les clés ne sortent pas est un dispositif dont les clés sont perdues avec lui. Le règlement l’affronte, et la réponse est franche : il n’y a pas de sauvegarde des clés, il y a une révocation et une nouvelle délivrance.

L’article 7 réserve la révocation des attestations d’unité de portefeuille au seul fournisseur, lui impose de publier une politique précisant conditions et délais, et lui impose d’informer l’utilisateur dans les vingt-quatre heures de la révocation, de sa raison et de ses conséquences, « de manière concise, facilement accessible et dans un langage clair et simple ». L’article 6 complète par un droit : l’utilisateur peut demander la révocation de ses attestations, au moyen de mécanismes d’identification et d’authentification « indépendants des unités de portefeuille ». Ce dernier mot est le plus important de la phrase : il faut un canal de secours qui ne dépende pas de l’objet perdu, sans quoi la révocation est impossible précisément dans le cas où elle sert.

L’article 13 règle la portabilité, et l’exclusion qu’il contient mérite d’être lue deux fois. Les unités de portefeuille permettent « l’exportation et la portabilité sécurisées des données à caractère personnel de l’utilisateur », mais « en fonction des possibilités techniques et hors actifs critiques ». Les attributs, les attestations reçues et les journaux migrent vers un autre portefeuille ; les clés, non. Changer de fournisseur signifie donc regénérer des clés dans le nouveau dispositif et obtenir une nouvelle délivrance de ses attestations, ce qui est logique et coûteux. Le considérant 13 encourage d’ailleurs les fournisseurs à réutiliser les mêmes solutions techniques pour implémenter les processus de sauvegarde et de récupération, « permettant ainsi de récupérer des unités de portefeuille perdues ou de transférer des informations », mais toujours sous la même réserve. Le parallèle avec la sauvegarde et la restauration des clés d’un module matériel est éclairant, et l’écart est instructif : là où un module d’entreprise accepte des mécanismes d’export sous enveloppe, le portefeuille personnel ne les prévoit pas.

Reste la journalisation, qui est l’autre face de la protection et dont l’article 9 fixe le régime. Le portefeuille journalise les transactions, avec l’identité du vérificateur, les types de données demandées et présentées, et, pour les opérations inachevées, la raison de l’inachèvement. Le fournisseur garantit l’intégrité, l’authenticité et la confidentialité de ces journaux ; il n’y accède que « sur la base du consentement préalable explicite de l’utilisateur » et seulement quand c’est nécessaire à la fourniture du service ; et l’utilisateur peut les exporter. Le but affiché par le considérant 11 est la transparence et la possibilité de partager rapidement certaines informations avec les autorités de protection des données « en cas de comportement suspect des parties utilisatrices ». C’est une inversion de la logique habituelle de journalisation, qui mérite d’être notée : le journal est tenu pour que l’utilisateur surveille les services, et pas l’inverse.

Sources

Règlement d’exécution (UE) 2024/2979 de la Commission du 28 novembre 2024, intégrité et fonctionnalités essentielles des portefeuilles européens d’identité numérique.
Règlement d’exécution (UE) 2026/1731 de la Commission du 15 juillet 2026, normes et spécifications applicables.

🐝 Ce qui arrive si on s’en passe

Sans clé privée confinée dans un dispositif inviolable, une attestation d’identité se copie avec le fichier qui la porte, et la présentation ne prouve plus que son porteur est son titulaire. Sans condition d’exclusivité sur le composant qui exécute les opérations cryptographiques, un chemin de repli logiciel laissé pour les appareils anciens devient le chemin que tout attaquant emprunte. Sans authentification préalable de l’utilisateur à chaque opération, un logiciel malveillant installé sur l’appareil présente les attestations à la place de son propriétaire, sans qu’aucune signature ne soit en défaut. Sans attestation de clé indiquant la nature et la certification du stockage, le vérificateur ne peut pas distinguer une clé protégée par un élément sécurisé d’une clé rangée dans un fichier, et il traite les deux de la même façon. Sans mécanisme d’authentification indépendant du portefeuille, l’utilisateur qui a perdu son appareil ne peut pas demander la révocation, c’est-à-dire exactement dans le cas où elle est nécessaire. Et sans conscience que les actifs critiques ne migrent pas, un changement de fournisseur se présente comme une portabilité alors qu’il est une réinscription.

🦫 Explication de la marmotte 🍫

Un portefeuille d’identité numérique est une application qui conserve des justificatifs signés par une administration et les présente à la demande. Pour que cela vaille mieux qu’une photographie de carte d’identité, il faut qu’un seul appareil au monde puisse présenter ces justificatifs : le vôtre. Cela repose sur une clé secrète enfermée dans une puce de l’appareil, qui calcule à la demande mais ne rend jamais la clé elle-même.

Les textes européens nomment cette puce, et lui imposent quatre choses. Elle doit savoir fabriquer de nouvelles clés, savoir les effacer vraiment, savoir prouver qu’elle détient une clé sans la révéler, et protéger les clés pendant toute leur existence. Deux règles de plus comptent autant. Aucun autre composant ne doit pouvoir faire ces calculs, pour qu’il n’existe pas de chemin de contournement plus faible. Et rien ne doit se faire avant que l’utilisateur ne se soit identifié auprès de l’application, pour qu’un programme malveillant installé sur le téléphone ne puisse pas présenter vos papiers à votre place.

Reste une question : comment le commerçant ou l’administration qui reçoit le justificatif sait-il que la clé est bien dans une telle puce, et pas simplement dans un fichier ? Par une attestation signée, dite attestation de clé, qui décrit le type de stockage et renvoie à sa certification officielle. La promesse devient donc une information vérifiable, et non une affirmation du fabricant.

Le revers est prévisible : si la clé ne sort jamais, on ne peut pas la sauvegarder. En cas de perte du téléphone, il n’existe pas de restauration. Il faut faire révoquer l’ancien portefeuille, ce qui suppose un moyen de s’identifier qui ne dépende pas du téléphone perdu, puis en recréer un et redemander la délivrance de ses justificatifs. Les textes le disent clairement : on peut emporter ses attributs et ses journaux vers un autre portefeuille, mais pas ses clés.

Dernier détail qui mérite d’être connu : le portefeuille tient un journal de ses présentations, et ce journal appartient à l’utilisateur. Il sert à lui montrer qui lui a demandé quoi, et à signaler aux autorités de protection des données un service qui demande plus que son dû. C’est le contraire de l’usage habituel d’un journal.

Pages voisines

La citent

Les clés d'un portefeuille d'identité : où elles vivent et pourquoi elles ne sortent pas

Elle cite

: les deux pages se citent l’une l’autre.