Announcements

• Minor editorial updates.

New Implementation Guidance

• 14.3 Logical Diagram for Software, Firmware and Hybrid Modules

New Implementation Guidance

• G.13 Instructions for completing a FIPS 140-2 Validation Certificate

Updated Implementation Guidance

• G.8 Revalidation Requirements
  • Additional guidelines for determining <30% change for Scenario 3.
• 7.1 Acceptable Key Establishment Protocols
  • Updated to reflect the publishing of NIST SP 800-56A.

[06-26-2007] -- Annex D: Approved Key Establishment Techniques for FIPS PUB 140-2, Security Requirements for Cryptographic Modules, [PDF] has been updated.

Symmetric Key Establishment Techniques:
Removed reference to FIPS 171. FIPS 171 was withdrawn February 08, 2005.

Asymmetric Key Establishment Techniques, Number 2:
Added references for additional schemes in FIPS 140-2 IG Section 7.1.

Updated Implementation Guidance

• G.2 Completion of a test report: Information that must be provided to NIST and CSE
  • Editorial changes for clarification.
• G.8 Revalidation Requirements
  • Editorial changes for clarification.

New Implementation Guidance

• 1.11 CAVP Requirements for Vendor Affirmation of NIST SP 800-56A
• 1.12 CAVP Requirements for Vendor Affirmation of NIST SP 800-90

Updated Implementation Guidance

• 3.1 Authorized Roles
  • Updated to reference hashing and RNG services.

Updated document links. Added Protection Profile for Single-level Operating Systems in Environments Requiring Medium Robustness, Version 1.91.

Updated Implementation Guidance

• Updated references to revision of NIST SP 800-57

[03-19-2007] -- Annex C: Approved Random Number Generators for FIPS PUB 140-2, Security Requirements for Cryptographic Modules, [PDF] has been updated.

Deterministic Random Number Generators, Number 6:
Recommendation for Random Number Generation Using Deterministic Random Bit Generators (Revised)- Updated to revised document.

[03-19-2007] -- Annex D: Approved Key Establishment Techniques for FIPS PUB 140-2, Security Requirements for Cryptographic Modules, [PDF] has been updated.

Asymmetric Key Establishment Techniques, Number 1:
Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography (Revised) - Updated to revised document.

Updated Implementation Guidance

• 1.6 Use of Non-NIST-Recommended Asymmetric Key Sizes and Elliptic Curves
  • Clarified text regarding specification of key strengths for elliptic curves.

Updated Implementation Guidance

• 7.4 Zeroization of Power-Up Test Keys
  • Clarified text regarding Section 4.9.1 test keys

New Implementation Guidance

• G.12 Post-Validation Inquiries

New Implementation Guidance

• 1.10 Vendor Affirmation of Cryptographic Security Methods

Updated Implementation Guidance

• G.8 Revalidation Requirements
  • Scenario 2, 1st paragraph clarification update.
• 7.5 Strength of Key Establishment Methods
  • Updated text on the calculation of key strength.

Random Number Generators, Number 1:
Annex C: Approved Random Number Generators for FIPS 140-2, Security Requirements for Cryptographic Modules - Updated reference document date

[01-24-2007] -- Annex C: Approved Random Number Generators for FIPS PUB 140-2, Security Requirements for Cryptographic Modules, [PDF] has been updated.

Deterministic Random Number Generators, Number 6:
Recommendation for Random Number Generation Using Deterministic Random Bit Generators - Added

[01-24-2007] -- Annex D: Approved Key Establishment Techniques for FIPS PUB 140-2, Security Requirements for Cryptographic Modules, [PDF] has been updated.

Asymmetric Key Establishment Techniques, Number 1:
Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography - Added

New Implementation Guidance

• 1.9 Definition and Requirements of an Hybrid Cryptographic Module

The transition period ends December 31, 2006.

As has been the policy in the past:

1. For any algorithm validation request where a lab has used a previous version of CAVS to create files and has already sent the sample and request files to the vendor, NIST will accept validations using this tool up through December 31, 2006.
2. If there are any validation requests where a lab has used a previous version of CAVS to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS5.2.
   
