Vulnérabilités documentées des HSM certifiés

Un HSM (Hardware Security Module) réduit drastiquement le risque d’extraction d’une clé privée ou secrète. Il ne le supprime pas. Une certification évalue une cible, une configuration et une version données, à un instant donné : elle ne transforme pas le firmware en objet mathématiquement immortel.

→ Lire l’explication complète de la marmotte

La certification HSM ne couvre pas les vulnérabilités futures

Une certification FIPS 140-2 (Federal Information Processing Standard) ou FIPS 140-3, et une évaluation Common Criteria, attestent qu’un produit satisfait un référentiel précis dans une configuration identifiée. Le certificat vise une version matérielle, une version de firmware, des algorithmes, parfois une bibliothèque cliente, et des options de compilation. Changer le firmware, remplacer une carte réseau de gestion ou activer un mécanisme supplémentaire peut faire sortir du périmètre évalué.

Le compromis central est brutal : le HSM fournit une frontière d’extraction de clés bien plus résistante qu’un processus logiciel, mais cette frontière devient un composant critique à maintenir, surveiller et faire évoluer. La recommandation est donc nette : traiter le HSM comme un équipement de sécurité exposé aux vulnérabilités, pas comme une boîte scellée que l’on installe puis oublie derrière une baie. L’immobilité rassure jusqu’au jour où elle devient une dette de sécurité avec ventilateur intégré.

Une certification ne prétend pas qu’aucun défaut n’existe. Elle montre qu’un laboratoire a exécuté un ensemble de tests et examiné des preuves selon les exigences applicables. Elle ne couvre généralement ni les attaques découvertes après l’évaluation, ni les erreurs d’intégration, ni les droits excessifs attribués dans l’application cliente, ni l’exposition imprudente de l’administration réseau.

Les vulnérabilités documentées dans des firmwares, bibliothèques cryptographiques embarquées et interfaces de gestion rappellent une règle : la racine de confiance dépend aussi de son code. Un défaut dans l’implémentation RSA (Rivest, Shamir, Adleman), ECC (Elliptic Curve Cryptography) ou PKCS#11 (Public-Key Cryptography Standards numéro 11) peut affecter un composant pourtant certifié. Le certificat reste valable pour l’objet évalué, pas pour l’hypothèse que la recherche s’arrête poliment après sa délivrance.

La présentation des HSM explique pourquoi une clé non exportable est précieuse. Cette propriété doit toutefois être lue précisément : « non exportable » signifie que l’interface normale interdit l’export en clair. Cela ne garantit pas qu’aucune séquence d’appels autorisés, aucun bug firmware ou aucun compte d’administration compromis ne puisse provoquer une violation de cette règle.

Attaques PKCS#11 par composition d’opérations autorisées

PKCS#11 expose des objets cryptographiques et des mécanismes tels que le chiffrement, le déchiffrement, la signature, le wrapping et l’unwrapping. Le wrapping chiffre une clé sous une autre clé, appelée KEK (Key Encryption Key), afin de déplacer ou sauvegarder la première sans l’exposer en clair. L’unwrapping importe ensuite cette clé protégée.

Une attaque PKCS#11 classique ne casse pas AES (Advanced Encryption Standard) ou RSA. Elle abuse de la politique d’usage des clés. Une clé peut être non exportable tout en étant autorisée à chiffrer, déchiffrer, wrapper ou unwraper. Si les attributs autorisent des combinaisons incompatibles, l’attaquant disposant d’une session authentifiée peut transformer le HSM en oracle cryptographique.

Les travaux de Mike Bond et Richard Clulow sur les attaques API contre les tokens cryptographiques, puis ceux portant sur les attaques de type wrap-decrypt, ont documenté le mécanisme : sous certaines politiques, une clé cible est wrappée sous une clé contrôlée ou transformée en une valeur déchiffrable. Chaque appel est valide. La séquence entière détruit pourtant la non-exportabilité. C’est moins spectaculaire qu’un laser dirigé vers une puce, mais beaucoup plus compatible avec une journée ordinaire de production. La crypto adore ce genre de bureaucratie meurtrière : chaque case est cochée, le secret est quand même parti.

Les attributs PKCS#11 critiques sont notamment :

CKA_EXTRACTABLE, qui détermine si une clé peut sortir sous forme wrappée ;
CKA_SENSITIVE, qui interdit la lecture de la valeur en clair ;
CKA_WRAP et CKA_UNWRAP, qui autorisent le transport protégé de clés ;
CKA_ENCRYPT et CKA_DECRYPT, qui peuvent créer des oracles dangereux ;
CKA_ALLOWED_MECHANISMS, qui limite explicitement les mécanismes applicables ;
les attributs propres au fournisseur, souvent nécessaires pour séparer les rôles et les domaines de clés.

