OpenSSL and FIPS 140-2Please please read the User Guide. Nothing will make sense otherwise (it still may not afterwards, but at least you've a better chance).
FIPS What? Where Do I Start?Ok, so your company needs FIPS validated cryptography to land that big sale, and your product currently uses OpenSSL. You haven't worked up the motivation to wade through the entire User Guide and want the quick "executive summary". Here is a grossly oversimplified account:
The "Private Label" ValidationWe refer to validations based directly on the OpenSSL FIPS Object Module as "private label" validations. These are also sometimes referred to as "cookie cutter" validations. The usual reason for such separate validations is the need for small modifications which forces a complete new validation, but some vendors, for marketing or risk management reasons, have obtained private label validations for binaries produced from unmodified (or only cosmetically modified) source code.
The OSF would really prefer to work on open source based validations of benefit to the OpenSSL user community at large, but financial support for that objective is intermittent at best. On the other hand many vendors are interested in private label validations and the OSF will assist in such efforts on a paid basis. We've done enough of these to be very cost competitive, and for uncomplicated validations we typically work on a fixed price basis.
Current ValidationsThe most recent open source based validation is the OpenSSL FIPS Object Module v2.0, FIPS 140-2 certificate #1747. You will need the Security Policy and source at a minimum. Note that for this validation a new "secure installation" requirement has been imposed. And did we mention the User Guide?
Important Note: Due to changes in the FIPS 140-2 validation requirements the current v2.0 Module is no longer a suitable model for private label validations in its current form past the year 2014.
No new validations are currently planned. The I.G. 9.5 issue has effectively precluded consideration of new validations for much of 2013, but with the July 25 2013 update of the Implementation Guidance (I.G.) document such validations appear to be feasible again. We will be happy to discuss our current understanding of the risks with interested sponsors.
Performance at StartupWe have had many complaints about poor performance of the Power-On Self Test (POST) on low powered computers, as with some embedded devices. In the worst cases the POST can take several minutes. Such devices were not included as test platforms at the time the code was originally written.
The current FIPS validated code performs a very comprehensive set of mandatory algorithm self tests when it enter FIPS mode covering many algorithm combinations. There is a DSA parameter generation self test which is especially CPU intensive.
As a result of the POST performance issue we revisited the KAT (Known Answer Test) requirements in the POST process that were burning up most of those cycle. In consultation with a CMVP test lab we determined that it should be possible to substantially reduce that performance penalty in a new validation. Unfortunately such a change can only be undertaken in the context of a new validation, and not as a change letter modification.
Another factor affecting performance is the use (or not) of platform specific optimizations. The x86/x64 Windows and Linux code makes use of assembly language optimizations for FIPS cryptographic algorithms. The C only version is much slower and so the POST is slower too.