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.  

Build your own FIPS 140-3 survival kit

"When is FIPS 140-3 coming out?"

This is probably the question I am asked most often. It's my own fault for trying to provide my best guesses at a FIPS 140-3 schedule.

Even though my predictions have not panned out as expected, that won't deter me from attempting to be helpful.

Since the last NIST activity was to replace dates with "TBDs" on the official FIPS 140-3 schedule, my recommendation to stay ahead of the FIPS 140-3 curve is to begin building your own FIPS 140-3 Survival Kit. The first items to place in the kit are the following ISO documents:

• ISO/IEC 19790 Security requirements for cryptographic modules
• ISO/IEC 24759 Test requirements for cryptographic modules

ISO 19790 may be what NIST selects as the replacement standard for FIPS 140-2.  

ISO 24759 is the "DTR" (with all the ASxx.xx, VExx.xx.xx, and TExx.xx.xx statements as you know and love them).

Even though I've been through several California earthquakes, I am not able to predict when they will occur. I do know that I need to prepare for the next one. 

I am not certain that these ISO documents will be adopted by NIST, but it is a good idea to prepare. 

In earthquakes and FIPS, it's best to have a survival kit ready and not need it.

(Go to the next post in the FIPS 140-3 Survival Kit series)

Mark Minnoch is an Account Manager at InfoGard Laboratories.  During the 1989 Loma Prieta earthquake, he was in Santa Clara... under his desk.

FIPS and sharks

The CMVP recently emerged from "Shark Week" with all limbs attached. In fact, the results of "Shark Week" are even better than fresh fish tacos with guacamole at the beach!

The CMVP probably has a different interpretation of "Shark Week" than I do, but I don't want to interrupt any of the Reviewers to ask them for a definition (they've been busy).

At the beginning of 2014, the CMVP was faced with an enormous backlog of FIPS 140-2 reports to review -- more than 150 reports were waiting for Reviewers to complete their initial pass. When I saw this report backlog, I feared that we might start seeing CMVP review times of 1 year or more. "Shark Week" was CMVP's strategy to attack the report queue.

No mercy.
No phone calls.
No meetings.

They became sharks. Reports were their prey.

How did they do?

Much better than the seals swimming in open waters. The March 10, 2014 Modules in Process report shows only 70 reports are in the "Review Pending" or "In Review" columns --  that's more than a 50% reduction in review backlog.

There's still work to do -- the report also shows 112 reports in the "Coordination" column. The "Coordination" phase indicates that the CMVP has completed their initial review and clarifying questions have been sent to the testing laboratory. This is the highest I've seen the Coordination value. The Vendor, Laboratory, and CMVP Reviewers all share responsibility in moving the report out of the "Coordination" phase so the certificate process can begin.

Will we see 3-4 month review times again this year? It could happen (and I would have never believed it in January).

Next week is InfoGard's "Shark Week."  We have some report comments to attack!

Mark Minnoch is an Account Manager at InfoGard Laboratories.  He was chased to shore once while surfing after seeing a shark fin that actually belonged to a dolphin.