Three steps to implementing robust encryption

By Derek Bouius |  No Comments  |  Posted: January 11, 2017
Topics/Categories: IP - Selection, EDA - Verification  |  Tags: , , , , ,  | Organizations: ,

Derek BouiusDerek Bouius is a product marketing manager for Synopsys’ security IP, and brings to the role more than 15 years of experience in software development and product architecture. Prior to Synopsys, Bouius held engineering, product development, and marketing positions at Elliptic Technologies, DEW, and Memory Experts/Datalocker.

The cryptographic algorithms that protect today’s devices and communications infrastructure are only useful if their implementations have been validated by regulatory bodies, to ensure that they will work properly in the edge cases that emerge in complex interoperability scenarios.

Each global standards body has programs for certifying security implementations. In North America, Communications Security Establishment Canada (CSEC) and the US National Institute of Standards and Technology (NIST) created the Cryptographic Module Validation Program (CMVP) for this purpose. This program validates commercial cryptographic modules to the Federal Information Processing Standard FIPS 140-2, which defines requirements for security systems that protect 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.”

Validating cryptographic modules

The FIPS 140-2 specification covers 10 features of cryptographic modules that are designed and implemented as SoCs:

  1. 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 security levels, to match the range of potential applications and environments for cryptographic modules. The lowest level of security is Level 1. The highest is Level 4, for use in situations where detection of, and response to, physical access is required.

In the CMVP, cryptographic module vendors use independent, accredited laboratories to test their modules. These labs must have completed the National Voluntary Laboratory Accreditation Program (NVLAP) to perform cryptographic module compliance and conformance testing.

  1. Validate a cryptographic algorithm implementation

There’s not much point in validating the implementation of a cryptographic module if you haven’t first validated the implementation of the algorithm it uses – this just creates a false sense of security. To address this is issue, CMVP formed the Cryptographic Algorithm Validation Program (CAVP), to check FIPS-approved and NIST-recommended cryptographic algorithms and their components.

CAVP has developed a validation system for each cryptographic algorithm to test its specifications, components, features, and/or function. CAVP validation assures users that the implementation of a cryptographic algorithm adheres to the reference specifications.

CAVP is one small section of CMVP certification (Source: Synopsys)

Figure 1 CAVP is one small section of CMVP certification (Source: Synopsys)

For CAVP to validate an algorithm, it must both have been designed as specified in the official algorithm document, and implemented in a way that allows for validation testing. If, for example, an algorithm is implemented within an application but there is no way to test that 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, not all possible OEs on which the implementation can run. The OE used for module validation must match the OE used for algorithm validation.

The OE applies to one implementation, such as a single binary executable file or dynamic library for a larger piece of software. 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 for different OEs, each distinct implementation must be tested separately.

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

  1. Validate the integration of a cryptographic algorithm in a module

The FIPS 140-2 standard suggests ways to identify the configuration, control and OE requirements for the cryptographic algorithm implementations in 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 these requirements:

  1. The validated cryptographic algorithm implementation is not modified during its integration into the cryptographic module undergoing testing; and
  2. The OE under which the algorithm implementation was tested by CAVP must be identical to the OE under which the cryptographic module is being tested 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.

  1. Validate with an accredited testing lab

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.

Interaction between the vendor, testing lab, certification program and end user (Source: Synopsys)

Figure 2 Interaction between the vendor, testing lab, certification program and end user (Source: Synopsys)

Strengthening FIPS security standards

CSEC and NIST is reviewing FIPS 140-2 to keep up with current technologies, incorporate suggestions from federal departments and industry, and strengthen key requirements. The new version should improve physical and software security and module assurance. 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

The Automated Cryptographic Validation (ACV) System is a project between NIST’s Information Technology Laboratory and commercial vendors to optimize the validation of cryptographic modules.

As described previously, making a minor change to the binary implementation or OE of a module means it can no longer be regarded as validated.

The current validation 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 to obtain compliance assurance on platforms of actual use. This limits industry’s efforts to validate products and prevents it from fixing critical problems, such as common vulnerabilities and exposures, without breaking program rules.

The ACV system is meant to provide economic incentives to industry by reducing the time and cost of validations, and enabling validations through verifiable tests.

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.

Implementation of a validation system based on a client/server architecture (Source: Synopsys)

Figure 3 Implementation of a validation system based on a client/server architecture (Source: Synopsys)

CAVP certification for faster time to market

CAVP certification is important because it validates that your implementation of a security algorithm is functionally correct. A CAVP-certified solution should also speed up the process of getting a FIPS 140-2 level validation through CMVP, because a lot of the manual work involved is due to creating the test infrastructure for the target operating environment.

Further information

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

Author

Derek Bouius is a product marketing manager for Synopsys’ security IP, and brings to the role more than 15 years of experience in software development and product architecture. Prior to Synopsys, Bouius held various engineering, product development, and marketing positions at Elliptic Technologies, DEW, and Memory Experts/Datalocker, among others. Bouius holds a BSc in Physics from the University of Waterloo.

Company info

Synopsys Corporate Headquarters
690 East Middlefield Road
Mountain View, CA 94043
(650) 584-5000
(800) 541-7737
 www.synopsys.com

Comments are closed.

PLATINUM SPONSORS

Synopsys Cadence Design Systems Siemens EDA
View All Sponsors