Attestation matérielle HSM des clés générées

L’attestation matérielle établit une preuve signée qu’une clé a été générée dans un HSM (Hardware Security Module) identifié, dans un état matériel et logiciel donné. Elle ne remplace ni la certification du module, ni la gestion du cycle de vie des clés : elle relie une clé précise à une instance précise de confiance.

→ Lire l’explication complète de la marmotte

Attestation HSM : la preuve attendue

Un certificat FIPS (Federal Information Processing Standards) ou Common Criteria qualifie un modèle de module, une version matérielle, un firmware et une configuration évaluée. Il ne prouve rien sur une clé donnée. Une attestation de clé, elle, est un objet signé par une identité d’attestation du constructeur ou du domaine de sécurité du HSM. Elle doit au minimum lier :

la clé publique, ou son empreinte calculée selon un format documenté ;
l’identifiant d’objet ou le label de clé, si cette valeur entre dans le périmètre signé ;
les attributs cryptographiques, notamment l’algorithme, la taille, les usages autorisés et le caractère non exportable ;
l’identité du module, son firmware et son état de sécurité ;
une valeur aléatoire fournie par le vérificateur, appelée nonce ;
la chaîne de certificats qui remonte à une racine de confiance connue.

Le compromis central est net : l’attestation apporte une preuve exploitable hors du HSM, mais transfère une part de confiance au constructeur, à sa chaîne de certification et au protocole de vérification. Cette dépendance est acceptable pour une clé racine de signature, une KEK (Key Encryption Key) ou une clé de signature réglementée. Elle ne justifie pas de transformer chaque clé éphémère en cérémonie cryptographique avec trois PDF et un tableur agonisant.

La recommandation est de rendre l’attestation obligatoire lors de la création des clés à haute valeur, puis de conserver la preuve avec les métadonnées de la clé. Pour les clés de données de courte durée, une politique de génération interne vérifiée par contrôle d’accès et journalisation est généralement plus proportionnée. La frontière dépend de la conséquence d’une importation frauduleuse, pas du nombre de logos sur la slide d’architecture.

PKCS#11 (Public-Key Cryptography Standards #11) expose des attributs tels que CKA_LOCAL, indiquant qu’une clé a été générée localement, et CKA_EXTRACTABLE, indiquant si elle peut être extraite. Ces attributs ne sont pas une attestation : une application qui interroge le module obtient une déclaration du module via une session déjà autorisée. Une preuve transférable à un tiers exige une signature vérifiable et un ancrage de confiance externe. La présentation du modèle PKCS#11 permet de replacer cette distinction dans les objets et sessions du module.

Chaîne de confiance et liaison de la clé

Le vérificateur doit posséder, ou récupérer depuis un dépôt authentifié, le certificat racine d’attestation du fabricant. Accepter une racine livrée dans la réponse d’attestation revient à demander au prisonnier de fournir aussi le juge. La racine doit être épinglée, versionnée et renouvelée suivant une procédure distincte de celle des clés applicatives.

La signature doit couvrir un défi frais. Sans nonce, une attestation capturée pour une ancienne clé peut être rejouée devant un service qui attend une preuve actuelle. Le défi doit être tiré avec un générateur aléatoire cryptographiquement sûr, associé à une demande unique, expiré rapidement et invalidé après vérification. Un horodatage seul ne suffit pas : l’heure du module peut être imprécise, manipulable ou absente du périmètre de sécurité.

La liaison entre la preuve et la clé est le point où les intégrations se trompent le plus souvent. Comparer uniquement un label est insuffisant : les labels peuvent être dupliqués, modifiés ou tronqués selon les bibliothèques. Comparer uniquement un identifiant interne est insuffisant si cet identifiant n’est pas signé. Il faut recalculer localement l’empreinte de la clé publique ou valider la structure de clé incluse dans le document signé, puis vérifier qu’elle correspond exactement à la clé enregistrée dans le système cible.

