Open Source Software Institute

OpenSSL FIPS 140-2 FAQ

Last updated November 16, 2007

Additional questions or comments are welcomed at: questions@oss-institute.org .

1) What is FIPS 140?
2) FIPS 140-2 validation is expensive. Who is sponsoring these validation efforts?
3) What exactly is being validated? The OpenSSL Crypto modules? The whole program? CA software that uses OpenSSL?
4) Is the pending validation for 140-1 or 140-2?
5) What version of OpenSSL is undergoing FIPS 140-2 validation? 0.9.7b?
6) What algorithms are included in the FIPS 140-2 validation?
7) What documentation should I be reading?
8) Won't an application that uses FIPS 140-2 validated OpenSSL libraries for all cryptography still require a separate FIPS 140-2 validation?
9) Is the FIPS validation tied to a specific operating system or to a CPU
processor?
10) What platforms have been FIPS validated?
11) What is the Security Policy?
12) No way NIST/CSE would ever validate source code!!
13) Since OpenSSL is providing source code what's to prevent a user modifying the crypto code and regenerating the checksum?
14) Once I have the FIPS crypto built, how do I use OpenSSL so that all SSL crypto work is done using that FIPS crypto?
15) Is optimized assembly code part of the FIPS module?
16) How is the library validated?
17) How do I build a FIPS validated application?
18) Have you also included the Known Answer Tests (KATs)?
19) Are both the static libraries and dynamic libraries to be validated?
20) What is the strategy for introducing bug fixes into the FIPS OpenSSL?
21) Are you focused on end user use? CA use?
22) For compliance with FIPS 140-1/2, is it OK to just validate a hardware module that is used?
23) What other open source software has been validated, or is considering validation?
24) What would it take to have additional hardware platforms validated?
25) Would the costs / validation differ for AMD vs. Intel or are they both considered the same from the FIPS validation perspective?
26) What would the costs would be to have system XXX with the operating system YYY FIPS140-2 evaluated for OpenSSL?

1) What is FIPS 140?
The US National Institute of Standards and Technology (NIST) publishes the FIPS (Federal Information Processing Standard) series of standards. FIPS 140-1 and FIPS 140-2 are both technical standards and worldwide de-facto standards for the implementation of cryptographic modules. FIPS 140-2 supersedes the prior FIPS 140-1. FIPS 140 is a hardware standard that preceded FIPS 140-1. FIPS 140-2 is a technical standard. The Cryptographic Module Validation Program (CMVP) is a process (Lab accreditation, Derived Test Requirements, Implementation Guidance, etc.) encompassing validation testing for cryptographic module (FIPS 140-2) and cryptographic algorithm (FIPS 46-3, FIPS 180-1, FIPS 186-2, FIPS 197, etc.) implementations. The CMVP is a joint program between the US and Canada used by NIST (USA) and CSE (Canada). US Federal users may still use, retain, and deploy modules validated to FIPS 140-1. The FIPS 140-1 and FIPS 140-2 standards can be found at http://csrc.nist.gov/cryptval/ . Products that have received a NIST/CSE validation are listed on the Cryptographic Module Validation List at http://csrc.nist.gov/cryptval/140-1/1401val.htm. FIPS 140-2 is primarily of interest to U.S., Canadian, and UK government agencies which have formal policies requiring use of FIPS 140 validated cryptographic software. The availability of open source FIPS 140-2 validated cryptography will lower the cost and increase the availability of cryptographic applications for those governments. Usually cryptographic algorithm implementations, not complete applications or products, are FIPS -140-2 validated. Separate algorithm-specific validations of FIPS Approved algorithms are a pre-requisite to the FIPS 140-2 validation of the module in which they reside.

