Cryptographic Module for SecureOSŪ v9.7.1 by Secure Computing Corporation FIPS 1402 NonProprietary Security Policy Version 1.0 Level 1 Validation November 9, 2007 This document may be reproduced in its entirety without modification Cryptographic Module for SecureOSŪ v9.7.1 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 13 Cryptographic Module for SecureOSŪ v9.7.1 Security Policy 1. Introduction This document is the nonproprietary security policy for the Cryptographic Module for SecureOSŪ. 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 Cryptographic Module for SecureOSŪ (hereafter referred to as the CMSOS) is a software library supporting FIPSapproved cryptographic algorithms. For the purposes of the FIPS 1402 level 1 validation, the Cryptographic Module for SecureOSŪ v9.7.1 is a single shared library file named libcrypto.so. This module provides a Clanguage application program interface (API) for use by other processes that require cryptographic functionality. For FIPS 1402 purposes the CMSOS is classified as a multichip 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 2150D, with SecureOS v6.1 and a SidewinderŪ, Model 2150D with SecureOS v7. Page 3 of 13 Cryptographic Module for SecureOSŪ v9.7.1 Security Policy Secure Computing FIPS-140 Cryptographic Module Block Diagram Plaintext Cryptographic v1.0 Boundary Ciphertext Secure Computing ROM RAM Cryptographic Module CPU CPU Controller Peripherals Ethernet Plaintext Ciphertext Figure 2 2.1 Roles and Services The CMSOS meets all FIPS 1402 level 1 requirements for Roles and Services, implementing both CryptoUser and CryptoOfficer roles. As allowed by FIPS 1402, 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. · 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. · CryptoOfficer Role: Installation of the CMSOS on the host computer system. This role is assumed implicitly when the system administrator installs the CMSOS library Page 4 of 13 Cryptographic Module for SecureOSŪ v9.7.1 Security Policy 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 Keyed Hash (HMAC) User, Crypto Officer HMAC SHA1 key read/write/execute Message digest (SHS) 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, HMACSHA1 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 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. Page 5 of 13 Cryptographic Module for SecureOSŪ v9.7.1 Security Policy FIPS Interface Physical Port Module Interface Data Input Gigabit Ethernet ports API input parameters Data Output Gigabit 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.2 2.3 Self Tests The CMSOS performs both powerup 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 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 Algorithm Test AES KAT TripleDES KAT DSA pairwise consistency test, sign/verify RSA KAT PRNG KAT HMACSHA1 KAT Page 6 of 13 Cryptographic Module for SecureOSŪ v9.7.1 Security Policy Algorithm Test HMACSHA224 KAT HMACSHA256 KAT HMACSHA384 KAT HMACSHA512 KAT SHA1 KAT1 SHA224 KAT1 SHA256 KAT1 SHA384 KAT1 SHA512 KAT1 module integrity HMACSHA1 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 1402 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 1 Tested as part of the HMAC known answer tests. Page 7 of 13 Cryptographic Module for SecureOSŪ v9.7.1 Security Policy CMSOS 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 CMSOS2. If all components of the powerup selftest are successful then the CMSOS is in FIPS mode. The powerup selftests 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 powerup selftest failure can only be cleared by a successful FIPS_mode_set invocation. No operator intervention is required during the running of the selftests. 2.4 Mitigation of Other Attacks The CMSOS does not contain additional security mechanisms beyond the requirements for FIPS 1402 level 1 cryptographic modules. 2.5 Physical Security The CMSOS is comprised of software only and thus does not claim any physical security. 2 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 8 of 13 Cryptographic Module for SecureOSŪ v9.7.1 Security Policy 3. Secure Operation The SecureOSŪ 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 CMSOS 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 CMSOS is installed on the SidewinderŪ G2 Security Appliance and SidewinderŪ 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 HMACSHA1 of the CMSOS library file as tested by the CMVP is verified after installation of the CMSOS file on the SidewinderŪ G2 Security Appliance or SidewinderŪ. Upon initialization of the CMSOS, the module will run its powerup self tests. Successful completion of the powerup 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 selftests 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 and SidewinderŪ are supplied to customers as a turnkey system with no customer or enduser access to the CMSOS. Page 9 of 13 Cryptographic Module for SecureOSŪ v9.7.1 Security Policy 4. Cryptographic Key Management 4.1 Key Generation The CMSOS supports generation of DH, DSA, and RSA publicprivate 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 CryptoUser) 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 13 Cryptographic Module for SecureOSŪ v9.7.1 Security Policy Only the process that creates or imports 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 nonoverlapping 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 Since the module is a software toolkit, it does not ship with keys or CSPs, nor does it store or manage keys or CSPs. It is the responsibility of the host application to manage key generation using the module API and to perform other key management duties including key storage. The CMSOS supports the following FIPS approved or allowed algorithms: Algorithm Validation Usage Keys/CSPs Certificate AES #552 encrypt/decrypt AES keys 128, 192, 256 bits TDES #548 encrypt/decrypt TripleDES keys 168 bits DiffieHellman (allowed in FIPS key agreement DiffieHellman (key mode) agreement; key establishment methodology provides 80 to 256 bits of encryption strength; noncompliant for less than 80 bits of encryption strength) Page 11 of 13 Cryptographic Module for SecureOSŪ v9.7.1 Security Policy Algorithm Validation Usage Keys/CSPs Certificate DSA #225 sign and verify DSA keys 1024 bits PRNG #320 random number generation PRNG seed value and seed key 64 bits RSA (X9.31, PKCS #1.5, PSS) #248 sign and verify RSA keys 1024 to 16384 bits RSA encrypt/decrypt (allowed in FIPS key transport, key RSA (key wrapping; mode) wrapping key establishment methodology provides 80 to 256 bits of encryption strength; noncompliant for less than 80 bits of encryption strength) SHA1 #617 hashing N/A SHA224 #617 hashing N/A SHA256 #617 hashing N/A SHA384 #617 hashing N/A SHA512 #617 hashing N/A HMACSHA1 #293 message integrity N/A HMACSHA224 #293 message integrity N/A HMACSHA256 #293 message integrity N/A HMACSHA384 #293 message integrity N/A HMACSHA512 #293 message integrity N/A Table 4.5a The DiffieHellman (key agreement, key establishment) methodology supports 80 to 256 bits of encryption strength (noncompliant for less than 80 bits of encryption strength). The RSA key wrapping methodology supports 80 to 256 bits of encryption strength (non compliant for less than 80 bits of encryption strength). The CMSOS supports the following nonFIPS approved algorithms: Page 12 of 13 Cryptographic Module for SecureOSŪ v9.7.1 Security Policy Algorithm Usage MD5 (allowed in FIPS mode for TLS) TLS interoperability Table 4.5b Page 13 of 13