Interdire CKA_EXTRACTABLE ne suffit pas. Une clé sensible non extractable ne doit pas servir indistinctement au wrapping, au déchiffrement de données applicatives et à l’import de clés. Une KEK de sauvegarde doit être dédiée à ce rôle, avec des mécanismes et des droits restreints. Une clé de signature ne doit jamais posséder des capacités de wrapping « au cas où ». Le « au cas où » est une expression qui finit souvent dans un rapport d’incident.

La séparation doit porter sur trois axes : types de clés, mécanismes autorisés et identités appelantes. Une partition HSM ou un domaine cryptographique distinct pour les KEK de sauvegarde et les clés applicatives réduit les chemins d’attaque. Une politique d’attributs imposée côté HSM est préférable à une convention applicative : une convention vit dans un wiki, une politique refusée par le module vit dans la réalité.

Les mécanismes de wrap et unwrap restent nécessaires pour la sauvegarde et la migration. Ils imposent simplement une modélisation des droits, pas un bouton magique marqué « sécurité ».

Firmware et interface d’administration réseau

Le firmware contient le code qui applique les contrôles d’accès, génère les nombres aléatoires, pilote les accélérateurs cryptographiques et traite les commandes de gestion. Une vulnérabilité à ce niveau peut contourner les garanties présentées par l’API. Les correctifs peuvent concerner une élévation de privilèges, une corruption mémoire, une validation insuffisante de commandes, une faiblesse dans une primitive embarquée ou une fuite d’information via un canal auxiliaire.

L’interface d’administration constitue une surface distincte de l’interface PKCS#11. Elle permet typiquement de créer des partitions, gérer des comptes, importer des certificats d’administration, configurer la haute disponibilité, appliquer le firmware et consulter l’état matériel. La rendre accessible depuis le réseau applicatif ou, pire, depuis un réseau d’administration étendu, transforme un composant de confiance en serveur exposé. Le chiffrement du canal ne corrige pas une authentification faible ni une vulnérabilité du service distant.

L’administration doit donc être placée dans un réseau dédié, filtré à la source et à la destination. Aucun accès Internet direct, aucun rebond générique partagé, aucun compte local permanent pour l’exploitation courante. L’authentification multifacteur, la journalisation centralisée et la séparation des rôles sont requises pour les actions capables de modifier les politiques, exporter un objet wrappé ou mettre à jour le firmware.

La haute disponibilité ne justifie pas l’ouverture large des interfaces de synchronisation. Dans une architecture active/passive ou active/active, seuls les flux documentés entre membres du groupe doivent être autorisés. Les flux d’administration et de réplication ne sont pas interchangeables. La conception d’un HSM haute disponibilité doit intégrer ce cloisonnement dès le départ, car le rattraper après création des partitions coûte généralement une fenêtre de maintenance, une migration de clés et quelques jurons parfaitement prévisibles.

Vérifier les mécanismes PKCS#11 avant l’exposition applicative

L’inventaire des mécanismes réellement publiés par un module doit faire partie de la recette de sécurité. Il détecte l’activation involontaire d’un mécanisme ancien, l’absence d’une restriction attendue ou une différence entre environnements. Cette commande utilise pkcs11-tool, fourni par OpenSC (Open Secure Card Development Tools), et interroge un module déjà accessible depuis l’hôte d’administration.

# Définir le chemin de la bibliothèque PKCS#11 fournie par le constructeur.
export PKCS11_MODULE=/opt/vendor/lib/libpkcs11.so

# Lister les mécanismes exposés par le token sélectionné.
# Conserver la sortie avec l'identifiant de firmware et la date de contrôle.
pkcs11-tool \
  --module "$PKCS11_MODULE" \
  --list-mechanisms \
  --login

# Rechercher les mécanismes de wrapping ou de chiffrement non prévus.
# La liste attendue doit être définie par partition et par profil de clés.
pkcs11-tool \
  --module "$PKCS11_MODULE" \
  --list-mechanisms \
  --login | grep -E 'WRAP|UNWRAP|RSA-PKCS|AES'

Cette vérification ne prouve pas l’absence d’une attaque API. Elle fournit une base pour comparer l’exposition réelle à la politique attendue. Il faut compléter par un test négatif : tenter, avec un compte applicatif de recette, une opération interdite par conception, par exemple wrapper une clé de production avec une KEK non autorisée. Le test doit échouer au niveau du HSM, pas uniquement dans le code client.

La bibliothèque PKCS#11 côté hôte compte autant que le firmware pour l’exploitation : une version vulnérable peut altérer les requêtes, les journaux ou la vérification de certificat d’administration. Les principes d’utilisation de PKCS#11 restent applicables, mais la dépendance doit être inventoriée comme un paquet critique avec version, empreinte, provenance et procédure de retour arrière.

Mise à jour, rotation et reprise après incident HSM

Un processus de mise à jour firmware doit commencer par l’avis de sécurité du fournisseur et l’analyse de compatibilité : modèle précis, version source, version cible, pilotes clients, bibliothèque PKCS#11, interopérabilité avec les membres du groupe HA, algorithmes activés et statut de certification de la version cible. Une mise à jour sans matrice de compatibilité est une expérience de physique appliquée, mais sans le budget du laboratoire.