Pour une clé symétrique, la valeur de clé ne doit évidemment pas sortir pour être comparée. L’attestation doit alors couvrir un identifiant d’objet immuable, ses attributs et une empreinte construite dans le HSM selon un schéma documenté. Si le constructeur ne fournit aucune liaison cryptographique vérifiable pour une clé symétrique, il faut considérer qu’il ne fournit pas d’attestation de cette clé. CKA_LOCAL=true n’est pas un substitut décoré d’un peu de vocabulaire conformité.

Vérification d’une attestation X.509

X.509 désigne le format usuel de certificats à clé publique. Les formats d’attestation restent propriétaires : PKCS#11 ne normalise ni le document signé ni la chaîne de certificats associée. Il faut donc encapsuler le validateur du constructeur derrière une interface locale et journaliser la version du validateur utilisée.

L’exemple suivant vérifie une chaîne de certificats puis une signature de défi RSA (Rivest, Shamir, Adleman). Les fichiers d’attestation doivent avoir été exportés par l’outil du constructeur après une demande contenant challenge.bin. La commande ne valide pas les attributs métier : cette vérification doit être codée contre le format d’attestation concerné.

# Générer un défi unique et conserver son identifiant côté service demandeur.
openssl rand -out challenge.bin 32

# Vérifier que le certificat d'attestation remonte à la racine épinglée.
openssl verify -CAfile manufacturer-attestation-root.pem \
  -untrusted hsm-attestation-intermediate.pem \
  hsm-attestation-certificate.pem

# Vérifier que le HSM a signé exactement le défi soumis.
openssl x509 -in hsm-attestation-certificate.pem -pubkey -noout \
  | openssl pkey -pubin -out attestation-public-key.pem

openssl dgst -sha256 -verify attestation-public-key.pem \
  -signature challenge.signature challenge.bin

Après cette étape, le validateur doit extraire le document d’attestation, vérifier son schéma, rejeter les champs inconnus lorsque le format l’exige, et comparer algorithme, taille, usages et empreinte de clé avec la politique attendue. Une signature valide sur une structure partiellement interprétée est une vulnérabilité classique : le champ ignoré est souvent celui qui porte la restriction de sécurité. Les parseurs permissifs sont charmants jusqu’au moment où ils deviennent un protocole maison.

Une preuve validée mérite un enregistrement immuable : empreinte de l’attestation, empreinte de la clé publique, chaîne validée, identifiant du validateur, date de contrôle, politique appliquée et résultat. Conserver seulement « attestation OK » interdit toute révision après compromission d’une racine constructeur ou découverte d’un défaut de firmware.

Surface d’attaque de l’attestation matérielle

L’attaque la plus rentable consiste à substituer la chaîne de confiance. Un certificat d’attestation émis par une autorité non épinglée, une racine de test restée active ou un magasin de certificats système trop large permettent de faire valider un faux module. La contre-mesure est de maintenir un magasin dédié aux racines d’attestation, sans réutiliser celui des autorités de certification Web.

Le rejeu est la seconde attaque attendue. Un document signé sans défi, ou signé avec un défi réutilisable, prouve seulement qu’un événement a existé. Il ne prouve pas que le module répond maintenant, ni que la clé demandée est celle enregistrée dans la requête. Le nonce doit être imprévisible, lié à l’opération et consommé atomiquement.

L’attestation ne protège pas contre un opérateur légitime qui demande la génération d’une clé avec des usages excessifs. Une clé attestée mais autorisée à signer, déchiffrer et exporter sous wrapping est conforme à sa preuve, pas à une politique raisonnable. Les attributs attendus doivent être décidés avant génération, puis refusés si l’attestation diverge. La séparation entre KEK et DEK (Data Encryption Key) reste nécessaire, comme détaillé dans KEK et DEK.

Un HSM compromis après émission peut continuer à présenter une attestation historiquement valide. L’attestation n’est pas une sonde magique dans le silicium. Il faut suivre les avis de sécurité du constructeur, retirer les versions de firmware interdites de la politique, et ré-attester après une mise à jour ou une restauration. Une révocation de certificat n’annule pas les décisions déjà prises par les applications : il faut retrouver les preuves stockées et déclencher une revue des clés concernées.

Exploitation : rotation, sauvegarde et haute disponibilité