3. It is strongly advised that any CMVP cryptographic module in the pre-validation phase re-test the RSA implementations with the new version of CAVS.
4. After December 31, 2006, all new received test reports to the CMVP pre-validation queue must use the CAVS5.2 to validate RSA.

The CAVP will also review special conditions on a case-by-case basis.

For all validated cryptographic modules that incorporate RSA, the CMVP and CAVP strongly suggest re-testing of the RSA algorithmic implementations to determine if the vulnerability is present.

• If new CAVP testing is performed, and the vulnerability is determined not to be present, the CMTL can send a letter to the CAVP along with the ZIP'ed CAVS 5.2 files requesting a new algorithm certificate printed to replace the already issued certificate referencing the new version of CAVS. Note that the certificate number will not change. Only the reference to the version of the CAVS tool will be changed.
• If CAVP testing is performed and the vulnerability is discovered, the following revalidation process shall be followed:
  • The algorithm implementation is changed to remove the vulnerability resulting in a different version number,
  • Submit the new test results to the CAVP for the new version of the implementation. A new algorithm certificate will be issued for the new version of the implementation. The certificate will reference CAVS5.2.
  • A revalidation letter can be submitted to the CMVP confirming that the only change to the module is to the RSA algorithmic implementation to correct the identified vulnerability; provide the reference to the new RSA algorithmic validation certificate; and provide a new version for the module. The CMVP will update the existing FIPS 140-1 or FIPS 140-2 module certificate web site entry to reference the new RSA algorithmic validation certificate and the new module version number associated with that certificate. No new FIPS 140-2 validation certificate will be issued. An updated Security Policy is required to include the new information. Any other changes to the validated cryptographic module shall handled in accordance with IG G.8 - Revalidation Requirements.

Please direct any CAVP or CMVP questions to the appropriate contact.

Updated Implementation Guidance

• G.8 Revalidation Requirements
  • New revalidation scenario: No change to module but update of security relevant service or function.

Updated Implementation Guidance

• G.2 Completion of a test report: Information that must be provided to NIST and CSE
  • Additional file to include and new NIST and CSE e-mail contact information.

Updated Implementation Guidance

• G.2 Completion of a test report: Information that must be provided to NIST and CSE
  • Added reference to include PIV Card Application certificate reference if applicable to the draft certificate.

[04-03-2006] -- New release of the CAVS algorithm validation testing tool to the CMT Laboratories (CAVS5.0).Version 5.0 of the CAVS tool includes the addition of a validation test suite for the CMAC algorithm. Documentation describing the CMAC validation tests is located in the CMACVS document accessible via our webpage. CAVS5.0 also includes several modifications to the existing algorithm validation tests to provide requested enhancements to the tool.

The transition period ends July 3, 2006.

As has been the policy in the past:

1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, DSA, SHA, RNG, RSA, ECDSA, HMAC, CCM and/or CMAC, the CMT lab must use the CAVS5.0 to validate the IUT.
2. For any algorithm validation request where a lab has used a previous version of CAVS to create files and has already sent the sample and request files to the vendor, NIST will accept validations using this tool up through July 3, 2006.
3. If there are any validation requests where a lab has used a previous version of CAVS to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS5.0.

The CAVP will also review special conditions on a case-by-case basis.

CMAC

National Institute of Standards and Technology, Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication, Special Publication 800-38B, May 2005.

Updated Implementation Guidance

• G.2 Completion of a test report: Information that must be provided to NIST and CSE
  • Updated NIST contact.
• G.5 Maintaining validation compliance of software or firmware cryptographic modules
  • Added exception for vendor recompilation.

New Implementation Guidance

• 1.8 Listing of DES Implementations
• 7.5 Strength of Key Establishment Methods

Updated Implementation Guidance

• G.2 Completion of a test report: Information that must be provided to NIST and CSE
  • Updated NIST contact

Information regarding allowed asymmetric key establishment methods moved to FIPS 140-2 IG 7.1.

