The claimed entropy source for a FIPS 140 validated module now requires compliance to NIST SP800-90B. This means that any cryptographic module going through FIPS 140-2 or FIPS 140-3 validation needs to adhere to NIST implementation guidance 7.18 – Entropy Estimation and Compliance with SP 800-90B. This post will introduce relevant requirements and cover basic concepts of entropy source validation for a FIPS 140 module.
A cryptographic module typically requires random numbers or bits to generate keys used to provide various cryptographic functions to operators and applications. NIST SP800-90B provides guidance and requirements on how to obtain random numbers in a FIPS 140 approved way.
The quality of the entropy source and entropy inputs are critical to generating sufficiently strong cryptographic keys needed for the overall security posture of a given technology. It is for this reason that the CMVP and other standards bodies are increasingly focused on ensuring that suitable entropy sources and implementations are being used in technologies being deployed in government agencies and other critical sectors.
The NIST SP800-90B recommendation describes the process to validate entropy sources relied upon to produce secure random numbers. Companion document NIST SP800-90A describes how to use the random number or “seed” from the entropy source to create an instance of a Deterministic Random Bit Generator (DRBG). A DRBG is considered deterministic since the same input seed will always produce the same output and not an unpredictable, random value. Another draft companion document is NIST SP800-90C, which recommends how to construct NIST approved random bit generators using entropy sources from SP800-90B and DRBGs from SP800-90A.
SP800-90B describes how to model, test and validate physical hardware and non-physical software noise sources. This includes the digitization or processing of these noise outputs to provide raw data. The digitized noise source outputs can then be conditioned to reduce bias and/or increase the entropy rate of the resulting output bits. Noise and entropy validation includes the collection and testing of the following types of data samples.
- Sequential dataset – A sequential dataset of at least 1,000,000 sample values obtained directly from the noise source (i.e., raw data). Note that this can be tricky if you cannot get access to the raw sample from your module’s noise source. For example, collecting raw sample data may require a specialized Linux kernel build or access to proprietary hardware procedures.
- Conditioned dataset – If the entropy source includes a non-vetted (aka “non-approved”) conditioning component, a conditioned sequential dataset of at least 1,000,000 consecutive conditioning component outputs. For example, a linear-feedback shift register (LFSR) is a non-vetted conditioner, and an approved cryptographic hash function is a vetted conditioner according to the SP800-90B recommendation.
- Restart dataset – For the restart tests, the entropy source must be restarted 1,000 times; for each restart, 1,000 consecutive samples are collected. Note that a restart should simulate the restart process expected in real-world use (e.g., the outputs are not generated until after the start-up tests are complete. All restarts are expected to be done in normal operating conditions.
Data sample testing can then be done using the traditional NIST 90B tool (https://github.com/usnistgov/SP800-90B_EntropyAssessment) or by using the brand new online testing tool called Entropy Source Validation (ESV) (https://github.com/usnistgov/ESV-Server). The testing results can then be included in the entropy report to provide estimates of entropy for module validation.
In addition to data sample testing, the entropy source must provide health testing to quickly detect deviations from the expected behavior of the noise source. Health tests are applied to the raw outputs of a noise source before any conditioning occurs.
Here are the types of health tests required by the entropy source.
- Repetition Count Test (RCT) – the goal of the Repetition Count Test is to quickly detect catastrophic failures that cause the noise source to become “stuck” on a single output value for a long period of time.
- Adaptive Proportion Test (APT) – the Adaptive Proportion Test is designed to detect a large loss of entropy that might occur as a result of some physical failure or environmental change affecting the noise source.
- Developer-Defined Alternatives – Developer tests are always permitted in addition to the two approved tests listed above.
Here is an overview of when health tests are required by the entropy source.
- Start-up health tests are designed to be performed after powering up, or rebooting, and before the first use of the entropy source. They provide some assurance that the entropy source components are working as expected before they are used during normal operating conditions.
- Continuous health tests are run indefinitely on the outputs of the noise source while the noise source is operating. Continuous tests focus on the noise source behavior and aim to detect failures as the noise source produces outputs.
- On-demand health tests can be called at any time. Note that resetting, rebooting, or powering up are acceptable methods for initiating an on-demand test if the procedure results in the immediate execution of the start-up tests.
When the health tests fail, the consuming application must take action to attempt to reset the source or to declare that the entropy source is not available to provide random numbers in an approved way.
Ready to validate? Please contact Lightship Security with any questions you may have about FIPS 140, entropy and requirements to meet NIST 800-90B.
James Ramage
James Ramage is a senior FIPS evaluator at Lightship. He has been doing FIPS evaluations and security certifications for 5+ years and enjoys working with customers, training team members and evaluating new technologies.