CMVP Validation Sunsetting Policy

Based on a CMVP notice from November 2015, we know that starting in 2017 the CMVP will move all 140-1 certificates and any 140-2 certificates older than 5 years to the Historical List. The goal is to keep current, valid crypto modules in circulation amongst federal agencies.  Remember that the Historical List is a “do not buy” list for US federal government procurement purposes. The previous policy was such that the 5 year clock would start running from the last date that a certificate was modified.  Between now and February 1, 2017, minor updates, such as updating vendor contact information or the module name, will reset the 5 year clock. However, after February 1, 2017, the policy is such that any validation submission that is a maintenance effort (i.e., submissions that are 1, 2, and 4 SUB submissions in CMVP speak) would NOT reset the 5 year running clock. With this change, vendors have the rest of 2016 to complete a minor update effort that would extend the life of their certificates. After that, in order to stay off of the Historical List, it must be proven that the module meets all current guidance.

Another topic to be aware of is that rebranding of an OEM module (1SUB scenario A submissions) will be under much more scrutiny by labs and CMVP reviewers when this policy goes into effect. It will have to be demonstrated that the rebranded module meets all current guidance. Alternatively, the CMVP may choose to only accept 1SUB scenario A submissions within a certain amount of time from the original OEM validation date. CMVP will provide further clarification as it relates to how they will accept rebranded modules.

We can expect an update to the validation sunsetting policy on the CMVP website soon.

The RNG Transition is Coming!

The RNG transition in 2016 is fast approaching.  Is your cryptographic module prepared?

Per the SP800-131A transition guidance, the following is stated in regards to the RNG transition:

"The use of the RNGs specified in FIPS 186-2, [X9.31] and [X9.62] is deprecated from 2011 through December 31, 2015, and disallowed after 2015".

Put simply, if a module utilizes one of the Random Number Generators (RNGs) in question for the purposes of key generation, the module will no longer have a compliant key generation method starting in January 2016. All cryptographic keys generated using the disallowed RNG will no longer be considered Approved.

This will not only affect future validations but be retroactive for all currently validated cryptographic modules.  Although CMVP would not confirm their specific course of action on January 1, 2016, we do know that a large percentage of FIPS 140-2 validated modules will be without a compliant mechanism to generate approved cryptographic keys, placing agencies using these cryptographic modules in a precarious position as they are required to use FIPS validated cryptographic modules.  Without updates to this functionality, federal agencies would be in direct violation of FISMA 2002.

So what are your options? If you are currently in the process, or plan to undergo FIPS 140-2 validation testing on a new module in the near future, you will need to ensure that your RNG is one defined in Special Publication 800-90A.  If you already have a FIPS 140-2 validated product and that device implements one or more of the soon to be disallowed RNGs, you will need to undergo revalidation testing with an approved RNG in order to maintain your validation.

FIPS Security Policy Updates for Heartbleed

(Image from heartbleed.com)

A month after the Heartbleed vulnerability was made public [Reference: CVE-2014-0160 National Vulnerability Database], and vendors with FIPS Crypto Modules are failing to do this one important thing.

In the FIPS 140-2 Security Policies I sampled, I have not found any affirming statements that the Modules supporting TLS or DTLS are safe from the Heartbleed bug. Customers are going to ask the Heartbleed question; why not be proactive in providing information?

If the security of your FIPS Crypto Module is not at risk to the Heartbleed vulnerability, then here are some sample statements that you are free to use (please modify as necessary) for inclusion in your FIPS 140-2 Security Policy:

The [Crypto_Module_Name] implements OpenSSL [1.0.1g] which properly handles Heartbeat Extension packets. This Module is not susceptible to the Heartbleed vulnerability.

The OpenSSL version implemented in the [Crypto_Module_Name] has been patched to properly handle Heartbeat Extension packets. This Module is not susceptible to the Heartbleed vulnerability.

The [Crypto_Module_Name] implements OpenSSL [1.0.1c] and has been compiled with the flag -DOPENSSL_NO_HEARTBEATS which properly handles the Heartbeat Extension packets. This Module is not susceptible to the Heartbleed vulnerability. 

The [Crypto_Module_Name] does not implement OpenSSL for TLS [or DTLS]. This Module is not susceptible to the Heartbleed vulnerability.

