FIPS Validated is More than a Check Box
If you belong to a U.S. Federal Government organization looking to purchase a cryptographic product to protect sensitive data, then you are probably aware that you need to buy a product that is FIPS 140-x validated (currently FIPS 140-1, or FIPS 140-2, and soon FIPS 140-3). The FIPS validation process is long and expensive for many vendors trying to tap the government security market, especially when trying to achieve higher levels of validation. Knowing that customers often treat the FIPS requirement as a check box some vendors have taken the path of least resistance to achieve certification.
Before you make the impulse buy after seeing the word “FIPS” on the product literature you should do some basic due diligence on the products that you are considering. Some FIPS validated products may not be suitable for the type of security you need or cannot operate in a FIPS approved mode in the environments that you have. Worse yet, I have seen products that contain FIPS validated modules that are atrocious implementations of security.
Here’s a quote from the actual standard, FIPS PUB 140-2 advising users to be vigilant: “While the security requirements specified in this standard are intended to maintain the security provided by a cryptographic module, conformance to this standard is not sufficient to ensure that a particular module is secure. The operator of a cryptographic module is responsible for ensuring that the security provided by a module is sufficient and acceptable to the owner of the information that is being protected and that any residual risk is acknowledged and accepted.”
Don’t fret over this. There are some simple checks you can do to cover the basics.
The first check isn’t optional. You must verify that the product really is FIPS validated or at least contains a FIPS validated module. Sometimes you will see the word “FIPS” used in statements like, “FIPS compliant”, or “implements FIPS approved algorithms”, but these statements don’t mean validated. Validated modules must have a certificate. If it is not stated clearly in the claim then ask the vendor for the certificate number and go and find it on the NIST Computer Security Division web site http://csrc.nist.gov/groups/STM/cmvp/validation.html.
Once you pass that gate the next easy step is to look at the overall validation level. There are 4 levels of validation that cover a wide range of security requirements. Here is a summary of some of the key differences:
• Level 1: The lowest level - provides basic assurance that algorithms are correct - no physical security or authentication requirements – can be software only
• Level 2: Adds physical security with tamper evidence – at least role based operator authentication
• Level 3: Stronger physical security with tamper detection and response for covers and doors - identity based operator authentication
• Level 4: Strongest physical security with tamper detection and response for the entire enclosure
Without getting into gritty detail you should know is that there is a big difference between level 1 and level 2. Typically, level 1 validations are just software modules. There is no requirement for physical security and no requirement for any operator authentication which means you need to be very careful about where and how you deploy it. You need to have additional security controls in place that the level 1 module does not provide. On the other hand, level 2 includes physical protection and operator authentication and therefore can be used in higher risk environments.
Here’s an example with USB encrypted flash drives. Stealth MXP is FIPS 140-2 level 2 validated. Being a self-contained hardware module with built in user authentication you can use it anywhere knowing that a software attack is not going to compromise it. If instead you use a plain flash drive with level 1 validated software encryption, that software is exposed to whatever malicious code might be on the machine. Stealth MXP can be used in riskier, untrustworthy environments than the level 1 module with much more security for your data.
From here on, the checks get more complicated. Every validated module has a security policy published that tells you about the module and how it should be deployed to be in FIPS approved mode (if you are a die-hard, check out our security policy for Stealth MXP: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2007.htm#748). Security policies can tell you a lot about the implementation of a module, sometimes with surprising revelations.
Here’s an example that is pretty twisted. I came across a security policy for a level 1 module (that shall not be named) which consists of Microsoft Enhanced CSP (already validated – certificate #238) and another dll. This other dll contains a proprietary crypto algorithm. The only validated algorithms in this validated module are ones contained within the Microsoft component while the proprietary algorithm is not approved. So this module adds no apparent value for the government considering the Microsoft CSP is already present on your system. This was one of those “path of least resistance” implementations I was referring to earlier.
What is rather disturbing is that this module is included in another product and no one is likely aware that a non-approved algorithm is being used. Things get difficult is when products only contain a validated module but are not validated themselves. Since the product itself is not validated there is no public document like the Security Policy that clearly states what you need to know. It is up to you to do a considerable amount of due diligence to ensure that:
a) the product is utilizing the module correctly
b) the product is actually meeting the customer’s security requirements
So when you are in the market to buy a FIPS validated solution it is wise to do more than looking for “FIPS” as a check box item. The security of your information is at stake.
Here’s a good FAQ if you want to learn more: http://csrc.nist.gov/groups/STM/cmvp/faqs.html.
You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.
January 8th, 2010 at 6:22 pm
[...] The best place for the authentication to occur in such a device is within the hardware. Of course the more secure the hardware the better. Some people are suggesting that the FIPS certification is meaningless given that the recent security flaw is associated with FIPS validated devices. There is nothing wrong with the FIPS process but it must be understood that it only deals with what happens inside the cryptographic boundary and there is much more to consider when looking at overall security (see this blog entry for some more insight http://www.mxisecurity.com/blog/cto/2008/07/14/fips-validated-is-more-than-a-check-box/). [...]