NIAP recently released Labgram #118 – Entropy Source Validation Certificates. It mandates that ESV certificates must be included as part of the Entropy Assessment Report (EAR) for all products that enter evaluation with NIAP from January 1st, 2025. Effective immediately, vendors may submit EARs that refer to an ESV certificate. This blog post discusses what ESV is, how it relates to Common Criteria under NIAP and the impact of this policy on vendors undertaking evaluations outside of NIAP (e.g. Canada etc.) but seeking NIAP PCL entry.
An ESV certificate signifies that an entropy source is SP800-90B compliant. The ESV package consists of a Public Use Document (PUD), which is available to the public, and a proprietary EAR. ESV certification is also required for FIPS 140-3 cryptographic module validation. For more information about FIPS ESV requirements, please refer to the blog posts ESV and Me! | Lightship Security and Entropy Validation in FIPS 140-3 (ENT vs ESV) | Lightship Security.
Vendors targeting the NIAP PCL must undertake evaluations claiming conformance to a NIAP Approved Protection Profile. Most of these Protection Profiles include requirements for an EAR for random bit generation functionality. The CC EAR describes what is the source of randomness, and how it provides random data to the cryptographic module used by the Target of Evaluation (TOE).
According to Entropy Documentation and Assessment section of PPs, the EAR must contain the following:
- Design Description. Entropy source components must be described. The flow of data from the entropy source to the calling application must be described.
- Entropy Justification. A min-entropy estimate must be provided and justified. The rate at which the entropy source seeds the DRBG must also be described and justified.
- Operating Conditions. The range of operating conditions under which the entropy source is expected to generate random data must be described.
- Health Testing. All health tests performed on the entropy source during start-up, continuously, and on-demand must be described.
Per NIAPs guidance on ESV, all of this is content is still required and “It is up to the vendor and the Common Criteria Technical Lab (CCTL) to determine if the documentation used for the ESV program is sufficient for submission to NIAP or if a separate document is submitted as the EAR.”
The Public Use Document (PUD) of the ESV certificate will typically have sufficient information to cover most of the requirements for a CC EAR. The PUD contains a description of the entropy source and its security boundary, operating conditions, and health tests. A min-entropy rate is also provided in the PUD.
However, the level of detail in the description of the entropy source in the PUD might not be sufficient. In particular, the PUD does not require a discussion on how the DRBG is instantiated, and how the product uses the entropy.
Even if the lab has access to the ESV EAR, additional information might still be required to describe how the DRBG is instantiated and in what conditions the product’s cryptographic operations use entropy.
This is because the CC EAR requires a detailed description of the flow of data from the entropy source to the calling application whereas an ESV EAR typically only describes the flow of data from the entropy source to the DRBG, and it seldom describes the DRBG itself.
Below are some frequently asked questions we’ve received.
Are vendors still allowed to claim platform-provided entropy?
Where the selection is available in the Protection Profile, platform-provided entropy sources are still allowed, however, if the random values provided by the platform are used to seed other DRBGs; or if the values are further processed or conditioned by the application prior to use, then platform-provided functionality cannot be claimed.
Will NIAP accept equivalency arguments for products that use CPU Jitter on Intel processors in the same family?
It is expected that the NIAP Policy 5 equivalency rules will apply – equivalent at the microarchitecture level and one exact CPU match in the ST.
Is NIAP going to use FIPS IG 9.3.A to determine which products need ESV certs?
Lightship assesses that this is unlikely. An EAR is required for all TOEs that implement DRBG functionality and claim conformance to a Protection Profile such as PP_APP or NDcPP. This implies that an ESV will be required to provide a min-entropy rate.
Will vendors certified by international schemes need ESV for NIAP PCL?
No. This policy is specific to evaluations undertaken within NIAP.
Will other schemes start to require ESV?
We assess that schemes closely aligned with NIAP such as Australia and Canada will likely implement policies that address ESV. These schemes tend to be a little more flexible – so we’ll see what policies come out if any.
How should vendors prepare for this?
Lightship recommends that vendors start to work towards obtaining ESV certificates now. This may require engaging with providers of third-party entropy sources (e.g. CPU sources such as RDRAND, TPMs etc.). It may be necessary for some vendors to change entropy sources so that they can control the ESV process.
Contact Lightship Security today if you need help with ESV.
Marina Ibrishimova
Marina Ibrishimova has 12 years of experience as a security engineer and a security researcher. In her current role as a Cyber Security Consultant at Lightship she helps clients achieve compliance to security standards such as Common Criteria and FIPS 140-2/140-3. She specializes in functional gap assessments, vulnerability testing, and entropy source analysis and statistical testing.
Lachlan has 20+ years of extensive product security certification experience, including roles as a government certifier, lab evaluator and vendor consultant. As the Director of Cyber Labs, Lachlan has overall responsibility for our Canadian and US Common Criteria laboratories.