PTTP Systems

If you use a computer today to buy anything over the internet then you are the end user of cryptographic algorithms. If you feel that you don't need to worry about the implementation of your cryptography, well, you are probably right. You may have read the news about how the MD5 cryptographic hash function is not as secure (collision resistant) as we used to think. Weaknesses in the SHA1 cryptographic hash function have also been found although SHA1 has fared somewhat better than MD5. That news causes people like me enough concern to track the progress of those attacks but so far there is no public indication that a disaster is at hand.

Nevertheless, as an individual you probably don't keep any secrets so valuable that you have to protect against someone attacking your cryptographically protected data or communications using the techniques that have been discovered. That is way too much work for what can be stolen, especially when it is far easier to pwn your machine and monitor your keystrokes or to steal your data from a vendor on the internet (but that is a different topic altogether).

Note: I'm not saying that your identity or credit card are not valuable, just that they are not valuable enough to be stolen by breaking cryptography.

In any case, I am not writing this article to go on about the details of cryptographic algorithms but rather to talk about Federal Information Processing Standard 140, what it is, who should care, and why.

Weakness shmeakness! It is still hard to break the crypto! Who Cares?

If you have valuable secrets protected by cryptography then you will care about FIPS 140. Corporations and governments (especially the military), as well as some financial and health-care institutions (to name a few) have information that is valuable enough to protect cryptographically. The information is also valuable enough for others to work very hard to steal it.

Stated succinctly:

FIPS 140 defines cryptographic library behaviors intended to ensure that the library does not have trivial weaknesses. The current version of the standard is FIPS 140-2 but FIPS 140-3 is in review as of the writing of this article.

If you are creating a cryptographic library then you already know all about FIPS 140. If you are creating a cryptographic library and DO NOT know about FIPS 140 then stop what you are doing and go read the specifications. From front to back. Five times. Yes, it can be cryptic (pun intended) but it outlines how you need to structure your library so that it is safe enough from malicious behavior for others to use with confidence. Better yet, hire someone who has already navigated the FIPS validation reefs.

If you are not creating a cryptographic library but need to use one then your requirements are significantly lighter but you probably do have some work ahead of you. This article is for you.

Why would I need to spend the effort to use a FIPS validated library?

Government and military buyers are required to (preferentially) procure products and systems that meet various standards, some of which you may have run across. Examples include Common Criteria, Section 508, and yes, FIPS 140.

So, if you want to target your product for the above listed markets then you need to navigate the alphabet sea. Unfortunately, the process of adopting FIPS 140 validated libraries can be a bit like landing an airplane in San Francisco fog using instrument flight rules and working with an air traffic controller who does not speak your language natively. My goal is to provide you with some important radar beacons.

I'm using a FIPS 140-2 validated library! Everything is peachy!

No, it is not. Many people have (and likely cannot be disabused of) the misconception that simply using cryptography makes everything ok. Here is a counter example: having strong locks on your doors is great but is it ok to hang a key on each door knob so you can get in? No. As product developers we face that exact problem with cryptographic libraries.

Here is another analogy (yes, I like analogies). Using a FIPS 140 validated library is like using strong bricks and wood to build your house. On the other hand, if you don't use good mortar and nails then the house can still fall down. Software developers must provide and use the right cryptographic mortar and nails when we adopt these libraries.

Well, then what do I have to do to use my FIPS 140-2 validated library correctly?

Well, possibly a lot. Maybe too much for the intended length of this article. Here is a list of the things you need to do at a minimum. You should also plan to implement these features as early in your product development cycle as possible. Just like software flaws, it will cost more to fix the longer you wait.

• Choose a FIPS validated cryptographic library guided by your business and development requirements.

• Don't run your product in a non-FIPS mode (if you can avoid it). Your QA will kiss you.

• Only use FIPS allowed ciphers. That means RSA, DSA, AES, 3key Triple DES, SHA1, SHA1HMAC, PRNG (pseudo random number generator). If you start with these you can find what breaks before adopting the actual FIPS 140 validated library and FIPS mode.

• Protect your secret keys. That means symmetric keys and asymmetric keys, as well as your SSL communications certificates. By protect I mean keep them encrypted/obfuscated and zeroize their memory footprints. Secret keys can be encrypted for persistent storage but then the passphrases must be protected. You should probably plan for at least the option of user-attended startup of you product for passphrase entry [some buyers can be very hard core]. It is turtles all the way down until you can make someone else responsible for protecting the secret. :)

• SHA1 will be unacceptable in FIPS 140-3, or so I hear. Do yourself a favor and go with one of the SHA2 algorithms for hashing mechanisms, like SHA512.

• When you load the cryptographic library ensure you initiate the library "Power On Self Test" and report the result in a tamper proof way (see Common Criteria). [During the POST the library checks itself for tampering.]

• Use only the algorithms/functions inside the validated library. If you need to "obfuscate" data then you can probably define that operation as outside of your cryptographic boundary, but if you use FIPS 140 approved ciphers then you will be better off.

• Use only Transport Layer Security (TLS) 1.0 and only the FIPS approved ciphers for authentication and communication. That means RSA, DSS, AES, Triple DES, SHA1. I have never gotten a straight answer as to why Diffie-Hellman key exchange is not an approved algorithm but is allowed for SSL. It is, so don't worry.

• Secure Sockets Layer (SSL) 3.0 is not allowed, and no one should be using SSL 2.0 today. Yes, this will break the default install of Internet Explorer 6. Just go reconfigure it. Better yet, use a more modern browser.

Are there any gotchas? You haven't mentioned any!

SSL seems to be a bit of a no-mans land that needs attention from the industry/community. You can, for example, limit SSL to use FIPS allowed ciphers. However, it turns out that X.509 certificates by default protect the private key using a symmetric encryption algorithm for which the key is derived using a Password Based Key Derivation Function (PBKDF). The PBKDF can rely on ciphers that are either not allowed in FIPS 140-2 (MD5) or will be disallowed by FIPS 140-3 (SHA1). If we are not careful FIPS 140-3 may break interoperability of SSL certificates through the PBKDF process.

Final Thoughts

This article is in no way a comprehensive guide to proper adoption of FIPS 140-2 validated cryptographic libraries. My intention is to clarify some of the mystical issues that can be difficult to enterpret and provide pointers to the problems you may encounter. I do hope, however, that it helps shine some light that benefits your journey down this road.

References

Commercial and Open Source alternatives for FIPS validated cryptographic libraries can be found here.

You can find PKCS standards information on Wikipedia but RSA Labs has the documents you want. The links to the specific sections ares cryptic (server generated) and might change, so I suggest that you Google the specification that you want then choose the link into RSA's site. :) For example, http://lmgtfy.com/?q=PKCS%235

For information about the Cryptographic Module Validation Program see http://csrc.nist.gov/groups/STM/cmvp/

Sotirov, Alexander; Marc Stevens, Jacob Appelbaum, Arjen Lenstra, David Molnar, Dag Arne Osvik, Benne de Weger (2008-12-30). "MD5 considered harmful today". http://www.win.tue.nl/hashclash/rogue-ca/. Retrieved 2008-12-30.  Announced at the 25th Chaos Communication Congress.