Avant toute opération, vérifier une sauvegarde restaurable des objets wrappés, des politiques de partition, des certificats d’administration et des paramètres de haute disponibilité. La sauvegarde ne doit jamais contenir les clés en clair. Sa restauration doit être testée sur un environnement isolé et sur un matériel ou service de remplacement compatible. Une sauvegarde que personne ne peut restaurer n’est pas une sauvegarde, c’est une archive décorative.

La fenêtre de mise à jour doit prévoir l’indisponibilité possible d’un membre, la resynchronisation contrôlée, les tests de signature ou de chiffrement, et la vérification de l’accès applicatif après bascule. Une compatibilité HA annoncée ne remplace pas le test de retour arrière. Certaines mises à jour sont irréversibles ou exigent une conversion de données internes : la procédure fournisseur doit être lue avant de charger l’image, détail étonnamment révolutionnaire dans un secteur qui adore cliquer sur « upgrade ».

En cas de vulnérabilité permettant une extraction ou une utilisation non autorisée, considérer les clés concernées comme compromises. Mettre à jour le firmware ne révoque pas une clé déjà divulguée. Il faut générer de nouvelles clés, rewrapper les DEK (Data Encryption Key) lorsque l’architecture le permet, renouveler les certificats de signature ou de TLS (Transport Layer Security), invalider les identifiants d’administration et rechercher les opérations suspectes dans les journaux. La rotation des clés doit donc être planifiée avant l’incident, avec un inventaire des dépendances par clé.

Ce mécanisme ne garantit pas la confidentialité des données déjà déchiffrées par une application compromise, ni la sécurité d’un administrateur légitime devenu malveillant, ni l’intégrité d’un serveur client qui demande des opérations autorisées. Le HSM protège une frontière cryptographique. La sécurité restante vient de l’IAM (Identity and Access Management), du cloisonnement réseau, du durcissement des hôtes, de la supervision et de la séparation des responsabilités.

🐝 Ce qui arrive si on s’en passe

Sans inventaire des mécanismes ni politique d’attributs imposée par le module, le déchiffrement RSA PKCS#1 v1.5 reste souvent actif : chaque unwrap accepté ou refusé renseigne sur la validité du bourrage, et le HSM devient l’oracle décrit dans « la question qui rend le module bavard ». L’attaquant récupère alors le contenu d’une clé wrappée, ou obtient une signature valide d’une clé qu’il n’a jamais extraite. Sans versions de firmware et de bibliothèque consignées par partition, un avis de sécurité ne peut pas être rapproché des clés réellement exposées : toutes doivent être traitées comme compromises. Sans journaux d’administration centralisés, le début d’un abus reste impossible à dater ; aucune signature produite depuis la dernière configuration vérifiée ne peut plus être distinguée d’une signature frauduleuse, ce qui force des révocations bien au-delà du périmètre réellement touché.

🦫 Explication de la marmotte 🍫

Un module cryptographique matériel conserve des clés secrètes et réalise des opérations de chiffrement ou de signature sans donner normalement la valeur de ces clés aux programmes qui l’utilisent. Un programme demande une opération, le module vérifie ses droits, puis renvoie le résultat. Cette protection dépend du logiciel installé dans le module, de ses réglages et des interfaces accessibles depuis le réseau.

Une attaque peut exploiter une erreur dans ce logiciel ou dans les règles autorisées. Par exemple, deux actions permises séparément peuvent être combinées pour obtenir une clé sous une forme réutilisable ailleurs. Le module peut aussi contenir une erreur dans son interface d’administration. Une personne qui obtient des droits d’administration pourrait alors modifier des règles, installer une version dangereuse ou accéder à des fonctions qui ne devraient pas être disponibles.

Un certificat de sécurité indique que le produit a été testé selon des règles données et dans une version donnée. Il ne protège pas contre une erreur découverte plus tard. Quand une erreur est publiée, il faut vérifier si le matériel et le logiciel concernés sont touchés, installer le correctif après test, puis contrôler que les opérations habituelles fonctionnent encore.

Si une clé a pu être copiée ou utilisée sans autorisation, remplacer seulement le logiciel ne suffit pas. Il faut créer de nouvelles clés, remplacer les certificats associés, vérifier les journaux et empêcher les anciens comptes d’accéder au module.

Pages voisines

La citent

Vulnérabilités documentées des HSM certifiés

Elle cite

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

Vulnérabilités documentées des HSM certifiés

Vulnérabilités documentées des HSM certifiés

La certification HSM ne couvre pas les vulnérabilités futures

Attaques PKCS#11 par composition d’opérations autorisées

Firmware et interface d’administration réseau

Vérifier les mécanismes PKCS#11 avant l’exposition applicative

Mise à jour, rotation et reprise après incident HSM

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines