Notices

2018 Notices

[11-30-2018]  CMVP Validation Policy

The CMVP has a long history of performing validations that show conformance to the FIPS 140-2 standard on any cryptographic module from anywhere in the world regardless of country of origin and/or company.  The US Government passed the National Defense Authorization Act (NDAA) for Fiscal Year 2019 on 13 Aug 2018, which contains language that restricts federal agencies from engaging in business with certain named companies.  US government agencies will be held accountable to ensure that they are not doing business with the companies that are identified in the NDAA.  This means that even if a company receives a CMVP validation, this is not sufficient to make the claim that products can be used in the US Federal infrastructure.  The CMVP will continue to perform validations for any company that goes through the conformance testing process, but vendors may need to decide their intent prior to going through the testing and validation process, since they will not be allowed to compete in US Federal acquisitions in instances where the language in the NDAA precludes it.   

The NDAA - Section 889  

2017 Notices

[12-20-2017] Symmetric Key Wrapping Transition, December 31, 2017

The Cryptographic Technology Group at NIST has confirmed the transition schedule for symmetric key wrapping to SP 800-38F provided in SP 800-131A. The CMVP will enforce the transition proactively. Accordingly, when the transition takes place the CMVP will proceed as follows:

• All Modules in the CMVP queue
  • The laboratories/vendors will be asked to provide an updated submission that is fully compliant with the transition. Only compliant submissions will be validated.
• All validations on the Active Validation List that implement the previously allowed AES or TDEA key wrapping: 
  • Entries will be moved to the Historical List. 

1SUB process: may be used to update the Security Policy and Certificate for affected modules without any module changes. After June 30, 2018, the CMVP will not accept 1SUBs to address the SP 800-38F transition if the module is on the Historical List.  Sunset dates will not be extended. 

Please note that this notice does not address key encapsulation or key agreement schemes.

[10-31-2017] -- Transition Plans for Key Establishment Schemes using Public Key Cryptography

Summary

NIST guidelines on approved public key key-establishments schemes are specified in the NIST SP 800-56 series of publications.  While legacy key establishment schemes have been programmatically allowed for use by agencies in FIPS 140-validated modules, NIST SP 800-131A Rev. 1, Transitioning the Use of Cryptographic Algorithms and Key Lengths, specifies that only schemes specified in the SP 800-56 series will be allowed after 2017.  However, there are widely used key-establishment schemes in protocols and applications that are not included in the current revisions of the SP 800-56 series publications.  These publications are being revised to align with current industry standards and best practices.  Compliance with the SP 800-56 series will not be required by the Cryptographic Module Validation Program (CMVP) until these revisions are complete.

Background

NIST recommendations on key establishment schemes using public key cryptography are published in the SP 800-56 series.  NIST SP 800-56A Rev. 2, Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography, specifies key-establishment schemes based on the discrete logarithm problem over finite fields and elliptic curves. NIST SP 800-56B Rev. 1 specifies RSA-based schemes.

The Diffie-Hellman and MQV-based schemes in NIST SP 800-56A were originally based on standards developed by American Standards Committee (ASC) X9: American National Standard (ANS) X9.42, Agreement of Symmetric Keys using Discrete Logarithm Cryptography, and ANS X9.63, Key Agreement and Key Transport using Elliptic Curve Cryptography.  The groups used for Finite Field Cryptography follow those used for the Digital Signature Algorithm as specified in Federal Information Processing Standard (FIPS) 186-4, Digital Signature Standard (DSS). However, widely used applications and protocols, including those used in the Internet Engineering Task Force (IETF), instead use so-called “safe-prime” groups.  Because such groups are more resilient to certain classes of implementation errors, the next revision of SP 800-56A will allow these groups, and require their use for security strengths above 112 bits.  This change will bring SP 800-56A into alignment with current best practices for using Diffie-Hellman.  Draft SP 800-56A Rev. 3 was released for comment in August 2017 with these, and other changes; comments are requested on the revision by November 6, 2017.  A final publication is expected in early 2018.

In addition, NIST guidelines on Elliptic Curve Cryptography are also being revised to propose the adoption of new elliptic curves specified in the Internet Engineering Task Force (IETF) RFC 7748. The upcoming draft of SP 800-186, which will specify approved elliptic curves, will include the curves currently specified in FIPS 186-4 and two additional curves: Curve25519 and Curve448.  Their associated key agreement schemes, X25519 and X448, will be considered for inclusion in a subsequent revision to SP 800-56A.  The CMVP does not intend to enforce compliance with SP 800-56A until these revisions are complete.

Guidelines for the RSA-based schemes in SP 800-56B are based on ANS X9.44, Key Establishment Using Integer Factorization Cryptography, and include RSA-OAEP and RSA-KEM-KWS key-transport schemes.  RSA-OAEP was standardized as an improvement over a common earlier scheme using RSA with PKCS#1 v1.5 padding, which is vulnerable to attacks if implementations do not employ certain countermeasures.  Due to those attacks, NIST sought to encourage implementers to migrate from RSA PKCS#1 v1.5 padding to RSA-OAEP, or to DH/ECDH schemes offering forward security, and did not include PKCS#1 v1.5 padding in SP 800-56B.  However, applications and protocols in common use today, including some common TLS v1.2 cipher suites and S/MIME e-mail encryption, continue to use PKCS #1 v1.5 padding.  Recognizing this widespread use, NIST is soliciting input from implementers, users and security researchers on whether to continue to allow RSA PKCS#1 v1.5 encryption as a deprecated scheme in certain protocols. Comments may be sent to CryptoTransitions@nist.gov by December 15, 2017. This feedback will be considered as part of the upcoming revision of SP 800-56B. NIST expects to release a draft of SP 800-56B Rev. 2 in the summer of 2018.

