First time vendors to the FIPS 140 validation process are often not aware of the scope of supporting documentation and evidence required. These documentation inputs are integral to the lab being able to perform and finalize the full validation process.
The set of documents described below provide the testers with in an in-depth description, with evidence, of how a cryptographic implementation complies with the FIPS 140 standard and the most current Implementation Guidance (IG) from the CMVP. The core documents are the first thing the Lab will evaluate and ultimately forms the basis of the report that the CMVP assesses in consideration of awarding the validation. As an independent third-party, laboratories are not permitted to author original design documentation for cryptographic modules under test. As such, it’s important for vendors to plan their FIPS strategy in advance to determine if they should “build or buy” the documentation / consulting support that will be required. Generating adequately detailed documentation and design information can be time-consuming and onerous depending on your experience and the complexity of the module being validated. This effort should not be underestimated and needs to be factored into the overall cost and effort of undertaking a FIPS 140 validation.
This blog breaks down the key parts of a standard documentation package that is provided to the Cryptographic Security Test (CST) lab in support of a FIPS 140-3 validation.
Security Policy
The Non-Proprietary Security Policy (SP) is the core document of a validation. As a mandated public documented, it is appended with the final validation listing, intended for operators in the federal government space. The SP includes the module description, ports & interfaces, sensitive security parameters (SSPs), and services, among other things.
A draft of the SP must first be provided to the Lab. This step facilitates the process of having the module listed on the Implementation Under Test (IUT), that indicates to end-users that the effort towards FIPS validation is underway – a helpful indicator given how long program review times can be.
Block Diagram
A block diagram visually identifies the cryptographic boundary (a key concept of a FIPS 140 validation), showing the physical and logical layout of the module. It should include color coded arrows that show where plaintext and ciphertext data flows within the module boundary. The diagram should also be consistent with data input, data output, control input, control output, and status output.
Bill of Materials
A document containing a list of all physical, electronic components of the cryptographic module.
Schematics
The schematics for the module provide a visual representation of the defined cryptographic boundary and its internal components. It also demonstrates how the internal components connect.
Finite State Model
This document requires a diagram and description of the following states of the module:
- normal operation;
- degraded operation;
- data input interface;
- data output interface;
- control input interface;
- control output interface;
- status output interface;
- trusted channel;
- crypto officer role;
- user role;
- other roles (if applicable);
- security services;
- SSP entry services (if applicable);
- show status service;
- operator authentication;
- self-tests;
- other authorized services, operations, and functions (if applicable);
- error states;
- bypass service (if applicable);
- maintenance access interface (if applicable);
- maintenance role (if a maintenance access interface is provided);
- SSP generation and establishment services (if applicable);
- SSP output services (if applicable);
- idle states (if applicable); and
- uninitialized states (if applicable).
Please visit the OpenSSL 3.0.0 Design, where a search for “State Machine” will provide an excellent example for this. The website also contains other documentation examples pertinent to existing and pending OpenSSL FIPS 140 validations.
Vendor Evidence Document (VE)
The Vendor Evidence Document (VE) is a document that is meant to provide a consolidated view on how a module meets the various requirements specified in the FIPS 140-3 Derived Test Requirements (DTR). Lightship has created a comprehensive template that we provide to all clients, simplifying the process of determining what information is required and at what level of granularity.
Entropy Documentation
A formidable effort on its own, the Entropy Rational Description has posed many challenges and difficulties for vendors with the recent NIST SP 800-90B conformance requirements now in full swing. The rationale provided in this document specifies how the module produces enough entropy for the key sizes that the module generates. The module’s entropy source must produce a minimum of 112-bits of encryption strength, but the devil is in the details of the Entropy solution. For more details and guides on Entropy compliance, see our blog on NIST 800-90B Concepts
This high-level summary of the base documentation set essential to a FIPS 140-3 Validation is just that, a high-level summary. In practice, other documents or methods of assurance gathering may be requested or required. The depth of possible test evidence required is based on the module design and complexity.
If you are planning on pursuing a FIPS 140-3 Validation, please reach out to the testing experts at Lightship Security to help get you there.
Grace Grundy
Grace Grundy is a Lightship Project Manager responsible for day-to-day operations of FIPS 140-3 and Common Criteria Certifications. She is an expert in the processes for both FIPS and CC and helps to guide clients throughout from contract signing to certification award.
Jason Cunningham
Jason Cunningham is the Program Manager for Lightship’s Cryptographic Security Testing (CST) Laboratory. Jason brings nearly two decades of experience to the cryptographic testing space, primarily working with FIPS 140.