Please contact me if you have questions about the Heartbleed bug and FIPS 140-2.

Mark Minnoch is an Account Manager at InfoGard Laboratories.  

Shut the backdoor

If you have a FIPS 140-2 cryptographic module that implements the Dual EC DRBG from SP800-90A, then you may be fielding questions from your customers after they read articles like this one from the IEEE Spectrum:  Can You Trust NIST?

Please contact me if InfoGard performed your FIPS 140-2 validation.  I would be happy to help determine if your Dual EC DRBG function can be disabled in a new version of your crypto module without going through a lengthy revalidation effort.

Mark Minnoch
mminnoch@infogard.com 
805-783-0810

FIPS 140-2 Implementation Guidance updated

The CMVP published an update to the FIPS 140-2 Implementation Guidance (IG) on July 25, 2013.

Note:  You must read 9.10 if you have a software-only module. 

New Implementation Guidance:

• 3.5 Documentation Requirements for Cryptographic Module Services
• 9.9 Pair-Wise Consistency Self-Test When Generating a Key Pair
• 9.10 Power-Up Tests for Software Module Libraries
• D.11 References to the Support of Industry Protocols

Updated Implementation Guidance:

• D.8 Key Agreement Methods
  • Resolution section has been updated.
• D.9 Key Transport Methods
  • Resolution section has been updated.

SP 800-38F added to Annex D

NIST Special Publication 800-38F, Recommendation for Block Cipher Modes of Operation: Methods for Key Wrapping, has been added to Annex D:  Approved Key Establishment Techniques for FIPS PUB 140-2 on January 2, 2013.

FIPS 140-2 Implementation Guidance updated

The FIPS 140-2 Implementation Guidance document was updated on December 21, 2012.  (You may need to refresh your browser to pick up the recent update.)

Updated Implementation Guidance:

• G.5 Maintaining validation compliance of software or firmware cryptographic modules
  • Included reference to the impact to the generated key strength assurance when porting, and vendor Security Policy updates.
• G.13 Instructions for Validation Information Formatting
  • For all embodiments, the OE shall be specified on the validation entry.
• G.14 Validation of Transitioning Cryptographic Algorithms and Key Lengths
  • Addressed two-key Triple-DES requirements.
• D.8 Key Agreement Methods
  • IG updated to address SP 800-135rev1.

NIST SP 800-90 B Draft comments due December 5

Reminder to all:  Comments are due December 5, 2012 for the NIST SP 800-90 B DRAFT Recommendation for the Entropy Sources Used for Random Bit Generation.

We have carefully reviewed this document here at InfoGard and I know that NIST is very interested in receiving feedback from vendors.

At a minimum, review the document containing 5 questions NIST is asking about this Recommendation.

FIPS 140-2 Annex D updated

On December 20, 2011, Annex D was updated with the following change:

Key Establishment Techniques
Added: Recommendation for Key Derivation through Extraction-then-Expansion,
Special Publication 800-56C

Power-on self-test guidance

The CMVP intends to release new FIPS 140-2 Implementation Guidance clarifying the power-on self-test required for cryptographic algorithms whose outputs do not vary for a given set of inputs (e.g. RSA).

A Known Answer Test (KAT) will be required in the future for cryptographic modules that perform RSA sign and verify when the outputs of those operations are deterministic.

The Implementation Guidance will include a transition date.  After that transition date, new FIPS 140-2 validation submissions must implement a Known Answer Test (for a deterministic mode of RSA) as a power-on self-test.  A Pairwise Consistency Test will no longer be acceptable as a power-on self-test (for a deterministic mode of RSA).

The release date of the Implementation Guidance and the transition date are not yet available. 

FIPS 140-2 Implementation Guidance updated

The FIPS 140-2 Implementation Guidance was updated on July 15, 2011.  The NIST website shows the following changes:

New Implementation Guidance:

• 11.1 Mitigation of Other Attacks
• D.4 Requirements for Vendor Affirmation of NIST SP 800-56B
• D.5 Requirements for Vendor Affirmation of NIST SP 800-108
• D.6 Requirements for Vendor Affirmation of NIST SP 800-132
• D.7 Requirements for Vendor Affirmation of NIST SP 800-135

Updated Implementation Guidance:

• G.3 Partial Validations and Not Applicable Areas of FIPS 140-2
  • Modified in regard to new IG 11.1