New Implementation Guidance

• G.11 Testing using Emulators and Simulators
• 1.6 Use of Non-NIST-Recommended Asymmetric Key Sizes and Elliptic Curves
• 1.7 Multiple Approved Modes of Operation
• 5.2 Testing Tamper Evident Seals
• 7.4 Zeroization of Power-Up Test Keys
  

Updated Implementation Guidance

• G.1 Request for Guidance from the CMVP
• 1.2 FIPS Approved Mode of Operation
• 7.1 Acceptable Key Establishment Protocols
• 7.2 Use of IEEE 802.11i Key Derivation Protocols
  

Updated Implementation Guidance

• G.2 Completion of a test report: Information that must be provided to NIST and CSE
  • Updated CSE contact.

Clarification regarding the use of asymmetric keys for key wrapping as a key transport method for key establishment.

DES and Triple-DES

National Institute of Standards and Technology, Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher, Special Publication 800-67, May 2004.

[05-11-2005] -- New release of the CAVS algorithm validation testing tool to the CMT Laboratories (CAVS4.6). Version 4.6 of the CAVS tool includes a couple of minor modifications. These modifications include:

1. For HMAC: Enforcing the minimum length allowed for the key size. As specified by FIPS PUB 198 The Keyed-Hash Message Authentication Code (HMAC) Section 3 Cryptographic Keys, it states: "The size of the key, K, shall be equal to or greater than L/2, where L is the size of the hash function output." The minimum key size is dependent on the hash function supported by the HMAC implementation and is specified on each screen for HMAC.
2. For DES and Triple-DES: The message displayed after validating results has been modified to indicate whether or not the tests have passed successfully.

The transition period ends August 11, 2005.

As has been the policy in the past:

1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of DES, Triple-DES, AES, DSA, SHS, RNG, RSA, ECDSA, HMAC and/or CCM, the CMT lab must use the CAVS4.6 to validate the IUT.
2. For any algorithm validation request where a lab has used CAVS4.5 to create files and has already sent the sample and request files to the vendor, NIST will accept validations using this tool during the transition period which expires August 11, 2005. The CMT Laboratory should contact those vendors to inform them that the algorithm validation files supplied to them will expire at the end of the transition period. If the vendor has not returned the response files by that time, the request and sample files will have to be regenerated by the CAVS4.6 tool and the vendor will have to regenerate the response files.
3. If there are any validation requests where a lab has used a previous version of CAVS to create files and has not sent the appropriate files to the vendor yet, please regenerate everything using CAVS4.6.

The CAVP will also review special conditions on a case-by-case basis.

• NIST-Recommended Random Number Generator Based on ANSI X9.31 Appendix A.2.4 Using the 3-Key Triple DES and AES Algorithms added.

• New RNG algorithm testing
  • Algorithm testing available for NIST-Recommended Random Number Generator Based on ANSI X9.31 Appendix A.2.4 Using the 3-Key Triple DES and AES Algorithms.
  • During the transition period, ANSI X9.31 RNG implementations using 3-Key Triple-DES and AES algorithms will continue to be recognized as FIPS Approved "vendor affirmed" or referenced to the new algorithm certificate if available for FIPS 140-2 validations. After the transition period, these RNG implementations will only be recognized on new FIPS 140-2 validations as FIPS Approved when referenced to an algorithm certificate.
  • All references to RNG on FIPS 140-2 validation certificates that have RNG certificates will be referenced as RNG (Cert. nnn).

The transition period ends April 30, 2005. New FIPS 140-2 validation test reports received from CMT Laboratories after the transition period must conform to the new algorithm testing schemes indicated above. For FIPS 140-2 re-validations received after April 30, 2005, if the security relevant changes do not require new algorithm testing, new algorithm testing is not required. If an algorithm is changed or added, that algorithm must conform to the new algorithm testing schemes indicated above.

