FIPS 140-2 Validation Has Become the Prerequisite for a Growing Number of Security Standards
FIPS 140 has become well-known as a building block certification. Many security standards for government and regulated industries require FIPS 140 as a prerequisite
The FedRAMP authorization is underpinned by SP 800-53, Security and Privacy Controls for Federal Information Systems and Organizations, which requires FIPS 140
The CMMC (Cybersecurity Maturity Model Certification) program is based on SP 800-171, Assessing Security Requirements for Controlled Unclassified Information, and requires FIPS 140
Common Criteria (CC) Protection Profiles (PPs) require FIPS 140 certification for cryptography
Department of Defense Information Network Approved Products List (DoDIN APL) requires FIPS 140 validation
FISMA, HIPAA and HITECH healthcare regulations all follow suit and require FIPS 140 validation for any cryptography deployed within the solution.
NIST and its Canadian counterpart CCCS (Canadian Centre for Cyber Security) teamed up in 1995 to establish the mechanisms for testing and certifying that the FIPS 140 benchmark had been met.
The CMVP (Cryptographic Module Validation Program) and CAVP (Cryptographic Algorithm Validation Program) are dedicated departments staffed by NIST and CSE employees. They focus on assessing FIPS 140 modules that are evaluated by independent, licensed third-party testing labs.
While the labs conduct functional testing and package and submit all the paperwork, it is the CMVP that ultimately reviews the testing results and issues the FIPS 140 validation.
The traditional FIPS 140 validation process has three main phases
Documentation The module under test must be thoroughly documented, and supporting assurance documentation must be developed to support vendor claims.
Testing An accredited FIPS 140 testing laboratory evaluates the documentation and tests the module. The documentation may need to be updated based on unresolved issues or comments from the testing laboratory.
Validation Upon successful completion of testing, NIST's Cryptography Module Validation Program (CMVP) reviews the lab's test report and the module’s Security Policy for accuracy and completeness. A successful review leads to NIST issuing a FIPS 140 validation certificate.
These steps have been known to take over two years, not counting the time needed to develop the cryptography module.
FIPS validation is not a one-and-done proposition
Frequent changes in FIPS 140 requirements, security vulnerabilities and other changes can trigger the need for revalidation
Any changes to a traditional module will force revalidation. So can additional platform support or discovered vulnerabilities.
If your cryptographic module is not architected with FIPS validation in mind, ANY change to your product could require re-validation
If you don’t go through the revalidation process when you need to, NIST will flag your certificate as ‘Historical’. That means it is no longer Active and cannot be used for any new acquisitions by government agencies.
Getting your own cryptography software reviewed, tested, validated, and certified by NIST can take as long as two years, not counting the time required to develop the software. SafeLogic literally cuts the time required to achieve NIST certification from two years to two months, then keeps your certification active over time with these three key capabilities.
CryptoComply is SafeLogic’s flagship software, a family of FIPS 140 validated cryptographic software modules. They deliver “Drop-in Compliance” as direct replacements for popular open-source crypto providers.
SafeLogic revolutionized the FIPS industry twelve years ago with RapidCert, the industry's first expedited rebranding program. Get a FIPS certification in your name in only two months with RapidCert.
Now SafeLogic is revolutionizing FIPS again with MaintainCert. FIPS certificates go ‘historical’, meaning they are no longer valid, all the time. Not with MaintainCert, SafeLogic’s new white-glove support service.
Vendors can choose their “module boundary.” That boundary may be the same as an entire product, or it may be a subset of a product (e.g., software library, printed circuit board, or integrated circuit chip). There is no requirement to make the cryptographic module include an entire product, especially as the standard only defines the requirements and testing of the cryptographic functionality. This is one of the biggest advantages of basing your FIPS strategy on CryptoComply. SafeLogic designed CryptoComply to have a small module boundary. As a result, SafeLogic customers can make changes to their products without impacting their FIPS validated module.
The standard period is 5 years unless the validated module has been modified, which can sometimes reset the clock. In other cases, technology can become obsolete, leading CMVP to deprecate algorithms or ban cryptographic techniques, which can force a certificate to be moved to the Historical List before the 5-year period expires. SafeLogic works to ensure that validations will remain Active as part of its MaintainCert service, regardless of these hurdles.
Many people confuse FIPS 140 iterations (i.e., FIPS 140-2, FIPS 140-3) with FIPS 140 levels (FIPS 140-2 Level 1, FIPS 140-2 Level 2, etc.)
Iterations are published versions of the benchmark. NIST issued FIPS 140-1 in 1994, FIPS 140-2 in 2001, and FIPS 140-3 in 2019. As of this time, both FIPS 140-2 and FIPS 140-3 validations are both accepted as current and Active.
FIPS 140-2 certification defines four different levels of security, termed “Level 1” through “Level 4”. These levels are intended to cover the wide range of potential applications and environments in which cryptographic modules may be employed. Typically only Level 1 applies to software modules since higher security levels incorporate requirements for hardware. FIPS makes no restrictions on Level requirements for specific applications.
The FIPS 140 standard provides four increasing, qualitative levels of security. Each level covers 11 different areas of security. Level 1 is the least stringent and level 4, the most. Each subsequent level builds upon the requirements of the previous level. That is, Level 2 includes all the requirements of Level 1 plus other requirements. The key difference in the levels is the way physical and logical access to the cryptographic module is limited to ensure its integrity. These levels are clearly indicated on each validation certificate. The requirements, corresponding testing, and assurance for cryptographic algorithms are identical at all security levels.
Security Level 1 provides the lowest level of security. Baseline security requirements are specified for a cryptographic module (e.g., at least one FIPS Approved algorithm must be used). No specific physical security mechanisms are required in a Security Level 1 cryptographic module beyond the basic requirement for production-grade components. A common example of a Security Level 1 cryptographic module is a software module that can be installed on any compatible device. Security Level 1 allows the software components of a cryptographic module to be executed on a general-purpose computing system using a variety of operating systems.
The implementation of cryptographic software may be more cost-effective or flexible than corresponding hardware-based mechanisms, enabling organizations to select alternative cryptographic solutions to meet lower-level security requirements.
Security Level 2 enhances the physical security mechanisms of a Security Level 1 cryptographic module by adding the requirement for the module to show evidence of any tampering. These requirements include the use of tamper-evident coatings or seals or pick-resistant locks on any removable covers or doors of the module. Tamper-evident coatings or seals are placed on a cryptographic module so that the coating or seal must be broken to attain physical access to the plaintext cryptographic keys and critical security parameters (CSPs) or sensitive security parameters (SSPs) within the module. Tamper-evident seals or pick-resistant locks are placed on covers or doors to protect against unauthorized physical access.
Security Level 2 requires, at a minimum, role-based authentication in which a cryptographic module authenticates the authorization of an operator to assume a specific role and perform a corresponding set of services.
Security Level 2 allows the software and firmware components of a cryptographic module to be executed on a general-purpose computing system using an operating system that meets additional requirements for access control and auditing. This trusted operating system provides a level of trust so that cryptographic modules executing on general-purpose computing platforms are comparable to cryptographic modules implemented using dedicated hardware systems.
Security Level 3 requires identity-based authentication mechanisms, enhancing the security provided by the role-based authentication mechanisms specified for Security Level 2. A cryptographic module authenticates the identity of an operator and verifies that the identified operator is authorized to assume a specific role and perform a corresponding set of services.
Security Level 3 requires the entry or output of plaintext CSPs be performed using ports that are physically separated from other ports or interfaces that are logically separated using a trusted path from other interfaces. Plaintext CSPs may be required to be entered into or output from the cryptographic module in encrypted form.
Security Level 4 provides the highest level of security defined in this standard. At this security level, the physical security mechanisms provide a complete envelope of protection around the cryptographic module with the intent of detecting and responding to all unauthorized attempts at physical access. Penetration of the cryptographic module enclosure from any direction has a very high probability of being detected, resulting in the immediate zeroization of all plaintext CSPs. Security Level 4 cryptographic modules are useful for operation in physically unprotected environments.
Security Level 4 also protects a cryptographic module against a security compromise due to environmental conditions or fluctuations outside of the module’s normal operating ranges for voltage and temperature. Intentional excursions beyond the normal operating ranges may be used by an attacker to thwart a cryptographic module’s defenses. A cryptographic module is required to either include special environmental protection features designed to detect fluctuations and zeroize CSPs, or to undergo rigorous environmental failure testing to provide a reasonable assurance that the module will not be affected by fluctuations outside of the normal operating range in a manner that can compromise the security of the module. For 140-3, only the former option is permitted.
Define the “cryptographic boundary”. The boundary may be an integrated circuit chip, printed circuit board, a software library, or a complete hardware appliance. This module must perform at least one cryptographic function approved by FIPS 140. Once the cryptographic boundary has been defined, along with the supported platforms, documentation illustrating how the module meets the FIPS 140 requirements can be prepared.
The first document that must be prepared is the Security Policy. At a high level, the Security Policy defines the cryptographic module and how it meets the FIPS 140 requirements. This document covers all the areas defined by the FIPS 140 standard. The Vendor Evidence documentation provides greater detail about how the module meets the areas of FIPS 140.
Once the evidence documentation has been written, this set of documents, along with the cryptographic module implementation, is submitted to the Cryptographic Module Testing Laboratory (CMTL) for testing. The CMTL will review the documentation and test results for any discrepancies or issues and report them back to the vendor.
The vendor must satisfactorily address all the questions and issues raised by the CMTL. Once the CMTL is satisfied with the responses and the CMTL has completed their testing and finalized their test report, they will submit their findings to CMVP.
Paying the CMTL fees is the responsibility of the vendor. Also, the CMVP charges vendors a “cost recovery” fee for their validation services.
After the report is submitted, the report resides in a queue until the CMVP is available to review it. The report then goes through the CMVP review, and the CMVP sends their questions and comments back to the CMTL. The CMTL will ask the vendor for assistance with many of these comments. After all comments are successfully resolved, the report moves into finalization, where the vendor must confirm several details. Finally, a certificate is awarded for the module. The publicly posted certificate includes a link to the Security Policy.
Certificates need to be updated when there is a change to the module. Certificates also move from Active to Historical when they reach their “Sunset” date or when a transition in FIPS algorithm requirements impacts their status. All changes require the vendor to redo the process described above.
This entire process, including waiting for NIST to work through a backlog of certifications, has been known to take as long as two years. Not included is any time required to develop the cryptographic module in the first place.
SafeLogic’s FIPS Validation-as-a-Service can reduce this timeframe from two years to two months.