Le holder binding expliqué : pourquoi une attestation copiée ne vaut rien
Une attestation signée est une excellente copie d’elle-même. Quiconque en obtient une dispose d’un document portant une signature valide de l’émetteur, et la vérification de cette signature lui confirmera volontiers qu’il est authentique. Le holder binding comble cette faille : il lie l’attestation à une clé qu’une seule personne peut utiliser, de sorte que la posséder ne suffit pas pour la présenter.
Cette page en est la version en langage clair. Elle explique ce qu’est réellement ce lien, quand il est créé, comment les deux formats d’attestation européens le mettent en œuvre, et le point que la plupart des explications passent sous silence : ce que le holder binding ne dit toujours pas au vérificateur.
Le problème qu’il résout
Les documents numériques se copient parfaitement. La photo d’un passeport est une piètre contrefaçon, car le papier porte des caractéristiques physiques qu’une photocopie perd. Une attestation signée n’a pas ce genre d’indice. Copiez le fichier et la copie se vérifie exactement aussi bien que l’original, car la signature de l’émetteur couvre le contenu et le contenu n’a pas changé.
Un vérificateur qui ne contrôle que la signature de l’émetteur répond donc à la mauvaise question. Il a appris que les données sont authentiques. Il n’a rien appris sur le droit de la partie en face de lui à s’en prévaloir, ce qui est généralement précisément ce qu’il avait besoin de savoir.
Les données
Les faits qu’énonce l’attestation : un nom, une date de naissance, une catégorie de permis, un numéro d’entreprise. C’est la partie que tout le monde imagine quand on parle d’attestation.
La signature de l’émetteur
La preuve que ces faits proviennent de l’émetteur et n’ont pas été modifiés depuis. Elle ne dit absolument rien de qui les détient aujourd’hui.
La clé publique du détenteur
L’élément qui crée le lien. L’émetteur inscrit la clé publique du détenteur dans l’attestation signée, si bien que l’attestation désigne désormais la clé autorisée à la présenter.
Quand le lien est créé, et quand il est utilisé
Le lien est établi une seule fois, à l’émission, et il est mis en jeu à chaque présentation de l’attestation. Le détenteur n’en voit rien, hormis la demande de déverrouillage à laquelle il s’attend déjà.
1. Le portefeuille crée une clé
Avant de demander quoi que ce soit, le portefeuille crée une nouvelle paire de clés dans le matériel sécurisé du téléphone. La moitié privée ne peut pas être relue, pas même par l’application du portefeuille.
2. L’émetteur l’inscrit
Le portefeuille envoie la moitié publique avec sa demande et prouve qu’il détient la moitié privée. L’émetteur place cette clé publique dans l’attestation avant de la signer.
3. Un vérificateur demande
La demande contient une nouvelle valeur aléatoire et indique qui la fait, de sorte que la réponse ne peut servir qu’une fois, et uniquement à la partie qui l’a demandée.
4. Le portefeuille signe
Le portefeuille signe la réponse avec la clé privée, généralement après une empreinte digitale ou un PIN. Le vérificateur contrôle cette signature avec la clé contenue dans l’attestation.
Où se trouve réellement la clé privée
Le lien ne vaut jamais plus que la difficulté d’utiliser la clé sans le détenteur. C’est pourquoi les portefeuilles génèrent ces clés dans un matériel dédié, le secure element ou son équivalent qui protège aussi les moyens de paiement du téléphone, plutôt que de les stocker dans un fichier que le système d’exploitation peut remettre à n’importe quelle application qui le demande.
Le vérificateur ne peut rien en voir dans la présentation elle-même. Une signature prouve que la clé a été utilisée, pas qu’elle a été bien gardée. Savoir si la clé se trouve vraiment dans un matériel certifié relève d’une garantie distincte, portée par les attestations qu’un portefeuille présente à un émetteur avant de recevoir quoi que ce soit. Selon les règles européennes, c’est précisément à cela que servent l’attestation de portefeuille et l’attestation de clé.
Le holder binding répond à
Cette réponse a-t-elle été produite à l’instant, pour cette demande, par la clé pour laquelle l’attestation a été émise ?
L’attestation de clé répond à
Cette clé est-elle conservée à un endroit d’où un attaquant ne peut pas l’extraire ? Autre question, autre preuve, tranchée à l’émission.
Comment les deux formats européens s’y prennent
L’idée est la même dans les deux formats sur lesquels repose le portefeuille européen. La mécanique diffère, ce qui compte pour qui implémente un vérificateur et pour presque personne d’autre.
SD-JWT VC
L’émetteur place la clé publique du détenteur dans un claim de confirmation au sein de l’attestation signée. Lors de la présentation, le portefeuille ajoute un petit jeton séparé, signé avec la clé privée, qui couvre l’identité du vérificateur et la valeur aléatoire de la demande. Un vérificateur qui ignore ce jeton a vérifié l’émetteur, et rien d’autre.
Lire la définitionmdoc
La clé de l’appareil figure dans l’objet signé qui protège les éléments de données, et le téléphone signe la transcription de la session en cours. Comme cette transcription couvre l’échange entre les deux appareils, l’enregistrement d’une présentation ne peut pas être rejoué dans une autre. C’est ce qui rend sûr un contrôle hors ligne au bord de la route ou à une porte.
Lire la définitionUn portefeuille de l’écosystème européen porte en général la même attestation dans les deux formats et remet celle que l’autre partie comprend. Une organisation qui accepte des attestations doit donc pouvoir vérifier le lien dans les deux.
Ce que le holder binding ne prouve pas
Le holder binding prouve le contrôle d’une clé. Il ne prouve pas qui tient le téléphone. Une personne à qui l’on a confié l’appareil et le PIN produit exactement la même réponse valide que le détenteur légitime, et aucune cryptographie dans l’attestation ne peut faire la différence.
Il ne dit rien non plus de la rigueur avec laquelle l’émetteur a vérifié l’identité avant l’émission. Une attestation liée à une clé n’est jamais plus fiable que le processus qui l’a créée, et c’est ce que décrit un Level of Assurance. Lier très solidement à une clé une attestation émise à la légère ne rend pas les données qu’elle contient plus vraies.
Mis bout à bout, le partage des rôles est assez clair. Le holder binding empêche le rejeu et la copie, le déverrouillage du portefeuille rattache la clé à une personne présente, le Level of Assurance décrit la qualité de l’identification de cette personne, et une trusted list indique quels émetteurs vous acceptez tout court. Un vérificateur qui veut une vraie réponse a besoin des quatre, pas seulement de celui qui vient gratuitement avec l’attestation.
Ce que cela signifie pour vous
Émetteur
Vos attestations ne servent plus à rien à qui en vole une copie, ce qui élimine toute une catégorie de fraude que vous devriez sinon détecter après coup. En contrepartie, vous devez être prêt à réémettre chaque fois qu’un détenteur change d’appareil.
Vérificateur
Vérifiez le lien, pas seulement la signature de l’émetteur. Envoyez une nouvelle valeur aléatoire à chaque demande et rejetez toute réponse qui ne la signe pas, sinon une présentation enregistrée pourra vous être rejouée plus tard.
Titulaire du portefeuille
Rien à gérer, et une chose à savoir : vos attestations sont liées à cet appareil. Un nouveau téléphone signifie donc les obtenir à nouveau, et non les restaurer depuis une sauvegarde.
Termes associés
Questions fréquentes
Le holder binding est-il la même chose que le key binding ou le device binding ?
En pratique, oui. Les termes diffèrent parce qu’ils viennent de spécifications différentes, pas parce que leur sens diffère. Le holder binding est la propriété : cette attestation appartient à ce détenteur. Key binding est le nom que l’univers SD-JWT VC donne au mécanisme, et côté ISO on parle de device binding ou de device authentication, parce que la clé se trouve dans un téléphone précis. Si un document emploie l’un de ces termes, lisez-le comme la même idée vue sous un autre angle.
Le holder binding prouve-t-il que la personne qui présente l’attestation en est bien le sujet ?
Non, et c’est de loin le contresens le plus fréquent. Il prouve que celui qui a produit la réponse contrôle la clé pour laquelle l’attestation a été émise. Savoir si la personne qui touche l’écran du téléphone est celle que décrivent les données dépend de la façon dont le portefeuille se déverrouille, du soin avec lequel l’émetteur a vérifié l’identité au départ, et du fait que le détenteur ait ou non confié l’appareil et le PIN à quelqu’un d’autre. Pour un contrôle à fort enjeu, on associe le lien à un portefeuille qui exige la biométrie et à une attestation émise à un Level of Assurance adapté au risque.
Que devient une attestation liée quand le détenteur change de téléphone ?
Elle ne suit pas. Tout l’intérêt de conserver la clé privée dans un matériel sécurisé est qu’elle ne peut pas être exportée : une attestation liée à l’ancien téléphone ne peut donc pas être restaurée sur le nouveau en espérant qu’elle fonctionne. Le nouvel appareil génère sa propre clé et l’attestation est émise à nouveau pour celle-ci. Prévoyez la réémission comme un événement normal et fréquent, pas comme une exception, car pour vos utilisateurs, c’est simplement le jour où ils ont changé de téléphone.
Existe-t-il des attestations sans holder binding ?
Oui, et elles ont leur utilité. Une attestation sans holder binding est une attestation au porteur : celui qui la présente en profite, comme avec un billet papier. C’est un compromis raisonnable pour quelque chose de faible valeur et de courte durée, où le coût d’une copie rejouée est faible et où l’on préfère ne rien faire déverrouiller au détenteur. C’est le mauvais choix pour l’identité, les droits et tout ce qu’un fraudeur jugerait utile de réutiliser.
Sources
- IETF SD-JWT-based Verifiable Digital Credentials (SD-JWT VC), encore à l’état de projet
- OpenID for Verifiable Credential Issuance, sur la preuve de possession de la clé à l’émission
- OpenID for Verifiable Presentations, sur le lien entre une réponse et une seule demande
- ISO/IEC 18013-5, sur l’authentification de l’appareil pour les documents mobiles
Cette page est informative et ne constitue pas un avis juridique. Pour la formulation qui fait autorité, consultez directement les spécifications.