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.

A strong mapping table should be precise enough for an engineer, lab reviewer, or procurement reviewer to find the same claim again. Avoid rows that say only "AES" or "approved crypto"; those labels do not show 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 certificate identifier or documented validation entry, the module service that invokes it, the approved-mode use, relevant parameters or restrictions, and the source table where the claim is published. If the service uses only part of another validated module, list only the functionality the module actually uses.

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.

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 it is resolved in the security policy, test report, or source evidence. The safest correction is usually to narrow the claim: show the exact service, algorithm capability, certificate entry, parameter set, and approved-mode condition that the module can support.