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.

Record number of FIPS 140-2 certificates issued in 2014

In 2014, The CMVP validated the most FIPS 140-2 cryptographic modules in a given year in the history of the program. 233 new FIPS certificates were issued last year, which surpassed the previous high of 229 in 2010.

Here are the totals by Laboratory for 2014:



Congratulations to the FIPS Team at InfoGard Laboratories.  That's 6 years in a row of producing the most FIPS 140-2 certificates (2009-2014).

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.

Maintaining a FIPS 140-2 Certificate

I often receive questions about maintaining a FIPS 140-2 certificate after changes are made to the module. Here is some information from the trenches for those not familiar with the process.

There are 5 different scenarios when making changes to a cryptographic module. I'll cover the 3 most common. Additional details are found in the FIPS 140-2 Implementation Guidance document, G.8.  

1SUB - Modifications are made to hardware, software or firmware components that do not affect any FIPS 140-2 security relevant items. The vendor is responsible for providing the applicable documentation to the CST laboratory, which identifies the modification(s).

[Mark Minnoch] A "1SUB" (say "one-sub") is a "maintenance" or "bug-fix" activity for the Lab. As an example, let's consider the case of a vendor making source code changes only. The Lab reviews the source code to determine if any of the changes are security relevant. If the Lab confirms the changes are not security relevant, then a letter request is submitted to the CMVP to include the updated firmware (or software) version on the existing FIPS certificate. Note: A NIST fee is not required.

There are two (relatively new) alternative scenarios for 1SUBs.  Alternative Scenario 1A allows for rebranding of an already validated OEM module. Alternative Scenario 1B allows a different Lab than the original testing Lab to review the non-security relevant changes to the module. Note: A NIST fee is applicable for Alternative Scenarios 1A and 1B.

3SUB - Modifications are made to hardware, software or firmware components that affect some of the FIPS 140-2 security relevant items. An updated cryptographic module can be considered in this scenario if it is similar to the original module with only minor changes in the security policy and FSM, and less than 30% of the module's security relevant features.

[Mark Minnoch]  For a "3SUB" change, the Laboratory updates the previous report submission to include the changes and also to confirm that the required regression testing was completed. This testing is more involved than a 1SUB but typically less effort than a new validation. The Lab considers service changes, algorithm changes, hardware changes, etc. in determining the 30% threshold limit for security relevant changes. Note: A NIST fee is not required for a 3SUB submitted before August 1, 2014. A $2000 NIST fee is applicable for a 3SUB submitted on or after August 1, 2014.

5SUB - If modifications are made to hardware, software, or firmware components that do not meet the above criteria, then the cryptographic module will be considered a new module and must undergo a full validation testing by a CST laboratory.

[Mark Minnoch]  A "5SUB" is commonly referred to as a "validation" or "full validation." The Laboratory submits a full validation test report package after completing all of the testing tasks. Note: A NIST fee is applicable.

Mark Minnoch is an Account Manager at InfoGard Laboratories. He is happy to help with your questions about maintaining your FIPS certificate. 

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.  

OpenSSL Heartbleed Bug and FIPS

(Image from heartbleed.com)

The Q&A section at Heartbleed.com states that "OpenSSL Federal Information Processing Standard (FIPS) mode has no effect on the vulnerable heartbeat functionality."

Although the OpenSSL FIPS module does not mitigate the heartbeat vulnerability, it is also important to note that the vulnerability exists outside of the OpenSSL FIPS cryptographic module boundary.

The vulnerability affects TLS implementations in certain OpenSSL libraries.

"The OpenSSL FIPS module is completely unaffected by the heartbeat vulnerability (CVE-2014-0160)," confirms Steve Marquess, Founding Partner at OpenSSL Software Foundation, Inc. 

The OpenSSL FIPS Object Module achieved FIPS 140-2 Certificate #1747 in 2012 (the certificate is maintained frequently by OpenSSL Software Foundation, Inc.)

Mark Minnoch is an Account Manager at InfoGard Laboratories.  The InfoGard FIPS Team performed the OpenSSL FIPS Object Module FIPS 140-2 validation for OpenSSL Software Foundation.

How to include additional operating environments in your Security Policy

© Mats Tooming | Dreamstime Stock Photos

Let's assume that you have met the porting requirements for listing additional operating environments in your FIPS 140-2 Security Policy. (As a reminder, those requirements are detailed in the FIPS 140-2 Implementation Guidance "G.5 Maintaining validation compliance of software or firmware cryptographic modules")

Now, you would like to include the proper wording in your Security Policy. You may use the statements below (in bold type) to add operating environments supported by your module but not included in the FIPS validation testing process:

As allowed by FIPS 140-2 Implementation Guidance G.5, the validation status of the Cryptographic Module is maintained when operated in the following additional operating environments:  [operating environment 1],  [operating environment 2], …

The CMVP makes no statement as to the correct operation of the module or the security strengths of the generated keys when the specific operational environment is not listed on the validation certificate.

Note 1: Don't skip on the last statement -- it's a requirement.

Note 2: The additional operating environments that meet the porting requirements are not listed on the validation certificate posted on the NIST FIPS Validated Modules website.  They will only appear in your Security Policy document that is available from that website.

Please leave a comment or contact me if you have questions.

Mark Minnoch is an Account Manager at InfoGard Laboratories.  

Alternate website for FIPS 140-2 certificate information