2) FIPS 140-2 validation is expensive. Who is sponsoring these validation efforts?
The FIPS 140-2 validation of the OpenSSL FIPS Object Module v1.1.1 was jointly sponsored by the HP Corporation (http://www.hp.com) and the Defense Medical Logistics Standard Support (DMLSS) program of the DoD Military Health System (http://www.tricare.osd.mil/dmlss/), in collaboration with the Open-Source Software Institute (http://oss-institute.org). Ben Laurie of OpenSSL (http://openssl.org/) developed the initial software modifications and Dr. Stephen Henson and Andy Polyakov made extensive subsequent contributions. DOMUS IT of Canada performed the validation testing. The FIPS Object Module v1.1.1 is compatible with OpenSSL v0.9.7, revisions 0.9.7m and above.

The pending validation of the OpenSSL FIPS Object Module v1.2 is sponsored by Symantec and the Naval Research Lab. Dr. Stephen Henson of OpenSSL made extensive revisions based on our learning curve from the first validation. The FIPS Object Module v1.2 will be compatible with an as yet unreleased OpenSSL v0.9.8.

The financial sponsorship only (barely) covers the direct test lab fees and associated costs. A great deal of voluntary labor is required to obtain these validations. Contributions are welcome!

3) What exactly is being validated? The OpenSSL Crypto modules? The whole distribution?
FIPS 140-2 is concerned with cryptographic module implementations, not applications or products per se. The FIPS 140-2 "cryptographic module" defined for the OpenSSL FIPS Object Module contains the FIPS 140 specific cryptographic API and algorithm implementations only; i.e. the API for low level algorithms (RSA, AES, 3DES, DSA, SHA-1). This cryptographic module is a minimal subset of the full OpenSSL distribution which is essentially just the *.c and *.h files for the relevant crypto algorithms (all such source is in the. /fips/ subdirectory of the source tree). This subset has been given the official version designation "OpenSSL FIPS Object Module". The code in this cryptographic module cannot be changed without affecting the FIPS 140-2 validation status; hence the isolation of the code within a specific distinct distribution and the distinct version number. That low level code is relatively stable, unlike the rest of OpenSSL which is very actively maintained. NIST/CSE allow some modification of the cryptographic algorithm source without requiring a complete new validation. Limits are stated in terms of percentage of source modified and impact on crypto algorithms. A letter of determination may be provided based on vendor input. The runtime libraries generated from this validated source in accordance with the instructions in the accompanying Security Policy document will be FIPS 140-2 validated, as will any software products utilizing these libraries for cryptography in FIPS mode. Apache mod_ssl, OpenSSH, stunnel, etc. will be FIPS 140-2 validated when built against the validated OpenSSL libraries and when appropriate application code is included to ensure that FIPS mode is activated and verified. Work has already begun on adding FIPS initialization modifications to several important open source applications. A number of commercial software vendors are known to have utilized the OpenSSL FIPS Object Module, either directly per the validation or indirectly as a model for their own validations of derivative code.

4) Is the pending validation for FIPS 140-1 or 140-2?
FIPS 140-2 level 1. Some parts could meet level 2 requirements, such as software design.

5) What version of OpenSSL is undergoing FIPS 140-2 validation? 0.9.7b?
OpenSSL itself has not been validated. A separate source distribution derived from a subset of the full OpenSSL distribution was defined as the "cryptographic module" containing the relevant code. Only this cryptographic module implementation is validated, not the larger OpenSSL distribution which can change without affecting the validation. What Ben did was to make copies of the code that constitutes the cryptographic module, and use those instead of the base versions. This allows two things to be done. First, the base distribution can be changed without affecting FIPS validation. Secondly, it means changes required by FIPS can be isolated in the validated code. For example, FIPS requires an approved PRNG, but replacement of OpenSSL's PRNG with FIPS 186-2 except in FIPS mode would not generally be considered desirable. The OpenSSL PRNG can seed the FIPS Approved RNG. Note the FIPS specific code will be carried forward in future OpenSSL releases, to serve as the basis for future new validations, but those releases cannot be used to generate validated modules.

6) What algorithms are included in the FIPS 140 validation?
DSA, 3DES, AES, SHA-1 and SHA-2 (SHA-224, SHA-256, SHA-384, SHA-512), HMAC-SHA-1, HMAC-SHA-2, RSA, and PRNG. Those, and DH are all that are currently implemented as FIPS modules.

7) What documentation should I be reading?
The one must-read document is the Security Policy from the NIST CMVP web site for the specific validation (http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp733.pdf for v1.1.1). The companion User Guide has considerably more detail but has not been officially endorsed by the CMVP (http://www.openssl.org/docs/fips/UserGuide-1.1.1.pdf for v1.1.1). See also question #11.

8) Won't an application that uses FIPS 140-1/2 validated OpenSSL libraries for all cryptography still require a separate FIPS 140-2 validation?
The OpenSSL user doesn't need any additional validations (if OpenSSL supplies _ all _ relevant crypto) because NIST/CSE will already have validated the OpenSSL libraries when used in accordance with the Security Policy.

A product that uses one of the FIPS Object Modules to satisfy FIPS 140-2 validation requirements should use a statement of the form

Product XXXX uses an embedded FIPS 140-2-validated cryptographic module (Certificate #NNN) running on a YYYY platform per FIPS 140-2 Implementation Guidance section G.5 guidelines.

to note that a product specific validation is unnecessary.

9) Is the FIPS validation tied to a specific operating system or to a CPU processor?
Yes and no. The validation has to specify at least one "platform" (hardware and O/S). However, NIST/CSE have stated that a validation obtained on one platform remains valid for another, provided that the validated software was merely recompiled (no source modifications) for the new platform. Note that the OpenSSL validation will be for binaries generated from source, not for a specific runtime executable. OpenSSL is portable code and, with only one significant exception, that same code compiles on multiple platforms. The exception is the x86 processor for which the FIPS Object Module uses several x86 specific assembly language optimizations within the FIPS 140 cryptographic module. Also see Questions #10 and #11.

