FIPS KDF and MAC coverage for validated modules

Start by naming the exact service: HMAC, truncated HMAC, KBKDF under SP 800-108, PBKDF under SP 800-132, KDA under SP 800-56C, a protocol KDF such as TLS, or a key-wrapping construction that combines encryption with an approved authentication function. Do not infer that HMAC, CMAC, or KMAC is approved for a service merely because its underlying SHA, AES, or SHA-3 primitive is approved.

FIPS 140-3 requires conforming cryptographic modules to employ approved security functions. CMVP implementation guidance then makes the evidence more granular: approved security services need indicators, and the module Security Policy must list approved and non-approved services with the details needed to interpret those indicators.

The most common KDF error is treating all key derivation as one bucket. CMVP guidance separates key derivation from a pre-shared key, key derivation during approved key establishment, password-based derivation for storage, and protocol-specific KDF components.

SP 800-108 KDFs are approved for deriving new keys from existing keying material when the key derivation key has been generated, entered, or established by a method approved or allowed in approved mode. They are not for directly generating asymmetric keys. SP 800-56C KDA belongs to key-establishment schemes, and CMVP guidance also identifies a no-iteration, no-counter one-step KDF variation with CAVP testing under KDA OneStepNoCounter.

HMAC coverage needs more than naming the hash. CMVP guidance requires a CAST for implemented HMAC using at least one implemented SHA-1, SHA-2, or SHA-3 algorithm, and it gives separate rules for truncated HMAC use in approved mode.

For truncated HMAC, the module evidence should show the leftmost tag length, CAVP validation of the applicable truncated HMAC, Security Policy disclosure, and key-strength limits. CMVP guidance allows approved truncated HMAC forms when the output is truncated to at least 32 leftmost bits, while also noting that truncations below 64 bits are discouraged by SP 800-107rev1.

A reviewer should be able to trace each claimed KDF or MAC service from the Security Policy to the CAVP or CVL evidence and back to the shipped module configuration. The module vendor records the implementation and service; the laboratory tests the applicable algorithm or component; the product team maps its callable feature to that service; and the assessor verifies the certificate, indicator, and usage restriction. The evidence table must explain the approved manner of use instead of reporting only "approved."

For FIPS 140-3, CMVP guidance on algorithm certificate binding is especially important. The CAVP certificate has to match the name and version of the validated algorithm implementation and the tested operational environment, and the embedded implementation must not be modified when integrated into the module under test.

Most coverage gaps are caused by collapsing separate CMVP concepts into one compliance sentence. Keep algorithm validation, module validation, approved-mode service use, Security Policy wording, and operational-environment binding separate.

Use the checklist below as a release or audit gate before publishing FIPS KDF or MAC claims, responding to procurement questions, or preparing module evidence.