For algorithm validation requests where a CMT Laboratory has used CAVS4.3 to create files and has already sent the sample and request files to the vendor, NIST will accept validations using the old tools during the transition period. The CMT Laboratory should contact those vendors to inform them that the algorithm validation files supplied to them will expire at the end of the transition period. If the vendor has not returned the response files by that time, the request and sample files will have to be regenerated by the CAVS4.4 tool and the vendor will have to regenerate the response files. The CMVP will also review special conditions on a case-by-case basis

New Implementation Guidance

• 6.4 Approved Integrity Techniques
• 7.2 Use of IEEE 802.11i Key Derivation Protocols
• 7.3 Use of other Core Symmetric Algorithms in ANSI X9.31 RNG
  

Updated Implementation Guidance

• G.1 Implementation guidance requests to NIST and CSE
  • Updated NIST and CSE contacts.
• G.2 Completion of a test report: Information that must be provided to NIST and CSE
  • Updated CSE contact. Change requirements for signature page.
• G.3 Partial Validations and Not Applicable Areas of FIPS 140-2
  • Added guidance regarding Not Applicable Areas.
• G.5 Maintaining validation compliance of software or firmware cryptographic modules
  • Clarified the distinct actions a vendor or user may affirm compliance.
• G.8 re-validation Requirements
  • Added Regression Test Suite and clarifications.

URL links for Approved protection profiles updated.

Message Authentication

National Institute of Standards and Technology, Recommendation for BlockCipher Modes of Operation: The CCM Mode for Authentication and Confidentiality , Special Publication 800-38C, May 2004.

Updated Implementation Guidance

• 9.1 Known Answer Test for Keyed Hashing Algorithm (updated)
  • Removed requirement that a KAT must be implemented for every HMAC.

New and Updated Implementation Guidance

• G.5 Maintaining validation compliance of software or firmware cryptographic modules (updated)
  • Added references to firmware modules.
• 1.5 Validation Testing of SHS Algorithms and Higher Cryptographic Algorithm Using SHS Algorithms (new)
• 7.1 Acceptable Key Establishment Protocols (updated)
  • Added reference to password-based key establishment protocols.
• 9.1 Known Answer Test for Keyed Hashing Algorithm (updated)
  • Added references to HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384 and HMAC-SHA-512.
• 9.2 Known Answer Test for Embedded Cryptographic Algorithms (updated)
  • Additional comment regarding SHA-1 within the FIPS 186-2 RNG.
• 9.4 Cryptographic Algorithm Tests for SHS Algorithms and Higher Cryptographic Algorithms Using SHS Algorithms (new)

Asymmetric Key

DSA, RSA and ECDSA
National Institute of Standards and Technology, Digital Signature Standard (DSS), Federal Information Processing Standards Publication 186-2 with Change Notice 1, October 05, 2001.
Updated reference to include Change Notice 1.

RSA Laboratories, PKCS#1 v2.1: RSA Cryptography Standard, June 14, 2002.
Updated to reflect CMVP FAQ Section 6 entry "What is the status of PKCS#1?".

New and Updated Implementation Guidance

• G.1 Implementation guidance requests to NIST and CSE (updated)
  • Distribution of CMT Lab guidance to all CMT Labs.
• G.5 Maintaining validation compliance of software cryptographic modules (updated)
  • Addition of compliance caveat.
• 1.4 Use of Cryptographic Algorithm Validation Certificates (new)
  • A transition period for conformance to IG 1.4 will end October 29, 2004. The CMVP will also review special conditions on a case-by-case basis.

• Added Key Generation to RSA X9.31.
• Added validation tests for the General Purpose RNG specified in FIPS 186-2 Change Notice.
• Added the ability to select more than one SHA when running validation tests for RSA. This has changed the format of the Signature Generation and Signature Verification files.

Hashing

Secure Hash Standard (SHA-1, SHA-224, SHA-256, SHA-384 and SHA-512)
National Institute of Standards and Technology, Secure Hash Standard, Federal Information Processing Standards Publication 180-2 with Change Notice 1, February 25, 2004. SHA-224 added as a reference.

New Guidance

• 1.3 Firmware Designation

