FIPS 140-3 and the CMVP: what 'FIPS validated' actually means

Every other NIST document on this site specifies an algorithm or a protocol. FIPS 140-3, Security Requirements for Cryptographic Modules, specifies something different: the product that runs those algorithms. A cryptographic module can be a software library, a firmware image, a smart card chip, or a rack-mounted HSM. FIPS 140-3 asks how that product draws its boundary, which services it offers and to whom, how it tests itself, how it generates, stores, and destroys keys, and how hard it is to open up physically.

The standard is enforced through the Cryptographic Module Validation Program (CMVP), run jointly by NIST and the Canadian Centre for Cyber Security. A vendor doesn't self-certify: an independent testing laboratory accredited under NIST's NVLAP program tests the module, and the CMVP reviews the lab's report before issuing a numbered certificate. US federal agencies (and Canadian government departments) are required to use validated modules to protect sensitive data, and a long list of other regimes inherit the requirement from them, from FedRAMP cloud authorizations to the US defense supply chain's CMMC.

FIPS 140-3 is a short document. Instead of restating its requirements, it adopts the international standard ISO/IEC 19790:2012 for the security requirements and ISO/IEC 24759 for the test methods, and then layers US-specific choices on top through the NIST SP 800-140 series: what documentation the lab needs (800-140A), what the public Security Policy must contain (800-140B), which security functions count as approved (800-140C), which key generation and establishment methods are approved (800-140D), which authentication mechanisms are approved (800-140E), and how non-invasive attacks are tested (800-140F). The CMVP's Implementation Guidance, updated several times a year, then interprets all of it.

This is the first time the US module standard and the international one have been the same text underneath, which is why the ISO/IEC page on this site calls 19790 the international counterpart rather than a competitor.

A module isn't simply 'Level 3'. ISO/IEC 19790 splits the requirements into eleven areas (module specification, interfaces, roles and authentication, software and firmware security, operational environment, physical security, non-invasive security, sensitive security parameter management, self-tests, life-cycle assurance, and mitigation of other attacks), and the lab assigns a level to each one. The overall level on the certificate is the lowest of those area levels, so a single weak area caps the whole module.

The levels mostly differ in two places: how the module authenticates its operators, and how it resists someone with physical access. That's why software libraries almost always validate at Level 1 (there is no enclosure to protect), while network HSMs typically target Level 3.

Algorithms are validated first, separately. The Cryptographic Algorithm Validation Program (CAVP) tests each algorithm implementation (AES-GCM, SHA-256, ECDSA P-256, a DRBG, a KDF) against NIST's test vectors through the automated ACVP protocol, and issues an algorithm certificate for each. The module certificate then lists which CAVP-validated algorithms the module uses in its approved mode. Entropy sources get a third, separate track: under SP 800-90B, the Entropy Source Validation program checks the noise source that seeds the module's DRBG, which is where this site's entropy module and its Playground tool connect to the standard.

With the algorithms established, the module testing covers what wraps them. The lab confirms the module's boundary and every service it exposes, and checks that the module tells callers whether a service is approved or not (an approved service indicator is a FIPS 140-3 requirement, so a caller can't accidentally run, say, MD5 and believe it was in approved mode). It checks the self-tests: a pre-operational integrity test of the module's own code or firmware before anything else runs, and conditional tests such as known-answer tests for each algorithm before its first use, and pairwise consistency tests on every newly generated key pair. It checks how keys and other sensitive security parameters enter and leave the module, and that they can be zeroized. And at Level 3 and above, it physically attacks the enclosure.

What the lab does not do is a free-form search for vulnerabilities in the product as a whole. FIPS 140-3 is conformance testing against a fixed list of requirements. Finding the unexpected flaw is closer to what a Common Criteria evaluation's vulnerability analysis is for.

Every certificate on the CMVP's public list names an exact module, an exact version (hardware, firmware, or software), the operational environments it was tested on, the overall and per-area levels, and the CAVP certificates for its algorithms. It links to the module's Security Policy, a public document that says how to configure and operate the module so that it is actually in its validated state. A FIPS 140-3 certificate is active for five years and then moves to the Historical list.

Marketing language is much looser than that. Only the first claim below is a validation; the others are statements a vendor can make without one.