FIPS 140-3 : validation des modules cryptographiques

Auteur Hugues Orgitello Mis à jour le 3 juillet 2026 ~15 min de lecture

Guide · FIPS 140-3

Publiee par le NIST en mars 2019 et applicable depuis septembre 2019, la norme FIPS 140-3 (Fédéral Information Processing Standard 140-3) définit les exigences de sécurité des modules cryptographiques utilises par les agences fédérales des Etats-Unis et du Canada. Le programme de validation associe, le CMVP (Cryptographic Module Validation Program), opere conjointement par le NIST et le centre canadien CCCS, prononce les certificats reconnus sur ces deux marches. Au-dela du périmètre fédéral, FIPS 140 est devenue la reference d'assurance de fait pour les modules cryptographiques exiges par le secteur financier, la défense, les opérateurs télécoms et un nombre croissant d'industriels. Ce guide expose la lignée 140-1 / 140-2 / 140-3, le partage de rôle entre CMVP et CAVP, les quatre niveaux de sécurité, les algorithmes approuves listes par la serie SP 800-140, le calendrier de sortie de FIPS 140-2 et la migration en cours vers les algorithmes post-quantiques.

Lignee FIPS 140 : trente ans de continuité

FIPS 140 est l'une des plus anciennes normes fédérales américaines en matière de cryptographie. Sa première version, FIPS 140-1, a ete publiée en janvier 1994 par le NIST, alors appelé NBS. Le besoin était simple : disposer d'un référentiel public sur lequel l'administration fédérale américaine pouvait s'appuyer pour acheter des produits cryptographiques sans devoir, agence par agence, reconduire une évaluation interne. Le texte de 1994 introduisait déjà les notions de module cryptographique, de frontière logique, de rôles opérateur, et une structure a quatre niveaux de sécurité.

FIPS 140-2 a remplace 140-1 en mai 2001. Elle a étendu le périmètre aux modules logiciels purs, integre des exigences explicites sur les nombres aléatoires (PRNG/DRBG) et formalise une annexe A listant les algorithmes approuves. Pendant pres de vingt ans, FIPS 140-2 a constitue le standard de reference, avec plusieurs milliers de modules valides figurant au registre du CMVP.

FIPS 140-3 a ete publiée en mars 2019, avec une entrée en vigueur effective des essais en septembre 2020 (première journée d'acceptation des nouveaux dossiers). Sa différence structurelle majeure tient a son adossement aux normes internationales : le texte ne reformule plus en propre les exigences de sécurité, il pointe vers ISO/IEC 19790:2012 (exigences de sécurité) et ISO/IEC 24759:2017 (méthodes d'essai), en y ajoutant des annexes nationales sous forme de SP 800-140A a SP 800-140F. Cette articulation ouvre une convergence internationale, plusieurs autres juridictions appliquant déjà directement ISO/IEC 19790.

Version	Publication	Statut
FIPS 140-1	janvier 1994	Retiree
FIPS 140-2	mai 2001	Acceptation des dossiers close en septembre 2021
FIPS 140-3	mars 2019	En vigueur, seule voie pour de nouveaux dossiers

CMVP, CAVP, CSTL : trois acronymes a distinguer

Le dispositif americano-canadien de validation cryptographique s'articule autour de trois entités complémentaires, fréquemment confondues dans les appels d'offres.

Le CMVP est le programme de validation des modules cryptographiques complets. Il est administre conjointement par le NIST (cote américain) et le Canadian Centre for Cyber Security (CCCS, cote canadien). Il prononce les certificats publies au "Cryptographic Module Validation List" du NIST. La validation porte sur un module identifie précisément : nom commercial, numéro de version, numéro de révision firmware, plate-forme opérationnelle, et frontière de cryptographic boundary délimitée dans la documentation.

Le CAVP est le programme de validation des algorithmes pris individuellement. Il delivre un certificat CAVP pour chaque implémentation d'algorithme (AES-128, SHA-256, RSA-PSS, ECDSA P-256, ML-KEM-768, etc.) validée par jeu de vecteurs de test. Un certificat CAVP n'a pas de valeur en soi pour un client, il sert de brique constitutive d'un dossier CMVP. Sans CAVP pour un algorithme donne, ce dernier ne peut être revendique comme approuve dans un module.

