[Updated 12-19-2016] -- Module Drop Policy

• Effective July 1, 2017, the CMVP will automatically drop modules in IUT after 18 months.
• Effective January 1, 2018, the CMVP will drop modules that have not been validated within 2 years of submission or IUTB, whichever occurred first. When the module is dropped, the vendor and lab will have to restart the validation process by sending an updated submission and paying a new cost recovery fee at the current rate.

[Updated 06-01-2016][11-12-2015] -- Validation Sunsetting Policy

The CMVP is adopting a five year validation sunsetting policy, effective February 1, 2017. The CMVP will move all validation entries with most recent validation dates** prior to February 1, 2012 and all FIPS 140-1 validation entries from the Active Validation Lists to the Historical Validation List. The Historical Validation List is not to be used for procurement by federal agencies. To maintain compliance with FISMA, agencies that use modules on the Historical List must make a risk management decision whether to continue to use these modules or replace them with compliant modules from the Active Validation Lists.

Through January 31, 2017, vendors may reinstate affected modules in one of the following ways:

• Modules fully compliant with the latest standard and guidance: 1SUB scenarios, reaffirming the validation. Vendors must work with one of the NVLAP accredited Cryptographic and Security Testing Laboratories to prepare the submission for CMVP. The laboratory will review the module and confirm it complies with all applicable transitions (e.g. 2-key Triple-DES, RNG).
• Modules that require some maintenance changes: all available revalidation scenarios - see FIPS 140-2 Implementation Guidance - G.8.

 

**[Note: The most recent validation date for a module is the latest update of the validation certificate as the result of the original submission or any of the available revalidation scenarios (1SUB, 2SUB, 4SUB).]

• Effective July 1, 2016, for validation entries on the Historical List, the CMVP will only accept 1SUBs for administrative updates (e.g. updating contact information). The CMVP will not accept 1SUBs for any other types of updates (e.g. adding operating environments).
• Effective February 1, 2017, 1A and 1BSUB scenarios will inherit the sunset date of the original certificate.
• Effective February 1, 2017, 1SUB scenarios will not reset the sunset date.

[12-09-2015] -- Two-key TDEA transition, December 31, 2015

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

 

• Modules on the CMVP queue
  • REVIEW PENDING or IN REVIEW: The laboratories/vendors will be asked to provide an updated submission that is fully compliant with the transition. Only compliant submission will be validated.
  • COORDINATION: These module submissions will be handled like those in the REVIEW PENDING or IN REVIEW case.
  • FINALIZATION: These module submissions will be handled like already validated modules.

 

• 1/2/4 SUBs for validated modules on the CMVP Active Validation Lists: When an updated Security Policy is submitted it will be required to comply with the transition.

[Updated 7-1-2016][Updated 11-24-2015][Updated 11-10-2015][03-16-2015] -- X9.31 RNG transition, December 31, 2015

The Cryptographic Technology Group at NIST has confirmed the transition schedule for RNGs (e.g., the X9.31 RNG) provided in SP 800-131A. Accordingly, when the transition takes place the CMVP will proceed as follows:

The CMVP will move all Category 3 and 4 modules to a Legacy Validation List, effective January 31, 2016. The Legacy Validation List is not to be used for procurement by federal agencies. However, impacted vendors who can substantiate a hardship case as the result of this deadline are encouraged to contact the CMVP as early as possible. The CMVP will work with them to minimize the negative impact.

The CMVP will provide vendors with a voluntary process for updating Category 3 and 4 modules on the Legacy Validation List and reinstating them back on the Active Validation Lists:

 

• Validated modules on the CMVP Active Validation Lists: The CMVP will classify the validations into four categories:
  • Category 1: Modules with DRBG's only.
  • Category 2: Modules without any DRBG's or RNG's.
  • Category 3: Modules with DRBG's and RNG's.
  • Category 4: Modules with RNG's only.

The CMVP will move all Category 3 and 4 modules to a Legacy Validation List, effective January 31, 2016. The Legacy Validation List is not to be used for procurement by federal agencies. However, impacted vendors who can substantiate a hardship case as the result of this deadline are encouraged to contact the CMVP as early as possible. The CMVP will work with them to minimize the negative impact.

The CMVP will provide vendors with a voluntary process for updating Category 3 and 4 modules on the Legacy Validation List and reinstating them back on the Active Validation Lists:

• 1SUB process: may be used to update the Security Policy and Certificate for modules without any module changes. After June 30, 2016, the CMVP will not accept 1SUBs to address the RNG transition.
• 1SUB-like process++: may be used to update modules with minimal changes. After June 30, 2016, the CMVP will not accept 1SUB-like submissions.

 

• 3SUB and 5SUB process: may be used for more substantial module changes.

 

• Modules on the CMVP queue
  • REVIEW PENDING or IN REVIEW: The laboratories/vendors will be asked to provide an updated submission that is fully compliant with the transition. Only compliant submission will be validated.
  • COORDINATION: These module submissions will be handled like those in the REVIEW PENDING or IN REVIEW case.
  • FINALIZATION: These module submissions will be handled like already validated modules.
• 1/2/4 SUBs for validated modules on the CMVP Active Validation Lists: When an updated Security Policy is submitted it will be required to comply with the transition.

++[Note:To take advantage of the 1SUB-like process vendors shall work with an accredited CST laboratory. The laboratory shall follow the procedure below:

1. The laboratory shall perform a Scenario 3 revalidation testing - see IG G.8.
2. The laboratory shall submit a 3SUB documentation, including a rationale for why this submission should be treated as a 1SUB-like. The rationale should be directly related to the RNG transition, i.e. modules in Categories 3 and 4 above. The RNG transition-related changes include changing all instances where an old RNG is used with a call to the new DRBG and the corresponding updates to the power-on self-tests and applicable health and conditional tests. The submisstion should not include any other security updates and the rationale shall state this explicitly. If it does, then cost recovery shall apply.
3. The CMVP will review the rationale and if accepted, NIST will waive the 3SUB cost recovery fee.
4. The report review will follow the 3SUB review process, except that the module does not have to adhere to the latest guidance and a new validation certificate will not be created. The CMVP will make a reasonable effort to expedite the processing of these submissions but the actual speedup will depend on the quality of the submissions. ]

[08-12-2015] -- NIST requests comments on using the ISO/IEC 19790:2012 standard as the U.S. Federal Standard for cryptographic modules

NIST is seeking public comments on using International Organization for Standardization/International Electrotechnical Commission (ISO/IEC) standards for cryptographic algorithm and cryptographic module testing, conformance, and validation activities, currently specified by Federal Information Processing Standard (FIPS) 140-2. The National Technology Transfer and Advancement Act (NTTAA), Public Law 104-113, directs federal agencies to adopt voluntary consensus standards wherever possible. The responses to this request for information will be used to plan possible changes to the FIPS or in a decision to use all or part of ISO/IEC 19790:2012 for testing, conformance and validation of cryptographic algorithms and modules. The Request for Information (RFI) posted in today’s Federal Register provides additional background, including seven questions that NIST is especially interested in having addressed, as well as NIST’s intentions.

Send public comments to: UseOfISO@nist.gov (also see the address for sending written comments)

Comment period closes: September 28, 2015.

**[Note: in the official RFI in the Federal Register Notice,
the link to the ISO site is incorrect; it should link to
http://www.iso.org/iso/catalogue_detail.htm?csnumber=52906 instead.]

[03-13-2015] -- The Third International Cryptographic Module Conference

The third annual International Cryptographic Module Conference will take place in November of this year. ICMC is a growing forum for global expertise in commercial cryptography. Industry leaders will convene November 4-6, 2015 in Hilton Washington, D.C., Rockville, MD to address the unique challenges faced by those who produce, use, and test cryptographic modules that conform with standards such as FIPS 140-2 and ISO/IEC 19790. Visit ICMC 2015 for complete information.

[Updated 12-09-2014][Updated 08-01-2014][Updated 06-05-2014][Updated 06-07-2007][Updated 01-24-2007][Updated 10-19-2006][Updated 04-19-2006][Updated 01-28-2003][07-18-2002] -- 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 or CMVP FAQ for further information.

Currently the CR fee is applicable for IG G.8 Scenarios 1A, 1B and 5; the CR fee is not applicable for IG G.8 Scenario's 1, 2, 3 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 current fee structure is as follows:

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

The CMVP review of report documents will not begin for new report submissions received after September 30, 2014 until the applicable CR fee is collected by NIST Billing. NIST Billing will invoice the CR fee when the submission documents are received. Modules are not validated unless all applicable fees (CR and ECR) have been collected by NIST Billing.

For questions about methods of payments and associated handling fees, contact NIST Billing: Phone: 301-975-3880, FAX: 301-975-8943 and e-mail: billing@nist.gov.

[04-24-2014] -- Heartbleed Vulnerability

Reference: CVE-2014-0160 National Vulnerability Database.

The TLS and DTLS implementations in OpenSSL 1.0.1 before 1.0.1g do not properly handle Heartbeat Extension packets, which allows remote attackers to obtain sensitive information from process memory via crafted packets that trigger a buffer over-read, as demonstrated by reading private keys, related to d1_both.c and t1_lib.c, aka the Heartbleed bug.

This vulnerability, which may allow the reading of a cryptographic modules private keys, would violate FIPS 140-2 functional security objectives as described in Section 4.3. The CMVP has two objectives to meet: 1) To ensure that the CMVP does not validate any new cryptographic modules that contain this uncorrected vulnerability, and 2) To provide a process by which vendors can quickly patch and re-validate their existing cryptographic modules.

Users of validated cryptographic modules should contact the modules vendor to determine if the Heartbleed vulnerability is applicable and determine if a patch or replacement module is available.

Vendors of validated cryptographic modules for which the Heartbleed vulnerability is applicable should contact a NVLAP Cryptographic and Security Testing Laboratory to validate a corrective patch or replacement module.

[04-24-2014] -- The Second International Cryptographic Module Conference

Bringing experts together from around the world to confer on the topic of cryptographic modules. Discussion on technical topics underlying the implementation of a cryptographic module including physical security, key management, side-channel analysis, key management, cryptographic algorithm implementation testing, standardization (FIPS 140-2, ISO/IEC 19790), validation programs and more. November 19-21, 2014 in Rockville, MD. Register now. Details at: ICMC 2014