FIPS 140 Questions
FIPS 140-2 is the benchmark established by the National Institute of Standards and Technology (NIST) to specify security requirements for cryptographic modules and testing methodology for confirming conformance. The standard provides four increasing, qualitative levels of security: Level 1, Level 2, Level 3, and Level 4. These levels are intended to cover the wide range of potential applications and environments in which cryptographic modules may be employed. The security requirements cover areas related to the secure design and implementation of a cryptographic module. These areas include cryptographic module specification, cryptographic module ports and interfaces; roles, services, and authentication; finite state model; physical security; operational environment; cryptographic key management; electromagnetic interference/electromagnetic compatibility (EMI/EMC); self-tests; design assurance; and mitigation of other attacks. Note that the -2 suffix represents the second version of the standard, not Level 2. FIPS 140-1 superseded FIPS 140, General Security Requirements for Equipment Using the Data Encryption Standard, in its entirety.
FIPS 140-3 is the update to the FIPS 140 benchmark established by the National Institute of Standards and Technology (NIST) to specify security requirements for cryptographic modules and testing methodology for confirming conformance and will replace FIPS 140-2. It began validation testing in September 2020 and is based upon the ISO/IEC 19790 international standard. FIPS 140-2 standards will continue to be available for testing until September 2021 and those certifications will remain valid until they sunset, which could be as much as 5 years later, if they maintain all other security requirements, so the transition will be gradual.
If a vendor sells a product to the US Federal Government that includes a cryptographic module for the protection of sensitive data, the cryptographic module must be FIPS 140 validated. Also, the Government of Canada recommends that Canadian Federal Departments use FIPS 140 validated cryptographic modules. By having your cryptographic module validated, you are showing potential customers that your cryptographic module implements a minimum baseline suite of IT security and cryptography features. FIPS 140 is the de facto international standard for cryptographic modules. As of January 11, 1994, FIPS 140-2 is applicable to all Federal agencies that use cryptographic-based security systems to protect sensitive information in computer and telecommunication systems (including voice systems) as defined in Section 5131 of the Information Technology Management Reform Act of 1996, Public Law 104-106. This standard shall be used in designing and implementing cryptographic modules that Federal departments and agencies operate or are operated for them under contract. The adoption and use of this standard is available to private and commercial organizations. FIPS 140-3 has since been approved and placed in service, with the transition from 140-2 to 140-3 currently underway.
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. The cryptographic module however, must meet all of the FIPS 140 requirements.
The traditional FIPS validation process can take as long as 16 months from start to certificate issuance. The validation phases are:
- Implementation under test – evidence and module has been submitted to the CMT lab and testing is underway.
- Review pending – testing has been completed and the lab report has been submitted to CMVP awaiting review.
- In review – A member of CMVP has been assigned and has begun the review of the lab report.
- Coordination – Questions from CMVP have been sent back to the CMT lab. Responses from the lab are then sent back to CMVP.
- Finalization – All questions have been satisfactorily addressed and the FIPS certificate is prepared for issuance.
Check out SafeLogic’s RapidCert service for accelerated and simplified FIPS 140 validations!
A fee is charged by the CMT laboratories for the testing of a cryptographic module. Testing time is variable, depending on the complexity of the cryptographic module, the overall security level and the individual security levels, and the completeness of the documentation evidence package. The test time varies depending on the following factors:
- Cryptographic module type – e.g.,. software, firmware, hardware, single vs. multi-function;
- Overall security level of the cryptographic module – 1, 2, 3, or 4;
- Accuracy and completeness of documentation; and
- The number of deficiencies identified by a CMT laboratory during the conformance testing process.
If a cryptographic module is being revalidated or if a new version based on a previously validated cryptographic module is being validated, the cost and time, typically, are less. NIST and CSE do not get involved in the contract negotiations between the vendor and a CMT lab. This is to ensure the independence of the validation authorities. Optimally, vendors may choose to hire outside consultants to prepare the necessary documentation for the module testing. These consultants will charge the vendor their fees for this service. Cost recovery is a fee provided to NIST by product vendors. A nominal fee is charged to cover the validation authority costs for the validation tasks and the program management responsibilities performed by NIST. CMVP cost recovery fees:
- Security Level 1: Base fee: $8,000
- Security Level 2: Base fee:$10,000
- Security Level 3: Base fee: $10,000
- Security Level 4: Base fee: $10,000
Talk to SafeLogic about an all-inclusive, fixed rate FIPS 140 validation based on CryptoComply to save on both hard and soft costs!
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 of 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 and the strength and functionality of the cryptography is the same for each level.
Security Level 1 provides the lowest level of security. Basic security requirements are specified for a cryptographic module (e.g., at least one FIPS-approved/NIST recommended algorithm (hereafter referred to as an Approved algorithm) or Approved security function 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. An example of a Security Level 1 cryptographic module is a personal computer (PC) encryption board.
Security Level 1 allows the software and firmware components of a cryptographic module to be executed on a general purpose computing system using an unevaluated operating system. Such implementations may be appropriate for some low-level security applications when other controls, such as physical security, network security, and administrative procedures are limited or nonexistent. The implementation of cryptographic software may be more cost-effective than corresponding hardware-based mechanisms, enabling organizations to select from 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 tamper-evidence, which includes the use of tamper-evident coatings or seals or for pick-resistant locks on 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) 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 the functional requirements specified in the Common Criteria (CC) Protection Profiles (PPs) listed in Annex B and is evaluated at the CC evaluation assurance level EAL2 (or higher).
An equivalent evaluated trusted operating system may be used. A 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.
In addition to the tamper-evident physical security mechanisms required at Security Level 2, Security Level 3 attempts to prevent the intruder from gaining access to CSPs held within the cryptographic module. Physical security mechanisms required at Security Level 3 are intended to have a high probability of detecting and responding to attempts at physical access, use or modification of the cryptographic module. The physical security mechanisms may include the use of strong enclosures and tamper detection/response circuitry that zeroizes all plaintext CSPs when the removable covers/doors of the cryptographic module are opened.
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 (including the entry or output of plaintext CSPs using split knowledge procedures) 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 entered into or output from the cryptographic module in encrypted form (in which case they may travel through enclosing or intervening systems).
Security Level 3 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 the functional requirements specified in the PPs listed in Annex B with the additional functional requirement of a Trusted Path (FTP_TRP.1);
- and is evaluated at the CC evaluation assurance level EAL3 (or higher) with the additional assurance requirement of an Informal Target of Evaluation (TOE) Security Policy Model (ADV_SPM.1).
An equivalent evaluated trusted operating system may be used. The implementation of a trusted path protects plaintext CSPs and the software and firmware components of the cryptographic module from other untrusted software or firmware that may be executing on the platform.
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.
Security Level 4 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 the functional requirements specified for Security Level 3;
- and is evaluated at the CC evaluation assurance level EAL4 (or higher).
An equivalent evaluated trusted operating system may be used.
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 validation to be moved to the Historical List before the 5 year period expires. SafeLogic ensures that validations will remain active as part of ongoing annual maintenance, regardless of these hurdles.