Security Policy 02.07.19 RSA BSAFE® Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy Level 1 with Level 2 Roles, Services and Authentication This document is a non-proprietary security policy for the RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 (Crypto-J JSAFE and JCE Software Module) security software. This document may be freely reproduced and distributed whole and intact including the copyright notice. Contents: Preface .............................................................
RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy Level 1 with Level 2 Roles, Services and Authentication Preface This document is a non-proprietary security policy for the Crypto-J JSAFE and JCE Software Module from RSA Security LLC, a Dell Technologies company (RSA).
RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy Level 1 with Level 2 Roles, Services and Authentication Document Organization This document explains the Crypto-J JSAFE and JCE Software Module features and functionality relevant to FIPS 140-2, and contains the following sections: • This section, Preface provides an overview and introduction to the Security Policy. • The Cryptographic Module, describes the module and how it meets the FIPS 140-2 Security Level 2 requirements.
RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy Level 1 with Level 2 Roles, Services and Authentication 1 The Cryptographic Module This section provides an overview of the module, and contains the following topics: • Introduction • Module Characteristics • Module Interfaces • Roles, Services and Authentication • Cryptographic Key Management • Cryptographic Algorithms • Self-tests. 1.
RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy Level 1 with Level 2 Roles, Services and Authentication The following table lists the certification levels sought for the JCM for each section of the FIPS 140-2 specification.
RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy Level 1 with Level 2 Roles, Services and Authentication 1.2.2 Affirmation of Compliance for other Operating Environments Affirmation of compliance is defined in Section G.5, “Maintaining Validation Compliance of Software or Firmware Cryptographic Modules,” in Implementation Guidance for FIPS PUB 140-2 and the Cryptographic Module Validation Program.
RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy Level 1 with Level 2 Roles, Services and Authentication – – Android 8.x • ARM v7 (32-bit) • ARM v8 (32-bit) • ARM v8 (64-bit) • x86 (32-bit). Android 9.0 • • HPE – • HP-UX 11.31 • Itanium® 2 (32-bit) HP JDK 8.0 • Itanium 2 (64-bit) HP JDK 8.0. IBM – – • AIX® 7.1 • PowerPC® (32-bit) IBM JDK 8.0 • PowerPC (64-bit) IBM JDK 8.0. AIX 7.2 • PowerPC (32-bit) IBM JDK 8.0 • PowerPC (64-bit) IBM JDK 8.0.
RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy Level 1 with Level 2 Roles, Services and Authentication – Windows 10 Enterprise • – Windows Server 2008 SP2 • – x86_64 (64-bit) IBM JDK 8.0, Oracle JDK 8.0 and 9.0.1. Oracle – – • x86_64 (64-bit) IBM JDK 8.0, Oracle JDK 8.0 and 9.0.1. Windows Server 2016 • • x86_64 (64-bit) IBM JDK 8.0, Oracle JDK 8.0 and 9.0.1. Windows Server 2012 R2 • – x86_64 (64-bit) IBM JDK. 8.0, Oracle JDK 8.0.
RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy Level 1 with Level 2 Roles, Services and Authentication 1.3 Module Interfaces As a multi-chip standalone module, the physical interface to the JCM consists of a keyboard, mouse, monitor, serial ports and network adapters. The underlying logical interface to the module is the API, documented in the relevant API Javadoc.
RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy Level 1 with Level 2 Roles, Services and Authentication 1.4 Roles, Services and Authentication The JCM is designed to meet all FIPS 140-2 Level 2 requirements for Roles, Services and Authentication, implementing both a Crypto Officer role and a Crypto User role. Role-Based Authentication is used for these roles. This authentication mechanism uses 512-bit (64 byte) PINs generated using an Approved Random Number Generator, HMAC DRBG.
RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy Level 1 with Level 2 Roles, Services and Authentication 1.4.2 Crypto User Role The Crypto User Role performs general security services, including cryptographic operations and other approved security functions. After installation and initialization, authentication is required to assume the Crypto User Role. An operator can assume the Crypto User Role by constructing a FIPS140Context object where the role is specified as ModuleConfig.
RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy Level 1 with Level 2 Roles, Services and Authentication The JCM provides services which are available for both FIPS 140-2 and non-FIPS 140-2 usage. For a list of FIPS 140-2 approved and FIPS 140-2 allowed algorithms, see Table 9. The following table lists the Services available only to the Crypto User role provided by the JCM in terms of the module interface.
RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.
RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.
RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.
RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.
RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.
RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.
RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy Level 1 with Level 2 Roles, Services and Authentication Table 5 Services Available only to the Crypto User Role (continued) Services Available only to the Crypto User Role Key Derivation: KDF clearSensitiveData clone generate getCryptoModule Algorithms allowed for FIPS 140-2 usage HKDF KDFTLS10 (For use with TLS versions 1.0 and 1.1) KDFTLS12 (For use with TLS version 1.
RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.
RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy Level 1 with Level 2 Roles, Services and Authentication 1.5 Cryptographic Key Management Cryptographic key management is concerned with generating and storing keys, protecting keys during use, zeroizing keys when they are no longer required and managing access to keys. 1.5.1 Key Generation The module supports the generation of the DSA, RSA, and Diffie-Hellman (DH) and ECC public and private keys.
RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.
RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy Level 1 with Level 2 Roles, Services and Authentication 1.5.5 Key Access An authorized operator of the module has access to all key data created during JCM operation. The following table lists the different services provided by the module with the type of access to keys or CSPs.
RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy Level 1 with Level 2 Roles, Services and Authentication 1.6 Cryptographic Algorithms The JCM offers a wide range of cryptographic algorithms. This section describes the algorithms that can be used when operating the module in a FIPS 140-2 compliant manner. The following table lists the FIPS 140-2 approved and FIPS 140-2 allowed algorithms that can be used when operating the module in a FIPS 140-2 compliant way.
RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.
RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy Level 1 with Level 2 Roles, Services and Authentication The following lists all other available algorithms in the JCM that are not allowed for FIPS 140-2 usage. These algorithms must not be used when operating the module in a FIPS 140-2 compliant way.
RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy Level 1 with Level 2 Roles, Services and Authentication 1.7 Self-tests The module performs power-up and conditional self-tests to ensure proper operation. If the power-up self-test fails, the module is disabled and throws a SecurityException. The module cannot be used within the current JVM. If the conditional self-test fails, the module throws a SecurityException and aborts the operation.
RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy Level 1 with Level 2 Roles, Services and Authentication By default, all Cryptographic Algorithm tests are run at power-up. However, if configured to do so, the module will run all of the power-up self-tests when first loaded in an operational environment, and run only the Software Integrity Test on subsequent restarts. 1.7.
RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy Level 1 with Level 2 Roles, Services and Authentication 2 Secure Operation of the Module The following guidance must be followed in order to operate the module in a FIPS 140-2 mode of operation, in conformance with FIPS 140-2 requirements. Note: The module operates as a Validated Cryptographic Module only when the rules for secure operation are followed. 2.
RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy Level 1 with Level 2 Roles, Services and Authentication 2.2 Security Roles, Services and Authentication Operation The Crypto Officer is responsible for installing and initializing the module for operation, as specified in the 2.1 Module Configuration section. Once this is complete, the module is ready for operation. During operation, the PINs created during module initialization (using the ModuleConfig.
RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy Level 1 with Level 2 Roles, Services and Authentication 2.3.1 Crypto User Guidance on Algorithms • The Crypto User must only use algorithms approved for use in a FIPS 140-2 mode of operation, as listed in Table 9. • Only FIPS 140-2 Approved DRBGs may be used for generation of keys (asymmetric and symmetric).
RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy Level 1 with Level 2 Roles, Services and Authentication • The AES-GCM cipher used for the TLS protocol as the cipher implementation complies with SP 800-52 and is compatible with RFC 5288 if the IV is configured as follows: The four-byte salt derived from the TLS handshake process is input using the parameter PARTIAL_IV during cipher initialization. This is used as the first four bytes of IV.
RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy Level 1 with Level 2 Roles, Services and Authentication • When generating RSA key pairs for signatures or key transport, generation shall comply with the following: – the KEY_TYPE parameter must be omitted or have a value of 0. – the KEY_BITS parameter must have value 2048, 3072 or 4096. – the SECURITY_STRENGTH parameter may be input. Acceptable values are: – • 112, when used for KEY_BITS of 2048.
RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy Level 1 with Level 2 Roles, Services and Authentication • • The iteration count shall be selected as large as possible, a minimum of 1000 iterations is recommended. • The maximum key length is (232 -1)*b, where b is the digest size of the hash function. • The key derived using PBKDF can be used as referred to in SP 800-132, Section 5.4, option 1 and 2.
RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy Level 1 with Level 2 Roles, Services and Authentication 2.3.2 Crypto User Guidance on Obtaining Assurances for Digital Signature Applications The module provides support for the FIPS 186-4 standard for digital signatures. The following gives an overview of the assurances required by FIPS 186-4.
RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy Level 1 with Level 2 Roles, Services and Authentication Table 11 Verifier Requirements (continued) FIPS 186-4 Requirement Module Capabilities and Recommendations Obtain assurance of the validity of the public key. The module provides APIs to explicitly validate the public key according to SP 800-89. For the JCM API, PublicKey.isValid(SecureRandom secureRandom) Outside the scope of the module.
RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy Level 1 with Level 2 Roles, Services and Authentication Table 12 Key Establishment Recommendations (continued) NIST SP 800-56A Recommendations Module Capabilities and Recommendations Owner assurance of the validity of the private key. The module provides APIs to explicitly validate the private key according to SP 800-56A. For the JCM API, PrivateKey.
RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy Level 1 with Level 2 Roles, Services and Authentication 2.3.5 Crypto User Guidance on Key Generation and Entropy The module generates cryptographic keys whose strengths are modified by available entropy. As a result, no assurance is given for the minimum strength of generated keys. The JCM provides the HMAC DRBG, CTR DRBG and Hash DRBG implementations for key generation.
RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy Level 1 with Level 2 Roles, Services and Authentication 2.5 Operating the Cryptographic Module Both FIPS and non-FIPS algorithms are available to the operator. In order to operate the module in the FIPS-Approved mode, all rules and guidance provided in Secure Operation of the Module must be followed by the module operator. The module does not enforce the FIPS 140-2 mode of operation.
RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy Level 1 with Level 2 Roles, Services and Authentication 3 Acronyms The following table lists the acronyms used with the JCM and their definitions. Table 15 Acronyms used with the JCM 40 Acronym Definition 3DES Refer to Triple-DES AD Authenticated Decryption. A function that decrypts purported ciphertext and verifies the authenticity and integrity of the data. AE Authenticated Encryption.
RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy Level 1 with Level 2 Roles, Services and Authentication Table 15 Acronyms used with the JCM (continued) Acronyms Acronym Definition CRNG Continuous Random Number Generation. CSP Critical Security Parameters. CTR Counter mode of encryption, which turns a block cipher into a stream cipher. It generates the next keystream block by encrypting successive values of a counter. CTS Cipher Text Stealing.
RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy Level 1 with Level 2 Roles, Services and Authentication Table 15 Acronyms used with the JCM (continued) 42 Acronym Definition FPE Format Preserving Encryption. HKDF HMAC-based Extract-and-Expand Key Derivation Function. HMAC Keyed-Hashing for Message Authentication Code. IV Initialization Vector. Used as a seed value for an encryption operation. JCE Java Cryptography Extension. JVM Java Virtual Machine.
RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy Level 1 with Level 2 Roles, Services and Authentication Table 15 Acronyms used with the JCM (continued) Acronyms Acronym Definition PC Personal Computer. Poly1305 A cryptographic MAC standardized in RFC 7539. private key The secret key in public key cryptography. Primarily used for decryption but also used for encryption with digital signatures. PRNG Pseudo-random Number Generator.
RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy Level 1 with Level 2 Roles, Services and Authentication Table 15 Acronyms used with the JCM (continued) 44 Acronym Definition TDES Refer to Triple-DES. TLS Transport Layer Security. Triple-DES A symmetric encryption algorithm which uses either two or three DES keys. The two key variant of the algorithm provides 80 bits of security strength while the three key variant provides 112 bits of security strength.
