OpenSSL FIPS
Object Module
Version 1.2.4
By the
Open Source Software Institute
http://www.oss-institute.org/
OpenSSL FIPS 140-2 Security Policy
Version 1.2.4
June 12, 2012
OpenSSL FIPS 140-2 Security Policy
Copyright Notice
Copyright © 2003-2012 the OpenSSL Team.
This document may be freely reproduced in whole or part without permission and without restriction.
Sponsored by:
Page 2 of 21
OpenSSL FIPS 140-2 Security Policy
Acknowledgments
The Open Source Software Institute (OSSI) serves as the "vendor" for this validation. Project management coordination for
this effort was provided by:
Steve Marquess +1 877-673-6775
President marquess@opensslfoundation.com
The OpenSSL Software Foundation
1829 Mount Ephraim Road
Adamstown, MD 21710
USA
John Weathersby 601-427-0152 office/601-818-7161 cell
Executive Director jmw@oss-institute.org
Open Source Software Institute 601-427-0156 fax
Administrative Office
P.O. Box 547 http://oss-institute.org/
Oxford, MS 38655
USA
with technical work by:
Stephen Henson
4 Monaco Place, shenson@opensslfoundation.com
Westlands, Newcastle-under-Lyme shenson@drh-consultancy.co.uk
Staffordshire. ST5 2QT.
England, United Kingdom http://www.drh-consultancy.co.uk/
Andy Polyakov
Chalmers University of Technology appro@fy.chalmers.se
SE-412 96 Gothenburg
Sweden
Tim Hudson
P.O. Box 6389 tjh@opensslfoundation.com
Fairfield Gardens 4103 tjh@cryptsoft.com
Australia
ACN 074 537 821 http://www.cryptsoft.com/
in coordination with the OpenSSL Team at www.openssl.org.
Initial validation testing was performed by The DOMUS IT Security Laboratory. For information on validation or
revalidations of software contact:
Eric Stevens 613-726-5010 office
Laboratory Director
DOMUS IT Security Laboratory estevens@domusitsl.com
400 March Road, Suite 190 http://www.domusitsl.com/
Kanata, Ontario
K2K 3H4
Canada
Additional validation testing was performed by Infogard Laboratories. For information on validation or revalidations of
software contact:
Mark Minnoch 805-783-0810 tel
FIPS Program Manager, CISSP 805-783-0889 fax
InfoGard Laboratories mminnoch@infogard.com
709 Fiero Lane, Suite 25 http://www.infogard.com/
San Luis Obispo, CA 93401
Page 3 of 21
OpenSSL FIPS 140-2 Security Policy
Modification History
2012-05-09 Added Apple iOS, Mac OS X platforms
2012-03-28 Assert validity of earlier revisions
2012-02-21 Added Wind River Linux platforms
2011-05-03 Added VxWorks PowerPC platform
2011-04-14 Added new Tables 2.1, 2.2
2011-01-03 Added algorithm certificate numbers for Droid II
2010-11-04 Addition of the Motorola Droid II platform
Retesting for Windows 64bit portability bugfix, Appendix A: incorporate earlier
uCLinux patch in new source distribution
2009-11-03 Section 2, Appendix A: Addition of a new platform.
2008-08-08 Original validation.
Page 4 of 21
OpenSSL FIPS 140-2 Security Policy
Table of Contents
1. Introduction........................................................................................................................6
2. Module Specification.........................................................................................................6
2.1 Roles and Services...................................................................................................... 9
2.2 Ports and Interfaces.....................................................................................................10
2.3 Self Tests.....................................................................................................................10
2.4 Mitigation of Other Attacks........................................................................................ 12
2.5 Physical Security.........................................................................................................12
3. Secure Operation................................................................................................................13
4. Cryptographic Key Management.......................................................................................14
4.1 Key Generation........................................................................................................... 14
4.2 Key Storage.................................................................................................................14
4.3 Key Access..................................................................................................................14
4.4 Key Protection and Zeroization.................................................................................. 14
4.5 Cryptographic Algorithms......................................................................................... 14
Appendix A Installation Instructions.....................................................................................17
Appendix B Controlled Distribution File Fingerprint........................................................... 20
Page 5 of 21
OpenSSL FIPS 140-2 Security Policy
1. Introduction
This document is the non-proprietary security policy for the OpenSSL FIPS Object Module. This
document was prepared as part of the Federal Information Processing Standard (FIPS) 140-2 Level 1
validation process.
FIPS 140-2, Security Requirements for Cryptographic Modules, describes the requirements for
cryptographic modules. For more information about the FIPS 140-2 standard and the cryptographic
module validation process see http://csrc.nist.gov/cryptval/.
2. Module Specification
The OpenSSL FIPS Object Module (hereafter referred to as the Module) is a software library
supporting FIPS-approved cryptographic algorithms. For the purposes of the FIPS 140-2 level 1
validation, the OpenSSL FIPS Object Module v1.2.4 is a single object module file named
fipscanister.o (Linux®1/Unix®2 and VxWorks®3) or fipscanister.lib (Microsoft Windows®4). This
module provides a C-language application program interface (API) for use by other processes that
require cryptographic functionality.
Note that the OpenSSL FIPS Object Module v1.2.4 is fully backwards compatible with all earlier
revisions of the OpenSSL FIPS Object Module v1.2. The v1.2.4 Module incorporates support for a
new platform without disturbing functionality for any previously tested platforms. The v1.2.4 Module
can be used in any environment supported by the earlier revisions of the Module, and those earlier
revisions remain valid.
For FIPS 140-2 purposes the Module is classified as a multi-chip standalone module. The logical
cryptographic boundary of the Module is the fipscanister object module. The physical cryptographic
boundary of the Module is the enclosure of the computer system on which it is executing. The Module
performs no communications other than with the process that calls it. It makes no network or
interprocess connections and creates no files.
The Module was tested on the following platforms:
Platform
#
Platform
1 Linux x86 no-asm, Linux.2.6.18_i686_gcc-4.1.2 (OpenSuSE 10.2) no-
asm
2 Linux x86-64 no-asm, Linux.2.6.20_x86-64_gcc-4.1.2 (OpenSuSE 10.2)
3 Linux x86 asm, Linux.2.6.18_i686_gcc-4.1.2 (OpenSuSE 10.2)
1 Linux is the registered trademark of Linus Torvalds in the U.S. and other countries.
2 UNIX is a registered trademark of The Open Group
3 VxWorks is a registered trademark owned by Wind River Systems, Inc
4 Windows is a registered trademark of Microsoft Corporation in the United States and other countries.
Page 6 of 21
OpenSSL FIPS 140-2 Security Policy
Platform
#
Platform
4 Linux x86-64 asm, Linux.2.6.20_x86-64_gcc-4.1.2 (OpenSuSE 10.2)
5 Windows x86 no-asm, WinXP.SP2_i386_MSVC.8.0 no-asm
6 Windows x64 no-asm, WinXP.SP2_x86-64_MSVC.8.0 no-asm
7 Windows x86 asm, WinXP.SP2_i386_MSVC.8.0 NASM, SSE2
8 Windows x64 asm, WinXP.SP2_x86-64_MSVC.8.0
9 Linux ARM no-asm, Linux.2.4.32-uc0_armv4l gcc-3.4.4 (uCLinux)
10 Linux ARM no-asm, Linux.2.6.32.9-g59f039501_armv7l gcc-4.4.0
(Android2.2)
11 Vxworks PowerPC hard float, powerpc-wrs-vxworks gcc 4.1.2
12 Vxworks PowerPC soft float, powerpc-wrs-vxworks gcc 4.1.2
13 Wind River 1.4, Linux 2.6.27, Freescale PowerPC-32
14 Wind River 4.0, Linux 2.6.34, Freescale PowerPC-32
15 Apple iOS 5.0, gcc version 4.2.1, ARMv7
16 Apple OS X 11, gcc version 4.2.1 (32 bit)
17 Apple OS X 11, gcc version 4.2.1 (64 bit)
Table 2.1
The “asm” designation means that assembler language optimizations were enabled when the binary
code was built, “no-asm” means that only C language code was compiled.
These platforms correspond to the Operational Environment configurations listed on the FIPS 140-2
Validation Certificate #1051 as follows:
Operational Environment Configuration Platform
OpenSuSE Linux 32-bit Version 10.2 (gcc Compiler Version
4.1.2 20061115 prerelease)
1, 3
Page 7 of 21
OpenSSL FIPS 140-2 Security Policy
Operational Environment Configuration Platform
OpenSuSE Linux 64-bit Version 10.2 (gcc Compiler Version
4.1.2 20061115 prerelease)
2, 4
Windows XP Pro SP2 32 bit (Microsoft Visual C++ version 8) 5, 7
Windows XP Pro SP2 64 bit (Microsoft Visual C++ version 8) 6, 8
uClinux Kernel Version 2.4.32 (gcc Compiler Version 3.4.4) 9
Android 2.2 (gcc Compiler Version 4.4.0) 10
VxWorks 6.7 (gcc Compiler Version 4.1.2) 11, 12
Wind River Linux 1.4 (gcc compiler 3.4.4) 13
Wind River Linux 4.0 (gcc compiler 4.4.1) 14
Apple iOS 5.0 (gcc compiler 4.2.1) 15
Apple OS X 11 32 bit (gcc compiler 4.2.1) 16
Apple OS X 11 64 bit (gcc compiler 4.2.1) 17
Table 2.2
Figure 2
Page 8 of 21
Plaintext
Ciphertext
Input Output
FIPS Object Module Block Diagram
v1.2
Cryptographic
Boundary
FIPS Object c Module
ROM RAM
Controller
CPU Peripherals
Ethernet
CPU
Logical Cryptographic Boundary
Physical Cryptographic Boundary
OpenSSL FIPS 140-2 Security Policy
2.1 Roles and Services
The Module meets all FIPS 140-2 level 1 requirements for Roles and Services, implementing both
Crypto-User and Crypto-Officer roles. As allowed by FIPS 140-2, the Module does not support user
authentication for those roles. Only one role may be active at a time and the Module does not allow
concurrent operators.
The User and Crypto Officer roles are implicitly assumed by the entity accessing services implemented
by the Module. The Crypto Officer can install and initialize the Module. The Crypto Officer role is
implicitly entered when installing the Module or performing system administration functions on the
host operating system.
• User Role: Loading the Module and calling any of the API functions. This role has access to all of
the services provided by the Module.
• Crypto-Officer Role: Installation of the Module on the host computer system. This role is assumed
implicitly when the system administrator installs the Module library file.
Service Role CSP Access
Symmetric encryption/decryption User, Crypto Officer symmetric key
AES, TDES
read/write/execute
Key transport User, Crypto Officer asymmetric private key
RSA
read/write/execute
Digital signature User, Crypto Officer asymmetric private key
RSA, DSA
read/write/execute
Symmetric key generation User, Crypto Officer symmetric key
AES, TDES
read/write/execute
Asymmetric key generation User, Crypto Officer asymmetric private key
RSA, DSA
read/write/execute
Keyed Hash (HMAC) User, Crypto Officer HMAC SHA-1 key
HMAC-SHA-1
read/write/execute
Message digest (SHS) User, Crypto Officer none
SHA-1, SHA-2
read/write/execute
Random number generation User, Crypto Officer seed key
seed
AES
read/write/execute
Show status User, Crypto Officer none execute
Module initialization1 User, Crypto Officer none execute
Self test User, Crypto Officer none execute
Zeroize User, Crypto Officer symmetric key, asymmetric
1 The FIPS mode initialization is performed when the application invokes the FIPS_mode_set() call which returns a “1” for
success and “0” for failure; see section 2.3.
Page 9 of 21
OpenSSL FIPS 140-2 Security Policy
Service Role CSP Access
key, HMAC-SHA-1 key,
seed key
AES
Table 2.3
2.2 Ports and Interfaces
The physical ports of the Module are the same as the computer system on which it is executing. The
logical interface is a C-language application program interface (API).
The Data Input interface consists of the input parameters of the API functions. The Data Output
interface consists of the output parameters of the API functions. The Control Input interface consists of
the actual API functions. The Status Output interface includes the return values of the API functions.
FIPS Interface Physical Port Module Interface
Data Input Ethernet ports API input parameters
Data Output Ethernet ports API output parameters
Control Input Keyboard, Serial port, Ethernet port API function calls
Status Output Keyboard, Serial port, Ethernet port API return codes
Power Input PCI Compact Power Connector N/A
Table 2.4
2.3 Self Tests
The Module performs both power-up self tests at module initialization2 and continuous condition tests
during operation. Input, output, and cryptographic functions cannot be performed while the Module is
in a self-test or error state as the module is single threaded and will not return to the calling application
until the power-up self tests are complete. If the power-up self tests fail, subsequent calls to the module
will fail and thus no further cryptographic operations are possible.
Power-Up Self Tests
Algorithm Test
AES KAT
2 The FIPS mode initialization is performed when the application invokes the FIPS_mode_set() call which returns a “1”
for success and “0” for failure; see section 2.3.
Page 10 of 21
OpenSSL FIPS 140-2 Security Policy
Algorithm Test
Triple-DES KAT
DSA pairwise consistency test,
sign/verify
RSA KAT
PRNG KAT
HMAC-SHA-1 KAT
HMAC-SHA-224 KAT
HMAC-SHA-256 KAT
HMAC-SHA-384 KAT
HMAC-SHA-512 KAT
SHA-1 KAT3
SHA-224 KAT1
SHA-256 KAT1
SHA-384 KAT1
SHA-512 KAT1
module integrity HMAC-SHA-1
Table 2.5a
Conditional Self Tests
Algorithm Test
DSA pairwise consistency
RSA pairwise consistency
PRNG continuous test
Table 2.5b
A single initialization call, FIPS_mode_set(), is required to initialize the Module for operation in the
FIPS 140-2 Approved mode. When the Module is in FIPS mode all security functions and
cryptographic algorithms are performed in Approved mode.
The FIPS mode initialization is performed when the application invokes the FIPS_mode_set() call
which returns a “1” for success and “0” for failure. Interpretation of this return code is the
responsibility of the host application. Prior to this invocation the Module is uninitialized in the non-
FIPS mode by default.
3 Tested as part of the HMAC known answer tests.
Page 11 of 21
OpenSSL FIPS 140-2 Security Policy
The FIPS_mode_set() function verifies the integrity of the runtime executable using a HMAC-SHA-1
digest computed at build time. If this computed HMAC-SHA-1 digest matches the stored known digest
then the power-up self-test, consisting of the algorithm specific Pairwise Consistency and Known
Answer tests, is performed. If any component of the power-up self-test fails an internal global error
flag is set to prevent subsequent invocation of any cryptographic function calls. Any such power-up
self test failure is a hard error that can only be recovered by reinstalling the Module4. If all components
of the power-up self-test are successful then the Module is in FIPS mode. The power-up self-tests may
be performed at any time with a separate function call, FIPS_selftest(). This function call also
returns a “1” for success and “0” for failure, and interpretation of this return code is the responsibility
of the host application.
A power-up self-test failure can only be cleared by a successful FIPS_mode_set() invocation. No
operator intervention is required during the running of the self-tests.
2.4 Mitigation of Other Attacks
The Module does not contain additional security mechanisms beyond the requirements for FIPS 140-2
level 1 cryptographic modules.
2.5 Physical Security
The Module is comprised of software only and thus does not claim any physical security.
4 The FIPS_mode_set() function could be re-invoked but such re-invocation does not provide a means from recovering
from an integrity test or known answer test failure.
Page 12 of 21
OpenSSL FIPS 140-2 Security Policy
3. Secure Operation
The tested operating systems segregate user processes into separate process spaces. Each process space
is an independent virtual memory area that is logically separated from all other processes by the
operating system software and hardware. The Module functions entirely within the process space of
the process that invokes it, and thus satisfies the FIPS 140-2 requirement for a single user mode of
operation.
The Module is installed using one of the set of instructions in Appendix A appropriate to the target
system. A complete revision history of the source code from which the Module was generated is
maintained in a version control database5. The HMAC-SHA-1 of the Module distribution file as tested
by the CMT Laboratory and listed in Appendix A is verified during installation of the Module file as
described in Appendix A.
Upon initialization6 of the Module, the module will run its power-up self tests. Successful completion
of the power-up self tests7 ensures that the module is operating in the FIPS mode of operation.
As the Module has no way of managing keys, any keys that are input or output from applications
utilizing the module must be input or output in encrypted form using FIPS approved algorithms.
The self-tests can be called on demand by reinitializing the module using the FIPS_mode_set()
function call, or alternatively using the FIPS_selftest() function call.
5 See http://cvs.openssl.org/
6 The FIPS mode initialization is performed when the application invokes the FIPS_mode_set() call which returns a “1”
for success and “0” for failure; see section 2.3.
7 The power-up self tests are performed as part of the FIPS mode initialization process; see section 2.3.
Page 13 of 21
OpenSSL FIPS 140-2 Security Policy
4. Cryptographic Key Management
4.1 Key Generation
The Module supports generation of DH, DSA, and RSA public-private key pairs. The Module employs
an ANSI X9.31 compliant random number generator for creation of asymmetric and symmetric keys.
The developer shall use entropy sources that contain at least 128 bits of entropy to seed the RNG as the
module is not capable of detecting randomness or quality of the seeding material provided.
4.2 Key Storage
Public and private keys are provided to the Module by the calling process, and are destroyed when
released by the appropriate API function calls. The Module does not perform persistent storage of
keys.
4.3 Key Access
An authorized application as user (the Crypto-User) has access to all key data generated during the
operation of the Module.
4.4 Key Protection and Zeroization
Keys residing in internally allocated data structures can only be accessed using the Module defined
API. The operating system protects memory and process space from unauthorized access. Zeroization
of sensitive data is performed automatically by API function calls for intermediate data items, and on
demand by the calling process using Module provided API function calls provided for that purpose.
Only the process that creates or imports keys can use or export them. No persistent storage of key data
is performed by the Module. All API functions are executed by the invoking process in a non-
overlapping sequence such that no two API functions will execute concurrently.
The calling process can perform key zeroization of keys by calling an API function.
4.5 Cryptographic Algorithms
The Module supports the following FIPS approved or allowed algorithms:
Algorithm Validation Certificate Usage Keys/CSPs
AES #695, #1534, #1630, #1933,
#2011
encrypt/decrypt AES keys 128, 192, 256 bits
TDES #627, #1011, #1066, #1259,
#1297
encrypt/decrypt Triple-DES keys 168 bits
DSA #264, #475, #512, #616,
#637
sign and verify DSA keys 1024 bits
Page 14 of 21
OpenSSL FIPS 140-2 Security Policy
Algorithm Validation Certificate Usage Keys/CSPs
PRNG (ANSI X9.31
Appendix A.2.4 using
AES)
#407, #826, #873, #1018,
#1053
random number
generation
PRNG seed value is 128 bits;
seed key values are 128 bits, 192
bits, and 256 bits
RSA (X9.31, PKCS
#1.5, PSS)
#323, #745, #804, #999,
#1040
sign and verify RSA keys 1024 to 16384 bits
RSA encrypt/decrypt (allowed in FIPS mode, see
caveat below)
key wrapping RSA (key wrapping; key
establishment methodology
provides 80 to 256 bits of
encryption strength
SHA-1 #723, #1362, #1435, #1698,
#1761
hashing N/A
SHA-224 #723, #1362, #1435, #1698,
#1761
hashing N/A
SHA-256 #723, #1362, #1435, #1698,
#1761
hashing N/A
SHA-384 #723, #1362, #1435, #1698,
#1761
hashing N/A
SHA-512 #723, #1362, #1435, #1698,
#1761
hashing N/A
HMAC-SHA-1 #373, #892, #957, #1167,
#1216
message
integrity
HMAC key
HMAC-SHA224 #373, #892, #957, #1167,
#1216
message
integrity
HMAC key
HMAC-SHA256 #373, #892, #957, #1167,
#1216
message
integrity
HMAC key
HMAC-SHA384 #373, #892, #957, #1167,
#1216
message
integrity
HMAC key
HMAC-SHA512 #373, #892, #957, #1167,
#1216
message
integrity
HMAC key
Table 4.5a
DSA supports a key size of less than 1024 bits except when not in FIPS mode.
RSA (key wrapping; key establishment methodology provides between 80 and 256 bits of encryption
strength).
The Module supports the following non-FIPS approved algorithms:
Algorithm Usage Keys/CSPs
Diffie-Hellman key establishment Diffie-Hellman keys
Table 4.5b
Page 15 of 21
OpenSSL FIPS 140-2 Security Policy
The Module only provides functions that implement Diffie-Hellman primitives. The shared secret
provides between 80 and 219 bits of encryption strength.
Page 16 of 21
OpenSSL FIPS 140-2 Security Policy
Appendix A Installation Instructions
The test platforms represent different combinations of installation instructions and “code paths” -- the
distinct set of object code generated depending on the host hardware and operating system platform.
For each of these code paths there is a build system, the host providing the build environment in which
the installation instructions are executed, and a target system on which the generated object code is
executed. The build and target systems may be the same type of system or even the same device, or
may be different systems.
Platform Code Path Installation Instruction Set
1 pure C 32 bit U1
2 pure C 32 bit W1
3 pure C 64 bit U1
4 pure C 64 bit W1
5 x86 asm U2
6 x86 asm W2
7 x86-64 asm U2
8 x84-64 asm W2
9 pure C 32 bit U2
10 pure C 32 bit U2
11 PowerPC 32 bit soft float U2
12 PowerPC 32 bit hard float U2
13 x86 asm U1
14 x86 asm U1
15 x86 asm U2
16 x86 asm U2
17 pure C 32 bit U2
Each of these command sets are relative to the top of the directory containing the uncompressed and
expanded contents of the distribution file openssl-fips-1.2.4.tar.gz. The command sets are:
U1:
./config fipscanisterbuild no-asm
make
make install
U2:
Page 17 of 21
OpenSSL FIPS 140-2 Security Policy
./config fipscanisterbuild
make
make install
W1:
ms\do_fips no-asm
W2:
ms\do_fips
Installation instructions
1. Download and copy the distribution file openss-fips-1.2.4.tar.gz to the build system.
These files can be downloaded from http://www.openssl.org/source/.
2. Verify the SHA-1 HMAC digest of the distribution file; see Appendix B. Note that if a suitable
utility to generate SHA1 HMAC digests is not available, this check will need to be deferred
until the openssl command is generated in the following step.
3. Unpack the distribution
gunzip -c openssl-fips-1.2.4.tar.gz | tar xf -
cd openssl-fips-1.2.4
4. Execute one of the installation command sets U1, W1, U2, W2 as shown above. No other
command sets shall be used.
5. The resulting fipscanister.o or fipscanister.lib file is now available for use.
6. The calling application enables FIPS mode by calling the FIPS_mode_set() function.
Note that failure to use one of the specified commands sets exactly as shown will result in a module
that cannot be considered compliant with FIPS 140-2.
Linking the Runtime Executable Application
Note that applications interfacing with the FIPS Object Module are outside of the cryptographic
boundary. When linking the application with the FIPS Object Module two steps are necessary:
1. The HMAC-SHA-1 digest of the FIPS Object Module file must be calculated and verified against
the installed digest to ensure the integrity of the FIPS object module.
2. A HMAC-SHA1 digest of the FIPS Object Module must be generated and embedded in the FIPS
Object Module for use by the FIPS_mode_set() function at runtime initialization.
The OpenSSL distribution contains a reference utility8 which can be used to perform the verification of
8 This utility is the “openssl sha” command with the -hmac option switch. It is included in the FIPS Object Module
distribution and also in all recent OpenSSL distributions. The version of this utility generated from the FIPS Object
Module distribution can be used to check the validity of the distribution tarball digest after the fact. Note that in
principle a software distribution could be corrupted in such a way as to incorrectly return the expected digest. This risk
Page 18 of 21
OpenSSL FIPS 140-2 Security Policy
the FIPS Object Module and to generate the new HMAC-SHA-1 digest for the runtime executable
application. Failure to embed the digest in the executable object will prevent initialization of FIPS
mode.
At runtime the FIPS_mode_set() function compares the embedded HMAC-SHA-1 digest with a
digest generated from the FIPS Object Module object code. This digest is the final link in the chain of
validation from the original source to the runtime executable application file.
is present for all validated products, of course, and would be even harder to detect without visible source code.
Page 19 of 21
OpenSSL FIPS 140-2 Security Policy
Appendix B Controlled Distribution File Fingerprint
The OpenSSL FIPS Object Module v1.2.4 consists of the FIPS Object Module (the fipscanister.o or
fipscanister.lib contiguous unit of binary object code) generated from the specific source files found in
the specific special OpenSSL distribution openssl-fips-1.2.4.tar.gz with HMAC-SHA-1 digest of
c7881d370c551056970aeac83119d62e0f654b7a
located at http://www.openssl.org/source/openssl-fips-1.2.4.tar.gz.
This digest can be calculated and displayed with the commands
openssl sha1 -hmac etaonrishdlcupfm openssl-fips-1.2.4.tar.gz
The set of files specified in this tar file (or these files as modified by the aforementioned patch only)
constitutes the complete set of source files of this module. There shall be no additions, deletions, or
alterations of this set as used during module build. The OpenSSL distribution tar file (and patch file if
used) shall be verified using the above HMAC-SHA-1 digest(s).
The arbitrary 16 byte key of:
65 74 61 6f 6e 72 69 73 68 64 6c 63 75 70 66 6d
(equivalent to the ASCII string "etaonrishdlcupfm") is used to generate the HMAC-SHA-1 value for
the FIPS Object Module integrity check.
The functionality of all earlier revisions of the FIPS Object Module are subsumed by this latest
revision, so there is no reason to use older revisions for any new deployments. However, older
revisions remain valid. The source distribution files and corresponding HMAC-SHA-1 digests are
listed below:
openssl-fips-1.2.tar.gz
URL: http://opensslfoundation.com/testing/validation-1.2/source/openssl-fips-1.2.tar.gz
digest: 79193087e8115df76d3de1f346f7410df79cf6e0
opensslfips1.2.crossbuild.diff.gz9 (revision 1.2.1)
URL: http://www.openssl.org/source/openssl-fips-1.2.crossbuild.diff.gz
digest: 7ac489c3777cb4a30198f8781ae040030684d672
openssl-fips-1.2.2.tar.gz
URL: http://opensslfoundation.com/testing/validation-1.2/source/openssl-fips-1.2.2.tar.gz
digest: 4a8e3144895dfe1950f19b7445e8d55f5b09c8d8
9 The patch is applied to the openssl-fips-1.2.tar.gz source distribution with the command "gunzip -c
../openssl-fips-1.2.crossbuild.diff.gz | patch -p0".
Page 20 of 21
OpenSSL FIPS 140-2 Security Policy
openssl-fips-1.2.3.tar.gz
URL: http://www.openssl.org/source/openssl-fips-1.2.3.tar.gz.
digest: e8fdbcaba53ff94d77317b7147bad16ac7df3b5c
Page 21 of 21