FIPS 140-3 Algorithm Certificate Mapping

Start with the FIPS 140-3 module claim, not with a library list. FIPS 140-3 requires conforming modules to employ Approved security functions, including algorithms specified in a FIPS, adopted in a FIPS, listed in SP 800-140C, or specified in SP 800-140D for sensitive security parameter establishment methods.

The CMVP Implementation Guidance describes CAVP as the program that tests Approved Security Functions and Approved Sensitive Security Parameter Generation and Establishment Methods referenced by the SP 800-140 series. For a visitor reviewing a module, the mapping should therefore answer four questions: which module service uses the algorithm, which approved function or method the service relies on, which CAVP certificate or documented entry supports the implementation, and where the claim appears in the security policy or validation package.

The mapping table should let an engineer, laboratory reviewer, or procurement reviewer reproduce the claim. Avoid rows that say only "AES" or "approved crypto"; those labels do not identify the implementation, mode, parameter set, service, or certificate evidence behind the FIPS 140-3 claim.

For each row, capture the algorithm name as shown in the validation evidence, the CAVP validation identifier or documented entry, the module service that invokes it, the approved-mode use, relevant parameters or restrictions, and the source table where the claim is published. Do not treat the presence of an algorithm family in a record as evidence for every mode, key size, curve, parameter set, or service. If the service uses only part of another validated module, list only the functionality the module actually uses.

Example: a CAVP entry for an AES implementation tested on a named 32-bit platform does not map to a 64-bit-only module environment. IG 2.3.A requires the algorithm implementation to remain unmodified and the tested environment to be identical to, or fully included in, the module test environment. Mark the row as unsupported pending new CAVP testing or a CST laboratory decision instead of carrying the certificate number forward.

Certificate reuse is where many mappings become misleading. The CMVP Implementation Guidance distinguishes an implementation under test from an existing validated module and requires clear separation of information associated with each. When an implementation under test uses an existing validated module, the security policy and validation test report must identify the existing module by name, CMVP certificate number, and version, and cite only the functionality actually used.

This means a mapping cannot simply import every algorithm on another module certificate. It must show the reused service or algorithm, the relationship to the module boundary, whether the existing module is embedded or bound, and whether the reused function is approved at the time it is claimed in the submission.

Use the mapping as a validation-control artifact, not as a static appendix. Review it whenever the module boundary, cryptographic library, operating environment, algorithm implementation, parameter set, bound or embedded dependency, or security policy service table changes.

The review should produce concrete corrections: remove certificate rows for unused functions, split rows where one algorithm appears in different services with different restrictions, add usage limits for component validations, and update the approved-mode evidence when an implementation moves between approved, vendor-affirmed, allowed, or no-security-claimed treatment.

The cryptography owner should prepare the map, the module engineer should verify the exact implementation and build, and the validation owner or CST laboratory should resolve rows that depend on environment inclusion, component restrictions, or reused-module status. Retain the public certificate evidence, build manifest, Security Policy cross-reference, review date, reviewer, outcome, and next reassessment trigger with the release record.

Most certificate-mapping errors come from overstating what a certificate proves. A CAVP algorithm validation supports an implementation-specific algorithm claim; it does not by itself validate the cryptographic module, its boundary, its approved mode, or every service that happens to call the same library.

Treat each mismatch as a validation risk until the Security Policy, test report, or source evidence resolves it. Narrow the claim to the exact service, algorithm capability, certificate entry, parameter set, and approved-mode condition that the module supports.