Vendors are increasingly looking to leverage OpenSSL 3.x as their cryptographic module of choice within their products. At the same time, entropy continues to a be a focus in both FIPS 140-3 and Common Criteria projects. For those transitioning from OpenSSL 1.0.2 and the FIPS Object Module 2.0.x, the ways in which entropy can seed the DRBG in OpenSSL 3.0 differs.
Read More
Quantum computing continues to be a hot topic. Within the certification industry, it was most recently covered at the International Common Criteria Conference (ICCC) recently held in Spain. So, what is quantum computing and more importantly, what is the potential impact on computer security and cryptography? The purpose of this post is to provide a brief introduction to post-quantum cryptography – including what changes are planned to algorithm standards to proactively defend against potential security issues and when will cryptography updates come into effect? In addition, what organizations are involved in assessing requirements, proposing updates and then enforcing post-quantum solutions?
Read More
This post aims to answer the most common questions we get about NDcPP 3.0:
Lightship has released, as open source, an ACVP vector test harness for OpenSSL 3.x.
The code can be found in our GitHub repository at https://github.com/lightshipsec/ls-acvp-harness.
The README.md contains the current capabilities which we expect to update and maintain. At the moment, we include most of the typical algorithms and properties that are often claimed or required in FIPS 140-3 and Common Criteria. The full set of supported algorithms, operating modes and properties are described in the README.md. Additional algorithms can be added as needed.
Read More
Many modern Common Criteria Protection Profiles include X.509 requirements requiring the evaluator to construct a series of certificates designed to verify that a system under test is correctly parsing and validating them. X.509 certificates appear relatively simple on the surface, but digging into the details uncovers a wealth of complexity and nuance in RFC5280, ASN.1, DER, and BER. We’ll explore this testing using a specific example of the basicConstraints:CA flag and show how common X.509 tools can represent — and potentially obscure — some of the requirements as it pertains to Common Criteria conformance testing.
Read More
As of November 7, 2020, the Cryptographic Module Validation Program (CMVP) required that all FIPS 140-2 and FIPS 140-3 module validation submissions include documentation justifying conformance of the entropy source to NIST SP 800-90B, if the module is “either generating the entropy itself or it is making a call to request the entropy from a well-defined source”. Compliance documentation would include an Entropy Assessment Report (EAR) and statistical testing of entropy data samples using the NIST 90B Test Tool.
Read More
To get an entropy source approved under FIPS 140-3 there are two options:
This blog post will address these entropy validation requirements in FIPS 140-3. We’ll provide details on the differences between the “ENT” validation certificate entry and Entropy Source Validation or “ESV” certificates. Relevant NIST Special Publications (SPs), important Implementation Guidance (IG) and links to templates and other important references will also be provided.
Read More
Algorithm validation testing is a critical path issue for FIPS 140-3 validations and for NIAP Protection Profile-based Common Criteria evaluations. Equipment vendors are often surprised at the level of effort and the potential challenges in successfully completing the algorithm testing process.
At Lightship, we have developed a suite of tools to allow us to standardize, simplify and streamline the process to obtain CAVP (Cryptographic Algorithm Validation Program) validation.
This post will outline each of the steps in addition to identifying where we will require input from the vendor.
Read More
Our previous article discussed how vulnerabilities are dealt with under the Common Criteria certification program in North America. All commercial product assurance programs deal with flaws and vulnerabilities in different ways, often with overlapping requirements, techniques and outcomes.
In this article, James Ramage of the Lightship Security FIPS team talks about how vulnerabilities are handled for FIPS 140-3 validations.
Read More
No computing system is free from security vulnerabilities. Such flaws can manifest themselves within software, firmware and hardware implementations. Often the ease in widespread mitigation is based in part on whether a vendor can provide updates to software (relatively easy), firmware (a bit harder), or whether a new version of hardware needs to be deployed (very difficult). The constraints and goals of point-in-time security certification programs such as Common Criteria (CC) and FIPS 140-3 can often conflict with the need to correct such security deficiencies. With the recent disclosure of CVE-2021-44228 (a remote code exploit [RCE] in the widely deployed log4j component in Java-based products), questions often come up as to how such vulnerabilities are handled within certain certification programs.
Read More
