Lire une certification FIPS 140-3 ou Critères Communs d’un HSM

Un HSM (Hardware Security Module) se vend rarement sans un logo de certification sur la fiche produit. Ces certifications disent des choses précises sur une version figée d’un module, dans un périmètre défini, et rien du tout sur le reste. Savoir les lire évite d’acheter un label à la place d’une garantie.

→ Lire l’explication complète de la marmotte

Niveaux de sécurité FIPS 140 : ce qui change physiquement

FIPS (Federal Information Processing Standard) 140 est la norme américaine de validation des modules cryptographiques, appliquée par le CMVP (Cryptographic Module Validation Program) du NIST (National Institute of Standards and Technology). FIPS 140-3, en vigueur depuis 2020, reprend la norme ISO/IEC (Organisation internationale de normalisation, Commission électrotechnique internationale) 19790. Les quatre niveaux se distinguent surtout par la sécurité physique :

Niveau 1 : aucune exigence physique. Une bibliothèque logicielle l’obtient. Face à un tournevis, aucune garantie.
Niveau 2 : preuve d’intrusion (scellés, revêtements). L’ouverture laisse une trace sans être empêchée. Authentification par rôle.
Niveau 3 : détection et réponse. Ouvrir le boîtier déclenche la mise à zéro (zeroization) des paramètres de sécurité critiques, c’est-à-dire l’effacement actif des clés. Authentification par identité, interfaces des secrets séparées, import de clés uniquement chiffrées ou fractionnées.
Niveau 4 : enveloppe complète, pénétration détectée par n’importe quelle face, protection contre les tensions et températures hors plage. FIPS 140-3 y ajoute l’authentification multifacteur.

Chaque niveau ajoute des capteurs, donc des fausses alertes, et un effacement qui ne distingue pas l’attaquant du technicien maladroit. Le niveau 4 se justifie hors d’une salle maîtrisée ; en centre de données avec contrôle d’accès physique, le niveau 3 couvre le risque réel.

Lire un certificat CMVP sans se faire piéger

Le certificat donne un niveau par domaine (onze au total) et un niveau global qui en est le minimum. Une fiche annonçant « sécurité physique niveau 3 » peut cacher un niveau global 2 : piège classique, repérable en trente secondes. Quatre autres points décident de la valeur réelle :

La version exacte. Un micrologiciel absent de la liste validée sort le module du périmètre, même si « rien n’a changé côté crypto ».
Le mode approuvé. La Security Policy publique fixe algorithmes et réglages autorisés ; hors de ce mode (algorithme non approuvé activé, clé importée en clair), le module n’est plus validé.
Le statut. Les validations FIPS 140-2 ont basculé en liste historique en septembre 2026 : elles ne justifient plus une nouvelle acquisition fédérale américaine. La liste « Modules In Process » n’est qu’une promesse.
Les algorithmes. Chacun doit renvoyer à un certificat CAVP (Cryptographic Algorithm Validation Program).

Pourquoi le niveau 3 devient une exigence contractuelle

Aux États-Unis, FIPS 140 est obligatoire pour la cryptographie des systèmes fédéraux, et l’exigence descend chez les sous-traitants de la défense. En finance, les exigences PCI (Payment Card Industry) PIN (Personal Identification Number) visent des modules FIPS 140 niveau 3 ou évalués PCI HSM. Côté eIDAS (electronic IDentification, Authentication and trust Services), les prestataires qualifiés s’appuient sur des modules évalués Critères Communs selon le profil EN 419221-5.

La règle d’achat : exiger un certificat FIPS 140-3 actif, niveau global 3, sur la version de micrologiciel réellement déployée. Le prix est connu : une revalidation prend des mois, donc un correctif arrive soit hors périmètre validé, soit en retard. Il faut trancher à l’avance, par écrit, lequel l’emporte, plutôt que pendant un audit.

Vingt ans de revues d’architecture apprennent une chose : « le HSM est-il certifié ? » reçoit toujours un oui, « la version installée l’est-elle ? » provoque un silence poli et une recherche fébrile dans un portail fournisseur.

Critères Communs : une autre méthode, d’autres marchés

Les Critères Communs (ISO/IEC 15408) n’imposent pas une liste fixe. Le fabricant rédige une cible de sécurité (Security Target) qui définit la TOE (Target of Evaluation) et ses menaces ; un laboratoire agréé vérifie ces affirmations avec une profondeur fixée par l’EAL (Evaluation Assurance Level), de 1 à 7. EAL6 et EAL7 exigent en outre une conception vérifiée de façon semi-formelle puis formelle, ce qui explique leur rareté dans les catalogues. Pour un HSM, le composant AVA_VAN.5 (attaquant de potentiel élevé) compte plus que le chiffre de l’EAL.

