Important News:SafeLogic's CryptoComply Achieves FIPS 140-3 Validation for 28 OEs and Receives Certificate #4781! Read the blog post!
The SafeLogic Blog
FIPS 140-2 and 140-3 Requirements for Level 1 Software Modules
March 15, 2024 •Aryeh Archer
With the announcement of our FIPS 140-3 Early Access Program (EAP), we've been hearing more questions from our customers about the differences between FIPS 140-2 and FIPS 140-3. To help with this transition, I've put together the table below outlining the major differences for Level 1 software modules.
FIPS 140-2 |
FIPS 140-3 |
Major Changes in FIPS 140-3 for Level 1 Software Modules |
- |
Area 1: |
New area. FIPS conformance is now tested against the international standards ISO 19790 and ISO 24759. |
Area 1: |
Area 2: |
Optional degraded mode of operation (not implemented by SafeLogic). When not in degraded mode, the module is in “normal mode”. Normal mode includes “non-approved mode” and “approved mode”. The module may switch between these modes with each service. All services must provide an indicator when the service utilizes an approved cryptographic algorithm, security function, or process in an approved manner. The software module boundary now only includes the module itself and not the physical boundary of the GPC (impacts Area 9) |
Area 2: |
Area 3: |
Optional control output interface (not implemented by SafeLogic). The Software/Firmware Module Interface (SFMI) is defined. |
Area 3: |
Area 4: |
Only one role (Crypto-Officer) is required. The User role is now optional (only implemented by SafeLogic in some modules). New required service to output an identifier and version that can be correlated with validation records. Optional Self-Initiated Cryptographic Output capability (not implemented by SafeLogic). |
Area 4: |
See Area 11 |
The Finite State Model (FSM) is integrated into Area 11 and reflects the other changes in the standard. |
- |
Area 5: |
New area specifying requirements for integrity testing. Temporary values in integrity test must be zeroised. The integrity test must be available on demand. Integrity tests must use an approved integrity technique. |
Area 6: |
Area 6: |
More detailed definitions for operational environments (OEs). The requirement for a single operator has been removed. The requirements no longer reference Common Criteria (CC) protection profiles. Instead, the vendor must describe how the module has controls its own SSPs, how the module owns its own processes, and how the OE separates application processes to prevent uncontrolled access to SSPs, etc. |
Area 5: |
Area 7: |
Changes do not impact software modules. |
Area 8: |
- |
EMI/EMC requirements have been removed. |
- |
Area 8: |
New area of testing. Only applicable if the module is designed to mitigate against non-invasive attacks. This area is not yet supported by CMVP, so these mitigations currently fall under Area 12. |
Area 7: |
Area 9: |
Increased management requirements for Sensitive Security Parameters (SSPs), i.e. both Critical Security Parameters (CSPs) and Public Security Parameters (PSPs). Additional items are now considered CSPs: RBG state information, hashed values of passwords, intermediate key generation values, entropy input from outside the module, authentication data, and key components. Zeroisation is required for all unprotected SSPs (including PSPs). Zeroisation status outputs are required. Two independent actions are required for SSP output from the software module to the GPC. |
Area 9: |
Area 10: |
Self-tests are redefined into the following categories:
Pre-operational changes: the algorithm for the software integrity test must pass a CAST before being used for the integrity test. Conditional test changes: optionally, CASTs can be run before algorithm operation instead of on power on (not implemented by SafeLogic). CASTs must be tested with KATs and not PCTs. Specific PCTs are now required for all key generation. The continuous random number generator test has been removed. Periodic self-test recommendations must be included. |
Area 10: |
Area 11: |
Additional requirements for management, testing, and documentation through the module’s lifecycle. The configuration management system (CMS) must track the revision of each item throughout the module life-cycle. Secure sanitization procedures are required. New section detailing requirements for development. The CMS must track the source code, language reference, the compilers, compiler versions and compiler options, the linker and linker options, the runtime libraries and runtime library settings, configuration settings, build processes and methods, the build options, environmental variables and all other resources used to compile and link the source code into an executable form. Documentation must specify the compiler, configuration settings and methods to compile the source code into an executable form, and the corresponding production grade development tools. The result of the integrity test must be integrated into the module during development. Functional testing must be implemented and documented, and automated security diagnostic tools must be used. CVEs must be listed in the FIPS report, and vendors must either mitigate them or provide assurance they are not security-relevant. |
Area 11: |
Area 12: |
No change at level 1. |
|
Annex B: |
Additional detailed requirements for content and order of the items in the security policy. |
|
Additional standards |
Requirements are specified by FIPS 140-3, which indicates that requirements are provided by the ISOs. ISO 19790 includes several Annexes and specifies the requirements for FIPS 140-3. ISO 24759 specifies the testing requirements that correspond to ISO 19790. The ISOs may be modified by the CMVP via the SP 800-140x Pubs. SP 800-140 modifies ISO 24759, SP 800-140A modifies ISO 19790 Annex A, SP 800-140B modifies ISO 19790 Annex B, etc. Additional guidance is provided by the CMVP through the 140-3 Implementation Guidance (IG) and 140-3 Management Manual. The latest versions of CMVP documents can be found on their website: https://csrc.nist.gov/Projects/cryptographic-module-validation-program/ |
|
Other |
Algorithms and corresponding services supported by the module have changed to reflect algorithm transitions and new algorithm standards/testing availability. The available certificate update options differ for FIPS 140-2 and FIPS 140-3. |
FIPS 140-3 has significant additional requirements and is more complex than FIPS 140-2. If you find the prospect of doing all this yourself daunting, Safelogic can help. We look forward to helping our customers easily transition to FIPS 140-3!
Aryeh Archer
Aryeh is Safelogic's Director, Operations and Compliance.
Popular Posts
Search for posts
Tags
- FIPS 140 (111)
- FIPS validation (85)
- Encryption (70)
- cryptography (68)
- NIST (62)
- CryptoComply (60)
- SafeLogic (58)
- Industry News (54)
- cryptographic module (51)
- Conversations (49)
- CMVP (48)
- RapidCert (46)
- compliance (41)
- Ray Potter (33)
- SafeLogic News (33)
- Event (27)
- federal (27)
- CAVP (23)
- Cybersecurity (23)
- FIPS 140-3 (18)
- OpenSSL (16)
- government (14)
- FedRAMP (13)
- CryptoCompact (12)
- Cryptology (12)
- DoD (12)
- RSA (12)
- healthcare (12)
- partners (12)
- NSA (11)
- post-quantum cryptography (11)
- Cloud (9)
- PQC (9)
- security (9)
- CMMC (8)
- Suite B (8)
- testing (8)
- whitepaper (8)
- Approved Products List (APL) (6)
- HITECH (6)
- ICMC (6)
- lab (6)
- CEO (5)
- NIST 800-171 (5)
- NIST 800-53 (5)
- OpenSSL 3.0 (5)
- iOS (5)
- procurement (5)
- C3PAO (4)
- Common Criteria (4)
- HITECH Act (4)
- deadline (4)
- encrypt (4)
- innovation (4)
- procure (4)
- public sector (4)
- Air Force (3)
- BSAFE (3)
- DFARS (3)
- HIPAA Safe Harbor (3)
- HITECH Safe Harbor (3)
- OpenSSL 1.1.1 (3)
- OpenSSL 3.x (3)
- POA&M (3)
- TLS 1.3 (3)
- magazine (3)
- queue (3)
- transition (3)
- 3PAO (2)
- ACVP (2)
- BAA (2)
- CIO (2)
- CSP (2)
- Cyber Defense Magazine (2)
- Defense Industrial Base (2)
- HIPAA security controls (2)
- Historical Status (2)
- MFA (2)
- OpenSSL 1.0.2 (2)
- SPRS (2)
- StateRAMP (2)
- entropy (2)
- excellence (2)
- finance (2)
- founder (2)
- gold (2)
- leader (2)
- maturity (2)
- overlap (2)
- pilot (2)
- rsa conference (2)
- solution (2)
- sponsors (2)
- sunset (2)
- vendor (2)
- year (2)
- Active Status (1)
- Alliance for Digital Innovation (1)
- Android (1)
- CIO Prime Views (1)
- DHS (1)
- DIU (1)
- DIUx (1)
- DOJ (1)
- DoDIN APL (1)
- Entropy Source Validation (1)
- FCA (1)
- FIPS Compliance (1)
- FISMA (1)
- GSA (1)
- HITRUST (1)
- Matt Cornelius (1)
- Matthew Cornelius (1)
- Maturity Model (1)
- NCCoE (1)
- OMB (1)
- SLED (1)
- SP800-131A (1)
- SP800-90A (1)
- TLS 1.1 (1)
- background (1)
- best (1)
- co-founder (1)
- codies (1)
- congress (1)
- cybertech (1)
- education (1)
- elliptic curve cryptography (1)
- extended (1)
- faq (1)
- fintech (1)
- fiscal (1)
- fiscal year (1)
- fraud (1)
- globee (1)
- hill (1)
- interview (1)
- kratos (1)
- libgcrypt (1)
- national cybersecurity strategy (1)
- opportunities (1)
- parallel (1)
- profile (1)
- public (1)
- representatives (1)
- reseller (1)
- senate (1)
- senators (1)
- simplify (1)
- state (1)
- stealth mode (1)
- story (1)
- terminology (1)
- trophy (1)
- whistleblower (1)
- whistleblowing (1)