La rotation d’une clé attestée crée une nouvelle identité cryptographique et exige une nouvelle attestation. Réutiliser l’ancienne preuve après régénération de la clé, même avec le même label, casse la liaison recherchée. Le processus de rotation des clés doit donc traiter l’attestation comme un artefact obligatoire de création.

Les clés d’attestation du constructeur et les certificats intermédiaires expirent aussi. Leur supervision doit couvrir la date d’expiration, les listes de révocation, les changements de racines acceptées et les versions de firmware autorisées. Une alerte à trente jours est insuffisante si la validation est embarquée dans des applications compilées et distribuées lentement. Le certificat qui expire le dimanche garde une régularité presque artistique.

En haute disponibilité, chaque membre du cluster doit pouvoir produire une preuve dont l’identité correspond à la politique. Une attestation d’un nœud ne prouve pas qu’une clé clonée ou synchronisée est protégée de la même façon sur les autres nœuds. Il faut attester chaque réplique, enregistrer les identités de modules autorisées et tester le basculement avec validation de preuve. Les contraintes de réplication et de quorum sont traitées dans l’architecture HSM haute disponibilité.

La sauvegarde pose une limite franche. Une sauvegarde chiffrée ou wrapped prouve la capacité à restaurer, pas que la clé restaurée conserve la même identité matérielle. Après restauration sur un autre module, exiger une nouvelle attestation et mettre à jour la relation de confiance. Une preuve de génération initiale ne voyage pas avec les bandes, même si le chiffrement des sauvegardes est impeccable.

🐝 Ce qui arrive si on s’en passe

Sans attestation matérielle, rien ne prouve qu’une clé a réellement été générée et conservée dans un HSM identifié plutôt qu’exportée, copiée ou fabriquée ailleurs. On se contente alors de croire sur parole une application qui affirme protéger un secret, sans preuve signée reliant cette clé précise à une instance de confiance précise dans un état matériel et logiciel donné. La conséquence est qu’une clé compromise ou générée hors du module peut se faire passer pour protégée, et qu’un audit ne peut pas vérifier l’origine du matériel cryptographique sur lequel repose toute la chaîne de confiance. L’absence de ce reçu scellé laisse subsister l’écart entre ce qu’un système prétend garantir et ce qu’il garantit vraiment, un écart que seul un attestataire indépendant du logiciel appelant pouvait fermer.

🦫 Explication de la marmotte 🍫

Un module matériel de sécurité est un appareil conçu pour créer et utiliser des clés secrètes sans les laisser apparaître en clair dans les applications. Une attestation est un document signé par cet appareil, ou par une identité liée à son fabricant. Le document contient des informations sur une clé donnée : sa partie publique quand elle existe, ses règles d’usage, l’appareil qui l’a créée et sa version logicielle.

Pour vérifier la preuve, le service qui demande l’attestation commence par produire une valeur aléatoire nouvelle. Cette valeur est envoyée avec la demande. L’appareil signe alors cette valeur et les informations sur la clé. Le service vérifie la signature avec un certificat de confiance obtenu à l’avance, puis contrôle que la clé décrite correspond bien à celle qu’il veut autoriser. Il vérifie aussi que l’appareil et sa version sont acceptés par sa politique.

Si la valeur aléatoire manque ou est réutilisée, une ancienne preuve peut être présentée de nouveau. Si le certificat de confiance n’est pas contrôlé, un faux appareil peut fournir sa propre preuve. Si les règles d’usage de la clé ne sont pas comparées, une clé créée avec des permissions trop larges peut être acceptée.

Cette preuve ne garantit pas qu’une application autorisée utilisera bien la clé, ni qu’un appareil restera sans défaut après la vérification. Il faut donc renouveler la vérification après une restauration, un remplacement d’appareil ou une mise à jour, surveiller les certificats, et remplacer les clés selon une règle prévue.

Pages voisines

La citent

Attestation matérielle HSM des clés générées

Elle cite

Attestation matérielle HSM des clés générées

Attestation matérielle HSM des clés générées

Attestation HSM : la preuve attendue

Chaîne de confiance et liaison de la clé

Vérification d’une attestation X.509

Surface d’attaque de l’attestation matérielle

Exploitation : rotation, sauvegarde et haute disponibilité

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines