FIPS 140-3 Entropy and DRBG

Start by drawing the entropy path for each DRBG instantiation and reseed: source, interface, boundary, caller, and whether the module actively requests entropy or passively receives it. CMVP Implementation Guidance 9.3.A distinguishes modules that generate entropy themselves or call a well-defined GetEntropy() interface from modules that passively receive entropy through a seed loader, preloaded seed, I/O port, buffer, file, API, or other caller-supplied input.

That classification drives the evidence. For active, well-defined sources, the testing lab corroborates the vendor's entropy-strength estimate and the Security Policy states the minimum entropy generated or requested. For external or passive inputs, the Security Policy and certificate caveats may need to warn that the minimum strength of generated SSPs is not assured. If an entropy source is inside the TOEPP, the module cannot rely on code outside the cryptographic boundary to fetch and deliver entropy; the module needs direct access to the GetEntropy() interface.

Apply the 112-bit floor before comparing entropy with the strength of a generated SSP. If a module is known to use fewer than 112 bits of entropy for SSPs used in an approved mode, IG 9.3.A says it cannot be validated. At 112 bits or more, a module can still need a caveat when it generates SSPs with greater comparable strength than the available entropy or when the lab cannot assure the external input.

The Security Policy should not merely say that a DRBG is seeded. It should state the entropy source scenario, the minimum entropy amount, the basis for the estimate, and the caveat text that applies when the lab cannot directly verify enough entropy for generated SSP strength. CMVP guidance also says the burden of proof is on the vendor when a tester reviews the rationale.

Compare three records side by side: the design description, the Security Policy language, and the module certificate caveat. If the design changed from active GetEntropy() access to externally loaded entropy, or if an operational environment moved the entropy source outside the tested perimeter, the certificate and Security Policy assumptions may no longer describe the deployed module.

Separate the records and actors. The vendor documents the source design and claimed estimate; an accredited entropy or CST laboratory performs the applicable SP 800-90B assessment and module testing; ESV can produce a standalone entropy-source validation; CAVP covers approved algorithm implementations; and CMVP decides the module validation and caveat. None of the supporting records makes the entire product a validated cryptographic module.

For SP 800-90A DRBG mechanisms, CMVP guidance treats the entropy input string and seed as critical security parameters. It also identifies secret working-state values for Hash_DRBG, HMAC_DRBG, and CTR_DRBG. This matters for design reviews because a DRBG service can look like a simple random API while its seed and internal state still need CSP handling, boundary protection, and test-report coverage.

CTR_DRBG needs extra attention when the derivation function is not used. The test report must indicate whether a derivation function is used during instantiation and reseeding; without it, the report must demonstrate seeding by a full-entropy source, and CMVP guidance places that source inside the TOEPP or physical perimeter or cryptographic boundary for hardware modules.

When an entropy source must be assessed under SP 800-90B, the evidence should include more than a statistical-test output. CMVP guidance says the lab still performs heuristic analysis of the entropy source, and it points to the CMVP implementation of the SP 800-90B entropy assessment tool for statistical testing.

Do not add entropy estimates by intuition. CMVP guidance allows concatenating outputs from multiple independent SP 800-90B-compliant sources to provide a DRBG seed, but the Security Policy must explain the sources, identify which ones receive entropy credit, and state whether the certificate identifies all-physical or not-all-physical validated entropy sources. If sources are mutually dependent, at most one dependent source may receive credit.

The ESV server's numerical estimate is only one part of the assessment. The laboratory must also submit documentation addressing the other SP 800-90B requirements, and CMVP reviews the justification when a certificate is requested. Keep the entropy assessment report, raw-data provenance, source configuration, validation number, and module integration evidence together.

Review this checklist before relying on a FIPS 140-3 entropy or DRBG claim in a customer response, procurement review, certificate summary, or release gate. Each public or internal claim should trace to module-specific evidence instead of a generic statement that the product uses an approved DRBG.