Important News:CryptoComply FIPS 140-3 Early Access Program is now open. Learn more!

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:
General

New area. FIPS conformance is now tested against the international standards ISO 19790 and ISO 24759.

Area 1:
Module Specification

Area 2:
Module Specification

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:
Module Ports and Interfaces

Area 3:
Module Interfaces

Optional control output interface (not implemented by SafeLogic).

The Software/Firmware Module Interface (SFMI) is defined.

Area 3:
Roles, Services, Authentication

Area 4:
Roles, Services, Authentication

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:
Finite State Model

See Area 11

The Finite State Model (FSM) is integrated into Area 11 and reflects the other changes in the standard.

 -

Area 5:
Software/ Firmware Security

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:
Operational Environment

Area 6:
Operational Environment

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:
Physical Security

Area 7:
Physical Security

Changes do not impact software modules.

Area 8:
EMI/EMC

-

EMI/EMC requirements have been removed.

-

Area 8:
Non-Invasive Security

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:
Cryptographic Key Management

Area 9:
Sensitive Security Parameter Management

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:
Self Tests

Area 10:
Self-Tests

Self-tests are redefined into the following categories:

  • Pre-operational:
    • Software integrity testing
    • Other, if applicable: bypass, critical functions
  • Conditional self-tests:
    • Cryptographic Algorithm Self-Tests (CASTs): comparable to FIPS 140-2 Power-On Self-Tests (POSTs)
    • Pairwise-Consistency Tests (PCTs): for key generation
    • Other, if applicable: software loading, manual entry, conditional bypass, critical functions

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:
Design Assurance

Area 11:
Life-Cycle Assurance

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:
Mitigation of Other Attacks

Area 12:
Mitigation of Other Attacks

No change at level 1.

 

Annex B:
Security Policy

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 Archer

Aryeh is Safelogic's Director, Operations and Compliance.

Share This:

Back to posts

Popular Posts

Search for posts

Tags

See all