FIPS key management mapping

FIPS 140-3 applies to cryptographic modules, not to a product name in isolation. The key-management map should therefore start with the module boundary, tested operational environment, security level, service name, and the sensitive security parameters handled by that service.

For each service, the module owner records whether the behavior is key generation, key agreement, key transport, key encapsulation, key derivation, key entry, key output, storage protection, or zeroization. The implementation owner records algorithms, strength, inputs, outputs, failure behavior, and key purpose. The assurance reviewer records the CAVP entries, CMVP certificate, Security Policy mapping, and any caveat. A single protocol or API can contain several behaviors, so the evidence should be service-level rather than marketing-level.

CMVP guidance groups SSP establishment into distinct methods. The mapping should not collapse them into a generic key-management control because each method has different certificate entries, self-test expectations, security-policy statements, and caveats.

Use separate rows for key agreement, key transport, key encapsulation, key derivation, key generation, key entry, and pre-loaded keys. The row should name the standard or implementation-guidance path, the CAVP algorithm entry when applicable, and whether the module certificate or Security Policy needs a specific annotation. If no approved path or matching evidence exists, mark the row non-approved, no-security-claimed where the guidance permits it, blocked, or subject to an owned exception; do not merge the gap into an approved row.

A CAVP certificate supports a tested algorithm implementation in a tested operational environment. It does not, by itself, prove that the finished product, service, protocol, or deployment is a validated FIPS 140-3 module.

When a validated algorithm is integrated into a module, the map should verify whether the implementation was modified and whether the operational environment matches the one used for algorithm testing. If the algorithm is used through a bound or embedded validated module, the Security Policy and validation report should identify the external validated module and mark the reused services, algorithms, SSPs, self-tests, and zeroization mechanisms clearly.

The most useful key-management map shows whether the establishment method is at least as strong as the keying material it establishes or protects. CMVP guidance reproduces comparable-strength rows from SP 800-57 and explains that weaker establishment methods can require certificate and Security Policy caveats.

Key-purpose separation also belongs in the map. FIPS 186-5 states that a key pair used for digital signature generation and verification under that standard must not be used for another purpose such as key establishment. This prevents a common evidence error: treating one public/private key pair as reusable across unrelated signing and establishment services.

Use the checklist as an evidence gate before publishing a FIPS claim, responding to an auditor, or relying on a supplier statement. The output should be a traceable table, not a general assurance paragraph.

The checklist is limited to evidence that can be tied to NIST FIPS and CMVP/CAVP sources. Procurement requirements, customer controls, and internal policies can reference the map, but they should remain separate from the cited FIPS claim. Reopen the map when a key purpose, algorithm, parameter set, strength target, library, processor path, operational environment, module boundary, Security Policy, certificate status, or supplier implementation changes.