Novell International Cryptographic Infrastructure (NICI) NICI 2.7.1 Cryptographic Library FIPS 140-2 Level 1 Security Policy Version 1.4 March 12 2007 Novell Inc. Copyright 2007 Novell, Inc. All Rights Reserved NICI 2.7.1 FIPS 140-2 Level 1 Security Policy Legal Notices COPYRIGHT © 2007, Novell, Inc. Novell, Inc. makes no representations or warranties with respect to the contents or use of this documentation, and specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose. Further, Novell, Inc. reserves the right to revise this publication and to make changes to its content, at any time, without obligation to notify any person or entity of such revisions or changes. Further, Novell, Inc. makes no representations or warranties with respect to any software, and specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose. Further, Novell, Inc. reserves the right to make changes to any and all parts of Novell software, at any time, without any obligation to notify any person or entity of such changes. This product may require export authorization from the U.S. Department of Commerce prior to exporting from the U.S. or Canada. This document may be copied freely without the author's permission provided the document is copied in it's entirety without any modification. U.S. Patent Nos. 4,555,775; 5,157,663; 5,349,642; 5,455,932; 5,553,139; 5,553,143; 5,594,863; 5,608,903; 5,633,931; 5,652,854; 5,671,414; 5,677,851; 5,692,129; 5,758,069; 5,758,344; 5,761,499; 5,781,724; 5,781,733; 5,784,560; 5,787,439; 5,818,936; 5,828,882; 5,832,275; 5,832,483; 5,832,487; 5,859,978; 5,870,739; 5,873,079; 5,878,415; 5,884,304; 5,893,118; 5,903,650; 5,905,860; 5,913,025; 5,915,253; 5,925,108; 5,933,503; 5,933,826; 5,946,467; 5,956,718; 5,974,474. U.S. and Foreign Patents Pending. Novell, Inc. 1800 South Novell Place Provo, Utah 84606 U.S.A. www.novell.com Novell Trademarks Third-Party Trademarks All third-party trademarks are the property of their respective owners. NICI 2.7.1 Novell, Inc. ©2007 FIPS 140-2 Level 1 Security Policy Version 1.4 03/12/2007 Page 2 NICI 2.7.1 FIPS 140-2 Level 1 Security Policy Table of Contents 1 Introduction............................................................................................................................................................... 4 2 Security Policy.......................................................................................................................................................... 4 2.1 Cryptographic Modules.......................................................................................................................................................... 4 2.2 Module Interfaces.................................................................................................................................................................. 6 2.2.1 Data Input/Output Interface............................................................................................................................................ 6 2.2.2 Command/Status Interface............................................................................................................................................ 6 2.3 Roles and Services................................................................................................................................................................ 6 2.3.1 User Role ...................................................................................................................................................................... 6 2.3.2 Crypto-Officer Role ....................................................................................................................................................... 7 2.4 Finite State Machine Model................................................................................................................................................... 7 2.5 Physical Security.................................................................................................................................................................... 7 2.6 Cryptographic Key Management........................................................................................................................................... 7 2.6.1 FIPS Approved Key Generation..................................................................................................................................... 7 2.6.2 Key Distribution ............................................................................................................................................................. 7 2.6.2.1 NICI Wrapped Keys .............................................................................................................................................. 7 2.6.2.2 NICI Session Keys ................................................................................................................................................ 9 2.6.2.3 Key Wrapping Attributes ....................................................................................................................................... 9 2.6.3 Key Entry and Output .................................................................................................................................................... 9 2.6.3.1 Password-Based Encryption (PBE) Wrapped Keys ............................................................................................10 2.6.3.2 Key Injection and Extraction ................................................................................................................................ 10 2.6.3.3 Protocol Support ................................................................................................................................................. 10 2.6.4 Key Storage ................................................................................................................................................................ 10 2.6.4.1 Key Storage Keys ................................................................................................................................................ 10 2.6.5 Key Destruction ........................................................................................................................................................... 10 2.7 Cryptographic Algorithms.................................................................................................................................................... 12 2.8 EMI/EMC.............................................................................................................................................................................. 13 2.9 Self-Tests............................................................................................................................................................................. 13 2.9.1 Startup Self-Tests ....................................................................................................................................................... 13 2.9.1.1 Cryptographic Algorithms Test............................................................................................................................. 13 2.9.1.2 Software/Firmware Test....................................................................................................................................... 13 2.9.1.3 Critical Functions Test ......................................................................................................................................... 13 2.9.2 Conditional Self Tests ................................................................................................................................................. 13 2.9.2.1 Pair-Wise Consistency Tests (for public/private key pairs.) ............................................................................... 13 2.9.2.2 Continuous Random Number Test ......................................................................................................................13 3 FIPS 140-2 Level 1 Operation Requirements ........................................................................................................................ 14 3.1 Crypto-Officer Guidance................................................................................................................................................. 14 3.2 User Guidance................................................................................................................................................................ 14 APPENDIX A ­ CCS API Definitions......................................................................................................................................... 15 NICI 2.7.1 Novell, Inc. ©2007 FIPS 140-2 Level 1 Security Policy Version 1.4 03/12/2007 Page 3 NICI 2.7.1 FIPS 140-2 Level 1 Security Policy 1 Introduction The Novell International Cryptographic Infrastructure (NICI) consists of a set of components that have been implemented on a number of different platforms. Versions have been implemented on Novell's NetWare 6.5. This document describes the Security Policy for NICI version 2.7.1 to meet the FIPS 140-2 Level 1 requirements as it has been implemented for the following platforms: · Netware 6.5 Service Pack 3 2 Security Policy The Novell NICI 2.7.1 Cryptography Library Security Policy, conforms to FIPS 140-2 Level 1 as shown in the Table 1. FIPS140-2 TEST CATEGORY LEVEL Cryptographic Module 1 Specification Cryptographic Module Ports and 1 Interfaces Roles, Services, and 1 Authentication Finite State Model 1 Physical Security N/A Operational Environment 1 Cryptographic Key Management 1 EMI/EMC 1 Self Tests 1 Design Assurance 1 Mitigation of Other Attacks N/A Table 1. FIPS 140-2 Test Category Levels 2.1 Cryptographic Modules NICI consists of a set of software libraries(or set of of NLMs for Netware) designed to run on a wide variety of modern operating systems and hardware platforms. In this configuration, NICI is a shared library (.so or dll). In FIPS 140-2 terms, NICI consists of a set of hardware, software, and firmware that make up a "multi-chip standalone module." The module consists of the following components: NICI runs on one of the general purpose operating systems specified above running on commercially available hardware platforms. All releases of NICI 2.7.1 consists of a matched upper library, which is linked to the application, and a lower library that is installed on the workstation or server. NICI 2.7.1 Novell, Inc. ©2007 FIPS 140-2 Level 1 Security Policy Version 1.4 03/12/2007 Page 4 NICI 2.7.1 FIPS 140-2 Level 1 Security Policy Figure 1. Software block diagram The physical cryptographic boundary is defined by the server hardware. The logical cryptographic boundary encompasses the signed NLMs -- referred to as XLMs -- xmgr.xlm, xsup.xlm, xim.xlm, ccs.xlm, domxeng.xlm, expxeng.xlm, nulxeng.xlm. Since NICI must be able to store at least one permanent key, the Key Storage Key, in order to be able to securely wrap and unwrap other keys, that key is stored in a TDES encrypted form per user, encrypted under an embedded key encryption key, protected by the operating system's mechanisms. For FIPS purposes, the Key Storage Key is considered the be stored in plaintext. Stored NICI keys can be zeroized by reformatting the computer's hard drives. MABLE is the Module Authentication and Binding Library Extensions (patent issued) technology used to authenticate NICI to an application and to provide ongoing binding between an application and NICI as if the application is statically linked to NICI. Upper MABLE is statically linked to an application and contains the challenge generation, certificate verification, and ongoing binding mechanism functions. Lower MABLE is statically linked to NICI and contains the response-to-challenge generation, signature creation, and ongoing binding mechanism functions. NICI 2.7.1 Novell, Inc. ©2007 FIPS 140-2 Level 1 Security Policy Version 1.4 03/12/2007 Page 5 NICI 2.7.1 FIPS 140-2 Level 1 Security Policy Figure 2. Hardware Block Diagram 2.2 Module Interfaces FIPS 140-2 defines a cryptographic boundary, and as well as interfaces through which information is allowed to enter and leave the cryptographic boundary. Defining such interfaces is normally straightforward for developers of hardware modules, but developers of software modules are faced with the task of choosing an appropriate set of interface definitions. 2.2.1 Data Input/Output Interface FIPS 140-2 requires the definition of Data Input/Output (I/O) and Command/Status interfaces. NICI defines these interfaces through the Controlled Cryptographic Services (CCS) API. The API provides the means to Input and output data, and to determine the status of the module. The Data Input/Output and the Status interfaces are active only during the User and Crypto-Officer States. 2.2.2 Command/Status Interface The FIPS 140-2 Control interface is used to initiate the NICI Module. It is activated by the operating system when an application program asks the operating system to attach NICI and causes it to commence operation. It may also be activated when the operating system commands NICI to shut down. Otherwise, it is active only during the User and Crypto Officer States, if and when commands are issued via the API set. NICI has the following logical interfaces: data in, data out, control-in, and status out. These interfaces are supported by the API set. 2.3 Roles and Services Novell NICI 2.7.1 is supports both the Crypto-Officer and User roles. The following are the operations performed by each operator. Operation User Role Crypto Officer Role Install NICI X Upgrade NICI X Configure NICI X Zeroize Keys X Encrypt/Decrypt X X Generate Keys and Random Data X X Sign/Verify X X 2.3.1 User Role A "User" is an application program, running as a single or multiple process (perhaps multi-threaded), which has been linked with the Novell NICI interface library. This version of NICI supports multiple processes with different user identities with separation between such multiple instances relying on the access mechanisms provided by the operating system. Each instance of NICI has an identity and a separate memory space with access to a unique set of key materials. Authenticating to the operating system authenticates the application to NICI; as an application cannot use NICI unless it authenticates to the operating system first. After authentication to the User state, the User program is able to perform Cryptographic operations via the API set defined in the Controlled Cryptography Services Software Development Specification (CCS) document. The authentication mechanisms of the operating systems, were not tested for compliance to FIPS 140-2 standards. NICI maintains a set of persistent unique keys per user with independent seeding and key generation capability per process. The operating system maintains the separation of such set of keys in a multi-user (multiple operator) setting. Each operator may potentially have more than one process. Each operator is associated with a unique User NICI 2.7.1 Novell, Inc. ©2007 FIPS 140-2 Level 1 Security Policy Version 1.4 03/12/2007 Page 6 NICI 2.7.1 FIPS 140-2 Level 1 Security Policy ID. All processes with the same User ID have access to a unique set of keys. 2.3.2 Crypto-Officer Role A single Crypto-Officer role is supported in NICI, the NICI Administrator, as the user with Administrator privileges on the Operating System. Authenticating to the Operating System assigns the Crypto-Officer, or the NICI Administrator, role to the user. The purpose of the NICI Administrator is to setup, configure, reconfigure and uninstall the NICI software. In addition, the Crypto-Officer can zeroize the Key Storage Keys of the original NICI instance if required. The NICI Administrator is also the security administrator as defined by the Operating System. 2.4 Finite State Machine Model NICI has an embedded finite state machine that is compliant with the FIPS 140-2 specification. The finite state machine is described fully in a separate document that is submitted during the FIPS 140-2 level 1 validation process. 2.5 Physical Security This is not applicable to NICI as it is a software module. 2.6 Cryptographic Key Management NICI provides extensive cryptographic key management services and facilities, and is unique in addressing these requirements from a cross-platform, general-purpose networking perspective. Compatible key management is provided for all cryptographic modules, on all supported platforms, and for all algorithms, including secret key (symmetric) and public key (asymmetric) algorithms. Secret keys and private key are protected from unauthorized disclosure, modification, and substitution. Public keys are protected against unauthorized modification and substitution. NICI implements all key management functions, enforces key use policies, and provides algorithm management services to applications. NICI key use policies are comprised of key usage flags (encrypt, wrap, sign, etc.), key types (TDES, RSA, AES, etc.), and algorithms (RSA, TDES, DSA, etc.). A key management key must have wrap and key management encrypt key usage flags set in order to wrap keys. Key type must also match the algorithm used with a particular key. For instance, a TDES key can not be used with the AES algorithm. These combined constitute NICI key use policies. 2.6.1 FIPS Approved Key Generation The G function in the pseudo-random generator described in FIPS 186-2 is constructed using the SHA-1 hash function with b=512. (see http://csrc.nist.gov/fips/fips186-2.pdf). 2.6.2 Key Distribution NICI key distribution capabilities comply with FIPS 171 options 1 (key exchange role), 4 (MAC), 5 (key and IV generation), 6 (key generation techniques), and 14 (send IV). 2.6.2.1 NICI Wrapped Keys Wrapping of keys is the mechanism that NICI provides for applications to obtain the value of secret or private keys for storage outside of NICI or for distribution among different instances of NICI. Various keys are provided by NICI for key wrapping. The same key (or corresponding private key of the same key pair) must subsequently be used to unwrap a wrapped key in order for it to be reloaded into NICI. The key-management keys discussed below are generated with attributes conforming to the key management usage policies. Those that are described below as being persistent per user are stored securely by NICI as an integral part of its infrastructure to persist across system shutdowns and restarts. The persistent NICI key management keys are TDES or RSA keys. All Triple DES, and HMAC-SHA1 keys are generated and used in FIPS mode. NICI uses HMAC-SHA1 to provide integrity of persistent keys in FIPS mode. NICI uses RSA digital signatures to sign certificates and to encrypt keys in NICI 2.7.1 Novell, Inc. ©2007 FIPS 140-2 Level 1 Security Policy Version 1.4 03/12/2007 Page 7 NICI 2.7.1 FIPS 140-2 Level 1 Security Policy FIPS mode. NICI does not use RSA for data encryption in FIPS mode. No means is provided for unauthorized applications to obtain any of the secret or private key-management keys for storage or distribution outside of NICI. Key-wrapping keys may also be generated at the request of applications, which are then responsible for their secure storage (for example, by wrapping with any of the keys described in this section). NICI keys are listed in the following table. SENSITIVE is an attribute of a key set at key generation time, and EXTRACT is a key usage flag. They are enforced by the NICI key use policies. Other NICI key attributes and key usage flags are described in the CCS Software Development Specification document. Key Name Key Type / Algorithm Key Usages Description Storage and Zeroization STORAGE Triple-DES WRAP, UNWRAP, Symmetric key wrapping key, Stored on disk in the xmgrcfg SENSITIVE generated and maintained by file in the /var/opt/novell/nici NICI. FIPS approved. directory. It is stored in an obfuscated format, but for FIPS purposes it is stored in plain text. SESSION Triple-DES WRAP, UNWRAP, Symmetric key-wrapping key Stored in the memory. SENSITIVE per connection between a Zeroized when the application client and server. Generated closes the context associated by NICI, present while the with the key. connection is active. FIPS approved. CA RSA SIGN, VERIFY, NICI's machine-unique CA It is stored in the xmgrcfg file SENSITIVE key-pair, 1024 bits. in the /var/opt/novell/nici/ Generated and maintained by directory. It is stored in an NICI. Not FIPS approved. obfuscated format, but for FIPS purposes it is stored in plain text. PARTITION Triple-DES WRAP, UNWRAP, Security Domain Keys, key Stored on disk in the SENSITIVE wrapping purposes only. nicisdi.key file in the Generated and maintained by /var/opt/novell/nici directory. NICI. FIPS approved. This is encrypted with the Storage key. Zeroized when the storage key is deleted or lost . FOREIGN Any EXTRACT and any, Use of these keys are not Could be stored in memory or but not SENSITIVE FIPS 140-2 approved. disk depending on the Generator unknown, maybe application. NICI. XKEY Random Value Used for seeding Generated by NICI using an Stored in memory. FIPS approved entropy collection method. PRNGs Only used as a seed value for random number generation. Other DES, Triple-DES, DSA, Any, but not These keys are generated by Stored in memory. FIPS-RSA (signature), EXTRACT NICI using a FIPS approved algorithm. FIPS approved. FIPS-RSA (key distribution), HMAC-SHA1 (signature) Other RSA (encryption) Any, but not NICI-generated, but not FIPS Stored in memory EXTRACT approved. It is the application's responsibility to use the FIPS approved APIs, algorithms, and keys to maintain the FIPS 140-2 mode of operation. Use of any one of the non-FIPS algorithms or non-FIPS approved APIs would invalidate the FIPS mode of operation. 2.6.2.2 NICI Session Keys Starting with version 2.7.1, NICI operates in a server mode. It supports NICI operating in a client mode from any previous versions. A unique session wrapping key is shared between a NICI client instance and a NICI server instance. NICI Session wrapping keys are intended only for wrapping of keys for distribution between clients and NICI 2.7.1 Novell, Inc. ©2007 FIPS 140-2 Level 1 Security Policy Version 1.4 03/12/2007 Page 8 NICI 2.7.1 FIPS 140-2 Level 1 Security Policy servers, or between two servers. Each session wrapping key is a transient symmetric key. Session wrapping keys can not be extracted in encrypted or unencrypted form for any kind of persistent storage outside of NICI; they are in- memory transient keys useable for key wrapping and unwrapping during the lifetime of a session as defined by the application (typically a network connection to a server/client). The terms server mode and client mode refer to the mode in which a user application operates and does not have any affect on the module's operation. 2.6.2.3 Key Wrapping Attributes Key wrapping is a secure way of transferring keys in and out of NICI. It has a confidentiality mechanism for the key value and an integrity mechanism for all attributes. A wrapped key includes all attributes of a key, such as key usage flags, key ID, and key value. The key value attribute is encrypted in the wrapping key to provide confidentiality. A SHA1 hash is computed over the entire wrapped key (attributes and the encrypted key value), and is encrypted by the wrapping key to generate a MAC. This provides integrity of the wrapped key. The user specifies the encryption algorithm (wrapping algorithm) and the wrapping key. NICI public-key key-wrapping keys may be stored or transmitted outside of NICI in X.509-compliant certificates for which NICI itself is the certification authority. These keys may not be used as server or end-user keys. Keys that are wrapped using a public key cannot have their authenticity guaranteed without some additional mechanism that makes use of either a secret or private key whose value is not exposed outside of NICI. For example, a digital signature would serve this purpose. Such signatures are not required as part of the wrapping mechanism because that would excessively limit the flexibility and use of the key distribution mechanism in NICI, as well as the possible performance impact. At the discretion of an application requesting the wrapping, the integrity check, such as HMAC-SHA1 or a DSA signature, on the wrapped key's attributes may optionally be calculated using a key management key, independent of the wrapping key that the application chooses to protect sensitive key attributes. Otherwise, these attributes must be considered only advisory in nature. To maintain the integrity of NICI's own protection mechanisms, keys whose authenticity is not assured by one of the mechanisms described here cannot be used to wrap internal NICI keys. 2.6.3 Key Entry and Output NICI does not possess a manual key entry method; all keys are entered electronically. Aside from the Crypto- Officer's role in distributing configuration data (used under the control of the Crypto Operator at installation time), all keys are entered under the User's control via the API interface. Typical key entry to NICI is done via key unwrapping, i.e., by decrypting the key value, and verifying the integrity of the attributes associated with the key. NICI maintains a set of key wrapping keys for this purpose. See Key Storage Keys section for details. There should seldom, if ever, be a requirement for a User to directly enter into or output from NICI a raw, plaintext private or secret key, except for compatibility with legacy systems. There are two exceptions to this general rule. The first is for compatibility with other systems, where the human user has a personal cryptographic key and no way to securely store it except for a password-based encryption mechanism. The second is not really a key injection or extraction per se, but rather a protocol-dependent key distribution mechanism. The integrity and the confidentiality of such keys are provided by the protocol. Raw access to all keys are controlled by three independent controls in NICI: 1) Key's usage must have EXTRACT bit set, 2) Key's usage must not have the SENSITIVE attribute set, and 3) The user must call the CCS_ExtractKey API. An application does not have access to plaintext secret keys unless it calls the CCS_ExtractKey API. 2.6.3.1 Password-Based Encryption (PBE) Wrapped Keys Password-Based Encryption (PBE) is frequently required when interfacing with other, non-NICI systems such as browsers, S/MIME e-mail clients, and certain authentication methods. Since many of these applications are software-based, and many of them run on non-trusted platforms such as Windows 95/98, the only economically NICI 2.7.1 Novell, Inc. ©2007 FIPS 140-2 Level 1 Security Policy Version 1.4 03/12/2007 Page 9 NICI 2.7.1 FIPS 140-2 Level 1 Security Policy feasible way of protecting those keys is to use a Password-Based Encryption mechanism. The password-based encryption API set is not FIPS 140-2 approved. NICI implements the PKCS #12 recommendation for password-based encryption and decryption. With this scheme, the key to be protected is encrypted in a randomly generated intermediate key of suitable strength (depending on import requirements and algorithm availability). The intermediate key is created by hashing an arbitrarily long password or passphrase entered by the user, and then truncating the key as required to meet the key management policy constraints. PKCS#12 builds into this scheme a deliberate slow-down mechanism that requires hashing and rehashing the password many, many times before decrypting the intermediate key. This is to provide some level of protection against an off-line password guessing attack. The time taken is small by human standards (a second or less) but the amount of computer time required to do an exhaustive search would be very large. As noted above, use of the password-based encryption API set is not FIPS 140-2 approved. 2.6.3.2 Key Injection and Extraction The NICI CCS API documentation defines key injection and extraction functions, but their use would invalidate the FIPS 140-2 mode of operation. 2.6.3.3 Protocol Support At the present time, protocol support for unwrapping keys that have been wrapped in a User's private key has been provided for SSL/TLS and IPSEC. Use of these APIs is not approved for the FIPS 140-2 mode. 2.6.4 Key Storage When keys have been unwrapped within NICI (that is, within the confines of the NICI cryptographic module boundaries), they are kept in the clear(in plaintext form), in order to minimize the latency and overhead when using them. 2.6.4.1 Key Storage Keys As mentioned previously, per-user Key Storage Keys are written to the operating system supported storage, which is protected against unauthorized access by the operating system's mechanisms. Whenever a Key Storage Key is used to wrap another key for storage, the Key ID of that Key Storage Key is included in the wrapped key. In this manner, any previously generated, wrapped, and stored keys will be accessible, even if a new Key Storage Keys is generated later. The Key ID contained in the wrapped key format also includes a unique ID to that particular machine and process, in order to help ensure that the correct Key Storage Key is being used to unwrap a particular key. At a minimum, this protects against the possibility that the wrapped key has been moved, migrated, or merged onto a new system, perhaps along with the data it protects, but somehow the correct Key Storage Key has been left behind. The integrity check in wrapped keys will catch this. Should some form of compromise of the Key Storage Keys file occur, all previously generated and wrapped keys on that server would potentially be compromised as well. This is unavoidable in a software-based key management system. However, because of the entropy added at NICI instantiation time, the attacker would not gain access to the new keys, except by re-attacking the Key Storage Key file. 2.6.5 Key Destruction When the particular NICI context associated with the usage of a set of keys is closed, all keys associated with that context within NICI are zeroized and destroyed in memory. When NICI itself is closed within a given process, assuming it is closed gracefully and not by a system crash or power outage, all keys in all contexts are zeroized. The destruction of the current and all previous Key Storage Keys in the Key Storage Keys file should be an extremely rare event, since it would effectively make it impossible to recover any previously wrapped keys. The only time this would be likely to occur would be if a particular machine were to be decommissioned and taken out of service, presumably after all of the information had been migrated to another machine. Since the ability to zeroize all keys might make possible a very serious Denial of Service attack, NICI does not provide a specific tool or function to cause this to occur. Instead, in this event it is the Crypto Operator's responsibility to perform a complete low-level hardware formatting and reinitialization of the hard disk, thoroughly NICI 2.7.1 Novell, Inc. ©2007 FIPS 140-2 Level 1 Security Policy Version 1.4 03/12/2007 Page 10 NICI 2.7.1 FIPS 140-2 Level 1 Security Policy scrubbing the disk to make certain there is no readable residue. NICI 2.7.1 Novell, Inc. ©2007 FIPS 140-2 Level 1 Security Policy Version 1.4 03/12/2007 Page 11 NICI 2.7.1 FIPS 140-2 Level 1 Security Policy 2.7 Cryptographic Algorithms NICI 2.7.1 supports the following FIPS approved algorithms: Algorithm Key Size(s) Algorithm Certificate # AES (FIPS 197) 128 bits, 256 bits 432 TDES (FIPS 46-3 and 81) 112-bit and 156-bits 461 SHA (SHA-1, SHA 256, SHA 384) (FIPS 128, 256, 384, 512 bit 502 180-1) hashes RSA (PKCS#1) 1024, 2048, 4096 bits 163 DSA (FIPS 186-2) 1024 bits 179 HMAC SHA-1 (FIPS 198) Keyed Hash Algorithm 204 Non-FIPS approved algorithms that also are supported include: 1. Diffie-Hellman (key establishment methodology provides 80 bits of encryption strength) 2. ECDSA 3. EC DH (key establishment methodology provides between 80 and 192 bits of encryption strength) 4. DES 5. MD2 (RFC 1319) 6. MD4 (RFC 1320) 7. MD5 (RFC 1321) 8. HMAC-MD5 (RFC 2104) 9. RC2 (RFC 2268) 10. RC4 11. RC5 (RFC 2040) 12. CAST128 (RFC 2144) 13. Password Based Encryption, six algorithms (PKCS#12) 14. UNIX* Crypt 15. LMdigest (CIFS) 16. TLS-KeyExchange-RSASign 17. NetWarePassword.(Novell) 18. X9.62 PRNG The Diffie-Hellman algorithm is allowed in a FIPS mode of operation. The following Elliptic Curve key sizes are implemented but not tested for FIPS. ECDSA (FIPS 186-2) Special Curves specified in FIPS 186-2 for the key sizes and Curves defined in ANSI X9.62 ­ 163, 176, 191, 192, 208, 224, 233, 239, 256, 272, 283, 304, 359, 368, 384, 409, 521, and 571 bits When only FIPS approved algorithms are used, NICI can be said to be functioning in FIPS mode. If any non-FIPS approved algorithm (numbers 2 and 4-18) is used, NICI is running in non-FIPS mode. It is the application programmer's responsibility to enforce FIPS and Non-FIPS modes of operation. The module implements the FIPS approved PRNG described in Appendix 3.1 of the FIPS 186-2 standard. 2.8 EMI/EMC This is not applicable to NICI as it is a software module. NICI 2.7.1 Novell, Inc. ©2007 FIPS 140-2 Level 1 Security Policy Version 1.4 03/12/2007 Page 12 NICI 2.7.1 FIPS 140-2 Level 1 Security Policy 2.9 Self-Tests NICI conforms to the FIPS 140-2 Level 1 requirements for self-test. The required start-up self-tests are performed every time the NICI is started by the operating system, prior to transitioning to the User state. If the self-tests do not run correctly, NICI will not start, and an error indication will be returned via the API. 2.9.1 Startup Self-Tests NICI satisfies the requirements for FIPS 140-2 Level 1 for Power-up Self-Tests. 2.9.1.1 Cryptographic Algorithms Test Known answer tests are performed for RSA, DSA, ECDSA, TDES, AES, SHA, HMAC-SHA-1 and PRNG implementation upon startup. Pair-wise consistency tests are performed for RSA, DSA and ECDSA upon startup. 2.9.1.2 Software/Firmware Test On Netware systems, the integrity self-check is a combination of HMAC-SHA1 and a RSA based signature verfication mechanism. The XIM is the first module (NLM) loaded and it performs a HMAC-SHA1 check on itself. If this is successful, the XIM loads the other modules after performing an RSA based signature check on each of the modules. In all these cases, if any check fails NICI will give out an error message and will become unusable. 2.9.1.3 Critical Functions Test The nature and design of NICI precludes successful completion of the cryptographic algorithm tests and the Software/Firmware tests without all critical functions operating properly. Successful completion of these tests is sufficient to indicate that all critical functions are operating properly. 2.9.2 Conditional Self Tests The following tests are performed as specified for each test: 2.9.2.1 Pair-Wise Consistency Tests (for public/private key pairs.) When a public/private key pair is generated the key pair is tested for pair-wise consistency. The public key is used to encrypt a plaintext value and checked to ensure that an identity mapping did not occur, and then the private key is used to decrypt that value and the value is compared to the original. If the values are not identical, the tests fails. If the keys are to be used only for the calculation of a signature, then the consistency is tested by the calculation and verification of a signature. These tests are applied to RSA, DSA and ECDSA keys. 2.9.2.2 Continuous Random Number Test The continuous random number generator tests specified in FIPS PUB 140-2. Security Requirements for Cryptographic Modules, Section 4.11.2 (see http://www.itl.nist.gov/fipspubs/fip140-2.htm or http://csrc.nist.gov/fips/fips140-2.pdf), are applied to the operating specific random entropy generator routines, prior to their being used to generate a cryptographic key, seed, or cryptographic random number. They are applied independently, both before and after any cryptographic processing to add entropy or whitening. This will test both the entropy generator and the results of the key generation function, etc. 3 FIPS 140-2 Level 1 Operation Requirements 3.1 Crypto-Officer Guidance The following steps should be followed by the Crypto-Officer to ensure that NICI is installed in a FIPS 140-2 Level 1 compliant mode: ­ The NICI system supported installation mechanism should be obtained from the proper web site. (http://download.novell.com/) NICI 2.7.1 Novell, Inc. ©2007 FIPS 140-2 Level 1 Security Policy Version 1.4 03/12/2007 Page 13 NICI 2.7.1 FIPS 140-2 Level 1 Security Policy ­ NICI should always be installed using the system supported installation mechanism. Manually copying the configuration files and libraries into their respective locations does not ensure that the permissions on the files are set properly and should not be done. ­ The operating system on which NICI has been installed should be used in single-user mode. 3.2 User Guidance The following steps should be followed to run NICI in a FIPS 140-2 Level 1 compliant mode of operation. ­ To ensure that NICI operates in an approved mode of operation, the user should not use non-FIPS approved algorithms. Novell recommends the following steps to be followed to ensure smooth operation: ­ The Crypto-Officer must ensure that the operating system is properly installed with the latest security patches. ­ Once used NICI's keys should not be deleted ­ Configuration files and license key, archive files should not be updated out-of-band. This makes NICI regenerate user keys, thus making NICI unusable. Every user has their Critical Security Parameters stored in a separate directory inside the /var/opt/novell/nici/ directory, to which the user has complete access. The Crypto-Officer has complete access to even the initialization files in the base /var/opt/novell/nici/ directory (not through the API but through the console). APPENDIX A ­ CCS API Definitions For complete descriptions, please refer to the Controlled Cryptography Services Development Specifications document available from Novell. NICI 2.7.1 Novell, Inc. ©2007 FIPS 140-2 Level 1 Security Policy Version 1.4 03/12/2007 Page 14 NICI 2.7.1 FIPS 140-2 Level 1 Security Policy API Description CCS_Init Initializes the CCS library CCS_Shutdown Closes the CCS library CCS_GetInfo Return information about the CCS interface CCS_GetPolicyInfo Determines the policy constraints on key attributes for a given key type and usage CCS_GetKMStrength Returns the key management strength level CCS_GetRandom Returns a random number CCS_GetAlgorithmInfo Obtain information about a specific algorithm. CCS_GetAlgorithmList Obtain information about the algorithms available in the system. CCS_GetMoreAlgorithmInfo Obtain variable-length information about an algorithm. CCS_CreateContext Create a cryptography context. CCS_DestroyContext Destroy a cryptography context. CCS_DestroyObject Destroy a CCS object. CCS_FindObjectsInit Initialize a search for objects that match a template. CCS_FindObjects Continue a search for objects that match a template. CCS_GetAttributeValue Obtain the value of one or more object attributes. CCS_SetAttributeValue Modify the values of one or more object attributes. CCS_DataEncryptInit Initialize a data encryption operation. CCS_Encrypt Encrypt single-part data. CCS_EncryptUpdate Continue a multi-part encryption operation. CCS_EncryptFinal Finish a multi-part encryption operation. CCS_EncryptRestart Reinitialize an encryption operation. CCS_DataDecryptInit Initialize a data decryption operation. CCS_Decrypt Decrypt encrypted data in a single part. CCS_DecryptUpdate Continue a multi-part decryption operation. CCS_DecryptFinal Finish a multi-part decryption operation. CCS_DecryptRestart Reinitialize a decryption operation. CCS_SetNewIV Sets a new IV CCS_Obfuscate Obfuscates an input string. CCS_DeObfuscate De-obfuscates an input string. CCS_pbeEncrypt Encrypt data in a single part using a password and password-based algorithm as described in PKCS#12. CCS_pbeDecrypt Decrypt data in a single part using a password and password-based algorithm as described in PKCS#12. CCS_pbeSign Generate signature for input data in a single part using a password and password- based algorithm as described in PKCS#12. CCS_pbeVerify Verify input data and its signature in a single part using a password and password- based algorithm as described in PKCS#12. CCS_pbeShroudPrivateKey Encrypt a PKCS#8 private key using a password and password-based algorithm as described in PKCS#5 or PKCS#12. CCS_pbeUnshroudPrivateKey Decrypt and load an encrypted PKCS#8 private key using the password and the password-based algorithm as described in PKCS#12. CCS_LoadPFXPrivateKeyWithPassword Loads zero or more private keys encrypted in a password from a PKCS#12 PFX structure. See PKCS#12 document for details. Only PKCS#8 private keys are supported. CCS_LoadPFXCertificateWithPassword Loads zero or more X.509 certificates and public keys in those certificates from a PKCS#12 PFX structure. The certificates either can be encrypted in a safe bag or can be in plain form. See PKCS#12 and RFC 2459 documents for details. CCS_DigestInit Initialize a message-digesting operation. CCS_Digest Digest data in a single part. CCS_DigestUpdate Continue a multi-part message-digesting operation. CCS_DigestFinal Finish a multi-part message-digesting operation. CCS_DigestRestart Reinitialize a message-digesting operation. CCS_SignInit Initialize a signature operation. CCS_Sign Sign data in a single part. CCS_SignUpdate Continue a multi-part signature operation. CCS_SignFinal Finish a multi-part signature operation. CCS_SignRestart Reinitialize a signature operation. CCS_SignRecoverInit Initialize a signature operation with data recovery. CCS_SignRecover Sign data in a single part, with data recovery. CCS_SignRecoverRestart Reinitialize a signature operation with data recovery. CCS_VerifyInit Initialize a verification operation. CCS_Verify Verify data in a single part. NICI 2.7.1 Novell, Inc. ©2007 FIPS 140-2 Level 1 Security Policy Version 1.4 03/12/2007 Page 15 NICI 2.7.1 FIPS 140-2 Level 1 Security Policy CCS_VerifyUpdate Continue a multi-part verification operation. CCS_VerifyFinal Finish a multi-part verification operation. CCS_VerifyRestart Reinitialize a verification operation. CCS_VerifyRecoverInit Initialize a signature verification operation with data recovery. CCS_VerifyRecover Verify a signature on data in a single part, with data recovery. CCS_VerifyRecoverRestart Reinitialize a verification operation with data recovery. IKE_Sign Sign using an IKE Authentication Phase 1 authentication algorithm. The algorithms and mechanisms are described in RFC 2409: The Internet Key Exchange. IKE_Verify Verify using an IKE Authentication Phase 1 authentication algorithm. The algorithms and mechanisms are described in RFC 2409: The Internet Key Exchange. CCS_GenerateKey Generate a secret key. CCS_GenerateKeyPair Generate a public-key/private-key pair. CCS_WrapKey Wrap (i.e. encrypt) a key for storage or distribution external to CCS. CCS_UnwrapKey Unwrap (i.e. decrypt) a key. CCS_InjectKey This is the raw (i.e., plaintext) key injection function that is used for legacy applications with raw key access, and required to use NICI with their existing raw keys. CCS_ExtractKey Extract attributes of a key, including its value (NICI_A_KEY_VALUE) attribute. CCS_LoadCertificate Load a public-key certificate, verify its signature and load the resulting public key. CCS_LoadSelfSignedCertificate Load a self-signed public-key certificate, verify its signature and load the resulting public key. CCS_LoadUnverifiedCertificate Load a public-key certificate and the resulting public key without verifying the certificate signature. CCS_GenerateCertificate Create and sign a public-key certificate. CCS_GenerateCertificateFromRequest Create and sign a public-key certificate whose public key is provided by a PKCS #10 Certification Request. CCS_GetLocalCertificate Return a public-key certificate or local portion of the certification path for one of the NICI-predefined public keys. CCS_GetCertificate Return a public-key certificate or complete certification path for one of the NICI- predefined public keys. CCS_GenerateKeyExchangeParameters This is the parameter generation stage of a key agreement algorithm. CCS_KeyExchangePhase1 This is the phase 1 of a key exchange algorithm. CCS_KeyExchangePhase2 This is the phase 2 of a key exchange algorithm. NICI 2.7.1 Novell, Inc. ©2007 FIPS 140-2 Level 1 Security Policy Version 1.4 03/12/2007 Page 16 NICI 2.7.1 FIPS 140-2 Level 1 Security Policy NICI 2.7.1 Novell, Inc. ©2007 FIPS 140-2 Level 1 Security Policy Version 1.4 03/12/2007 Page 17