FIPS 140-3

Validate your product against the newly released version of the FIPS standard.

FIPS White 406x406

FIPS 140-3

Validate your product against the newly released version of the FIPS standard.

FIPS 140-3 Is Here

FIPS 140-3 is approved and the timelines have been set. Is your certification strategy aligned with the recently released timelines and new standard?
Discuss your FIPS 140-3 validation approach and ensure your project is successfully conducted against changes in requirements, timelines, and processes.

The Timeline: FIPS 140-3

FIPS 140-3 Timelines

Federal Register Notice has been issued for the “Federal Information Processing Standard (FIPS) 140-3, Security Requirements for Cryptographic Modules”. Companies actively working on or planning a FIPS validation will inevitably face decisions around which standard to work towards. The following dates will be critical for those projects:

  • 5/1/2019: Federal Register Announcement
  • Mid 2019: Draft For Comments
  • 9/22/19: Standard Published & Effective Date **DELAYED**
  • 10/9/19: Draft NIST SP 800-140x Sub-series Available
  • 3/22/20: CMVP Program Updates
  • 9/22/20: New Testing Begins
  • 9/22/21: 140-3 Mandated & The Last Day for 140-2 Submissions – Labs must submit their Lab reports to CMVP by this date

The Changes: FIPS 140-3

FIPS 140-3 Requirements

The eleven sections of FIPS 140-3 have been updated. Software/Firmware Security and Sensitive Security Parameter Management are new categories. Both EMI/EMC and Finite State Model were removed. The new sections and requirements are as follows:

Cryptographic Module Specification:

The new standard defines five types of cryptographic modules or boundaries that can achieve validations; hardware module, firmware module, software module, hybrid-software module, and hybrid-firmware module. Hybrid modules, which were originally restricted to Level 1 validations in FIPS 140-2, no longer have a Level limitation.

Cryptographic Module Interfaces:

This section defines the interfaces or commands used by each module type, the new interfaces include; Hardware Module Interfaces (HMI), Software or Firmware Module Interfaces (SFMI), Hybrid-Software Module Interfaces (HSMI), Hybrid-Firmware Module Interfaces (HFMI), and Control Output Interface.

Software/Firmware Security:

This new section introduces Integrity Testing. This section does not apply to Hardware specific embodiments.

Roles, Services, & Authentication:

Roles: 1.) Crypto Officer Role, 2.) User Role, and 3.) Maintenance Role

The new FIPS 140-3 standard only mandates the Crypto Officer Role.

Services: 1.) Show Status, 2.) Perform Self-Tests, 3.) Perform Approved Security Function, 4.) Show Modules Versioning Information, and 4.) Perform Zeroization

Authentication: Level 4 now requires multi factor identity-based authentication.

Operational Environment:

Updates to this section include the elimination of the need for software modules at a Level 2 to be Common Criteria (CC) certified. However, there are many new requirements that coincide with CC that need to be addressed.

Physical Security:

Embodiments: 1.) Single-chip, 2.) Multiple-chip, and 3.) Multiple-chip Standalone

There are additional requirements at Level 2 (definition changes), Level 3 (tamper evidence seals), and Level 4 (EFP).

Non-Invasive Security:

This section outlines documentation and testing requirements for protecting the module from attacks performed in the absence of direct physical contact to components.

Sensitive Security Parameter Management (SSPs):

A new section in FIPS 140-3. SSPs include both Critical Security Parameters (CSPs) and Public Security Parameters (PSPs). This section covers SSP entry and output requirements at each level; as well as information on Random Bit Generation (RBG), CSP encryption, and Zeroisation.

Self-Tests:

New requirements for Periodic Self-Tests and Conditional Fault-Detection Tests have been added in addition to renaming Power On Self Tests to Pre-Operational Self-Tests.

Life-Cycle Assurance:

This section is dedicated to security requirements on how the module was designed, developed, and operates.

This section also includes requirements for the module’s End of Life. Additionally, the requirements from FIPS 140-2’s section on Finite State Model (FSM) have been absorbed into this section.

Mitigation of Other Attacks:

A section to address any additional attack mitigating functionality that was not directly called out in previous test requirements.

The Documents: FIPS 140-3

The new SP 800-140 documents are still in development, so we don’t have a fully vetted list of implementation and administrative guidance yet. Many of the supplemental and more detailed documents have not been released. They are scheduled to be released for comment later this year:

“Sections 3.3 and 3.4 of FIPS 140-3 identify NIST publications that will modify the annex requirements of ISO/IEC 19790:202(E) and ISO/IEC 24759:2017(E). The SP 800-140x documents are currently in development and NIST plans to release drafts for public comment in mid-2019. Final publication of those documents will occur by September 22, 2019”

References to ISO & Documents:

  • FIPS 140-3 will point to ISO 19790 for the requirements. This method of referencing the ISO requirement allows the U.S. and Canada to provide additional guidance deemed necessary by both governing bodies within the FIPS 140-3 standard. By creating and keeping their own validation policy, the two governments are able to mandate their own requirements for approved cryptographic algorithms, approved random number generators, and approved key establishment techniques.

Draft NIST SP 800-140X Subseries:

  • CMVP wants to minimize the content in the series of NIST SP 800-140 documents because they hope to be as close to the international standard (ISO) as possible.
  • On October 9th, 2019, NIST released a series of draft documents, SP 800-140X that we believe will replace the existing FIPS 140-2 DTR, Appendices, and Annexes:

Public comments are due by 12/9/19

**A notable omission from the new SP 800-140 series is any reference document for Approved Protection Profiles from Common Criteria (a CC-certified operating system was required for software validations at level 2 and above).

The Levels: FIPS 140-3

Within each of the eleven DTRs, there are four increasing qualitative security levels. At each level, greater amounts of evidence and engineering are required of the product in order to show compliance with the standard. FIPS 140-3 is retaining the 4 levels of validation:

      Level 1

Previous Requirements
Validation of at least one approved algorithm or security function
 Production-grade evaluated components

      Level 2

Previous Requirements
All Level 1 requirements
 Role-based authentication & physical security requirements for tamper evidence

     Level 3

Previous Requirements
 All Level 1 and 2 requirements
 Identity-based authentication & physical security mechanisms for tamper detection & tamper response

     Level 4

Previous Requirements
 All Level 1, 2, and 3 requirements
 Physical security mechanisms to detect and reply to tampering; including environmental attacks

Moving Forward: FIPS 140-3

As companies prepare for current and future projects, they will have a number of options to consider:

  1. Get Ahead: Be the first to complete the new standard (FIPS 140-3)
  2. Revalidate Early: Avoid the new requirements prior to the mandated transition date and add 5 years to your current FIPS 140-2 validation
  3. Plan Accordingly – Products being evaluated against FIPS 140-2 during testing transition may face problems completing their certification under old requirements.
FPS 140-2 & FIPS 140-3 Process

FIPS Inside & FIPS Compliance

Corsec details the differences between FIPS 140-2 Validation, FIPS Compliant, and FIPS Inside.
Your customer requests, timelines, and product will all have an influence on which approach is best suited for your company. Review the white-paper to learn more.

Have Questions? Talk To An Expert