FIPS 140-3 : validation des modules cryptographiques

Auteur Hugues Orgitello Mis à jour le 27 mai 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 (Federal Information Processing Standard 140-3) definit les exigences de securite des modules cryptographiques utilises par les agences federales 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 perimetre federal, FIPS 140 est devenue la reference d'assurance de fait pour les modules cryptographiques exiges par le secteur financier, la defense, les operateurs telecoms et un nombre croissant d'industriels. Ce guide expose la lignee 140-1 / 140-2 / 140-3, le partage de role entre CMVP et CAVP, les quatre niveaux de securite, 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 continuite

FIPS 140 est l'une des plus anciennes normes federales americaines en matiere de cryptographie. Sa premiere version, FIPS 140-1, a ete publiee en janvier 1994 par le NIST, alors appele NBS. Le besoin etait simple : disposer d'un referentiel public sur lequel l'administration federale americaine pouvait s'appuyer pour acheter des produits cryptographiques sans devoir, agence par agence, reconduire une evaluation interne. Le texte de 1994 introduisait deja les notions de module cryptographique, de frontiere logique, de roles operateur, et une structure a quatre niveaux de securite.

FIPS 140-2 a remplace 140-1 en mai 2001. Elle a etendu le perimetre aux modules logiciels purs, integre des exigences explicites sur les nombres aleatoires (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 publiee en mars 2019, avec une entree en vigueur effective des essais en septembre 2020 (premiere journee d'acceptation des nouveaux dossiers). Sa difference structurelle majeure tient a son adossement aux normes internationales : le texte ne reformule plus en propre les exigences de securite, il pointe vers ISO/IEC 19790:2012 (exigences de securite) et ISO/IEC 24759:2017 (methodes 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 deja 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 entites complementaires, frequemment 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 americain) 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 precisement : nom commercial, numero de version, numero de revision firmware, plate-forme operationnelle, et frontiere de cryptographic boundary delimitee dans la documentation.

Le CAVP est le programme de validation des algorithmes pris individuellement. Il delivre un certificat CAVP pour chaque implementation d'algorithme (AES-128, SHA-256, RSA-PSS, ECDSA P-256, ML-KEM-768, etc.) validee 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 etre revendique comme approuve dans un module.

Les CSTL (Cryptographic and Security Testing Laboratories) sont les laboratoires d'essai accredites qui executent les tests. L'accreditation NVLAP au NIST porte sur la competence du laboratoire pour conduire les essais decrits 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 securite

FIPS 140-3 reprend la structure historique a quatre niveaux, en alignement avec ISO/IEC 19790. La gradation porte sur onze domaines d'exigences (specification, interfaces, roles, services et authentification, environnement logiciel/firmware, environnement physique, environnement operationnel, gestion des parametres de securite sensibles, auto-tests, assurance du cycle de vie, attenuation d'autres attaques). Le tableau ci-dessous resume la progression dominante.

Niveau	Securite physique	Authentification	Environnement	Attaques non-invasives
1	Aucune exigence specifique	Aucune authentification requise	Plate-forme generale acceptable	Pas d'exigence
2	Tamper-evident (preuve de manipulation)	Authentification par role	OS evalue selon profil de protection	Couverte qualitativement
3	Tamper-detect et tamper-respond	Authentification par identite	Isolation forte des interfaces	Tests documentes
4	Enveloppe active de detection, protection environnementale (tension, temperature)	Authentification multi-facteur	Domaines de securite separes	Evaluation par canaux caches

Le niveau 1 correspond a un usage logiciel courant sur plate-forme generale. La seule contrainte structurante est que les algorithmes employes figurent sur la liste des algorithmes approuves. Une bibliotheque OpenSSL en mode FIPS validee correspond typiquement a ce niveau.

Le niveau 2 introduit une dimension physique : l'enveloppe du module doit montrer une evidence visible en cas de tentative d'ouverture (seal, peinture, marquage destructif). Une authentification par role distingue au minimum l'operateur cryptographique de l'administrateur de la maintenance. L'environnement operationnel logiciel doit etre evalue, typiquement via un profil de protection Common Criteria.

Le niveau 3 durcit l'exigence physique en imposant une detection active des tentatives d'intrusion couplee a une reponse : effacement des secrets, mise en alarme, blocage du module. L'authentification est basee sur l'identite individuelle de l'operateur. Les interfaces de saisie et de sortie des secrets doivent etre physiquement separees des autres interfaces. Une carte cryptographique HSM (Hardware Security Module) ou une carte a puce embarquant un element securise atteint typiquement ce niveau.

Le niveau 4 vise les environnements physiquement hostiles. Le module doit detecter et reagir aux variations environnementales (tension d'alimentation hors plage, temperature anormale, rayonnement). Une enveloppe active de detection enrobe le module, capable d'effacer les secrets en cas de perforation, percage ou alteration. L'authentification est multi-facteurs. Les attaques non-invasives, ajoutees explicitement par FIPS 140-3, font l'objet d'une evaluation documentee a ce niveau. Un HSM tactique, une cartouche securisee pour munitions intelligentes ou un module integre a une infrastructure de cle souveraine relevent generalement du niveau 4.

Types de modules : materiel, logiciel, firmware, hybride

FIPS 140-3 reconnait quatre profils d'environnement operationnel, definis a la clause 7.2 d'ISO/IEC 19790 et precises dans la SP 800-140B.

• Module materiel : implementation physique dediee, dont la frontiere cryptographique est materielle. Un HSM PCIe, un Trusted Platform Module (TPM), un element securise embarque dans une carte SIM, une carte a puce releve de cette categorie. Ces modules peuvent viser tous les niveaux, du 1 au 4.
• Module logiciel : implementation purement logicielle executee sur une plate-forme generale (OS commercial). La frontiere cryptographique englobe le code et les structures de donnees du module, l'OS hote etant l'environnement operationnel evalue mais hors frontiere. Limite typique : niveau 1 ou 2.
• Module firmware : implementation logicielle executee sur un environnement materiel limite, generalement non programmable apres deploiement (microcontroleur, carte radio, gateway). La frontiere englobe le firmware et le materiel d'execution. Niveaux 1, 2 voire 3 selon les protections physiques.
• Module hybride : combinaison d'un composant logiciel et d'un composant materiel, indissociables pour la fourniture des services cryptographiques. Une bibliotheque logicielle couplee a un element securise via une interface dediee constitue un module hybride.

Le choix du type d'environnement est l'une des decisions structurantes du dossier. Une erreur de classification a posteriori peut imposer une nouvelle campagne d'essais, le perimetre de tests differant 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 modularite 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 (methodes d'essai).
• SP 800-140B : exigences sur le document de politique de securite (Security Policy).
• SP 800-140C : fonctions de securite approuvees (algorithmes cryptographiques).
• SP 800-140D : parametres de securite sensibles (cles, semences, nonces).
• SP 800-140E : etablissement 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 categories avec leur statut a la date courante.

Categorie	Algorithmes representatifs	Statut
Chiffrement symetrique	AES (FIPS 197) en modes ECB, CBC, GCM, CCM, XTS	Approuve
Chiffrement asymetrique historique	RSA OAEP, RSA-PSS	Approuve, transition surveillee
Echange de cle classique	DH, ECDH (courbes NIST P-256, P-384, P-521)	Approuve
Signature numerique	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 deterministes	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 implementerait des algorithmes hors liste n'est pas necessairement disqualifie : il peut etre valide en mettant ces algorithmes en dehors du perimetre cryptographique approuve, avec mention explicite dans la politique de securite. Le risque commercial est ailleurs : un acheteur federal pourrait considerer que la presence 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 aout 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 eventuel ordinateur quantique cryptanalytiquement utile.
• FIPS 204 (ML-DSA) : Module-Lattice-based Digital Signature Algorithm, derive de CRYSTALS-Dilithium, pour la signature numerique.
• 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 securite different (utile en defense en profondeur).

Ces algorithmes sont eligibles a validation CAVP depuis fin 2024. Leur integration dans des modules valides CMVP a debute en 2025. La trajectoire attendue par le NIST est une migration progressive sur la decennie 2025-2035, avec une periode de hybridation (algorithmes classiques + post-quantiques en parallele) durant la phase de transition. Plusieurs agences federales americaines (NSA via le memorandum CNSA 2.0, OMB via la circulaire associee) ont publie des feuilles de route fixant des dates de bascule par categorie de systeme.

Pour un fabricant europeen visant un marche mixte (federal americain + financier mondial), l'inclusion d'un mecanisme hybride dans la prochaine generation 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 deja prononces ne disparaissent pas, mais ils sortent du registre "Active" pour rejoindre l'historique. Pour un acheteur federal soumis a l'obligation FIPS, un produit ne presentant qu'un certificat 140-2 a partir de cette date risque d'etre ecarte. Cette echeance 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 ecarts entre 140-2 et 140-3 peuvent imposer des modifications de conception : ajout d'exigences non-invasives, renforcement de la politique de securite, mise a jour des auto-tests, alignement des roles et des authentifications. Pour un module logiciel pur, l'effort reste raisonnable. Pour un module materiel niveau 3 ou 4, le delai 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 egalement un parcours Common Criteria ISO/IEC 15408, une partie des artefacts de conception est mutualisable, en particulier le document de politique de securite et l'analyse de la frontiere 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 precisant les algorithmes approuves, les services et les parametres de securite acceptes dans le cadre americano-canadien.

Texte	Role
ISO/IEC 19790:2012	Exigences de securite des modules cryptographiques
ISO/IEC 24759:2017	Methodes d'essai des exigences ISO/IEC 19790
FIPS 140-3	Adoption nationale americaine d'ISO/IEC 19790
SP 800-140A-F	Annexes nationales aux methodes d'essai et algorithmes

Cette articulation a deux consequences 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 reconnaitre, en tout ou partie, un dossier deja constitue pour le CMVP, sous reserve d'adaptations locales.

Pieges frequents

Quelques erreurs reviennent regulierement 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 federal apres le sunset. Planifier la revalidation 140-3 au moins dix-huit mois avant l'echeance 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 operationnel. Un module annonce comme logiciel mais s'appuyant sur un materiel specifique (extension AES-NI, instructions cryptographiques d'un microcontroleur) peut etre requalifie en module hybride en cours d'instruction, avec un perimetre de tests etendu.

Omettre la specification de l'environnement operationnel. La politique de securite doit lister precisement la plate-forme evaluee (OS, version, materiel). Un OS hote different en production conduit le client federal a considerer le module comme non operant en regime FIPS.

Inclure un algorithme non approuve dans le perimetre. Un algorithme proprietaire ou non liste a la SP 800-140C doit etre mis explicitement hors du perimetre cryptographique approuve, faute de quoi le module est rejete a la validation.

Sous-estimer la documentation de la frontiere cryptographique. La definition precise de cette frontiere conditionne l'ensemble du dossier. Une frontiere mal tracee impose des reprises majeures en cours d'instruction.

Ignorer la portabilite plateforme. Un module valide sur Linux x86_64 n'est pas automatiquement valide sur Linux ARM64 ou Windows. La revalidation cross-plateforme est prevue par le programme mais implique des essais complementaires non triviaux.

Comparaison synthetique 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 integree	SP 800-140C, document distinct
Attaques non-invasives	Couverture limitee	Chapitre dedie, exigences par niveau
Auto-tests	Distinction implicite	Distinction explicite tests "preoperational" et "conditional"
Authentification niveau 4	Authentification par identite	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'echeance

Pour un fabricant : demarche pratique

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

1. Decision d'opportunite. Identifier les marches qui exigent FIPS 140 (federal americain, 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 cout et un delai significatifs, qui ne se justifient que par un objectif commercial documente.

2. Cadrage du module et du niveau. Definir la frontiere cryptographique, le type d'environnement (materiel, logiciel, firmware, hybride) et le niveau vise. Cette decision conditionne le choix du materiel, l'architecture logicielle, et le cout d'evaluation. Mieux vaut viser un niveau atteignable et iterer ensuite, qu'echouer sur un niveau 4 mal prepare.

3. Selection du laboratoire CSTL. Le choix du CSTL influe sur le delai, le cout, et la qualite du dialogue avec le CMVP. Demander plusieurs devis, verifier la familiarite du laboratoire avec le profil technique du module (materiel, logiciel embarque, HSM).

4. Constitution du dossier. Le coeur du travail. La politique de securite (Security Policy) est le document central, public apres validation. Elle decrit le module, ses roles, ses services, ses parametres de securite sensibles, ses interfaces, sa frontiere. La documentation interne comprend les rapports CAVP, les specifications d'algorithmes, les schemas materiels, 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 supportee, changement de fournisseur de composant cryptographique) declenche une procedure 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 europeen radio, ces decisions s'articulent avec les obligations RED et les exigences cybersecurite IoT EN 303 645, qui ne font pas double emploi avec FIPS 140-3 mais relevent d'autres referentiels. Le glossaire consolide les acronymes CMVP, CAVP, CSTL et leurs equivalents internationaux.

Voir aussi

• TPM 2.0 et securite materielle TCG
• CSPN et ANSSI Visa : cybersecurite francaise
• CMMC et UK Cyber Essentials: baselines cyber de defense
• PSA Certified: securite IoT pilotee par Arm
• SESIP: methodologie d'evaluation cybersecurite 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 decennie 2025-2035 pour FIPS 140-3.

La premiere est la migration post-quantique generalisee. ML-KEM, ML-DSA et SLH-DSA sont desormais standardises, mais leur deploiement 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 integrent de plus en plus systematiquement une voie hybride classique + post-quantique.

La deuxieme est la convergence internationale via ISO/IEC 19790. L'adoption directe d'ISO/IEC 19790 par plusieurs schemas nationaux (Japon, Coree, partiellement Australie via la passerelle ASD) ouvre la possibilite d'une reconnaissance mutuelle progressive. Le programme CMVP, le JCMVP japonais et le KCMVP coreen pourraient a terme rapprocher leurs procedures.

La troisieme est la consolidation des outils d'evaluation automatisee. Les vecteurs CAVP sont desormais executables via le protocole ACVP (Automated Cryptographic Validation Protocol), permettant de tester un module en interaction avec un serveur central NIST. Cette automatisation reduit le delai sur la phase algorithmique du dossier, sans changer la phase d'instruction CMVP qui reste documentaire.

Pour un fabricant europeen, FIPS 140-3 n'est pas une obligation reglementaire de marquage CE, mais reste une reference d'assurance frequemment exigee contractuellement. Le calendrier sunset de septembre 2026 impose d'avoir, pour tout produit cryptographique en service, soit un certificat 140-3 deja prononce, soit une trajectoire de revalidation documentee.

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 : referentiel d'evaluation de securite generique, complementaire de FIPS 140-3
• ETSI EN 303 645 : cybersecurite IoT consommateur
• RED : cadre europeen pour les equipements radio, articulation avec la cybersecurite produit
• Glossaire : definitions 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