The transition schedule for key establishment schemes, currently specified in SP 800-131A, will be revised to reflect that CMVP will not require compliance with the SP 800-56 series until the in-process revisions are complete.  Additional details on the revised schedule will be released by the CMVP as the relevant standards and guidelines are finalized.

[3-31-2017] -- Using modulus sizes other than 2048 and 3072 bits in RSA signature generation:

The CT group at NIST has made the decision that the RSA moduli of any length not smaller than 2048 bits may be used when generating the RSA signatures. This policy is already reflected in SP 800-131A Rev1, Section 3, but not yet in the FIPS 186-4 standard, which will be updated later.

At least one of the RSA modulus lengths supported by the module for RSA signature generation shall be 2048, 3072, or 4096 bits. The RSA signature algorithm implementations shall be tested by a CST lab for all implemented RSA modulus lengths where CAVS testing is available.

Some of the RSA key generation methods described in Appendix B.3 of FIPS 186-4 rely on the use of the auxiliary primes p1, p2, q1 and q2 that must be generated before the module generates the RSA primes p and q. Table B.1 in FIPS 186-4 specifies, for RSA modulus lengths of 2048 and 3072 bits only, the minimum bit lengths and the maximum total length of the auxiliary primes. When implementing the RSA signature generation algorithm with other approved RSA modulus sizes, the vendor shall use the limitations from Table B.1 that apply to the longest RSA modulus shown in Table B.1 of FIPS 186-4 whose length does not exceed that of the implementation’s RSA modulus. In particular, when generating the primes for the 4096-bit RSA modulus the limitations stated for the 3072-bit modulus shall apply.

The use of the approved hash functions in digital signatures is documented in SP 800-131A Rev1, Table 9. Please note that the choice of a hash function may affect the security strength of the RSA signature algorithm.

Per IG 9.4, Note3, an RSA known-answer test for signature generation may be implemented for any approved RSA modulus size supported by the cryptographic module; that is, any implemented RSA modulus size of at least 2048 bits.

The use of the 1024-bit moduli in RSA signature verification is still approved, per SP 800-131A Rev1.

This guidance is effective immediately and will be formalized in an IG in the future.

[Updated 3-08-2018][Updated 3-31-2017][Updated 3-22-2016] -- NIST CMVP Fees:

Cost recovery fees are collected for NIST CMVP report review of new module submissions, modified module submissions, and for report reviews that require additional time due to complexity or quality. These fees are referred to as Cost Recovery (CR) and Extended Cost Recovery (ECR). Modules are not validated unless all applicable fees have been collected by NIST Billing. Please see the CMVP Management Manual for further information.

Currently the CR fee is applicable for IG G.8 Scenarios 1A, 1B, 3 and 5; the CR fee is not applicable for IG G.8 Scenario's 1, 2, and 4. The ECR fee is applicable per the overall Security Level to all test reports received by NIST CMVP under FIPS 140-2 IG G.8 (all five scenarios).

The following fee structure is effective October 1, 2018:

• IG G.8 Scenario's 1, 2 and 4: CR fee N/A, ECR fee: $1000
• IG G.8 scenario's 1A and 1B: CR fee $2000, ECR fee: $1000
• IG G.8 Scenario 3: CR fee $4000, ECR fee: $1500
• IG G.8 Scenario 5:
  • Security Level 1: CR fee: $8000, ECR fee: $3000
  • Security Level 2: CR fee: $10000, ECR fee: $4000
  • Security Level 3: CR fee: $10000, ECR fee: $4000
  • Security Level 4: CR fee: $10000, ECR fee: $4000

The following fee structure is effective October 1, 2017:

• IG G.8 Scenario's 1, 2 and 4: CR fee N/A, ECR fee: $1000
• IG G.8 scenario's 1A and 1B: CR fee $1500, ECR fee: $1000
• IG G.8 Scenario 3: CR fee $3000, ECR fee: $1500
• IG G.8 Scenario 5:
  • Security Level 1: CR fee: $6000, ECR fee: $3000
  • Security Level 2: CR fee: $8000, ECR fee: $4000
  • Security Level 3: CR fee: $8000, ECR fee: $4000
  • Security Level 4: CR fee: $8000, ECR fee: $4000

The following fee structure is effective October 1, 2016:

• IG G.8 Scenario's 1, 2 and 4: CR fee N/A, ECR fee: $1000
• IG G.8 scenario's 1A and 1B: CR fee $1500, ECR fee: $1000
• IG G.8 Scenario 3: CR fee $3000, ECR fee: $1500
• IG G.8 Scenario 5:
  • Security Level 1: CR fee: $6000, ECR fee: $3000
  • Security Level 2: CR fee: $8000, ECR fee: $4000
  • Security Level 3: CR fee: $11000, ECR fee: $5000
  • Security Level 4: CR fee: $15000, ECR fee: $6000

Past  Notices

2016-2014 Notices

2013-2009 Notices

2007-2003 Notices

^{Back to Top}