OpenSSL and FIPS 140-2

Please 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:

OpenSSL itself is not validated, and never will be. Instead a special carefully defined software component called the OpenSSL FIPS Object Module has been created. This Module was designed for compatibility with OpenSSL so that products using the OpenSSL API can be converted to use validated cryptography with minimal effort.
The OpenSSL FIPS Object Module validation is unique among all FIPS 140-2 validations in that the product is "delivered" in source code form, meaning that if you can use it exactly as is and can build it (according to the very specific documented instructions) for your platform, then you can use it as validated cryptography on a "vendor affirmed" basis.
If even the tiniest source code or build process changes are required for your intended application, you cannot use the open source based validated module directly. You must obtain your own validation. This situation is common; see "Private Label" validation, below.
New FIPS 140-2 validations (of any type) are slow (6-12 months is typical), expensive (US$50,000 is probably typical for an uncomplicated validation), and unpredictable (completion dates are not only uncertain when first beginning a validation, but remain so during the process).

Note that FIPS 140-2 validation is a complicated topic that the above summary does not adequately address. You have been warned!

The "Private Label" Validation

We 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 will work on a fixed price basis. A routine private label validation on a single commodity platform can cost as little as US$35,000. Contact the OSF for more information.

Update: In collaboration with an accredited CMVP testing laboratory we were through December 2012 offering a cost effective turnkey validation package for routine private label validations. However, due to some changes in CMVP requirements introduced in 2013 the current OpenSSL FIPS Object Module code base can no longer be readily be validated. We are still adding new platforms to the #1747 validation.

Current Validations

The 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 v1.2 Module is no longer be a suitable model for private label validations in its current form past the year 2010. See the NIST Notices, discussion paper and SP 800-131.

Upcoming Validations

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.

Technical Notes

Performance at Startup

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