FIPS: Is it Chaos or New CMVP Entropy Requirements? Testing

# FIPS: Is it Chaos or New CMVP Entropy Requirements? Testing

Updated CMVP entropy requirements under the FIPS 140 framework require cryptographic modules to validate entropy sources against NIST SP 800-90B estimation methods. Vendor documentation alone is no longer sufficient. Noise sources, health tests, and conditioning components must each pass defined testing before entropy claims are accepted.

Principle & mechanism

An entropy source converts a physical or computational noise process into random bits. These bits seed deterministic random bit generators. The architecture follows the model defined in SP 800-90B. A noise source produces raw digitized samples. Health tests monitor those samples for catastrophic failure. An optional conditioning component compresses raw output into a more uniform distribution.

Validation examines each stage separately. The noise source is characterized by the min-entropy it contributes per sample. Min-entropy is a worst-case measure, not an average. Health tests must detect stuck-at, repetitive, and biased output conditions within defined response limits. Conditioning functions, whether vetted or non-vetted, must demonstrate that output entropy is not less than the entropy claimed for the input. The reviewer's task is to trace the claimed entropy rate through every stage, from physical phenomenon to final seed material, with no unsupported leaps.

Entropy source testing scope

Testing under the CMVP entropy requirements covers three distinct objects. First, the noise source itself. It may be based on ring oscillators, avalanche noise, metastability, or other physical phenomena. Its per-sample entropy must be estimated from large sample datasets. Second, the health tests implemented in firmware or hardware. These include power-up tests, continuous tests such as repetition-count and adaptive-proportion checks, and their failure behavior. Third, conditioning components. Vetted constructions such as hash-based functions follow prescribed entropy calculations. Non-vetted functions require full entropy estimation on their output.

The scope also includes documentation review. The entropy justification document must describe the noise mechanism, sampling conditions, environmental assumptions, and developer-side entropy assessment. Repaired and mitigated entropy sources fall within scope as well. Field failures and their remediation affect the validity of the original entropy claims.

Test methods and procedures

The standard workflow proceeds in defined stages. The developer first collects sample datasets from the entropy source under representative operating conditions. The minimum dataset size is one million consecutive samples per tested condition. Datasets are gathered across temperature, voltage, and process corners as applicable.

Each dataset then undergoes the estimator suite specified in SP 800-90B. For binary sources, these include the most-common-value estimate, collision estimate, compression estimate, and Markov estimate. For non-binary sources, estimates such as most-common-value, collision, and compression apply to the sample space. Each estimator returns a lower-bound entropy value. The minimum across all estimators becomes the assessed entropy rate.

Health tests are exercised by injecting known-faulty data to confirm detection and response. Conditioning outputs are tested using the same estimator suite. Restart testing is added to measure whether consecutive start-up sequences show independence. All procedures are documented for reviewer reproducibility.

Performance metrics and validation

The principal metric is the assessed min-entropy per sample, expressed as a proportion of the maximum possible entropy. For full-entropy conditioning claims, the output must satisfy the criteria for full-entropy sources under SP 800-90B, subject to the specified statistical allowance. For non-full-entropy claims, the validated entropy rate becomes the value a module may credit when deriving seeding material. The seeding procedure in SP 800-90C governs how much entropy must be combined to reach the target security strength.

Additional metrics include the false-positive rate of health tests, calculated from their thresholds and sample sizes. The inter-dataset variation of entropy estimates reveals sensitivity to operating conditions. Restart test results are evaluated for independence between consecutive power cycles. Reviewers compare the documented developer assessment against independently computed estimator outputs. Discrepancies must be resolved before the entropy claim is accepted.

Acceptance criteria under CMVP

Acceptance within CMVP requires that every entropy claim trace to an estimator result or a vetted-construction calculation, with no gaps. The minimum entropy across all estimators and all datasets becomes the validated rate. No dataset may be excluded without documented justification tied to operating conditions the module enforces.

Health tests must be present, correctly implemented, and shown to trigger on simulated failures. Absent or non-functional health tests are grounds for rejection. Vetted conditioning functions must be instantiated exactly as specified. Non-vetted functions must pass the full estimator suite on output data under all claimed conditions.

The entropy justification document must state the noise mechanism, all assumptions, and the sampling environment. Where any assumption depends on module behavior, such as controlled start-up sequencing, that behavior must be verified in the module's security policy. Claims that exceed demonstrated results cannot be validated.

Application scenarios and deliverables

Typical scenarios include cryptographic hardware modules preparing for FIPS 140-3 validation. Embedded devices seek to substantiate randomness claims for key generation. Product lines update legacy entropy sources after requirement changes. Testing also serves pre-submission gap assessment. In that case, a laboratory runs the estimator suite on developer datasets before formal validation to identify weak claims early.

The deliverables comprise the validated entropy rate per sample, the complete estimator outputs for every dataset, health test verification records with fault-injection results, conditioning analysis, and the reviewed entropy justification document. These artifacts accompany the module submission package and are referenced in the module's security policy, which states how validated entropy is consumed. Upon successful review, the entropy source appears as a validated component. Module reviewers can then credit its entropy rate in downstream seeding and DRBG evaluations without re-characterization.