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.

Certificates and Queue Time Updates

At the end of the second quarter, we wrote about the CMVP being on a record pace for issuing FIPS 140-2 certificates in 2014.  Well, three quarters of the year have gone by now, and the CMVP remains on track.  One hundred ninety-one (191) FIPS 140-2 certificates have been issued during these 9 months of 2014. At the current pace, the projection for 2014 is 254 certificates (down from a projection of 262 in July).  We're still looking at the CMVP blowing by last year's mark of 208 certificates and the all-time record of 229 in 2010.

Here is the breakdown of certificates by the FIPS Laboratories for the first three quarters of 2014.

 

 

A quick update about the CMVP report queue:

  

InfoGard's current estimate for the CMVP queue time is 3-4 months (this is the time between report submission -- "Review Pending" -- to the time the Lab receives comments from the CMVP -- "Coordination").

Obviously I can't predict the future, but there is no indication that this current queue time will not be maintained.  It's a good sign for the remainder of the year and heading into 2015.  The CMVP was able to reduce the queue from 8-9 months last year to 3-4 months this year amid all of the algorithm transitions that took place, not an easy task. Next year should be a breeze comparatively.

 

What a Great 400 Weeks!

[Mark Minnoch posting one last time for The FIPS Lab blog]

I am so fortunate to have been part of the best Cryptographic Security Testing Laboratory these past 400 weeks (my InfoGard start date was January 2, 2007). I wanted to stay at least 500 weeks, but I ended up accepting an opportunity to join wolfSSL to help change the security world in a different way.

Yes, I will dearly miss my awesome co-workers and customers. The security world is a small place so I expect to keep in touch with many of you. Please send me a connection request on LinkedIn:

• www.linkedin.com/in/minnoch/

Marc Ireland, InfoGard's FIPS Program Manager, will be your new "FIPS Lab" blogger. Here I am passing InfoGard's "Top Tiger" Award to Marc for taking over the blog. Please let him know what topics you would like to see covered in The FIPS Lab blog!

Marc Ireland (Left) accepting the "Top Tiger" Award from Mark Minnoch

Mark Minnoch is now the new Account Manager at wolfSSL.

Marc Ireland is the FIPS Program Manager at InfoGard Laboratories and new author of The FIPS Lab blog.

FIPS 140-4 Draft Available

The CMVP posted a proposed draft of FIPS 140-4 today. This draft includes a warning statement that vendors are strongly advised not to design to requirements of draft FIPS 140-4 if they conflict with the requirements of FIPS 140-2.

(sigh)

Let's recap where we stand with FIPS 140-4:

1. No schedule. The Division Chief position at NIST has still not been "officially" filled. Expect no progress or schedule before the new Division Chief is announced.
2. No surprise. The FIPS 140-4 draft is an 11 page document that points to ISO/IEC 19790:2012. 
3. No overlap. If you are the proactive type, do not jump to the draft standard too early. Meeting a FIPS 140-4 requirement will not allow you a free pass on an annoying FIPS 140-2 requirement if they conflict.   

The Vendor and Lab communities need to become more active in driving FIPS 140-4. 

QUESTION: "How can I positively influence the adoption of FIPS 140-4?" 

ANSWER: Contact Charles Romine, the Director of the Information Technology Laboratory at NIST. In the FOREWORD section of the FIPS 140-4 draft, the Director welcomes all comments. (A physical address is provided in the draft but a quick search on nist.gov shows the following e-mail for Dr. Romine: charles.romine@nist.gov)

Make "FIPS 140-4 Feedback" the subject of your e-mail.

Here are some things to think about when crafting your feedback to the Director:

1. With the current 13 year-old FIPS 140-2 standard, will you be satisfied testing your future products to those aging requirements?
2. Can you make the world a better place for government agencies by designing your products to more relevant requirements?
3. Share your development lead times with the Director. Express how important it is for you to understand (and plan for) requirement changes.

My feedback e-mail has already been sent.

Mark Minnoch is an Account Manager at InfoGard Laboratories.  He covers FIPS 140-4 updates like TMZ covers a paparazzi-dodging star.

CMVP Could Set Record in 2014 for FIPS 140-2 Certificates

The CMVP is on a record pace for issuing FIPS 140-2 certificates in 2014.  One hundred thirty-one (131) FIPS 140-2 certificates have been issued during the first 6 months of 2014. At the current pace, the projection for 2014 is 262 certificates -- that would smash the 208 certificates issued in 2013 and crush CMVP's all-time record of 229 in 2010.

Here is the breakdown of certificates by the FIPS Laboratories for the first half of 2014. 

A few folks were on travel (or camera shy), but most of the InfoGard FIPS Team are pictured here.

Mark Minnoch is an Account Manager at InfoGard Laboratories. The InfoGard FIPS Team produces more FIPS certificates for our customers than any other lab.

Save $2000 on Your FIPS Project!

Congrats to all the new 2014 high school graduates. This is an exciting time in your life and I would like to share a bit of advice with you.

If your parents are involved in a FIPS 140-2 project at work, then be sure to tell them how they can save their company $2000 or more.

This tip is almost guaranteed to work its way back into an awesome graduation present for you!

The NIST Cost Recovery fees for FIPS 140-2 reports are increasing on August 1, 2014.

Security Level	Cost Recovery Fee (through July 31, 2014)	Cost Recovery Fee (starting Aug 1, 2014)	Increase
1	$2750	$4250	$1500
2	$3750	$5750	$2000
3	$5250	$8000	$2750
4	$7250	$11000	$3750