FIPS 140 répond à « le module respecte-t-il la norme ? », les Critères Communs à « le produit tient-il ses promesses face à tel attaquant ? ». Le marché fédéral américain exige le premier, les marchés européens réglementés (eIDAS, qualifications de l’ANSSI, Agence nationale de la sécurité des systèmes d’information, schéma européen EUCC, European Common Criteria-based cybersecurity certification) regardent le second : d’où les doubles certifications des fabricants. L’acheteur n’a besoin que de celle que lit son régulateur ; la page Organismes recense les autorités. Piège propre aux Critères Communs : un EAL élevé sur une TOE qui exclut l’interface d’administration. Lire la Security Target avant le certificat.

Ce que les certifications ne garantissent pas

Aucune certification ne couvre l’usage du module. L’API (Application Programming Interface) PKCS#11 (Public-Key Cryptography Standards #11) tolère des attributs incohérents qui permettent d’extraire une clé par l’API elle-même ; voir PKCS#11 expliqué et wrap et unwrap. Des oracles de padding RSA (Rivest-Shamir-Adleman) ont touché des modules validés, et ROCA (Return of Coppersmith’s Attack, 2017) a produit des clés factorisables dans des puces certifiées. La certification atteste d’un état évalué, pas de l’absence de défaut.

Le reste relève de l’exploitation : contrôle d’accès applicatif, quorum d’administration, journalisation, haute disponibilité, sauvegarde vers un module de même niveau, supervision des événements d’intrusion et du statut du certificat.

Exemple : vérifier la version déployée contre le certificat

Avec OpenSC et poppler-utils installés, et le numéro relevé sur la page du certificat CMVP :

# Modèle et micrologiciel annoncés par le module (bibliothèque PKCS#11 du fabricant)
pkcs11-tool --module /usr/lib/libCryptoki2_64.so --show-info

# Numéro du certificat CMVP consulté sur csrc.nist.gov
CERT=4745

# Téléchargement de la Security Policy publique du certificat
curl -sSfo "sp-${CERT}.pdf" \
  "https://csrc.nist.gov/CSRC/media/projects/cryptographic-module-validation-program/documents/security-policies/140sp${CERT}.pdf"

# Versions validées, niveau global et conditions du mode approuvé
pdftotext -layout "sp-${CERT}.pdf" - | grep -Ei "firmware|overall|approved mode" | head -40

Si la version remontée par --show-info n’apparaît pas dans la Security Policy, le module en production n’est pas celui qui a été validé. Ce contrôle a sa place dans la supervision, pas seulement dans le dossier d’achat.

🐝 Ce qui arrive si on s’en passe

Sans lecture attentive du certificat, rien ne distingue un boîtier vendu comme HSM d’une bibliothèque logicielle : le niveau 1 n’impose aucune enveloppe physique, donc l’ouverture du châssis, le dessoudage d’une mémoire ou le branchement d’une sonde ne déclenchent aucun effacement et laissent la clé lisible. Sans niveau 3, aucune séparation cryptographique des rôles n’est vérifiée par un tiers : l’affirmation « la clé ne sort jamais du module » redevient une promesse commerciale, impossible à produire devant un auditeur financier ou un donneur d’ordre défense, ce qui bloque la qualification du service entier. Un périmètre non évalué laisse aussi passer des comportements observables que les campagnes de test auraient relevés, comme le montre la brèche « la question qui rend le module bavard », où les réponses d’erreur suffisent à reconstituer un secret.

🦫 Explication de la marmotte 🍫

Un module de sécurité matériel est un boîtier qui garde des clés secrètes et fait les calculs de chiffrement à l’intérieur, sans jamais laisser sortir ces clés. Pour savoir s’il tient vraiment, un laboratoire indépendant le teste selon une norme, puis un organisme public délivre un certificat. La norme américaine prévoit quatre niveaux. Au premier, rien ne protège le boîtier. Au deuxième, une ouverture laisse une trace visible. Au troisième, des capteurs détectent l’ouverture et effacent aussitôt les clés, et chaque personne doit prouver son identité. Au quatrième, le boîtier réagit à une attaque par n’importe quel côté et aux changements anormaux de température ou de courant. Le niveau affiché est celui du point le plus faible. Le certificat ne vaut que pour la version exacte testée et pour les réglages décrits dans un document public : changer le logiciel interne ou activer un réglage interdit fait sortir le boîtier de ce qui a été vérifié. Une seconde méthode, européenne et internationale, demande au fabricant d’écrire ce qu’il promet, puis vérifie ces promesses plus ou moins en profondeur. Les banques et l’armée exigent souvent le troisième niveau. Aucun certificat ne protège contre un mauvais usage du boîtier par les programmes autorisés à lui parler.

Pages voisines

La citent

Lire une certification FIPS 140-3 ou Critères Communs d'un HSM

Elle cite

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