As I covered in my previous blog post, there have many changes in the FIPS 140 requirements for entropy validations. So what’s next? The next major change to FIPS 140 entropy requirements will be to require validated entropy sources for software modules!
Both FIPS 140-2 and FIPS 140-3 have defined the different cases in which an entropy validation is or is not required for a FIPS module. For FIPS 140-3, these cases and corresponding examples are defined in the 140-3 Implementation Guidance (IG) under IG 9.3.A – Entropy Caveats.
The most straightforward example in this IG is case 1(a) for “hardware module with an entropy generating source inside the module’s cryptographic boundary.” For FIPS modules that fall under this scenario, entropy validations have been required for as long as entropy has been a requirement. This is because the module is clearly generating its own entropy from an entropy source that is inside of and controlled by the FIPS module.
In contrast to the example above, historically most software modules have fallen under case 2(b) of this IG. Case 2 is for a module “passively receiving the entropy while exercising no control over the amount or the quality of the obtained entropy”. Case 2(b) in particular is for a software module that receives its entropy from outside the module’s boundary and does not control the entropy source(s) (e.g. a module receiving entropy via a LOAD command).
Because the module does not include an entropy source and the module is not responsible for the entropy source(s), a corresponding caveat is included on the module’s FIPS certificate that “The module generates SSPs (e.g., keys) whose strengths are modified by available entropy.” However, the entropy analysis requirements are minimal and operators have the freedom to use a variety of entropy sources, so long as they are believed to provide sufficient entropy.
Last year the CMVP made a large change by updating this IG to require entropy validations for almost all software modules in the future.
The CMVP changed the case that applies to most software modules to a revised case 1(b). For this revised case, a software module’s approved DRBG “is seeded exclusively from one or more known entropy sources, located within the [computing platform]”. In this case, a full ESV (SP 800-90B) entropy validation is now required.
With this change, entropy validation will be required for software modules that use entropy sources outside the module, but on the same computing platform. Entropy validation will also be required if the software module does not control the entropy source.
As I outlined in my blog on the SP 800-90 series, validated entropy sources must meet the stringent requirements of SP 800-90B and these requirements cannot be met by many popular entropy sources, including dev/random.
It’s important to note that the module can only use the validated entropy source, so this path forward is less flexible. Also, the entropy source validation must cover every tested platform that will be listed on the FIPS certificate. Additionally, the IG updates specify that an entropy source cannot be validated if the module does not have direct access to the entropy source’s GetEntropy() interface. This direct access requirement is intended to prevent manipulation of the entropy by an entity or code outside the FIPS module.
This is a major change to FIPS 140 validation requirements for software modules. The CMVP recognized that time is needed for vendors to create and test modules that align with these requirements, so they implemented a transition timeline.
All new module submissions to the CMVP will need to meet the new entropy validation requirements starting on January 1, 2026. Until then, modules may continue to align with the older requirements described above for software modules. Additionally, this will be a “soft” transition, so modules that do not align with the new guidance will still remain on the Active FIPS certificates list after this date.
While these requirements will be more difficult to meet, we’re looking forward to a future where software module users will have assurance that they’re using strong entropy sources for their cryptography!
FIPS 140 is also not the only validation program implementing stricter requirements for entropy – stay tuned for our next blog post on changes to entropy requirements for NIAP’s Common Criteria (CC) evaluations.