10) What platforms have been FIPS validated?
For v1.1.1 the formal test platforms were HP-9000/PA-RISC under HP-UX 11i, and Intel/x86 under SuSE Linux. According to NIST/CSE the validation will also apply to any other platform for which the libraries are simply recompiled without source modifications. Since OpenSSL already has a portable design, this means a large number of platforms. Only the Intel/x86 case utilizes code not included in the HP-9000/PA-RISC test; the Intel/x86 platform test covers that platform specific source.

For v1.2 a permutation of x86 and x86_64 processors and the Linux and Microsoft Windows operating systems were selected as test platforms to cover the use of assembler optimizations on most x86 based processors as well as non-optimized use other platforms.

11) What is the Security Policy?
The Security Policy documents the conditions for use of the cryptographic module that are necessary for the validation to apply. In the case of OpenSSL, the Security Policy document describes the process of building the OpenSSL library from the validated source and linking that object code into the end application.

The Security Policy for v1.1.1 is at http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp733.pdf. The companion User Guide is at http://www.openssl.org/docs/fips/UserGuide-1.1.1.pdf.

The Security Policy and User Guide documents for v1.2 are currently in preparation.

12) No way NIST/CSE would ever validate source code!!
Strictly speaking the CMVP is not "validating source code". The ultimate target of the validations are source code deliverables, but that source is used to build binary code which is tested on specific hardware/OS platforms by the testing lab. However, once validated on one platform, NIST/CSE consider executable code generated from the same unmodified source code in accordance with the Security Policy to be validated on any other platform. So the technically precise statement is not "the source code is validated" but "executable code for any platform generated from the original source in accordance with the build process documented in the Security Policy is validated". The end result is the same: this FIPS 140-2 validation will be applicable to a wide range of platforms. Note that the key concern is establishing that the binary runtime executables are running code generated from the same source as the binaries actually tested by the CMVP lab. The Security Policy and the build process establish a chain of verifications beginning with the initial SHA-1 HMAC fingerprint of the validated source code and ending with a runtime validation check in the calling application; see the following question for details on these verifications. The testing laboratory (DOMUS IT) receives only the source code distribution and Security Policy, which they analyze directly and use to generate the binaries for run-time testing.

13) Since OpenSSL is providing source code, what's to prevent a user from modifying the crypto code and regenerating the checksum?
What's to prevent you claiming you're using FIPS 140 -1/2 validated stuff and not doing so? An Evil Hacker can always download the code (any software, actually, whether related to FIPS OpenSSL or even any version of OpenSSL or not) and hack out any goodness and hack in badness and falsely claim it is "FIPS 140-1/2 validated". The FIPS 140-2 validation only applies if the steps documented in the Security Policy are followed. FIPS 140-2 is about establishing a audit trail back to the validated cryptographic module. It requires your willing collusion to work. The point of the audit trail is to guard against accidental use of non-validated code. Deliberate use of non-validated code is, of course, always possible. Distribution of the source code from a validated module, and the question of how the running executable software is derived from that source was discussed at length with NIST/CSE. The long answer is that validity of any validation is predicated on the proper use of the software or hardware as documented in the Security Policy that accompanies the validation certificate. In the case of binary executables there is the original validation of that executable and a vendor process of packaging those executables on distribution media (implicitly assumed to be trustworthy but not verified by NIST/CSE), and a process for installation by the end user (again not independently verified). An end user that does not follow that process (installs from different media, modifies the software, substitutes non-FIPS software, configures it improperly, etc.) is invalidating the conditions of the validation. Having a purchase order or install CD of FIPS 140-2 validated software is not enough, it must also be installed and used as intended. In the case of OpenSSL source, the relevant source files are identified by a HMAC-SHA-1 digest listed in the Security Policy document. This build process generates a new HMAC-SHA-1 digest for the resulting object code. The application developer/end user then has the responsibility of confirming that the application using the OpenSSL FIPS Object Module is built against the correct OpenSSL libraries; the HMAC-SHA-1 digests are generated for that purpose and a utility is provided for generating the digest of the application executable (see Question 17).