Les CSTL (Cryptographic and Security Testing Laboratories) sont les laboratoires d'essai accredites qui exécutent les tests. L'accréditation NVLAP au NIST porte sur la compétence du laboratoire pour conduire les essais décrits par ISO/IEC 24759 et les SP 800-140. Le fabricant contracte directement avec un CSTL de son choix. Le CSTL prepare le rapport d'essai et le transmet au CMVP, qui prononce la validation finale apres revue.

Sigle	Objet	Acteur	Livrable
CMVP	Validation du module complet	NIST + CCCS	Certificat module au registre CMVP
CAVP	Validation d'un algorithme	NIST	Certificat algorithme
CSTL	Laboratoire d'essai accredite	NVLAP / laboratoire prive	Rapport d'essai vers CMVP

Les quatre niveaux de sécurité

FIPS 140-3 reprend la structure historique a quatre niveaux, en alignement avec ISO/IEC 19790. La gradation porte sur onze domaines d'exigences (spécification, interfaces, rôles, services et authentification, environnement logiciel/firmware, environnement physique, environnement opérationnel, gestion des parametres de sécurité sensibles, auto-tests, assurance du cycle de vie, atténuation d'autres attaques). Le tableau ci-dessous resume la progression dominante.

Niveau	Securite physique	Authentification	Environnement	Attaques non-invasives
1	Aucune exigence spécifique	Aucune authentification requise	Plate-forme générale acceptable	Pas d'exigence
2	Tamper-evident (preuve de manipulation)	Authentification par rôle	OS evalue selon profil de protection	Couverte qualitativement
3	Tamper-detect et tamper-respond	Authentification par identité	Isolation forte des interfaces	Tests documentes
4	Enveloppe active de détection, protection environnementale (tension, température)	Authentification multi-facteur	Domaines de sécurité separes	Evaluation par canaux caches

Le niveau 1 correspond a un usage logiciel courant sur plate-forme générale. La seule contrainte structurante est que les algorithmes employés figurent sur la liste des algorithmes approuves. Une bibliothèque OpenSSL en mode FIPS validée correspond typiquement a ce niveau.

Le niveau 2 introduit une dimension physique : l'enveloppe du module doit montrer une évidence visible en cas de tentative d'ouverture (seal, peinture, marquage destructif). Une authentification par rôle distingue au minimum l'opérateur cryptographique de l'administrateur de la maintenance. L'environnement opérationnel logiciel doit être evalue, typiquement via un profil de protection Common Criteria.

Le niveau 3 durcit l'exigence physique en imposant une détection active des tentatives d'intrusion couplée a une réponse : effacement des secrets, mise en alarme, blocage du module. L'authentification est basée sur l'identité individuelle de l'opérateur. Les interfaces de saisie et de sortie des secrets doivent être physiquement séparées des autres interfaces. Une carte cryptographique HSM (Hardware Security Module) ou une carte a puce embarquant un élément securise atteint typiquement ce niveau.