Don't let the NIST shutdown keep you from accessing details of the FIPS 140-2 validated cryptographic modules.  The folks at Cryptsoft maintain a copy of the information that is publicly available from NIST (well, available during non-furlough days):  http://www.cryptsoft.com/fips140/

The information is current (last update was September 30, 2013).

FIPS 140-2 report queue

Let's take a look at the numbers for the FIPS 140-2 Modules in Process list on the NIST website (Nov 13, 2012 update).

The "Review Pending" column shows 95 FIPS 140-2 reports have been submitted to the CMVP but Reviewers have not yet been assigned.  As you might have guessed, this is a large number of reports waiting to be reviewed (this number has increased over the year).  The CMVP is responsible for moving reports to the next phase of "In Review."

The "In Review" column indicates that 17 reports have been assigned to Reviewers.  My guess is that each Reviewer has between 4-6 reports in various stages of the review process (typically, 2 Reviewers are assigned to each report).  The CMVP is responsible for moving reports to the "Coordination" phase.

The 52 reports in the "Coordination" phase means that the CMVP has completed their initial review and clarifying questions have been sent to the testing laboratory.  This is a very high number of reports for the CMVP to manage and it has a direct impact on the queue time.  Again using my guessing skills, I estimate that each Reviewer maintains 12-18 reports in the "Coordination" phase.  The Vendor, Laboratory, and CMVP Reviewers all share responsibility in moving the report to the "Finalization" phase.

The 9 reports in the "Finalization" phase are near the finish line.  The Reviewers' comments have been satisfied and the CMVP is completing administrative tasks prior to posting the validation certificate on the NIST website.

Because of the heavy volume and recent report activity, InfoGard increased our current estimate for the CMVP queue time to 6-7 months (this is the time between report submission -- "Review Pending" -- to the time the lab receives comments from the CMVP -- "Coordination").

Circling back to the first column, the "IUT" or "Implementation Under Test" number of 112 indicates to the CMVP that at least 112 modules are in the testing process currently.  The responsibility to move a module into the "Review Pending" phase is with the Vendor and Laboratory.  A report submission to the CMVP is the trigger to move the module into the "Review Pending" phase.

The FIPS 140-2 Modules in Process list is updated weekly by NIST.

CMVP review times currently in the 4-6 month range

InfoGard's Quality Manager informed me that CMVP review times have slipped to the 4 to 6 month range for FIPS reports this summer.  We believe the reasons for the summer slow-down are due to CMVP vacations, new Implementation Guidance, and a surge in report submissions by Labs in the spring.

When selecting a FIPS Laboratory for your next FIPS project, make sure to ask about the Lab's report review process prior to submission.  InfoGard has a deliberate review process involving an independent technical review by a FIPS Security Engineer, a Quality review, a Signatory review, and then a final quick Quality check at the end.  This is our secret sauce for delivering high-quality reports to the CMVP.  Clear, consistent, and compliant reports are easily reviewed by the CMVP allowing you to reach your product sales goals sooner.

FIPS 140-2 Implementation Guidance updated (again)

The CMVP has been busy updating the FIPS 140-2 Implementation Guidance.  If you delayed reviewing the April update, then delay no further.  The May update deserves your attention.

See the May 2, 2012 document and changes here:  http://csrc.nist.gov/groups/STM/cmvp/announcements.html

Note:  You may need to clear your browser's cache to open the latest IG document.

FIPS 140-2 revalidation terms to know: 1SUB, 3SUB, 5SUB

I received a question recently about maintaining a FIPS 140-2 certificate after changes are made to the module.  Here is some background for those not familiar with the process.

There are 5 different scenarios when making changes to a cryptographic module.  I'll cover the 3 most common.  Additional details are found in the FIPS 140-2 Implementation Guidance document, G.8.  

1SUB - Modifications are made to hardware, software or firmware components that do not affect any FIPS 140-1 or FIPS 140-2 security relevant items. The vendor is responsible for providing the applicable documentation to the CST laboratory, which identifies the modification(s).

[Mark Minnoch]  A "1SUB" (say "one-sub") is a "maintenance" or "bug-fix" activity for the Lab.  As an example let's consider the case of a vendor making source code only changes.  The Lab reviews the source code changes to determine if any of the changes were security relevant.  If the Lab agrees with the vendor that the changes are not security relevant, then a letter request is submitted to the CMVP to include the updated firmware (or software) version on the existing FIPS certificate.  

3SUB - Modifications are made to hardware, software or firmware components that affect some of the FIPS 140-2 security relevant items. An updated cryptographic module can be considered in this scenario if it is similar to the original module with only minor changes in the security policy and FSM, and less than 30% of the modules security relevant features.

[Mark Minnoch]  A "3SUB" change is commonly referred to as a "revalidation".  The Laboratory updates the previous report submission to include changes and also to confirm that the required regression testing was completed.  This is more involved than a 1SUB but typically less effort than a new validation.  The Lab considers service changes, algorithm changes, hardware changes, etc. when determining if the 30% threshold for security relevant changes is exceeded.

5SUB - If modifications are made to hardware, software, or firmware components that do not meet the above criteria, then the cryptographic module will be considered a new module and must undergo a full validation testing by a CST laboratory.

[Mark Minnoch]  A "5SUB" is commonly referred to as a "validation".  The Laboratory submits a full validation test report package and the appropriate NIST fee applies.