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.
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.
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.
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, 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.
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.
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.
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.