Le niveau 4 vise les environnements physiquement hostiles. Le module doit détecter et réagir aux variations environnementales (tension d'alimentation hors plage, température anormale, rayonnement). Une enveloppe active de détection enrobe le module, capable d'effacer les secrets en cas de perforation, perçage ou altération. L'authentification est multi-facteurs. Les attaques non-invasives, ajoutées explicitement par FIPS 140-3, font l'objet d'une évaluation documentée a ce niveau. Un HSM tactique, une cartouche sécurisée pour munitions intelligentes ou un module integre a une infrastructure de cle souveraine relèvent généralement du niveau 4.

Types de modules : matériel, logiciel, firmware, hybride

FIPS 140-3 reconnaît quatre profils d'environnement opérationnel, définis a la clause 7.2 d'ISO/IEC 19790 et precises dans la SP 800-140B.

• Module matériel : implémentation physique dédiée, dont la frontière cryptographique est matérielle. Un HSM PCIe, un Trusted Platform Module (TPM), un élément securise embarque dans une carte SIM, une carte a puce releve de cette catégorie. Ces modules peuvent viser tous les niveaux, du 1 au 4.
• Module logiciel : implémentation purement logicielle exécutée sur une plate-forme générale (OS commercial). La frontière cryptographique englobe le code et les structures de données du module, l'OS hôte étant l'environnement opérationnel evalue mais hors frontière. Limite typique : niveau 1 ou 2.
• Module firmware : implémentation logicielle exécutée sur un environnement matériel limite, généralement non programmable apres déploiement (microcontrôleur, carte radio, gateway). La frontière englobe le firmware et le matériel d'execution. Niveaux 1, 2 voire 3 selon les protections physiques.
• Module hybride : combinaison d'un composant logiciel et d'un composant matériel, indissociables pour la fourniture des services cryptographiques. Une bibliothèque logicielle couplée a un élément securise via une interface dédiée constitue un module hybride.

Le choix du type d'environnement est l'une des décisions structurantes du dossier. Une erreur de classification a posteriori peut imposer une nouvelle campagne d'essais, le périmètre de tests différant sensiblement entre les profils.

Algorithmes approuves : la serie SP 800-140

Sous FIPS 140-2, les algorithmes approuves figuraient dans l'annexe A du texte. FIPS 140-3 a sorti cette liste du standard pour en faire un document tiers, la SP 800-140C ("CMVP Approved Security Functions"), mise a jour de maniere autonome au rythme des publications NIST. Cette modularité permet d'introduire de nouveaux algorithmes (notamment les algorithmes post-quantiques) sans amender la norme principale.

La famille des SP 800-140 couvre les domaines suivants :

• SP 800-140A : modifications a ISO/IEC 24759 (méthodes d'essai).
• SP 800-140B : exigences sur le document de politique de sécurité (Security Policy).
• SP 800-140C : fonctions de sécurité approuvées (algorithmes cryptographiques).
• SP 800-140D : parametres de sécurité sensibles (clés, semences, nonces).
• SP 800-140E : établissement de cle approuve (key establishment).
• SP 800-140F : services et fonctions non approuves.

La SP 800-140C liste les familles d'algorithmes acceptes pour un module valide. Le tableau ci-dessous synthetise les principales catégories avec leur statut a la date courante.

Categorie	Algorithmes représentatifs	Statut
Chiffrement symétrique	AES (FIPS 197) en modes ECB, CBC, GCM, CCM, XTS	Approuve
Chiffrement asymétrique historique	RSA OAEP, RSA-PSS	Approuve, transition surveillée
Echange de cle classique	DH, ECDH (courbes NIST P-256, P-384, P-521)	Approuve
Signature numérique	ECDSA, RSA-PSS, EdDSA (depuis FIPS 186-5)	Approuve
Hachage	SHA-2 (SHA-256, SHA-384, SHA-512), SHA-3	Approuve
MAC	HMAC, KMAC, CMAC	Approuve
Generateurs déterministes	Hash_DRBG, HMAC_DRBG, CTR_DRBG (SP 800-90A)	Approuve
Encapsulation post-quantique	ML-KEM (FIPS 203, ex-Kyber)	Approuve depuis 2024
Signature post-quantique	ML-DSA (FIPS 204), SLH-DSA (FIPS 205)	Approuve depuis 2024
Cryptographie legacy	DES, MD5, SHA-1 (signature)	Non approuve

Un module qui implémenterait des algorithmes hors liste n'est pas nécessairement disqualifie : il peut être valide en mettant ces algorithmes en dehors du périmètre cryptographique approuve, avec mention explicite dans la politique de sécurité. Le risque commercial est ailleurs : un acheteur fédéral pourrait considérer que la présence d'un algorithme non approuve dans le module affecte l'assurance globale.

Migration post-quantique : ML-KEM, ML-DSA, SLH-DSA

Le NIST a conclu en août 2024 son programme de standardisation post-quantique entame en 2016. Trois standards FIPS ont ete publies, integres a la liste des algorithmes approuves :

• FIPS 203 (ML-KEM) : Module-Lattice-based Key Encapsulation Mechanism, derive de CRYSTALS-Kyber, destine a remplacer les echanges de cle RSA et ECDH face a un éventuel ordinateur quantique cryptanalytiquement utile.
• FIPS 204 (ML-DSA) : Module-Lattice-based Digital Signature Algorithm, derive de CRYSTALS-Dilithium, pour la signature numérique.
• FIPS 205 (SLH-DSA) : Stateless Hash-based Digital Signature Algorithm, derive de SPHINCS+, signature a base de fonctions de hachage, plus lente mais offrant un fondement de sécurité different (utile en défense en profondeur).

Ces algorithmes sont éligibles a validation CAVP depuis fin 2024. Leur intégration dans des modules valides CMVP a debute en 2025. La trajectoire attendue par le NIST est une migration progressive sur la décennie 2025-2035, avec une période de hybridation (algorithmes classiques + post-quantiques en parallèle) durant la phase de transition. Plusieurs agences fédérales américaines (NSA via le memorandum CNSA 2.0, OMB via la circulaire associée) ont publie des feuilles de route fixant des dates de bascule par catégorie de systeme.

Pour un fabricant européen visant un marche mixte (fédéral américain + financier mondial), l'inclusion d'un mécanisme hybride dans la prochaine génération de modules devient un argument commercial autant que technique.

Transition FIPS 140-2 vers FIPS 140-3

Le calendrier de transition publie par le NIST se decline en trois jalons.

Date	Evenement
22 septembre 2020	Premier jour d'acceptation des dossiers FIPS 140-3
21 septembre 2021	Dernier jour d'acceptation des dossiers FIPS 140-2
21 septembre 2026	Bascule des certificats FIPS 140-2 dans l'historique (sunset)

Apres le 21 septembre 2026, les certificats 140-2 déjà prononces ne disparaissent pas, mais ils sortent du registre "Active" pour rejoindre l'historique. Pour un acheteur fédéral soumis a l'obligation FIPS, un produit ne présentant qu'un certificat 140-2 a partir de cette date risque d'être ecarte. Cette échéance impose aux fabricants un planning de revalidation 140-3 si le produit reste commercialise au-dela.

La revalidation n'est pas une simple migration administrative. Les écarts entre 140-2 et 140-3 peuvent imposer des modifications de conception : ajout d'exigences non-invasives, renforcement de la politique de sécurité, mise a jour des auto-tests, alignement des rôles et des authentifications. Pour un module logiciel pur, l'effort reste raisonnable. Pour un module matériel niveau 3 ou 4, le délai peut atteindre dix-huit a vingt-quatre mois entre lancement et certificat, avec un risque non nul de redesign partiel.

Pour les fabricants qui examinent également un parcours Common Criteria ISO/IEC 15408, une partie des artefacts de conception est mutualisable, en particulier le document de politique de sécurité et l'analyse de la frontière cryptographique.

Articulation avec ISO/IEC 19790 et 24759

ISO/IEC 19790:2012 et son texte d'essai associe ISO/IEC 24759:2017 sont les normes internationales sur lesquelles FIPS 140-3 s'adosse. La table de correspondance est claire : FIPS 140-3 reprend ISO/IEC 19790 sans le modifier, et y ajoute, via les SP 800-140, des annexes nationales précisant les algorithmes approuves, les services et les parametres de sécurité acceptes dans le cadre americano-canadien.

Texte	Role
ISO/IEC 19790:2012	Exigences de sécurité des modules cryptographiques
ISO/IEC 24759:2017	Methodes d'essai des exigences ISO/IEC 19790
FIPS 140-3	Adoption nationale américaine d'ISO/IEC 19790
SP 800-140A-F	Annexes nationales aux méthodes d'essai et algorithmes

Cette articulation a deux conséquences pratiques. D'une part, un module valide FIPS 140-3 satisfait par construction les exigences ISO/IEC 19790. D'autre part, plusieurs juridictions hors Amerique du Nord (Japon via JCMVP, Coree du Sud via KCMVP) qui appliquent directement ISO/IEC 19790 peuvent reconnaître, en tout ou partie, un dossier déjà constitue pour le CMVP, sous reserve d'adaptations locales.

Pieges fréquents

Quelques erreurs reviennent régulièrement dans les dossiers de validation cryptographique.

Compter sur un certificat 140-2 au-dela de septembre 2026. Un produit dont le seul certificat est 140-2 deviendra non opposable a un acheteur fédéral apres le sunset. Planifier la revalidation 140-3 au moins dix-huit mois avant l'échéance evite la rupture commerciale.

Confondre validation d'algorithme et validation de module. Disposer de certificats CAVP pour AES, SHA et RSA ne constitue pas une validation FIPS 140. Le CMVP exige un dossier complet sur le module, les certificats CAVP n'en sont qu'une piece.

Mal classifier le type d'environnement opérationnel. Un module annonce comme logiciel mais s'appuyant sur un matériel spécifique (extension AES-NI, instructions cryptographiques d'un microcontrôleur) peut être requalifie en module hybride en cours d'instruction, avec un périmètre de tests étendu.

Omettre la spécification de l'environnement opérationnel. La politique de sécurité doit lister précisément la plate-forme évaluée (OS, version, matériel). Un OS hôte different en production conduit le client fédéral a considérer le module comme non opérant en régime FIPS.

Inclure un algorithme non approuve dans le périmètre. Un algorithme propriétaire ou non liste a la SP 800-140C doit être mis explicitement hors du périmètre cryptographique approuve, faute de quoi le module est rejeté a la validation.

Sous-estimer la documentation de la frontière cryptographique. La définition precise de cette frontière conditionne l'ensemble du dossier. Une frontière mal tracée impose des reprises majeures en cours d'instruction.

Ignorer la portabilité plateforme. Un module valide sur Linux x86_64 n'est pas automatiquement valide sur Linux ARM64 ou Windows. La revalidation cross-plateforme est prévue par le programme mais implique des essais complémentaires non triviaux.

Comparaison synthétique 140-2 vs 140-3

Dimension	FIPS 140-2 (2001)	FIPS 140-3 (2019)
Texte de reference	Specifique NIST	ISO/IEC 19790 + ISO/IEC 24759 + annexes nationales
Algorithmes approuves	Annexe A intégrée	SP 800-140C, document distinct
Attaques non-invasives	Couverture limitée	Chapitre dedie, exigences par niveau
Auto-tests	Distinction implicite	Distinction explicite tests "preoperational" et "conditional"
Authentification niveau 4	Authentification par identité	Multi-facteur explicite
Convergence internationale	Faible	Forte, via ISO/IEC 19790
Statut acceptation dossiers	Close (septembre 2021)	Ouverte
Sunset des certificats	21 septembre 2026	Pas d'échéance

Pour un fabricant : demarche pratique

Une demarche de validation FIPS 140-3 utile a la commercialisation suit cinq phases.

1. Décision d'opportunite. Identifier les marches qui exigent FIPS 140 (fédéral américain, certains contrats financiers, marches publics canadiens, certains industriels exportateurs vers les Etats-Unis). Quantifier l'impact d'une absence de certificat. La validation a un coût et un délai significatifs, qui ne se justifient que par un objectif commercial documente.

2. Cadrage du module et du niveau. Definir la frontière cryptographique, le type d'environnement (matériel, logiciel, firmware, hybride) et le niveau vise. Cette décision conditionne le choix du matériel, l'architecture logicielle, et le coût d'évaluation. Mieux vaut viser un niveau atteignable et itérer ensuite, qu'échouer sur un niveau 4 mal prepare.

3. Sélection du laboratoire CSTL. Le choix du CSTL influe sur le délai, le coût, et la qualité du dialogue avec le CMVP. Demander plusieurs devis, vérifier la familiarité du laboratoire avec le profil technique du module (matériel, logiciel embarque, HSM).

4. Constitution du dossier. Le coeur du travail. La politique de sécurité (Security Policy) est le document central, public apres validation. Elle décrit le module, ses rôles, ses services, ses parametres de sécurité sensibles, ses interfaces, sa frontière. La documentation interne comprend les rapports CAVP, les spécifications d'algorithmes, les schémas matériels, les listings de code pour les niveaux les plus eleves.

5. Validation et maintenance. Apres validation, le module entre au registre CMVP. Toute modification non triviale (changement de version firmware, ajout d'une plate-forme supportée, changement de fournisseur de composant cryptographique) declenche une procédure de revalidation ou de "letter of attestation" selon la nature de la modification. La gestion du cycle de vie est aussi exigeante que la validation initiale.

Pour la dimension produit européen radio, ces décisions s'articulent avec les obligations RED et les exigences cybersécurité IoT EN 303 645, qui ne font pas double emploi avec FIPS 140-3 mais relèvent d'autres référentiels. Le glossaire consolide les acronymes CMVP, CAVP, CSTL et leurs équivalents internationaux.

Voir aussi

• TPM 2.0 et sécurité matérielle TCG
• CSPN et ANSSI Visa : cybersécurité française
• CMMC et UK Cyber Essentials: baselines cyber de défense
• PSA Certified: sécurité IoT pilotée par Arm
• SESIP: méthodologie d'évaluation cybersécurité IoT

Un cas concret de la cartographie d'un projet exigeant FIPS 140-3 et son articulation avec la conformite RED ou CRA ? AESTECHNO peut auditer votre conception et votre plan de certification. Nous contacter →

Perspectives

Trois tendances structurent la décennie 2025-2035 pour FIPS 140-3.

La première est la migration post-quantique généralisée. ML-KEM, ML-DSA et SLH-DSA sont désormais standardises, mais leur déploiement effectif dans les modules valides en est a ses debuts. Une partie des certificats 140-3 actuels seront amendes pour les inclure, et les nouveaux dossiers intègrent de plus en plus systématiquement une voie hybride classique + post-quantique.

La deuxième est la convergence internationale via ISO/IEC 19790. L'adoption directe d'ISO/IEC 19790 par plusieurs schémas nationaux (Japon, Coree, partiellement Australie via la passerelle ASD) ouvre la possibilité d'une reconnaissance mutuelle progressive. Le programme CMVP, le JCMVP japonais et le KCMVP coréen pourraient a terme rapprocher leurs procedures.

La troisième est la consolidation des outils d'évaluation automatisée. Les vecteurs CAVP sont désormais exécutables via le protocole ACVP (Automated Cryptographic Validation Protocol), permettant de tester un module en interaction avec un serveur central NIST. Cette automatisation réduit le délai sur la phase algorithmique du dossier, sans changer la phase d'instruction CMVP qui reste documentaire.

Pour un fabricant européen, FIPS 140-3 n'est pas une obligation réglementaire de marquage CE, mais reste une reference d'assurance fréquemment exigée contractuellement. Le calendrier sunset de septembre 2026 impose d'avoir, pour tout produit cryptographique en service, soit un certificat 140-3 déjà prononce, soit une trajectoire de revalidation documentée.

Besoin d’un appui ?

Un audit de 30 minutes avec les ingénieurs AESTECHNO.

AESTECHNO est le bureau d'études qui édite spilma. Nous aidons les équipes produit à cadrer leur démarche de certification et à éviter les pièges classiques.

Réserver un audit gratuit

Pour aller plus loin

• Common Criteria ISO/IEC 15408 : référentiel d'évaluation de sécurité générique, complémentaire de FIPS 140-3
• ETSI EN 303 645 : cybersécurité IoT consommateur
• RED : cadre européen pour les équipements radio, articulation avec la cybersécurité produit
• Glossaire : définitions CMVP, CAVP, CSTL, ISO/IEC 19790

Sources & références

1. FIPS 140-3, Security Requirements for Cryptographic Modules , NIST csrc.nist.gov/pubs/fips/140-3/final
2. Cryptographic Module Validation Program (CMVP) , NIST csrc.nist.gov/projects/cryptographic-module-validation-program
3. ISO/IEC 19790:2012, Security requirements for cryptographic modules , ISO www.iso.org/standard/52906.html
4. NIST SP 800-140 series, CMVP-approved security functions and tests , NIST csrc.nist.gov/pubs/sp/800/140/final
5. CMVP transition guidance, 140-2 to 140-3 , NIST csrc.nist.gov/Projects/cryptographic-module-validation-program/fips-140-3-transition-effort
6. NIST Post-Quantum Cryptography standardisation, FIPS 203, 204, 205 , NIST csrc.nist.gov/projects/post-quantum-cryptography
7. Cryptographic Algorithm Validation Program (CAVP) , NIST csrc.nist.gov/projects/cryptographic-algorithm-validation-program