Artifact GuideGLOBALFIPS 140-3

FIPS 140-3 Entropy and DRBG

A focused guide to the entropy-source and deterministic random bit generator evidence that can affect FIPS 140-3 module validation.

Use it to separate module design facts from CMVP caveat, Security Policy, ESV, and test-report evidence needs.

Back to main artifact Review sources

Author

Sorena AI

Published

May 9, 2026

Updated

May 9, 2026

Sections

Structured answer sets in this page tree.

Primary sources

Cited legal and guidance references.

Publication metadata

Sorena AI

Published May 9, 2026

Updated May 9, 2026

Overview

Entropy and DRBG review under FIPS 140-3 starts with how the cryptographic module obtains entropy, where the entropy source sits relative to the cryptographic boundary or TOEPP, and how the DRBG seed, internal state, and generated SSP strength are documented. This page does not treat an entropy source or DRBG as approved by default; it helps teams identify the evidence that must be checked before making a validation, procurement, or release claim.

Section 1

Classify how the module obtains entropy

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.

Record whether each source is inside the cryptographic boundary, inside the TOEPP, outside the TOEPP, or externally loaded.
Document the exact interface used by the module: direct GetEntropy() call, callback with a direct path, GET command, LOAD command, seed loader, preloaded seed, or caller-supplied API buffer.
State the minimum number of entropy bits generated, requested, accepted, or believed to have been loaded for SSP generation.
Flag passive paths early because they can trigger certificate caveats or, for some inside-TOEPP designs without direct GetEntropy() access, prevent validation.

Sources for this answer

CMVP Implementation Guidance for FIPS 140-3

IG 9.3.A explains entropy caveat scenarios, direct GetEntropy() access, Security Policy statements, and certificate caveats for DRBG seeding.

NIST FIPS 140-3 security requirements for cryptographic modules

FIPS 140-3 frames the module-level validation context for sensitive security parameter management, self-tests, and life-cycle assurance.

Section 2

Tie entropy claims to Security Policy and certificate caveats

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.

A practical review therefore compares 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.

For active entropy generation or a direct call to a known source, keep the vendor entropy-strength estimate and the lab corroboration evidence with the Security Policy text.
For externally requested or externally loaded entropy, confirm whether the certificate needs the no-assurance caveat and whether the Security Policy explains the caller responsibility.
For generated SSPs or random strings whose strength is limited by available entropy, make the caveat and Security Policy language match the affected output.
For configurable entropy sources, list the configured source, any ESV certificate number, and the Security Policy configuration rule that makes the source valid for the module.

Sources for this answer

CMVP Implementation Guidance for FIPS 140-3

IG 9.3.A specifies when Security Policy entropy statements and module-certificate caveats are required for SSP generation.

NIST CAVP validation search

CAVP validation records help teams verify algorithm evidence that supports approved DRBG and related approved-security-function claims.

Section 3

Protect SP 800-90A DRBG critical security parameters

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.

List DRBG mechanism type: Hash_DRBG, HMAC_DRBG, CTR_DRBG, or another approved random bit generation construction in scope.
Classify entropy input, seed, and required internal-state values as CSPs in the Security Policy and design evidence.
Show how non-DRBG code and other DRBG instantiations are prevented from accessing DRBG internal state.
For CTR_DRBG, record whether the derivation function is used and attach the full-entropy source evidence when it is not.

Sources for this answer

CMVP Implementation Guidance for FIPS 140-3

IG D.L identifies SP 800-90A DRBG entropy input, seed, and secret internal-state values as CSP evidence topics.

NIST FIPS 140-3 security requirements for cryptographic modules

FIPS 140-3 includes sensitive security parameter management and self-tests among the module security requirement areas.

Recommended next step

Operationalize FIPS 140-3 entropy evidence

Use the module boundary, entropy-source path, Security Policy, certificate caveat, ESV, and DRBG CSP records as the working evidence set.

Assessment workflow

Open Assessment Autopilot for FIPS 140-3

Turn entropy-source, DRBG, Security Policy, and certificate-caveat checks into accountable evidence work.

Explore next step

Research workflow

Research FIPS 140-3 source questions

Resolve CMVP guidance, CAVP record, ESV, and module-scope questions before implementation or procurement review.

Explore next step

Talk to Sorena

Talk through FIPS 140-3 entropy and DRBG implementation

Review module scope, entropy evidence, DRBG CSP handling, and the next validation-support actions with Sorena.

Explore next step

Section 4

Check SP 800-90B and multiple-source evidence

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.

Multiple entropy sources should not be counted 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 nature of the sources, which are creditable, and whether the certificate identifies all-physical or not-all-physical validated entropy sources. If sources are mutually dependent, at most one dependent source may be credited.

Keep raw entropy data handling, statistical-test results, and heuristic entropy-source analysis together in the validation evidence pack.
Distinguish physical and non-physical entropy sources before crediting entropy from multiple sources.
Credit only independent source behavior when summing entropy for a concatenated seed, and document any dependency argument.
Do not rely on external conditioning to rescue an entropy claim where current CMVP guidance does not allow it.

Sources for this answer

CMVP Implementation Guidance for FIPS 140-3

IG D.J and D.K discuss SP 800-90B compliance, entropy-source assessment, multiple-source concatenation, and physical/non-physical source notation.

NIST SP 800-90B entropy assessment tool

CMVP guidance cites this tool for SP 800-90B statistical testing while preserving the lab's responsibility for heuristic analysis.

Section 5

Release checklist for entropy and DRBG claims

Use this checklist before relying on a FIPS 140-3 entropy or DRBG claim in a customer response, procurement review, certificate summary, or release gate. The goal is to make each public or internal claim traceable to module-specific evidence rather than a generic statement that the product uses an approved DRBG.

Module boundary: confirm the cryptographic boundary, TOEPP or physical perimeter, entropy source location, and DRBG service entry points match the validation evidence.
Entropy scenario: classify each source under the relevant CMVP entropy caveat scenario and record whether the module actively obtains entropy, passively receives it, or uses a hybrid design.
Security Policy: verify minimum entropy amounts, source configuration, caller guidance, caveat wording, random-string treatment, and ESV or ENT references.
DRBG CSPs: map entropy input, seed, and mechanism-specific internal state values to CSP handling, access controls, zeroization, and self-test evidence.
Algorithm evidence: attach CAVP or other validation records for the DRBG and related approved functions without implying that an algorithm certificate validates the whole module.
Change triggers: reopen the review after hardware, operating-system, virtualization, boundary, entropy-source, callback path, derivation-function, or DRBG-configuration changes.

Sources for this answer

CMVP Implementation Guidance for FIPS 140-3

CMVP guidance provides the entropy caveat, SP 800-90B, and SP 800-90A DRBG CSP criteria behind this checklist.

NIST CAVP validation search

CAVP records are useful evidence for approved algorithm implementations, but they do not replace module validation scope review.

Primary sources