OpenSSL FIPS Runtime Module Version 1.2 By the Open Source Software Institute http://www.oss-institute.org/ OpenSSL FIPS 140-2 Security Policy Version 1.2 March 11, 2009 OpenSSL FIPS 1402 Security Policy Copyright Notice Copyright © 2003, 2004, 2005, 2006, 2007, 2008, 2009 the OpenSSL Team. This document may be freely reproduced in whole or part without permission and without restriction. Sponsored by U.S. Department of Defense Offices of Advanced Systems and Concepts Open Technology Development program Acknowledgments Page 2 of 13 OpenSSL FIPS 1402 Security Policy The Open Source Software Institute (OSSI) serves as the "vendor" for this validation. Project management coordination for this effort was provided by the OSSI: Steve Marquess 301-524-9915 Project Manager marquess@oss-institute.org 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 with technical work by: Stephen Henson 4 Monaco Place, shenson@drh-consultancy.co.uk Westlands, Newcastle-under-Lyme 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 in coordination with the OpenSSL Team at www.openssl.org. Validation testing was performed by Aspect Labs, a division of BKP Security, Inc. For information on validation or revalidations of software contact: Aspect Labs 888-347-7140 3080 Olcott Street, Suite 110-A info@aspectlabs.com Santa Clara, CA 95054-3221 http://www.aspectlabs.com/ Page 3 of 13 OpenSSL FIPS 1402 Security Policy Table of Contents 1. Introduction........................................................................................................................5 2. Module Specification.........................................................................................................5 2.1 Roles and Services......................................................................................................6 2.2 Ports and Interfaces.....................................................................................................7 2.3 Self Tests.....................................................................................................................7 2.4 Mitigation of Other Attacks........................................................................................9 2.5 Physical Security.........................................................................................................9 3. Secure Operation................................................................................................................10 4. Cryptographic Key Management.......................................................................................11 4.1 Key Generation...........................................................................................................11 4.2 Key Storage.................................................................................................................11 4.3 Key Access..................................................................................................................11 4.4 Key Protection and Zeroization..................................................................................11 4.5 Cryptographic Algorithms.........................................................................................11 Appendix A Installation Instructions.....................................................................................13 Page 4 of 13 OpenSSL FIPS 1402 Security Policy 1. Introduction This document is the nonproprietary security policy for the OpenSSL FIPS Runtime Module. This document was prepared as part of the Federal Information Processing Standard (FIPS) 1402 Level 1 validation process. FIPS 1402, Security Requirements for Cryptographic Modules, describes the requirements for cryptographic modules. For more information about the FIPS 1402 standard and the cryptographic module validation process see http://csrc.nist.gov/cryptval/. 2. Module Specification The OpenSSL FIPS Runtime Module (hereafter referred to as the Module) is a software library supporting FIPSapproved cryptographic algorithms. For the purposes of the FIPS 1402 level 1 validation, the OpenSSL FIPS Runtime Module v1.2 is a single shared library module file1. This module provides a Clanguage application program interface (API) for use by other processes that require cryptographic functionality. For FIPS 1402 purposes the Module is classified as a multichip standalone module. The logical cryptographic boundary of the Module is the shared library file itself. 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: 1) Windows XP Service Pack 2 2) Fedora Linux 9 FIPS Runtime Module Block Diagram Plaintext Cryptographic v1.2 Boundary Ciphertext Physical Cryptographic Boundary Logical Cryptographic Boundary Runtime Module ROM RAM CPU CPU Controller Peripherals Operating System Application Ethernet Input Output Figure 2 1 libfips.so.0.9.8 (Linux/Unix) or libosslfips.dll (Windows) Page 5 of 13 OpenSSL FIPS 1402 Security Policy 2.1 Roles and Services The Module meets all FIPS 1402 level 1 requirements for Roles and Services, implementing both CryptoUser and CryptoOfficer roles. As allowed by FIPS 1402, 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. · CryptoOfficer 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 User AES and TDES symmetric read/write/execute encryption/decryption keys Key wrapping for key User RSA public/private key read/write/execute transport pairs DH primitives User DiffieHellman keys read/write/execute Digital signature User RSA and DSA asymmetric read/write/execute keys Symmetric key User AES, TDES and HMAC read/write/execute generation symmetric keys Asymmetric key User RSA, DSA and Diffie read/write/execute generation Hellman keys Keyed Hash (HMAC) User HMAC keys read/write/execute Message digest (SHS) User none read/write/execute Random number User RNG seed and seed key read/write/execute generation (ANSI X9.31) Show status User none execute Module initialization User none execute Self test User Integritycheck HMAC key execute Zeroize User all symmetric and write Page 6 of 13 OpenSSL FIPS 1402 Security Policy Service Role CSP Access asymmetric keys, as well as parameters other than those used by Data Input and Output Interfaces Table 2.1 Note that only the private key components of public/private key pairs are CSPs. The public keys are assumed to be publicly visible. 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 Clanguage 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 Physical Ports of a GPC API input parameters Data Output Physical Ports of a GPC API output parameters Control Input Physical Ports of a GPC API function calls and parameters, other than those used by Data Input and Output interfaces Status Output Physical Ports of a GPC API return codes Power Input Power Port of a GPC N/A Table 2.2 2.3 Self Tests The Module performs both powerup self tests at module initialization and conditional tests during operation. Input, output, and cryptographic functions cannot be performed while the Module is in a selftest or error state as the module is single threaded and will not return to the calling application until the powerup self tests are complete. If the powerup self tests fail subsequent calls to the module will fail and thus no further cryptographic operations are possible. PowerUp Self Tests Page 7 of 13 OpenSSL FIPS 1402 Security Policy Algorithm Test AES KAT TripleDES KAT DSA signatures pairwise consistency test, sign/verify RSA signatures KAT ANSI X9.31 PRNG KAT HMACSHA1 KAT HMACSHA224 KAT HMACSHA256 KAT HMACSHA384 KAT HMACSHA512 KAT SHA1 KAT2 SHA224 KAT2 SHA256 KAT2 SHA384 KAT2 SHA512 KAT2 module integrity check HMACSHA1 Table 2.3a Conditional Self Tests Algorithm Test DSA key pair generation pairwise consistency RSA key pair generation pairwise consistency PRNG continuous RNG test Table 2.3b A single initialization call, FIPS_mode_set, is required to initialize the Module for operation in the FIPS 1402 Approved mode. When the Module is in FIPS mode all security functions and cryptographic algorithms are performed in Approved mode. 2 Tested as part of the HMAC known answer tests. Page 8 of 13 OpenSSL FIPS 1402 Security Policy 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 nonFIPS mode by default. The FIPS_mode_set function verifies the integrity of the runtime executable using a HMACSHA1 digest computed at build time. If this computed HMACSHA1 digest matches the stored known digest then the powerup selftest, consisting of the algorithm specific Pairwise Consistency and Known Answer tests, is performed. If any component of the powerup selftest fails an internal global error flag is set to prevent subsequent invocation of any cryptographic function calls. Any such powerup self test failure is a hard error that can only be recovered by reinstalling the Module3. If all components of the powerup selftest are successful then the Module is in FIPS mode. The powerup selftests may be performed at any time by restarting the module. A powerup selftest failure can only be cleared by a successful FIPS_mode_set invocation. 2.4 Mitigation of Other Attacks The Module does not contain additional security mechanisms beyond the requirements for FIPS 1402 level 1 cryptographic modules. 2.5 Physical Security The Module is comprised of software only and thus does not claim any physical security. 3 The FIPS_mode_set() function could be reinvoked but such reinvocation does not provide a means from recovering from an integrity test or known answer test failure. Page 9 of 13 OpenSSL FIPS 1402 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 1402 requirement for a single user mode of operation. The "single user mode" means that for each spawned instance of a cryptographic module, only one operator may access the module at a time. The Module is installed using the 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 database4. Upon initialization of the Module by invocation of the FIPS_mode_set call the module will run its powerup self tests. Successful completion of the powerup self tests as indicated by a return value of "1" from the FIPS_mode_set call ensures that the module is operating in the FIPS mode of operation. The selftests can be called on demand by restarting the module (i.e., reloading the module and re invoking the FIPS mode initialization API call). 4 See http://cvs.openssl.org/ Page 10 of 13 OpenSSL FIPS 1402 Security Policy 4. Cryptographic Key Management For each API call the calling application provides public and private keys (if any) specified in the API call. 4.1 Key Generation The Module supports generation of DH, DSA, and RSA publicprivate key pairs. The Module employs an ANSI X9.31 compliant random number generator for creation of asymmetric and symmetric keys as well as FIPS 1862 compliant DSA key pair generation algorithm. 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 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. 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. Rebooting of the system will zeroize any keys present in volatile RAM. 4.5 Cryptographic Algorithms The Module supports the following FIPS approved or allowed algorithms: Algorithm Validation Certificate Usage AES #681, #682 encrypt/decrypt TDES #623, #624 encrypt/decrypt DiffieHellman (allowed in FIPS mode, see DH primitives caveat below) DSA #257, #258 sign and verify PRNG #397, #398 random number generation RSA (X9.31, PKCS #1.5, PSS) #318, #319 sign and verify Page 11 of 13 OpenSSL FIPS 1402 Security Policy Algorithm Validation Certificate Usage RSA encrypt/decrypt (allowed in FIPS mode, see key wrapping caveat below) SHA1 #711, #712 hashing SHA224 #711, #712 hashing SHA256 #711, #712 hashing SHA384 #711, #712 hashing SHA512 #711, #712 hashing HMACSHA1 #362, #363 message integrity HMACSHA224 #362, #363 message integrity HMACSHA256 #362, #363 message integrity HMACSHA384 #362, #363 message integrity HMACSHA512 #362, #363 message integrity Table 4.5a DiffieHellman (provides between 80 and 256 bits of encryption strength). DiffieHellman, DSA, and RSA do not permit a key size of less than 1024 bits when in FIPS mode. RSA (key wrapping; key establishment methodology provides between 80 and 150 bits of encryption strength). The module supports the DES encryption algorithm, which shall not be used in the Approved mode of operation. Page 12 of 13 OpenSSL FIPS 1402 Security Policy Appendix A Installation Instructions Installation consists of copying the shared library file to the appropriate location where it can be referenced by the host operating system at application runtime. For Unix and Linux systems the shared library file is named libfips.so.0.9.8. For Microsoft Windows the shared library file is named libosslfips.dll. Installation instructions: 1. Copy the shared library file to the appropriate location on the host system. 2. As appropriate define or register the shared library for reference by the operating system (O/S) runtime loader. This step will vary depending on the O/S and whether the shared library is to be installed for global access by all users or only for use by a specific application. For Windows simply placing the shared library in the same directory as the calling application suffices for use by that application. For Unix/Linux the LD_LIBRARY_PATH environment variable (or possibly others such as LD_PRELOAD) can be defined, or the ldconfig command can be used to configure the systemwide cache of shared libraries listed in the /etc/ld.so.conf file. 3. The module is now available for use. Page 13 of 13