Important News:SafeLogic's CryptoComply Achieves FIPS 140-3 Validation for 28 OEs and Receives Certificate #4781! Read the blog post!
Your Guide to FIPS 140-2 Certification and Validation
Validated Security for Cryptographic Modules
FIPS 140-2 is the second iteration of a standard established by NIST (the U.S. National Institute of Standards and Technology) to establish a minimum level of cryptographic security for deployment in the U.S. federal government.
Products (modules) that complete FIPS 140-2 validation receive a publicly listed FIPS certificate on the NIST website.
Without this validation, NIST considers cryptographic encryption modules to be of unknown quality and places them in the same category as plaintext.
The industry is transitioning from FIPS 140-2 (published in 2001) to FIPS 140-3 (published in 2019).
FIPS 140-2 Certification and Its Role in Compliance
FIPS 140-2 is a Prerequisite for Many Security Standards, Including FedRAMP, CMMC, Common Criteria, and DoDIN APL
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.
US and Canada Partner on CMVP and CAVP certification
NIST and its Canadian Counterpart Have Established Mechanisms for Validating Cryptography Modules and Issuing FIPS 140-2 Certifications
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-2 validation.
How Many Times Will You Need to Revalidate Your FIPS Certification to Avoid It Going 'Historical'?
-
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.
Get FIPS 140-2 Certification in 60 Days with SafeLogic
Only SafeLogic’s unique FIPS Validation-as-Service expedites and maintains your FIPS validation over time.
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.
CryptoComplyTM
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.
RapidCertTM
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.
MaintainCertTM
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.
To find out more about how SafeLogic can get you FIPS 140-2 certified in two months, talk to one of our FIPS experts!
Does My Entire Product Need to be FIPS Validated?
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.
How Long does a FIPS Certification Remain Valid?
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.
Are FIPS Iterations the Same as FIPS Levels?
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.
What are the Different Levels of FIPS 140 Validation?
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
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
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
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
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.
What Am I Required to Do to Meet Government Regulations for Cryptography?
- Identify your cryptographic module
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.
- Prepare documentation evidence
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.
- Submit evidence and the module to an accredited cryptographic module testing lab for testing
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.
- Address any issues or questions from the CMTL
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.
- Pay the necessary fees
Paying the CMTL fees is the responsibility of the vendor. Also, the CMVP charges vendors a “cost recovery” fee for their validation services.
- CMVP queue and review
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.
- Revalidate as needed to maintain an Active certificate
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.
