CMVP algorithm transitions can be a great source of anxiety for vendors who seek to attain or maintain compliance to the FIPS 140-2 and 140-3 standards. A great deal of diligence, patience and persistence are required to continually review and assess product requirements against planned transitions.
When a FIPS validated product no longer complies with a CMVP requirement due to an algorithm transition event, the module may be moved from the Active to the Historical list of validated modules, subject to the CMVP’s transition management. Products on the Historical list are NOT recommended for Federal agency procurement. For example, the SP 800-56Ar3 transition that occurred on July 1, 2022, caused several modules being relegated to the Historical list from the active list.
The tables below are intended to provide a snapshot of CMVP transitions as of July 2023. The idea behind Table 1, is to list CMVP documents that generally apply to “all” algorithm transitions. The objective of the second table is to list algorithm specific transitions with enough information to determine applicability e.g., “does this transition affects my module or not?”
The first table, Table 1- Key CMVP Transition Documents, lists baseline documents relating to all transitions. This includes a CMVP website with a summary of transitions both past and future. The SP 800-131Ar2 document spans all categories of algorithms indicating their status in terms of being approved, allowed or disallowed (deprecated) for use. The list culminates with the respective Implementation Guidance (IG) documents for both FIPS 140-2 and FIPS-140-3, with the 140-3 IG document showing a mapping of IGs between the standards.
| Transition Document Reference | Link |
|---|---|
| CMVP Programmatic Transitions | CMVP Programmatic Transitions |
| Transitioning the Use of Cryptographic Algorithms and Key Lengths | SP 800-131Arev2 |
| FIPS 140-3 Implementation Guidance (IG) | FIPS 140-2 IG FIPS 140-3 IG |
The second table lists algorithm specific transitions with links to related FIPS and NIST documents. FYI transitions can affect timing for both the submission date and the date on which module status is impacted by a move from the Active to the Historical list – both dates are specified in the table below. The submission date is the day on which the lab submits the full test report to the CMVP, and the module goes into the queue. The Historical date is the day on which the CMVP may move non-compliant modules from the Active to Historical list. Here are more details about these two dates:
- Submission Date: The last date that a module that implements this algorithm in the approved mode can be submitted to the CMVP. Submissions that do not modify or initiate a sunset date can still be submitted after this date.
- Historical Date: Date in which modules that implement these algorithms in an approved mode will be moved to the historical list. If marked N/A, the module will NOT be moved to the historical list based on this transition.
| Algorithm/Scheme | Standard | Relevant IG(s) and Links | Submission Date | Historical Date |
|---|---|---|---|---|
| AES-CBC-MAC allowed within OTAR | P25 OTAR (Over-The-Air-Rekeying) defined in TIA-102.AACA-B | FIPS 140-2: N/A FIPS 140-3 IG: D.C | November 1, 2023 | N/A |
| RSA-based KAS or KTS compliant to SP 800-56B | SP 800-56B (Withdrawn) and superseded by SP 800-56Br1 SP 800-56Br2 | FIPS 140-2 IGs: D.4,D.8,D.9 FIPS 140-3: N/A | December 31, 2020 | January 1, 2024 |
| RSA-based key transport schemes that are not compliant to either SP 800-56B or SP 800-56B Rev. 2 | SP 800-56B (Withdrawn) and superseded by SP 800-56Br1 SP 800-56Br2 | FIPS 140-2 IGs: allowed D.9 FIPS 140-3: N/A | December 31, 2020 | January 1, 2024 |
| RSA-based key transport schemes that only use PKCS#1-v1.5 padding | RFC 2313 Section 8.1 | FIPS 140-2 IG: D.9 FIPS 140-3 IG: D.G | December 31, 2023 | January 1, 2024 |
| Triple-DES encryptions | SP 800-67 Rev. 2 SP 800-131A Rev. 2 | FIPS 140-2: N/A FIPS 140-3: N/A | December 31, 2023 | FIPS 140-2: N/A FIPS 140-3: January 1, 2024 |
| Transition from FIPS 186-4 to FIPS 186-5 and SP 800-186 | FIPS 186-4 FIPS 185-5 SP 800-186 | FIPS 140-2: N/A FIPS 140-3: C.K. | February 4, 2024 (12 months after the publication of 186-5) | N/A (soft transition) |
| TLS 1.2 KDF master_secret parameter | RFC 7627 | FIPS 140-2: N/A FIPS 140-3 IGs: D.Q | May 16, 2023 (if sunset date changed). Submissions must use the approved Extended Master Secret according to RFC 7627 past this date. | N/A |
| SHA-1 (migrate to SHA-2 or SHA-3 as soon as possible) | FIPS.180-4 | FIPS 140-2: N/A FIPS 140-3: N/A NIST SHA-1 Transition | December 31, 2030 | N/A |
| Post-Quantum Computing | PQC: CNSA 1.0 PQC: CNSA 2.0 | NIST PQC Standards | Suggest compliance to PQC algorithms by 2025 | Non-PQC algorithms at risk by 2030 |
So how does a vendor deal with an algorithm transition and devise a plan to remain compliant? Well, there are a few ways to achieve this objective:
- Remove or disable the offending algorithm and/or key lengths within module code.
- Transition to recommended or replacement algorithms and/or key lengths.
- Use the Security Policy to designate the offending algorithm as being non-approved and list in the appropriate table e.g., “Non-Approved Algorithms Not Allowed in the Approved Mode of Operation.”
The testing experts at Lightship Security can help assist in identifying, assessing, and avoiding unwanted algorithm transitions. Contact us at info@lightshipsec.com to discuss your requirements in more detail.
James Ramage
James Ramage is a senior FIPS evaluator at Lightship. He has been doing FIPS evaluations and security certifications for 5+ years and enjoys working with customers, training team members and evaluating new technologies.