Is FIPS 140-2 Fatally Flawed?

- January 13th, 2010

 

So, upon my return to the Valley of the Sun and after figuring out where our new offices (let alone the coffee machine and bathrooms) were (Lumension has moved, in case you’ve not heard – 3rd floor with a seriously sweet view), I settled down to see what happened over the holidays. First up – the German security consultancy SySS published a method by which certain USB flash drives with “built in” FIPS 140-2 certified encryption are vulnerable to attack. Gosh, that’s not good news. After all, FIPS 140-2 is the standard by which cryptographic modules are measured. What happened? Does this mean that FIPS 140-2 is fatally flawed?

First, a little detail on what the good folks at SySS discovered. Basically, they were able to get access to the encrypted data without the password. It seems that the hardware-based encryption scheme used by SanDisk (and Kingston & Verbatim, which seem to use SanDisk technology) was designed to authorize access on the PC which the USB flash drive was attached. However, during this procedure it will, irrespective of the password, always send the same 32-byte key to the drive – and this is the case for all USB flash drives of this type, and does not change when the password is changed or the drive reformatted. In fact, SySS write in their reports that “[i]f an appropriate software tool was available on the Internet, even technically inexperienced attackers could pose a security risk when getting hold of such a tool.” For more details, see this (warning: German PDF).

Now, this seemingly obvious flaw has caused several observers to question the value of FIPS 140-2 validation; as Jürgen Schmitt at The H Security put it: how could USB flash drives that exhibit such a serious security hole be given one of the highest certificates for crypto devices? Even more importantly, perhaps – what is the value of a certification that fails to detect such holes? Before looking into this question, let’s step back a bit to understand what FIPS 140-2 is and how the validation process works.

The Federal Information Processing Standards (FIPS) 140-2 validation specifies security requirements necessary for a cryptographic module to be used within government security systems protecting sensitive, but unclassified, information. This standard is a US and Canadian government certification, administered by the National Institute of Standards and Technology (NIST), and is a prerequisite for many agencies purchasing cryptographic software, as well as a globally respected standard.

There are four different security levels, ranging from the basic level 1 to the most stringent level 4. [For a more in-depth discussion on the various levels of FIPS 140-2, see Table 1: Summary of security requirements on page 12 of the standard, which can be found here.] Level 2 is as high as software modules can go, and is not overly common; only hardware modules can be submitted for levels 3 and 4. The testing process involves both an Algorithm validation (to test each algorithm implementation individually) and then a Module validation to test the whole thing as a package. As with most things governmental, the process for final validation is long and expensive.

Now, this is where things get nuanced. These modules are only tested for, and NIST only certifies, what happens within the “cryptographic boundary” (i.e., where the cryptographic functions reside). Certifications can be granted to software- and hardware-based modules, or so-called hybrid modules, based on these tests – but what is within the cryptographic boundary is defined by the vendor. And, in this case, the certification clearly did not include a crucial software component that shipped with final product.

This is the gist of NIST’s position, as reported in Computerworld, “From our initial analysis, it appears that the software authorizing decryption, rather than the cryptographic module certified by NIST, is the source of this vulnerability … Nevertheless, we are actively investigating whether any changes in the NIST certification process should be made in light of this issue.” So you can see how, contrary to the claims of some, hardware encryption is not necessarily more secure than software encryption – they still need software somewhere. Thus, it’s incumbent on you to investigate and understand what you’re buying.

So, bottom line: while this discovery seems to suggest an area to which NIST might want to bring some clarity and rigor, it does not mean that FIPS 140-2 is fatally flawed. It’s up to you, as the buyer, to understand what (potentially critical) functions occur inside & outside the cryptographic boundary, and how that might impact the security of the device in your case. And since what you’re looking for is what’s not certified, it might be useful to have an expert review the vendor security policy (posted with the certification on the NIST website) to help you understand the nuances.

Oh, and remember … none of this means much if you don’t use the device in “FIPS mode.”

Anyhow, Happy New Year everyone … looks like this one has started off with a bang!


About the Author

, Director, Solutions Marketing for Lumension, specializes in Data Protection, Intelligent Whitelisting and Endpoint Security. Merritt brings strong product and security market knowledge and is responsible for marketing strategy, core messaging and product positioning for all Lumension solutions.





Comments

One Response to “Is FIPS 140-2 Fatally Flawed?”

  1. Peter Hillier says:

    Why would you think the FIPS 140-2 standard is flawed, when it was the software that was exploited not the crypto module?

Leave a Reply


IT Secured. Success Optimized.™

Contact Lumension | Privacy Policy

Comments


Share

blog.lumension.com