• G.6 Modules with both a FIPS mode and a non-FIPS mode
  • Clarification that all implemented algorithms shall be referenced on the validation certificate.
• G.8 Revalidation Requirements
  • Added security policy requirements for revalidation Scenarios 1 and 4
• G.13 Instructions for Validation Information Formatting
  • Added examples for CVL and KTS
• 1.4 Binding of Cryptographic Algorithm Validation Certificates
  • Added examples of an operational environment change
• D.1 CAVP Requirements for Vendor Affirmation of NIST SP 800-56A
  • Modified the testing for primitives
• D.2 Acceptable Key Establishment Protocols
  • Modified the transition text and key agreement guidance

Second draft of SP 800-56C open for comments

Open for public comments:  SP 800-56 C - DRAFT (2nd Draft) Recommendation for Key Derivation through Extraction-then-Expansion

The comment period closes on August 11, 2011.

New drafts posted: SP 800-90 A and SP 800-57 Part 1

Two new FIPS Special Publication drafts were posted on the NIST website:

SP 800-90 A - DRAFT Recommendation for Random Number Generation Using Deterministic Random Bit Generators
Comments due August 1, 2011

AND

SP 800-57 Part 1 - DRAFT Recommendation for Key Management: Part 1: General
Comments due July 1, 2011

The NIST website has details for comment submissions.

Comments posted for SP 800-131 B and 800-131 C

The comments received for the following drafts have been posted:

Comments received on SP 800-131 B DRAFT Transitions: Validation of Transitioning Cryptographic Algorithm and Key Lengths

Comments received on SP 800-131 C DRAFT Transitions: Validating the Transition from FIPS 186-2 to FIPS 186-3


The draft SPs are available here.

Public meeting March 18 to discuss Federal transition to SHA-256

Re-posted summary from the Federal Register website:

The Civilian Agency Acquisition Council, and the Defense Acquisition Regulations Council are hosting the first of at least two public meetings to start a dialogue with industry and Government agencies about ways for the acquisition community to transition to Secure Hash Algorithm SHA-256. SHA-256 is a cryptographic hash function that is used in digital signatures and authentication protocols.

The meeting is March 18, 2011 from 9am-noon EDT.  Visit the Federal Register website for more details.

Draft available for FIPS 201-2 PIV

On March 8, NIST released the Draft FIPS 201-2, Personal Identity Verification of Federal Employees and Contractors.

Comments are due by June 6, 2011.

A workshop will be held April 18 and 19, 2011 at NIST in Gaithersburg, Maryland.  Remote attendance is available via webcast.  You must pre-register by April 11, 2011 to participate in the workshop.

The Draft FIPS 201-2 PIV document and workshop details are available at the NIST Draft Publications website.

FIPS 140-2 Implementation Guidance updated

The FIPS 140-2 Implementation Guidance was updated on March 3, 2011.  No new guidance is included in this update, but the following modified guidance may be of interest:

• A.2 Use of Non-NIST-Recommended Asymmetric Key Sizes and Elliptic Curves
• Updated for consistency with recent standards
• A.6 CAVP Requirements for Vendor Affirmation of FIPS 186-3 Digital Signature Standard
• Transition end date for FIPS 186-3 RSA is defined

Draft SP 800-147 BIOS Protection Guidelines

And another draft Special Publication is available:

SP 800-147 DRAFT Basic Input/Output System (BIOS) Protection Guidelines

Comments are due March 13, 2011.

Draft available for FIPS 180-4 (SHS)

NIST has been busy publishing drafts this month.  Now open for comments is:


FIPS 180-4 DRAFT Secure Hash Standard (SHS)

Comments are due May 12, 2011.

NIST draft SP 800-131 B & SP 800-131 C

NIST published the following draft SPs.  As expected, FIPS 140-2 Security Policies need to address algorithms and key lengths subject to transition requirements [details are in SP 800-131 A].  Comments to the draft Special Publications are due March 31, 2011.

SP 800-131 B
DRAFT Transitions: Validation of Transitioning Cryptographic Algorithm and Key Lengths

SP 800-131 C
DRAFT Transitions: Validating the Transition from FIPS 186-2 to FIPS 186-3


Stop by the InfoGard booth at the RSA Conference in San Francisco next week.  We would be happy to answer your questions.