New Guidance

• G.10 Physical Security Testing for Re-validation from FIPS 140-1 to FIPS 140-2
• 6.3 Correction to Common Criteria Requirements on Operating System

Details can be found in the Change Notices section of the DTR. DTR Change Notice 5.

Details can be found in the Change Notices section of the DTR. DTR Change Notice 4.

New Guidance

• 1.2 FIPS Approved Mode of Operation

• New rDSA algorithm testing
  • Testing is now available for conformance to several versions of the rDSA algorithm.
  • During the transition period, rDSA algorithms will continue to be recognized as FIPS Approved "vendor affirmed" or referenced to the new algorithm certificate if available for FIPS 140-2 validations. After the transition period, rDSA will only be recognized on new FIPS 140-2 validations as FIPS Approved when referenced to an algorithm certificate.
  • All references to RSA on FIPS 140-2 validation certificates that have rDSA certificates will be referenced as rDSA (Cert. nnn).
• Expanded SHS algorithm testing
  • Testing is now available for conformance to SHA-1, SHA-256, SHA-384, and SHA-512 algorithms.
  • SHS algorithms will only be recognized as FIPS Approved with reference to an algorithm certificate.
  • All references to Secure Hash Algorithms on FIPS 140-2 validation certificates that have SHS certificates will be referenced as SHS (Cert. nnn).
• New RNG algorithm testing
  • Testing is now available for conformance to the RNG algorithms that are referenced in FIPS 140-2 Annex C.
  • During the transition period, FIPS Approved RNG's found in FIPS 140-2 Annex C that do not have an algorithm certificate can still be used in FIPS Approved mode and will not be listed on the FIPS 140-2 validation certificate. They will only be listed on the FIPS 140-2 validation certificate if an algorithm certificate is available. After the transition period, FIPS Approved algorithms that can be tested can only be used in a FIPS Approved mode with reference to an algorithm certificate. Where testing is not available for the FIPS Approved algorithms, they will be annotated as "vendor affirmed".
  • All references to RNG algorithms on FIPS 140-2 validation certificates will be referenced as RNG (Cert. nnn).
  
  The transition period ends June 04, 2004. New FIPS 140-2 validations or re-validation test reports (RE: FIPS 140-2 IG G.8) received from CMT Laboratories after the transition period must conform to the new algorithm testing schemes indicated above and meet ALL current standards and IGs.

  For algorithm validation requests where a CMT Laboratory has used CAVS1.3 or DSSVS to create files and has already sent the sample and request files to the vendor, NIST will accept validations using the old tools during the transition period. The CMT Laboratory should contact those vendors to inform them that the algorithm validation files supplied to them will expire at the end of the transition period. If the vendor has not returned the response files by that time, the request and sample files will have to be regenerated by the CAVS3.0 tool and the vendor will have to regenerate the response files. The CMVP will also review special conditions on a case-by-case basis.
  

Hashing

Secure Hash Standard (SHA-1, SHA-256, SHA-384 and SHA-512)
National Institute of Standards and Technology, Secure Hash Standard, Federal Information Processing Standards Publication 180-2, August 01, 2002.

Random Number Generators

Annex C: Approved Random Number Generators
National Institute of Standards and Technology, Annex C: Approved Random Number Generators for FIPS 140-2, Security Requirements for Cryptographic Modules, March 17, 2003.

Change Notices 2, 3 and 4 have been added. Change Notices 2, 3 and 4 will be mandatory for all modules submitted to NIST and CSE for FIPS 140-2 validation after June 04, 2004. For Change Notice 2, the CMT Laboratories will begin performing validation testing of the FIPS-approved Random Number Generators.

During the transition period prior to June 04, 2004, the following requirements are applicable:

• Change Notice 2: FIPS PUB 140-2 Section 4.9.1, Power-Up Tests: Statistical random number generator tests are not required and will not be tested. The additional changes specified by Change Notice 2 are not mandatory until June 04, 2004. For example, the RNG KAT will not be required until after the transition period.
• Change Notice 3: Until such time a FIPS-approved key agreement method is available, there is no pair-wise consistency test required for key agreement. When a FIPS-approved key agreement method is available, the FIPS 140-2 conditional test requirements will be developed.
• Change Notice 4:Clarification.
  Details can be found in the Change Notices section of the standard.

