Cryptographic Module for SecureOSŪ v9.7 by Secure Computing Corporation FIPS 140-2 Non-Proprietary Security Policy Version 1.4 Level 1 Validation February 7, 2006 Cryptographic Module for SecureOSŪ v9.7 Security Policy Table of Contents 1. Introduction......................................................................................................................3 2. Module Specification.......................................................................................................3 2.1 Roles and Services....................................................................................................4 2.2 Ports and Interfaces...................................................................................................5 2.3 Self Tests...................................................................................................................6 2.4 Mitigation of Other Attacks......................................................................................8 2.5 Physical Security.......................................................................................................8 3. Secure Operation..............................................................................................................9 4. Cryptographic Key Management...................................................................................10 4.1 Key Generation.......................................................................................................10 4.2 Key Storage.............................................................................................................10 4.3 Key Access..............................................................................................................10 4.4 Key Protection and Zeroization...............................................................................10 4.5 Cryptographic Algorithms.....................................................................................11 Page 2 of 12 Cryptographic Module for SecureOSŪ v9.7 Security Policy 1. Introduction This document is the non-proprietary security policy for the Cryptographic Module for SecureOSŪ. 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 Cryptographic Module for SecureOSŪ (hereafter referred to as the CMSOS) is a software library supporting FIPS-approved cryptographic algorithms. For the purposes of the FIPS 140-2 level 1 validation, the Cryptographic Module for SecureOSŪ v9.7 is a single shared library file named libcrypto.so. This module provides a C-language application program interface (API) for use by other processes that require cryptographic functionality. For FIPS 140-2 purposes the CMSOS is classified as a multi-chip standalone module. The logical cryptographic boundary of the CMSOS is the shared library file itself. The physical cryptographic boundary of the CMSOS is the enclosure of the computer system on which it is executing. The CMSOS performs no communications other than with the process that calls it. It makes no network or interprocess connections and creates no files. The CMSOS was tested on a SidewinderŪ G2 Security Appliance, Model 2150c. Page 3 of 12 Cryptographic Module for SecureOSŪ v9.7 Security Policy Secure Computing FIPS140 Cryptographic Module Block Diagram Plaintext Cryptographic Boundary v1.0 Ciphertext Secure Computing ROM RAM Cryptographic Module CPU CPU Controller Peripherals Ethernet Input Output Figure 2 2.1 Roles and Services The CMSOS 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 CMSOS does not support user authentication for those roles. Only one role may be active at a time and the CMSOS does not allow concurrent operators. The User and Crypto Officer roles are implicitly assumed by the entity accessing services implemented by the CMSOS. The Crypto Officer can install and initialize the CMSOS. The Crypto Officer role is implicitly entered when installing the CMSOS or performing system administration functions on the host operating system. · Crypto-User Role: Loading the CMSOS and calling any of the API functions. This role has access to all of the services provided by the CMSOS. Page 4 of 12 Cryptographic Module for SecureOSŪ v9.7 Security Policy · Crypto-Officer Role: Installation of the CMSOS on the host computer system. This role is assumed implicitly when the system administrator installs the CMSOS library file. Service Role CSP Access Symmetric encryption/decryption User, Crypto Officer symmetric key read/write/execute Key transport User, Crypto Officer asymmetric private key read/write/execute Digital signature User, Crypto Officer asymmetric private key read/write/execute Symmetric key generation User, Crypto Officer symmetric key read/write/execute Asymmetric key generation User, Crypto Officer asymmetric private key read/write/execute Message digest ­ HMAC SHA-1 User, Crypto Officer HMAC SHA-1 key read/write/execute Message digest - SHA-1 User, Crypto Officer none read/write/execute Random number generation User, Crypto Officer seed key read/write/execute Show status User, Crypto Officer none execute Module initialization User, Crypto Officer none execute Self test User, Crypto Officer none execute Zeroize User, Crypto Officer symmetric key, asymmetric key, HMAC-SHA-1 key, seed key Table 2.1 2.2 Ports and Interfaces The physical ports of the CMSOS 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 Page 5 of 12 Cryptographic Module for SecureOSŪ v9.7 Security Policy the return values of the API functions. FIPS Interface Module Port Module Interface Data Input Gigabit Ethernet ports API input parameters Data Output Gigabit Ethernet ports API output parameters Control Input Serial port API function calls Ethernet port Status Output Serial port API return codes Ethernet port Power Input PCI Compact Power Connector N/A Table 2.2 2.3 Self Tests The CMSOS performs both power-up self tests at module initialization and continuous condition tests during operation. Input, output, and cryptographic functions cannot be performed while the CMSOS is in a self-test or error state. Power-Up Self Tests Algorithm Test AES KAT Triple-DES KAT DSA pairwise consistency test, sign/verify RSA sign/verify KAT Page 6 of 12 Cryptographic Module for SecureOSŪ v9.7 Security Policy Algorithm Test PRNG KAT SHA-1 KAT SHA-224 KAT SHA-256 KAT SHA-384 KAT SHA-512 KAT module integrity HMAC-SHA-1 Table 2.3a Conditional Self Tests Algorithm Test DSA pairwise consistency RSA pairwise consistency PRNG continuous test Table 2.3b A single initialization call, FIPS_mode_set, is required to initialize the CMSOS for operation in the FIPS 140-2 Approved mode. When the CMSOS 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 CMSOS is uninitialized in the non-FIPS mode by default. 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 Page 7 of 12 Cryptographic Module for SecureOSŪ v9.7 Security Policy 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. If all components of the power-up self-test are successful then the CMSOS 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 CMSOS does not contain additional security mechanisms beyond the requirements for FIPS 140-2 level 1 cryptographic modules. 2.5 Physical Security The CMSOS is comprised of software only and thus does not claim any physical security. Page 8 of 12 Cryptographic Module for SecureOSŪ v9.7 Security Policy 3. Secure Operation The SidewinderŪ G2 Security Appliance operating system segregates 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 CMSOS 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 CMSOS is installed on the SidewinderŪ G2 Security Appliance by the vendor during the manufacturing process, using the vendors established configuration management and quality assurance process. A complete revision history of the source code from which the CMSOS was generated is maintained in a version control database. The HMAC-SHA1 of the CMSOS library file as tested by the CMVP is verified after installation of the CMSOS file on the SidewinderŪ G2 Security Appliance. Upon initialization of the CMSOS, the module will run its power-up self tests. Successful completion of the power-up self tests ensures that the module is operating in the FIPS mode of operation. As the CMSOS 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. The SidewinderŪ G2 Security Appliance is supplied to customers as a turn-key system with no customer or end-user access to the CMSOS. Page 9 of 12 Cryptographic Module for SecureOSŪ v9.7 Security Policy 4. Cryptographic Key Management 4.1 Key Generation The CMSOS supports generation of DH, DSA, and RSA public-private key pairs. The CMSOS employs an ANSI X9.31 compliant random number generator for creation of asymmetric and symmetric keys. 4.2 Key Storage Public and private keys are provided to the CMSOS by the calling process, and are destroyed when released by the appropriate API function calls. The CMSOS 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 CMSOS. 4.4 Key Protection and Zeroization Keys residing in internally allocated data structures can only be accessed using the CMSOS 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 CMSOS provided API function calls provided for that purpose. Page 10 of 12 Cryptographic Module for SecureOSŪ v9.7 Security Policy Only the process that creates or imports AES or Triple-DES keys can use or export them. No persistent storage of key data is performed by the CMSOS. 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 CMSOS supports the following FIPS approved or allowed algorithms: Algorithm Validation Certificate Usage AES #295 encrypt/decrypt TDES #368 encrypt/decrypt Diffie-Hellman (allowed in FIPS mode) key agreement DSA #141 sign and verify PRNG #120 random number generation RSA (X9.31, PKCS #1.5) #85 sign and verify RSA encrypt/decrypt #85 key transport, key wrapping SHA-1 #368 hashing SHA-224 #368 hashing SHA-256 #368 hashing SHA-384 #368 hashing SHA-512 #368 hashing HMAC-SHA1 #106 message integrity HMAC-SHA224 #106 message integrity HMAC-SHA256 #106 message integrity HMAC-SHA384 #106 message integrity Page 11 of 12 Cryptographic Module for SecureOSŪ v9.7 Security Policy Algorithm Validation Certificate Usage HMAC-SHA512 #106 message integrity Table 4.5a The Diffie-Hellman (key agreement, key establishment) methodology supports 80 bits to 256 bits of encryption strength. The RSA key wrapping methodology supports 80 bits to 150 bits of encryption strength. The CMSOS supports the following non-FIPS approved algorithms: Algorithm Usage DES1 (non-compliant) encrypt/decrypt MD5 (allowed in FIPS mode for TLS) TLS interoperability Table 4.5b 1 Use of DES is non-compliant. Note DES is provided for backward compatibility with legacy applications and should not be used for new development or in FIPS mode. Page 12 of 12