110 captures 12 Jun 2010 - 26 Jan 2018
About this capture
Collection: The WebBase Archive
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:
- 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).
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 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 are now offering a cost effective turnkey validation package for routine private label validations.
Current ValidationsThe most recent open source based validation is 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 upcoming changes in the FIPS 140-2 validation requirements the current v1.2 Module will 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.
We hope to address these new changes in the next open source based validation (see below).
We now have sufficient sponsorship for a new validation and that effort is currently underway. More details can be found on our separate FIPS 140-2 Validation page.
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.