Details can be found in the Change Notices section of the DTR.

New Guidance

• 1.1 Cryptographic Module Name

MQV and EC MQV added as Asymmetric Key Establishment Techniques for use in a FIPS Approved mode.

New Guidance

• 5.1 Opacity and Probing of Cryptographic Modules with Fans, Ventilation Holes or Slits at Level 2
• 7.1 Acceptable Key Establishment Protocols
• 9.1 Known Answer Test for Keyed Hashing Algorithm
• 9.2 Known Answer Test for Embedded Cryptographic Algorithms
• 9.3 KAT for Algorithms used in an Integrity Test Technique

G.1 Implementation guidance requests to NIST and CSE
Personnel change.

G.2 Completion of a test report
Requirements for submission of documents and termination of initial review.

Removed Asymmetric Key references to ANSI X9.31-1998 and ANSI X 9.62-1998.
These are referenced FIPS 186-2.

6.2 Applicability of Operational Environment Requirements to JAVA Smart Cards updated for clarity.

Clarification of Asymmetric Key Establishment Techniques for use in a FIPS Approved mode.

G.1 and G.2 NIST CMVP contacts changed.

G.5 Maintaining validation compliance of software cryptographic modules

Software modules that require any source code modifications to be recompiled and ported to another General Purpose Computer (GPC) or operational environment must be reviewed by a CMT laboratory and revalidated per IG G.8 (1) [non-security relevant changes].

The effective date for the modified guidance is September 15, 2003.

URL link for CAPP updated.

Bookmarking has been added within each list for each individual certificate. Either while browsing the list, or by link from another web page, one can easily navigate directly to a single certificate entry. If browsing the list, simply append #nnn (where nnn is the 1-3 digit certificate number) to the link, hit enter, and you will go directly to the certificate number.If referencing from another web page, an example syntax would be: http://csrc.nist.rip/cryptval/140-1/140val-all.htm#nnn

A cryptographic module may either be a component of a product, or a standalone product. NIST directs user inquiries to cryptographic module vendors to determine specific products that use a validated cryptographic module. Typically there are a large number of security products available that use every validated cryptographic module.

While the CMVP cannot maintain a list of vendor products that utilize an embedded validated cryptographic module, we would like to provide potential users and customers a way to find information on these products. Therefore we have added an optional 2nd URL below the Certificate link on each validation list entry. The 1st URL is the traditional link to the cryptographic module vendor's home page. It is intended that the 2nd URL would link to a vendor provided product page that contains a concise listing of those vendor products that use the validated cryptographic module or, if the module is a standalone product, additional pertinent information.

Providing a direct link for a user or customer to locate products that use validated cryptographic modules should make it easier for users and customers to deploy solutions with validated modules.

The directed link is vendor maintained and optional. NIST and the CMVP do not endorse the views expressed or the facts presented at the directed link. Further, NIST and the CMVP do not endorse any commercial products that may be advertised or available at the directed link.

Reference to FIPS 171 added for symmetric keys.

Reference to ANSI X9.31-1998 - Appendix A changed to ANSI X9.31-1998 - Appendix A.2.4.

NIST Special Publication 800-38A reference added.

Details can be found in the Change Notices section of the DTR.

URL links updated.

FIPS 197 (AES) and FIPS 198 (HMAC) have been added.

Validation Lists

ANSI X9.62-1998 Annex A.4 PRNG has been added as FIPS Approved.

CMVP Symposium 2004
Presentations and Photos Available
(go to Agenda page and select PDF and [photo] links)

CMVP Conference 2002
Presentations and Photos Available
(go to Agenda page and select PDF and [photo] links)

Computer Security Division Announcements

Last Modified: July 26, 2007
Computer Security Division
National Institute of Standards and Technology