14) Once I have the FIPS crypto built, how do I use OpenSSL so that all SSL crypto work is done using that FIPS crypto?
You have to specify a crypto suite that only contains DSA, 3DES, AES, DH, RSA, SHA-1/SHA-2. Those and DH are all that are currently implemented as FIPS modules. Applications do need minor modification to switch on FIPS mode (it is optional by design), and also typically to avoid using unapproved algorithms (which in general don't work in FIPS mode). Consideration is being given to having it optionally (at build time, of course) start out switched on, but given that very few apps can actually run correctly in FIPS mode without some modification, the motivation for that is not huge.

15) Is optimized assembly code part of the FIPS module?
Yes. The optional optimized assembly code that does not replace any functionality in the FIPS validated cryptographic module is unaffected. The standard "./config fips" build for x86 includes the relevant x86 optimizations.

16) How is the library validated?
The FIPS validation applies to a subset of the code, known as the cryptographic module. All of this code lives in the fips/ subdirectory. The OpenSSL tarball includes SHA-1 HMAC fingerprints of all the validated code. The build process checks the digests while building the libcrypto.a library. Therefore, once the build completes, the library necessarily contains the code compiled from the source used for the original validation. When the library has been built, a SHA-1 HMAC fingerprint for the library is generated and is installed along with the library itself. This enables applications, in turn, to validate the FIPS validation of the library.

17) How do I build a FIPS validated application?
This process of incorporating the FIPS library in an application is covered in detail in the Security Policy and accompanying User Guide. These documents should be used as the reference for any use of the OpenSSL FIPS library.

18) Have you also included the Known Answer Tests (KATs)?
All the software supplied to the NIST/CSE validated testing laboratory for the FIPS testing will be included in the FIPS Object Module distributions; this includes much more than just KATs.

19) Are both the static libraries and dynamic libraries to be validated?
The v1.1.1 FIPS Object Module only generates binary code suitable for static linking. Basically, we ran out of money to cover the testing for shared code. The v1.2 FIPS Object Module will produce binary code suitable for either static or shared contexts.

20) What is the strategy for introducing bug fixes into the FIPS OpenSSL?
Changes within the cryptographic module need to be evaluated on a case-by-case basis. NIST/CSE permit some degree of modification without requiring a full re-validation, based on a vendor affirmation and/or testing lab review of the extent of changes. The fine print on how much work is required is fairly involved. To date we have no direct experience with any such “letter change” modifications.

21) Are you focused on end user use? CA use?
Neither/both. The FIPS-140-2 validation is for the cryptographic algorithm libraries in the OpenSSL FIPS Object Module. These libraries can be used to supply the cryptographic functionality for any application, including end-user clients or Certificate Authority products.

22) For compliance with FIPS 140-1/2, is it OK to just validate a hardware module that is used?
Cryptographic implementations ("modules") can be hardware, software, or a combination of both. If an application uses multiple cryptographic modules then all of them must be FIPS 140-1/2 validated. All cryptography must be performed by FIPS 140-1/2 validated components in order to claim FIPS 140-1/2 validation for the application.

23) What other open source software has been validated, or is considering validation?
OpenSSL derived software has been validated multiple times within proprietary software products. Open source cryptographic has been validated in binary form for specific platforms. The open source Crypto++ Library has been FIPS 140-2 validated in binary Windows DLL form only (http://csrc.nist.gov/cryptval/140-1/140sp/140sp343.pdf). The Mozilla NSS cryptographic library has been FIPS-140-1 validated on several platforms (see http://www.mozilla.org/projects/security/pki/nss/fips/). To our knowledge the upcoming OpenSSL validation will be the first based on a source code distribution.

24) What would it take to have additional hardware platforms validated?
You may not need validation for a new platform. NIST/CSE have told us that if the validated OpenSSL software is compiled as-is for a new platform in accordance with the Security Policy then the original validation still applies (see Question 12). If source code changes are involved then some degree of re-validation will be needed (see Question 20). However, if a new platform is validated for a cryptographic module for which a certificate has already been issued, NIST/CSE just update their website (http://csrc.nist.gov/cryptval/140-1/1401val.htm) but do not modify the original certificate itself.

25) Would the costs / validation differ for AMD vs. Intel or are they both considered the same from the FIPS validation perspective?
Our understanding is that the hardware portion of the platform is an architecture type, not a specific processor model within a type. Since AMD is a faithful x86 clone separate validation would not be needed. A FIPS 140-2 level 1 validation is not tied all that closely to hardware.

26) What would the costs be to have system XXX with the operating system YYY FIPS140-2 evaluated for OpenSSL?
John Weathersby of OSSI ( http://oss-institute.org/ ) handled the contracting for this effort and would be a good resource for exploring specific validation scenarios. Based on verbal discussions with some of the players, a new platform will cost somewhere in the low five figures ($USD 10-50K), more or less independent of the type of platform. Note also that a loan of appropriate platform hardware to the test lab may be necessary. But, in any event, larger enterprises are not looking at big bucks compared to what commercial licenses would cost.