Also, beginning August 1, 2014, revalidation reports (3SUBs) will require a $2000 Cost Recovery fee (currently there is no Cost Recovery fee for 3SUBs).

Here is your take-away: complete your FIPS 140-2 testing in time to get your report submitted to the CMVP no later than July 31, 2014.

Mark Minnoch is an Account Manager at InfoGard Laboratories. Mark helps technology vendors save money and make money!

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. 

CMVP Queue Time is 4 to 5 Months

InfoGard's current estimate for the CMVP queue time is 4-5 months (this is the time between report submission -- "Review Pending" -- to the time the Lab receives comments from the CMVP -- "Coordination").  

InfoGard submitted 22 FIPS 140-2 reports in December 2013.  Half of those reports have made it through the CMVP queue as of today.

The CMVP "Shark Week" in March 2014 took a bite out of the queue, but reviews have stretched out a month since that push.   

Please contribute your comments to this post or contact me directly.

Contact info:

Mark Minnoch

InfoGard Laboratories

805-783-0810

mminnoch@infogard.com

If you are interested in FIPS 140-2 updates, then please connect with me on LinkedIn:  

• www.linkedin.com/pub/mark-minnoch/0/5a1/80b/

  
  

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.  

FIPS 140-3 is Dead

Let's all agree to stop referring to "FIPS 140-3" as the next revision of FIPS 140-2.

Instead, let's use "FIPS 140-4" to identify the follow-on standard that the United States Department of Commerce will eventually approve.

Here are the latest developments and my projections for FIPS 140-4:

• The Division Chief of NIST's Computer Security Division has moved into a new role. Matthew Scholl is now the Acting Division Chief.
• Since Matt Scholl is serving in an "Acting" role, expect no progress on FIPS 140-4 until the Division Chief role is officially filled. (NOTE: This is absolutely no dig on Matt -- he understands the FIPS 140 revision history very well and I imagine he is being asked to focus on other matters as Acting Division Chief)
• I suspect the new Division Chief will have someone in NIST put a bow on ISO/IEC 19790:2012 and present it as FIPS 140-4 to the Secretary of Commerce for signature.

With these developments and projections in mind, here is my guess at a FIPS 140-4 schedule:

Estimated Duration	Activity	Estimated Completion Date
3-6 months	Division Chief role filled at NIST; FIPS 140-4 presented to the Secretary of Commerce	Aug-Oct 2014
Up to 6 months	Secretary of Commerce signs FIPS 140-4	Feb-Apr 2015
6 months	FIPS 140-4 effective; FIPS 140-2 transition period begins	Aug-Oct 2015
6 months	FIPS 140-2 transition period ends	Feb-Apr 2016

The FIPS 140-2 transition period is expected to be a 6 month period where cryptographic modules may be tested to FIPS 140-2 requirements or FIPS 140-4 requirements.

Mark Minnoch is an Account Manager at InfoGard Laboratories.  His guesses at a FIPS 140-4 schedule and next year's Superbowl champ are always free.

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.

8 Important requirements for your FIPS 140-3 Survival Kit

Why 8? Because 8 is my favorite, positive, single-digit number.

(Also, some might say I am relying on my Magic 8 Ball for my FIPS 140-3 posts.)

This is the second post in my FIPS 140-3 Survival Kit series. As of this post, no formal announcement has been made on the replacement standard to FIPS 140-2.  Be sure to read the first post for proper context.

For Technology Vendors in the planning phase for future products, here are 8 important requirements that are likely to change from the current FIPS 140-2 requirements:

1. EMI/EMC testing - there are no EMI/EMC requirements in ISO 19790. Everyone is thrilled that this requirement got cut -- especially those vendors with short-shelf-life products.
   
2. EFP or EFT for Level 3 - This FIPS 140-2 Level 4 requirement has been pushed down to Level 3 in ISO 19790. (Note: Only EFP is allowed at Level 4 in ISO 19790)
   
3. Cryptographic integrity tests - For Level 2 and above, either an Approved keyed MAC based integrity check (Level 2) or an Approved digital signature based integrity test (Levels 2-4) is required. FIPS 140-2 allowed a non-cryptographic error detection code as a start-up integrity check for HW/FW modules.
   
4. Conditional tests for algorithms - known-answer tests (KATs) are not required for all of the Approved algorithms on power-up. A conditional test of an Approved algorithm is required prior to use of that algorithm. This will allow for faster module start-up times!
   
5. Degraded operation - ISO 19790 allows for a module to transition to a degraded operation if the mechanism or function causing the failure is isolated.
   
6. One role minimum - Only the Crypto Officer Role is required. Other roles may be defined as needed (User Role, Maintenance Role, ...).
   
7. Multi-factor authentication - If you are designing a Level 4 module, then you will need to employ multi-factor identity based authentication for access control.
   
8. Zeroisation gets stricter - At Levels 2 and 3, you can no longer overwrite an SSP (Sensitive Security Parameter) with another SSP. Temporary SSPs must be zeroised when no longer needed. At Level 4, even cryptographically protected SSPs must be zeroised. (Note: In ISO 19790, things get "zeroised" not "zeroized")

My next FIPS 140-3 Survival Kit post will take a look into SSPs.

Mark Minnoch is an Account Manager at InfoGard Laboratories.  His other favorite single-digit numbers are 0 (because zero is awesome) and -3 (that's right -- negative-three).

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.