Ensure Robust Encryption With CAVP Validation For FIPS 140-2 Conformance

Changes are on the horizon for validation of cryptographic algorithms.


Cryptographic algorithms are mathematical procedures used to implement security protocols in today’s devices and communication infrastructure. Designers must validate their cryptographic algorithm implementations through certification by regulatory bodies, such as Communications Security Establishment Canada (CSEC) and National Institute of Standards and Technology (NIST), to ensure accuracy and interoperability. It is important to validate the implementation of these algorithms so accurate results are provided during complicated edge cases that arise in interoperability scenarios. This article describes certification requirements, implementation guidelines, and future initiatives that may challenge the status quo.

CMVP validates FIPS 140-2 conformance
Each of the many worldwide standards bodies have definitions and programs for certification of security implementations. In North America, the Cryptographic Module Validation Program (CMVP) was jointly created by two regulatory bodies, CSEC and NIST. NIST is a non-regulatory federal agency within the U.S. Commerce Department’s Technology Administration.

The CMVP validates commercially available cryptographic modules to the Federal Information Processing Standard (FIPS) 140-2. FIPS 140-2 defines the security requirements that must be used in a security system requiring the protection of sensitive information.

The goal of the CMVP is “to promote the use of validated cryptographic modules and provide Federal agencies with a security metric to use in procuring equipment containing validated cryptographic modules.” Cryptographic modules that conform to FIPS 140-2 meet security requirements related to SoC design and implementation. These requirements include 10 different components of the cryptographic module specification:

  1. Module ports and interfaces
  2. Roles, services, and authentication
  3. Finite state model
  4. Physical security
  5. Operational environment
  6. Cryptographic key management
  7. Electromagnetic interference/electromagnetic compatibility (EMI/EMC)
  8. Self-tests
  9. Design assurance
  10. Mitigation of other attacks

The FIPS 140-2 standard defines four increasing levels of security to cover the wide range of potential applications and environments where cryptographic modules are used. Level 1 defines the lowest level of security up to Level 4 where detection and response of physical access is required.

In the CMVP, vendors of cryptographic modules use independent, accredited testing laboratories to have their modules tested. Accredited laboratories must have completed the National Voluntary Laboratory Accreditation Program (NVLAP) to perform cryptographic module compliance/conformance testing.

But first, CAVP validation of cryptographic algorithms
Originally the CMVP validated cryptographic algorithms as well, but in 2003, they formed a separate program called Cryptographic Algorithm Validation Program (CAVP). CAVP validates FIPS-approved and NIST-recommended cryptographic algorithms and their individual components. Cryptographic algorithm validation is a prerequisite of cryptographic module validation.

CAVP has designed a suite of validation tests for each cryptographic algorithm (called the algorithm’s validation system) to test the algorithm specifications, components, features, and/or functionality of that algorithm. CAVP validation assures that cryptographic algorithm implementations adhere to the specifications detailed in the associated cryptographic algorithm references.

template testCS5

Figure 1: CAVP is only one small section of CMVP certification

For CAVP to validate a cryptographic algorithm, the algorithm must be designed as specified in the corresponding official algorithm document and must allow for testing by the validation tests. If these two conditions are not met, the cryptographic algorithm implementation cannot be validated. For example, if the algorithm is contained within a custom application and there is no interface to test the algorithm, then the algorithm cannot be validated.

CAVP validations list the operating system and processor, known as the operational environment (OE), on which the testing was conducted. They do not list all OEs on which the implementation can run. The OE used for module validation must match the OE used for algorithm validation.

The operational environment applies to a single implementation, such as a single binary executable file or dynamic library for a software implementation. If a vendor has multiple implementations that use the same name and version number, such as a single source code base that can be compiled to target different OEs, each distinct implementation must be tested separately.

For a software algorithm, CAVP validates the binary executable or dynamic library that contains the executable code of the algorithm implementation. The implementation’s boundary is effectively the entire binary file that contains the algorithm implementation. When applied generally, the algorithms must be tested again if the binary file is different.

The FIPS 140-2 standard provides implementation guidance to identify the configuration, control and operational environment requirements for the cryptographic algorithm implementations that are embedded within the cryptographic module. For a validated cryptographic algorithm implementation to be embedded in a software, firmware or hardware cryptographic module that undergoes testing for compliance to FIPS 140-2, the design must meet the following requirements:

  1. The implementation of the validated cryptographic algorithm has not been modified upon integration into the cryptographic module undergoing testing; and
  2. The OE under which the validated cryptographic algorithm implementation was tested by CAVP must be identical to the OE that the cryptographic module is being tested under by the accredited Cryptographic and Security Testing (CST) laboratory.

The system designer must be very careful to create an interface that allows the algorithms to be tested so that the above requirements can be met without compromising security.

Vendors may use any of the NVLAP-accredited CST laboratories to test algorithm implementations. When vendors engage the lab, a large set of unique vectors is generated for testing. The vendor implements a test harness to create appropriate responses to the vectors and returns the results to the lab for verification. Once an algorithm implementation is successfully tested by a lab and validated by NIST/CSEC, it is added to an appropriate validation list that identifies the vendor, implementation, operational environment, validation date and algorithm details.

template testCS5

Figure 2: Interaction between the vendor, the testing lab, certification program and the end user

Strengthening FIPS security standards
CSE and NIST started the process of reviewing and updating FIPS 140-2 to keep the standard consistent with current technologies, to incorporate suggestions from federal departments and industry, and to update and strengthen the requirements in key areas of the standard. The new version is expected to include significant improvements in the areas of physical and software security and module assurance. After many years of review and multiple drafts, CMVP’s goal is to create an updated FIPS standard that will align with the International Organization of Standardization 19790 [ISO/IEC 19790:2012]. Other countries (e.g., Japan, Korea, Brazil) have similar programs to CMVP that may eventually consolidate into one international standard.

Automating cryptographic module validation with the ACV System
Another new initiative has started with the creation of the Automated Cryptographic Validation (ACV) System. This project began as a working group between NIST’s Information Technology Laboratory and commercial vendors to optimize the validation process. As described previously, if one minor change is made to the binary implementation or operating environment, the validation is no longer valid. This leads to long validation cycles that are well beyond product development cycles and hinder the adoption of new technology.

The current process does not allow automated testing to exercise all the complexity of today’s algorithm implementations. It is also difficult to test algorithms designed into hardware and it is difficult to obtain compliance assurance on platforms of actual use. This all limits the industry’s efforts to validate more products and prevents the industry from fixing critical problems, e.g., Common Vulnerabilities and Exposures, without breaking program rules.

The main goals of the ACV System are to provide economic incentives to the industry by reducing the length and cost of validations and enabling validations through verifiable tests. This will widen access to the latest technologies and align with other government test programs.

The working group has reached a key milestone with the demonstration of a test and validation implementation. Figure 3 shows the basic architecture of the components of the validation system and the interaction between the components.

template testCS5

Figure 3: Implementation of a validation system based on Client/Server architecture

CAVP certification for faster time-to-market
CAVP certification is still very important today because it gives concrete validation that your implementation is functionally correct. A CAVP-certified solution also facilitates a faster time to market when targeting a FIPS 140-2 level validation via CMVP, because a lot of the manual work is creating the test infrastructure for the target operating environment.

Synopsys develops cryptographic and other security IP solutions to enable highly secure SoCs. Learn more at synopsys.com/security-IP.