12.12.23
RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy 1
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 .................................................................................................... 2
Terminology ...................................................................................... 2
Document Organization ................................................................... 2
1 The Cryptographic Module ................................................................... 3
1.1 Introduction ................................................................................. 3
1.2 Module Characteristics ............................................................... 4
1.3 Module Interfaces ....................................................................... 8
1.4 Roles, Services and Authentication ............................................ 9
1.5 Cryptographic Key Management .............................................. 19
1.6 Cryptographic Algorithms .......................................................... 23
1.7 Self-tests ................................................................................... 27
2 Secure Operation of the Module ........................................................ 29
2.1 Module Configuration ................................................................ 29
2.2 Security Roles, Services and Authentication Operation ............ 30
2.3 Crypto User Guidance .............................................................. 30
2.4 Crypto Officer Guidance ........................................................... 37
2.5 Operating the Cryptographic Module ........................................ 37
3 Acronyms ............................................................................................ 38
4 Change Summary ............................................................................. 42
2 RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy
Preface
This document is a non-proprietary security policy for the Crypto-J JSAFE and JCE
Software Module from Dell Australia Pty Limited, BSAFE Product Team1
.
This security policy describes how the Crypto-J JSAFE and JCE Software Module meets
the Level 2 security requirements of FIPS 140-2 for Roles, Services and Authentication,
and overall Level 1 security requirements for all other relevant aspects of FIPS 140-2,
and how to securely operate it.
Federal Information Processing Standards Publication 140-2 - Security Requirements for
Cryptographic Modules details the U.S. Government requirements for cryptographic
modules. More information about the FIPS 140-2 standard and validation program is
available on the NIST website.
Terminology
In this document, the term Crypto-J JSAFE and JCE Software Module denotes the
Crypto-J JSAFE and JCE FIPS 140-2 validated Cryptographic Module for Overall
Security Level 1 with Level 2 Roles, Services and Authentication and Level 3 Design
Assurance.
The Crypto-J JSAFE and JCE Software Module is also referred to as:
• The Cryptographic Module
• The Java Crypto Module (JCM)
• The module.
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, the 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.
• Secure Operation of the Module, addresses the required configuration for the FIPS
140-2 mode of operation.
• Acronyms, lists the definitions for the acronyms used in this document.
With the exception of the Non-Proprietary RSA BSAFE Crypto-J JSAFE and JCE
Software Module Security Policy documents, the FIPS 140-2 Security Level 2 Roles,
Services and Authentication, Security Level 3 Design Assurance, and Security Level 1
overall validation submission documentation is proprietary to Dell Australia Pty Limited,
BSAFE Product Team. and is releasable only under appropriate non-disclosure
agreements. For access to the documentation, please contact Dell Support.
1
Dell Technologies has acquired the BSAFE product line, which is now referred to as Dell BSAFE.
Future module versions will be renamed to reflect this change.
12.12.23
RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy 3
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.1 Introduction
More than a billion copies of the RSA BSAFE technology are embedded in today's most
popular software applications and hardware devices. Encompassing one of the most
widely-used and rich set of cryptographic algorithms as well as secure communications
protocols, RSA BSAFE software is a set of complementary security products relied on by
developers and manufacturers worldwide.
The RSA BSAFE Crypto-J software library relies on the JCM library. It includes a wide
range of data encryption and signing algorithms, including AES, the RSA Public Key
Cryptosystem, the Elliptic Curve Cryptosystem, DSA, and the SHA-1, SHA-2 and SHA-3
message digest routines. Its software libraries, sample code and complete
standards-based implementation enable near-universal interoperability for your
networked and e-business applications.
4 RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy
1.2 Module Characteristics
The JCM is classified as a FIPS 140-2 multi-chip standalone module. As such, the JCM is
tested on particular operating systems and computer platforms. The cryptographic
boundary includes the JCM running on selected platforms that are running selected
operating systems.
The JCM is validated for FIPS 140-2 Security Level 2 for Roles, Services and
Authentication, Security Level 3 for Design Assurance, and overall for Security Level 1
requirements.
The following table lists the certification levels sought for the JCM for each section of the
FIPS 140-2 specification.
The JCM is packaged in a Java Archive (JAR) file containing all the code for the module.
The JCM API of the module is provided in the jcmFIPS-6.2.5.jar file.
1.2.1 Laboratory Validated Operating Environments
For FIPS 140-2 validation, the JCM is tested by an accredited FIPS 140-2 testing
laboratory on the following operating environments:
• Oracle®
JRE 8.0 on Microsoft®
Windows Server®
2016 (64-bit) running on
Dell EMC™ PowerEdge™ T130 with an Intel®
Xeon®
E3 processor
• OpenJDK 8.0 on CentOS 7.6 (64-bit) running on Dell PowerEdge R710 with an Intel
Xeon E5 processor.
Table 1 Certification Levels
Section of the FIPS 140-2 Specification Level
Cryptographic Module Specification 1
Cryptographic Module Ports and Interfaces 1
Roles, Services, and Authentication 2
Finite State Model 1
Physical Security N/A
Operational Environment 1
Cryptographic Key Management 1
EMI/EMC 1
Self-Tests 1
Design Assurance 3
Mitigation of Other Attacks 1
Overall 1
12.12.23
RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy 5
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. Compliance is maintained
in all operational environments for which the binary executable remains unchanged.
Specifically, RSA affirms compliance for the following operational environments:
• Apple®
– Mac OS®
X 10.8+
• x86 (32-bit) Apple JDK 8.0
• x86_64 (64-bit) Apple JDK 8.0.
• Canonical™
– Ubuntu™ 16.04 Server
• x86 (32-bit) IBM JDK 8.0, OpenJDK 8u, Oracle JDK 8.0
• x86_64 (64-bit) IBM JDK 8.0, OpenJDK 8u, Oracle JDK 8.0, 11.0.
• Dell EMC
– PowerProtect™ Data Domain™ OS on
• x86_64 (64-bit), Oracle JDK 8.0.
• Google
– Android 4.4.x
• ARM v7 (32-bit)
• x86 (32-bit).
– Android 5.x
• ARM v7 (32-bit)
• x86 (32-bit).
– Android 6.x
• ARM v7 (32-bit)
• ARM v8 (32-bit)
• ARM v8 (64-bit)
• x86 (32-bit).
– Android 7.x
• ARM v7 (32-bit)
• ARM v8 (32-bit)
• ARM v8 (64-bit)
• x86 (32-bit).
6 RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy
– Android 8.x
• ARM v7 (32-bit)
• ARM v8 (32-bit)
• ARM v8 (64-bit)
• x86 (32-bit).
– Android 9.0
• ARM v8-A (64-bit).
• 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.
• Linux®
– CentOS 6.10
• x86_64 (64-bit) IBM JDK 8.0, OpenJDK 8u, Oracle JDK 8.0, 11.0
– CentOS 7.6 and any subsequent 7.x releases made available with the same
capabilities
• x86_64 (64-bit) IBM JDK 8.0, OpenJDK 8u, Oracle JDK 8.0, 11.0.
– Red Hat®
Enterprise Linux 7.6 and any subsequent 7.x releases made available
with the same capabilities
• x86_64 (64-bit) IBM JDK 8.0, OpenJDK 8u, Oracle JDK 8.0, 11.0.
– SUSE Software Solutions®
SUSE®
Linux Enterprise Server 12 SP1, SP2, SP3,
SP4, SP5 and any subsequent service packs made available with the same
capabilities
• x86_64 (64-bit) IBM JDK 8.0, OpenJDK 8u, Oracle JDK 8.0, 11.0.
– SUSE Software Solutions SUSE Linux Enterprise Server 15 SP2 and any
subsequent service packs made available with the same capabilities
• x86_64 (64-bit) OpenJDK 8, 11
• Microsoft
– Windows 7 Enterprise SP1
• x86_64 (64-bit) IBM JDK 8.0, Oracle JDK 8.0, 11.0.
12.12.23
RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy 7
– Windows 8.1 Enterprise
• x86_64 (64-bit) IBM JDK 8.0, Oracle JDK 8.0, 11.0.
– Windows 10 Enterprise
• x86 _64 (64-bit) IBM JDK 8.0, Oracle JDK 8.0, 11.0.
– Windows Server 2008 SP2
• x86_64 (64-bit) IBM JDK 8.0, Oracle JDK 8.0, 11.0.
– Windows Server 2012
• x86_64 (64-bit) IBM JDK 8.0, Oracle JDK 8.0, 11.0.
– Windows Server 2012 R2
• x86_64 (64-bit) IBM JDK 8.0, Oracle JDK 8.0, 11.0.
– Windows Server 2016
• x86_64 (64-bit) IBM JDK 8.0, Oracle JDK 8.0, 11.0.
• Oracle
– Solaris®
10
• SPARC®
v9 (64-bit) IBM JDK 8.0, Oracle JDK 8.0, 11.0
• x86_64 (64-bit) Oracle JDK 8.0.
– Solaris 11
• SPARC v9 (64-bit) IBM JDK 8.0, Oracle JDK 8.0, 11.0
• x86_64 (64-bit) Oracle JDK 8.0, 11.0.
– Linux 7
• 64-bit on Oracle X Series Servers, Oracle JDK 8, 11 (32 & 64 bit)
• 64-bit on Oracle E Series Servers, Oracle JDK 8, 11 (32 & 64 bit)
• 64-bit on Oracle A Series Servers, Oracle JDK 8, 11 (32 & 64 bit)
– Linux 8
• 64-bit on Oracle X Series Servers, Oracle JDK 8, 11 (32 & 64 bit)
• 64-bit on Oracle E Series Servers, Oracle JDK 8, 11 (32 & 64 bit)
• 64-bit on Oracle A Series Servers, Oracle JDK 8, 11 (32 & 64 bit)
• The FreeBSD®
Foundation
– FreeBSD 11.x x86_64 (64-bit) OpenJDK 8u.
Note: The Cryptographic Module Validation Program (CMVP) makes
no statement as to the correct operation of the module or the security
strengths of the generated keys when the specific operational
environment is not listed on the validation certificate.
8 RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy
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. The module provides the following four logical interfaces that have been
designed within the module where input and output are indicated from the perspective of
the module:
• Control In - the invocation of all methods, the function and API names
• Data In - input arguments to all constructors and methods specifying input parameters
• Data Out - modified input arguments, those passed by reference, and return values
for all constructors and methods modifying input arguments and returning values
• Status Out - information returned by the methods and any exceptions thrown by
constructors and methods.
This is shown in the following diagram.
Figure 1 JCM Logical Diagram
Physical Boundary
Cryptographic Module
FIPS class files within the JCM jar
Java Virtual Machine (JVM)
Operating System (OS)
Hardware
Cryptographic Boundary
Software
Hardware
Runs on JVM
Run on OS
Runs on Hardware
Provides service for OS
Provides services for
JVM
Provides services for
Module
Application
Data In Data Out Control In Status Out
12.12.23
RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy 9
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. An attacker would have to make 2495
random
attempts within a one-minute period to exceed a probability of 1 in 100,000.
The PIN is saved as a salted hash in the module configuration file. The salted hash value
is computed by combining the PIN and a 512-bit random (salt) value, which is generated
using the HMAC-DRBG, then hashing the combined value using SHA-512.
The API for control of the JCM is through the com.rsa.crypto.ModuleConfig
class.
Roles can be assumed by creating a FIPS140Context object which encapsulates a
particular FIPS 140-2 Role, and using the object as input to authenticated services.
Authentication is required in order to create a FIPS140Context object, and
authenticated services cannot be accessed without a FIPS140Context object. The
ModuleConfig class contains APIs for PIN initialization and management.
The length of the PIN specified in this Security Policy document is sufficient to prevent
brute force searching of the PIN value with a probability greater than 1 in 100,000 over a
period of one minute when the hash calculations are performed by a computing resource
with the performance equivalence of a cluster of up to one million Amazon EC2 GPU
instances.
1.4.1 Crypto Officer Role
The Crypto Officer role is responsible for installation and management of the
cryptographic module. During installation of the module, the Crypto Officer role is
assumed. The installation process includes module initialization, which requires
initialization of role PINs required for authentication during operation of the module.
After installation and initialization, authentication is required to assume the Crypto Officer
role. An operator can assume the Crypto Officer role by providing credentials to the
Service to be used by the operator.
The Services section provides a list of services available to the Crypto Officer Role.
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.USER_ROLE.
The FIPS140Context object can then be input to a Service which is to be used by the
Crypto User Role.
10 RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy
The Services section provides a list of services available to the Crypto User Role.
1.4.3 Services
The following table lists the services that must be used to install and initialize the module.
These services can be accessed un-authenticated by the Crypto Officer role.
The following table lists the services provided by the JCM which may be used by
un-authenticated operators after installation, in terms of the module interface. These
services do not affect the security of the module since they do not make any use of
cryptographic keys or Critical Security Parameters (CSPs).
The following table lists the Services only available to the Crypto Officer role provided by
the JCM in terms of the module interface.
Table 2 Crypto Officer Role Installation Services
Crypto Officer Role Installation Services
ModuleLoader.load ModuleConfig.initFIPS140PINs
Table 3 Un-Authenticated Services
Un-Authenticated Services
ModuleConfig.getEntropySource ModuleConfig.setEntropySource
ModuleConfig.initFIPS140RoleP
INs
ModuleConfig.isFIPS140Complia
nt
ModuleConfig.getSecurityLevel ModuleConfig.getVersionDouble
ModuleConfig.getVersionString
Table 4 Services only available to the Crypto Officer Role
Services only Available to the Crypto Officer Role
ModuleConfig.resetFIPS140RoleP
IN
ModuleConfig.setFIPS140RoleP
IN
12.12.23
RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy 11
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 the
Cryptographic Algorithms section.
The following table lists the Services available only to the Crypto User role provided by
the JCM in terms of the module interface. For each interface, lists of algorithms that are
approved and not approved when operating the module in a FIPS 140-2 compliant way
are specified.
Table 5 Services Available only to the Crypto User Role
Services Available only to the Crypto User Role
Encryption/Decryption:
SymmCipher clearSensitiveData
clone
doFinal
getAlg
getAlgorithmParams
getBlockSize
getCryptoModule
getFeedbackSize
getMaxInputLen
getOutputSize
init
isIVRequired
reInit
update
Algorithms approved for FIPS 140-2 usage
AES (CBC, CCM, CFB, CTR, ECB, GCM, OFB, XTS)
PBE (PKCS #5 V2 - Approved for key storage)
Algorithms not approved for FIPS 140-2 usage
AES (BPS, CBC_CS1, CBC_CS2, CBC_CS3)
Triple-DES (CBC_CS1, CBC_CS2, CBC_CS3)
Triple-DES (CBC, CFB, ECB, OFB)
ChaCha20
ChaCha20/Poly1305
DES
DESX
RC2®
RC4®
RC5®
PBE (PKCS #12, PKCS #5, SSLCPBE)
12 RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy
Encryption/Decryption: (continued)
Cipher clearSensitiveData
clone
doFinal
getAlg
getAlgorithmParams
getBlockSize
getCryptoModule
getMaxInputLen
getOutputSize
init
reInit
update
Algorithms approved for FIPS 140-2 usage
SP 800-38F KW (AE, AD, provides between 128 and 256 bits
of encryption strength)
SP 800-38F KWP (AE, AD, provides between 128 and 256 bits
of encryption strength)
Algorithms not approved for FIPS 140-2 usage
ECIES
KTS-KEM-KWS
KTS-OAEP
RSA
Signature Generation/Verification:
Signature clearSensitiveData
clone
getAlg
getCryptoModule
getSignatureSize
initSign
initVerify
reInit
sign
update
verify
Algorithms approved for FIPS 140-2 usage
RSA X9.31, PKCS #1 V.1.5, RSASSA-PSS
DSA
ECDSA
Algorithms not approved for FIPS 140-2 usage
None
Table 5 Services Available only to the Crypto User Role (continued)
Services Available only to the Crypto User Role
12.12.23
RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy 13
MAC Generation/Verification:
MAC clearSensitiveData
clone
getAlg
getCryptoModule
getMacLength
init
mac
reset
update
verify
Algorithms approved for FIPS 140-2 usage
CMAC
HMAC (when used with an approved Message Digest algorithm)
Algorithms not approved for FIPS 140-2 usage
HMAC-MD5
PBHMAC (PKCS #12, PKIX)
Poly1305
Digest Generation:
MessageDigest clearSensitiveData
clone
digest
getAlg
getCryptoModule
getDigestSize
reset
update
Algorithms approved for FIPS 140-2 usage
SHA-1
SHA-224
SHA-256
SHA-384
SHA-512
SHA-512/224
SHA-512/256
SHA3-224
SHA3-256
SHA3-384
SHA3-512
SHAKE128
SHAKE256
MD5 (Allowed in FIPS mode only
for use in TLS)
Algorithms not approved for FIPS 140-2 usage
MD2
RIPEMD160
Table 5 Services Available only to the Crypto User Role (continued)
Services Available only to the Crypto User Role
14 RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy
Parameters:
AlgInputParams clone
get
getCryptoModule
set
AlgorithmParams getCryptoModule
DHParams1 getCounter
getCryptoModule
getG
getJ
getMaxExponentLen
getP
getQ
getSeed
DomainParams getCryptoModule
DSAParams getCounter
getCryptoModule
getDigestAlg
getG
getP
getQ
getSeed
ECParams getA
getB
getBase
getBaseDigest
getBaseSeed
getCofactor
getCryptoModule
getCurveName
getDigest
getFieldMidTerms
getFieldPrime
getFieldSize
getFieldType
getOrder
getSeed
getVersion
ECPoint clearSensitiveData
getEncoded
getX
getY
PQGParams getCryptoModule
getG
getP
getQ
Parameter Generation:
AlgParamGenerator generate
getCryptoModule
initGen
initVerify
verify
Algorithms approved for FIPS 140-2 usage
DSA
Algorithms not approved for FIPS 140-2 usage
Diffie-Hellman (DH)
Table 5 Services Available only to the Crypto User Role (continued)
Services Available only to the Crypto User Role
12.12.23
RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy 15
Key Establishment:
KeyAgreement clearSensitiveData
clone
doPhase
getAlg
getCryptoModule
getSecret
init
Algorithms approved for FIPS 140-2 usage
ECC-CDH (primitives only)
Algorithms not approved for FIPS 140-2 usage
Diffie-Hellman (DH)
EC Diffie-Hellman (ECDH)
KeyConfirmation clearSensitiveData
computeMacTag
verifyMacTag
Algorithms approved for FIPS 140-2 usage
None
Algorithms not approved for FIPS 140-2 usage
Diffie-Hellman (DH)
EC Diffie-Hellman (ECDH)
Key Generation:
KeyGenerator clearSensitiveData
generate
getCryptoModule
initialize
Algorithms approved for FIPS 140-2 usage
AES
Algorithms not approved for FIPS 140-2 usage
DES
DESX
Shamir Secret Sharing
Triple-DES
RC2
RC4
RC5
Table 5 Services Available only to the Crypto User Role (continued)
Services Available only to the Crypto User Role
16 RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy
Key Generation: (continued)
KeyPairGenerator clearSensitiveData
clone
generate
getCryptoModule
initialize
Algorithms approved for FIPS 140-2 usage
ECDSA
DSA
RSA
Algorithms not approved for FIPS 140-2 usage
Diffie-Hellman (DH)
EC Diffie-Hellman (ECDH)
RSA Keypair Generation MultiPrime
Keys:
DHPrivateKey1 clearSensitiveData
clone
getAlg
getCryptoModule
getParams
getX
isValid
DHPublicKey1 clearSensitiveData
clone
getAlg
getCryptoModule
getParams
getY
isValid
DSAPrivateKey clearSensitiveData
clone
getAlg
getCryptoModule
getParams
getX
isValid
DSAPublicKey clearSensitiveData
clone
getAlg
getCryptoModule
getParams
getY
isValid
ECPrivateKey clearSensitiveData
clone
getAlg
getCryptoModule
getD
getParams
isValid
ECPublicKey clearSensitiveData
clone
getAlg
getCryptoModule
getParams
getPublicPoint
isValid
Key clearSensitiveData
clone
getAlg
getCryptoModule
Table 5 Services Available only to the Crypto User Role (continued)
Services Available only to the Crypto User Role
12.12.23
RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy 17
Keys: (continued)
KeyBuilder newDHParams1
newDHPrivateKey1
newDHPublicKey1
newDSAParams
newDSAPrivateKey
newDSAPublicKey
newECParams
newECPrivateKey
newECPublicKey
newPasswordKey
newPQGParams
newRSAPrivateKey
newRSAPublicKey
newSecretKey
recoverShamirSecretKey
KeyPair clearSensitiveData
clone
getAlgorithm
getPrivate
getPublic
PasswordKey clearSensitiveData
clone
getAlg
getCryptoModule
getKeyData
getPassword
PrivateKey clearSensitiveData
clone
getAlg
getCryptoModule
isValid
PublicKey clearSensitiveData
clone
getAlg
getCryptoModule
isValid
RSAPrivateKey clearSensitiveData
clone
getAlg
getCoeff
getCryptoModule
getD
getE
getExpP
getExpQ
getN
getOtherMultiPrimeInfo
getP
getQ
hasCRTInfo
isMultiprime
isValid
RSAPublicKey clearSensitiveData
clone
getAlg
getCryptoModule
getE
getN
isValid
SecretKey clearSensitiveData
getAlg
getCryptoModule
getKeyData
SharedSecretKey clearSensitiveData
clone
getAlg
getCryptoModule
getKeyData
getSharedParams
Table 5 Services Available only to the Crypto User Role (continued)
Services Available only to the Crypto User Role
18 RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy
Key Derivation:
KDF clearSensitiveData
clone
generate
getCryptoModule
Algorithms approved for FIPS 140-2 usage
HKDF
KDFTLS10 (For use with TLS versions 1.0 and 1.1)
KDFTLS12 (For use with TLS version 1.2)
PBKDF2 (Approved for key storage)
Single-step KDF
Algorithms not approved for FIPS 140-2 usage
PKCS #5 KDF
PKCS #12 KDF
scrypt
Random Number Generation:
SecureRandom autoseed
clearSensitiveData
getCryptoModule
newInstance
nextBytes
selfTest
setAlgorithmParams
setOperationalParameter
s
setSeed
Algorithms approved for FIPS 140-2 usage
CTR DRBG
Hash DRBG
HMAC DRBG
Algorithms not approved for FIPS 140-2 usage
FIPS 186-2 PRNG (Change Notice General)
Other Services:
BigNum getBitLength toOctetString
CryptoModule getDeviceType
getKeyBuilder
getModuleOperations
newAlgInputParams
newAlgParamGenerator
newAsymmetricCipher
newKDF
newKeyAgreement
newKeyGenerator
newKeyPairGenerator
newKeyWrapCipher
newMAC
newMessageDigest
newSecureRandom
newSignature
newSymmetricCipher
JCMCloneable clone
Table 5 Services Available only to the Crypto User Role (continued)
Services Available only to the Crypto User Role
12.12.23
RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy 19
The following table lists the Services provided by the JCM which may be used by either
the Crypto User role or Crypto Officer role, in terms of the module interface. For more
information on each function, see the relevant API Javadoc.
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
All Critical Security Parameters (CSPs), including keys, are generated as required by the
algorithm standard for which the CSP is used.
The module supports the generation of the DSA, RSA, and ECDSA public and private
keys. In the FIPS-Approved mode, RSA keys can only be generated using the Approved
186-4 RSA key generation method.
ModuleConfig getEntropySource
getFIPS140Context
getSecurityLevel
getVersionDouble
getVersionInfo
getVersionString
initFIPS140RolePINs
isFIPS140Compliant
newCryptoModule
runSelfTests
setEntropySource
ModuleLoader load
ModuleOperations perform
PasswordKey clearSensitiveData
clone
getAlg
getCryptoModule
getKeyData
getPassword
SelfTestEvent getTestId getTestName
SelfTestEventListener failed
finished
passed
started
SensitiveData clearSensitiveData
1
Not approved for use in FIPS 140-2 mode of operation.
Table 6 Services Available to the Crypto User and Crypto Officer Roles
Services Available to the Crypto User and Crypto Officer Roles
FIPS140Context ModuleConfig.getFIPS140Contex
t
Table 5 Services Available only to the Crypto User Role (continued)
Services Available only to the Crypto User Role
20 RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy
The module employs a FIPS-Approved SP 800-90A DRBG for generating all CSPs,
including asymmetric and symmetric keys used in algorithms such as AES, RSA, DSA
and ECC.
1.5.2 Key Protection
All key data resides in internally allocated data structures and can only be output using
the JCM API. The operating system and the JRE safeguards memory and process space
from unauthorized access.
1.5.3 Key Zeroization
The module stores all its keys and CSPs in volatile memory. Users can ensure CSPs are
properly zeroized by making use of the <object>.clearSensitiveData() method.
All of the module’s keys and CSPs are zeroizable. The module operator must zeroize all
keys before switching from an approved FIPS 140-2 mode to non-FIPS 140-2 approved
mode.
For more information about clearing CSPs, see the relevant API Javadoc.
1.5.4 Key Storage
The JCM does not provide long-term cryptographic key storage. Storage of keys is the
responsibility of the JCM user.
The following table shows how the storage of keys and CSPs are handled.
Table 7 Key and CSP Storage
Item Storage
AES keys In volatile memory only (plaintext)
HMAC with SHA-1, SHA-2 and SHA-3 keys In volatile memory only (plaintext)
CMAC keys In volatile memory only (plaintext)
ECDSA private keys/public key In volatile memory only (plaintext)
ECC-CDH primitive output In volatile memory only (plaintext)
RSA private key/public key In volatile memory only (plaintext)
DSA private key/public key In volatile memory only (plaintext)
CTR DRBG Entropy In volatile memory only (plaintext)
CTR DRBG V Value In volatile memory only (plaintext)
CTR DRBG Key In volatile memory only (plaintext)
CTR DRBG init_seed In volatile memory only (plaintext)
Hash DRBG Entropy In volatile memory only (plaintext)
Hash DRBG V Value In volatile memory only (plaintext)
12.12.23
RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy 21
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.
Hash DRBG C In volatile memory only (plaintext)
Hash DRBG init_seed In volatile memory only (plaintext)
HMAC DRBG Entropy In volatile memory only (plaintext)
HMAC DRBG V Value In volatile memory only (plaintext)
HMAC DRBG Key In volatile memory only (plaintext)
HMAC DRBG init_seed In volatile memory only (plaintext)
TLS KDF Shared Secret In volatile memory only (plaintext)
Katstatus In volatile memory and on disk
(protected with HMAC SHA256)
Crypto User Role PIN In volatile memory and on disk1
Crypto Officer Role PIN In volatile memory and on disk1
1
In plaintext, output from the module as a salted hash.
Table 8 Key and CSP Access
Service Key or CSP Type of Access
Asymmetric
encryption and decryption
Asymmetric keys (RSA) Read/Execute
Encryption and decryption Symmetric keys (AES) Read/Execute
Digital signature and
verification
Asymmetric keys (DSA, ECDSA, RSA) Read/Execute
Hashing None N/A
MAC HMAC keys
CMAC keys
Read/Execute
Random number generation CTR DRBG entropy, V, key, init_seed
Hash DRBG entropy, V, C, init_seed
HMAC DRBG entropy, V, key, init_seed
Read/Write/Execute
Table 7 Key and CSP Storage (continued)
Item Storage
22 RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy
Key derivation HKDF keys
Single-step KDF keys
TLS KDF Shared Secret
Read/Execute
Key establishment Asymmetric keys (ECC-CDH) Read/Execute
Key generation Symmetric keys (AES)
Asymmetric keys (DSA, ECDSA, ECC-CDH, RSA)
MAC keys (HMAC, CMAC)
Write
Self-test Hard-coded keys,
(AES, Triple-DES, RSA, DSA, ECDSA, HMAC,
CMAC, HKDF)
Hard-coded entropy, strength, and seed
(HMAC DRBG, HASH DRBG, CTR DRBG)
Read/Execute
Show status None N/A
Zeroization All Read/Write
Table 8 Key and CSP Access (continued)
Service Key or CSP Type of Access
12.12.23
RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy 23
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.
1.6.1 FIPS 140-2-approved Algorithms
The following table lists the FIPS 140-2 approved algorithms that can be used when
operating the module in a FIPS 140-2 compliant way.
Table 9 JCM FIPS 140-2 Approved Algorithms
Algorithm Type Algorithm Standard
Validation
Certificate
Asymmetric
Cipher
RSADP (RSA decryption primitive) component
Modulus sizes: 2048 bits
SP 800-56B
Rev. 2
C662
Key Agreement
Primitives
KASECC_(ECCCDH) Primitive Component Test SP 800-56A
Rev.3
C662
Key Derivation HMAC-based Extract-and-Expand KDF (HKDF):
• SHA-1, SHA-224, SHA-256, SHA-384, SHA-512
SP 800-56C Vendor affirmed
Single-Step KDF:
• SHA-224, SHA-256, SHA-384, SHA-512,
SHA-512/224 and SHA-512/256
SP 800-56C Vendor affirmed
Key Based KDF (KBKDF), using pseudo-random functions:
• HMAC-based Feedback Mode, with:
– SHA-1, SHA-224, SHA-256, SHA-384, SHA-512
SP 800-108 C662
Password-based Key Derivation Function 2 (PBKDF2) SP 800-132 Vendor Affirmed
(Approved in FIPS
mode for key
storage1
)
KDFTLS102 SP 800-135
Rev. 1
C662
KDFTLS122
with SHA-256, SHA-384, SHA-512
Key Wrap AES in KW and KWP modes with 128, 192, and 256-bit key
sizes
SP 800-38F C662
Key Generation Cryptographic Key Generation (CKG) SP 800-133 Vendor affirmed
Message
Authentication
Code
CMAC (using AES) SP 800-38B C662
HMAC3 FIPS 198-1 C662
Message Digest SHA:
• SHA-14
, SHA-224, SHA-256, SHA-384, SHA-512,
SHA-512/224, SHA-512/256
FIPS 180-4 C662
SHA-3:
• SHA3-224, SHA3-256, SHA3-384, SHA3-512,
SHAKE1285
, SHAKE2565
FIPS 202 C662
24 RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy
Random Bit
Generator
CTR DRBG
AES-CTR mode with 128, 192, and 256-bit key sizes
SP 800-90A
Rev. 1
C662
Hash DRBG
SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224,
SHA-512/256
HMAC DRBG
SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224,
SHA-512/256
Signature3 RSA X9.31, PKCS #1 V.1.5, RSASSA-PSS
(2048 and 3072 bit key sizes)
FIPS 186-4 C662
DSA (2048 and 3072 bit key sizes)
ECDSA (224 to 571 bit key sizes)
Symmetric Cipher AES in CBC, CFB, CTR, ECB, OFB modes
(128, 192, 256 bit key sizes)
SP 800-38A C662
AES in CCM modes (128, 192, 256 bit key sizes) SP 800-38C
AES in GCM (128, 192, 256 bit key sizes) SP 800-38D
AES in XTS mode (128, 256 bit key sizes)6 SP 800-38E
1
The module implements PBKDF2 as the PBKDF algorithm as defined in SP 800-132. This can be used in FIPS mode when used with a
FIPS-approved Symmetric Cipher and Message Digest algorithm.
For information on how to use PBKDF, see For PBKDF:
2
The TLS 1.0/1.1 and 1.2 KDF, documented in SP 800-135, are allowed only when the conditions detailed in the Crypto User Guidance are
satisfied. JCM does not implement the full TLS protocol and only the implemented components have been tested by the CAVP and CMVP.
3
When used with a FIPS-approved Message Digest algorithm.
4
SHA-1 is allowed for use in the TLS protocol but no longer allowed to be used in digital signature generation.
5
The SHAKE algorithms can be used only as standalone message digest algorithms.
6
AES in XTS mode shall be used only for cryptographic protection of data on storage devices.
Table 9 JCM FIPS 140-2 Approved Algorithms (continued)
Algorithm Type Algorithm Standard
Validation
Certificate
12.12.23
RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy 25
1.6.2 FIPS 140-2 Allowed Algorithms
The following is a list of the FIPS 140-2 allowed algorithms.
• MD5
Allowed as part of an approved key transport scheme, for example, TLS 1.0, where
no security is provided by the MD5 algorithm.
Allowed in the FIPS140-2 approved mode of operation for a purpose that is not
security relevant or is redundant to an approved cryptographic algorithm.
See section 4.2.1 of SP 800-135 Rev. 1 and IG 1.23.
26 RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy
1.6.3 Non-FIPS 140-2 Approved Algorithms
The following s a list of all other available algorithms in the JCM that are not approved
for FIPS 140-2 usage. These algorithms must not be used when operating the module in
a FIPS 140-2 compliant way.
• AES in BPS mode for FPE
• AES in CBC_CS1, CBC_CS2 or CBC_CS3 mode for CTS
• ChaCha20/Poly1305 AEAD cipher
• ChaCha20 cipher
• DES
• DESX
• ECIES
• FIPS 186-2 PRNG (Change Notice General)
• HMAC-MD5
• Key Agreement
– Diffie-Hellman
– EC Diffie-Hellman
• Key Agreement Primitives:
– FFC Component
[dhHybrid1, dhEphem, dhHybridOneFlow, dhOneFlow, dhStatic, (Cofactor)
Full Unified Model, (Cofactor) Ephemeral Unified Model, (Cofactor)
One-Pass Unified Model, (Cofactor) One-Pass Diffie-Hellman, (Cofactor)
Static Unified Model]
• KTS-OAEP
• KTS-KEM-KWS
• MD2
• Poly1305 MAC
• RC2 block cipher
• RC4 stream cipher
• RC5 block cipher
• RSA Keypair Generation MultiPrime (2 or 3 primes)
• RSA Key Wrapping using a PKCS#1-v1.5 padding scheme
• RSA X9.31, PKCS #1 V.1.5, RSASSA-PSS Signature Generation FIPS 186-2
(4096 bit key size)
• RIPEMD160
• scrypt
• Shamir Secret Sharing
• Triple-DES in CBC, CFB, ECB and OFB modes.
• Triple-DES in CBC_CS1, CBC_CS2 or CBC_CS3 mode for CTS.
12.12.23
RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy 27
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. A conditional self-test failure does NOT disable the module.
1.7.1 Power-up Self-tests
Power-up self-tests are executed automatically when the module is loaded into memory.
The power-up self-tests include the FIPS 140-2 required Software Integrity Test and a set
of Cryptographic Algorithms tests. The Software Integrity Test is comprised of an
HMAC-SHA1 verification of the files listed in fips140/module.files.
The following Cryptographic Algorithm tests are implemented in the module:
• AES Decrypt KAT
• AES Encrypt KAT
• AES/CCM Decrypt KAT
• AES/CCM Encrypt KAT
• AES/GCM Decrypt KAT
• AES/GCM Encrypt KAT
• CMAC KAT
• CTR DRBG KAT
• DSA Sign/Verify Test
• ECDSA Sign/Verify Test
• Hash DRBG KAT
• HKDF KAT
• HMAC DRBG KAT
• KDFTLS10 KAT
• KDFTLS12 SHA-256 KAT
• RSA Signature Generation KAT
• RSA Signature Verification KAT
• SHA3-512 KAT
• SHA-512 KAT
• SHAKE256 KAT.
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.
28 RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy
1.7.2 Conditional Self-tests
The module performs two conditional self-tests:
• Pair-wise Consistency Tests each time the module generates a DSA, RSA or ECDSA
public/private key pair.
• Continuous RNG (CRNG) Test each time the module produces random data, as per
the FIPS 140-2 standard. The CRNG test is performed on all approved and
non-approved PRNGs (HMAC DRBG, HASH DRBG, CTR DRBG, FIPS186 PRNG,
non-approved entropy source).
1.7.3 Mitigation of Other Attacks
RSA, EC, and DSA key operations implement blinding by default. Blinding is a reversible
way of modifying the input data, so as to make the operations immune to timing attacks.
Blinding has no effect on the algorithm other than to mitigate attacks on the algorithm.
RSA, EC, and DSA blinding is implemented through blinding modes, for which the
following options are available:
• Blinding mode off
• Blinding mode with no update, where the blinding value is squared for each operation.
For other types of timing attacks the module implements time invariant comparisons and
operations, for example, PKCS #1 unpadding, HMAC verify, and RSA verify.
RSA signing operations implement a verification step after private key operations. This
verification step, which has no effect on the signature algorithm, is in place to prevent
potential faults in optimized Chinese Remainder Theorem (CRT) implementations. For
more information, see Modulus Fault Attacks Against RSA-CRT Signatures.
12.12.23
RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy 29
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.1 Module Configuration
To operate the module in compliance with FIPS 140-2 Level 1 with Level 2 Roles,
Services and Authentication requirements, the module must be loaded using the following
method:
com.rsa.crypto.jcm.ModuleLoader.load()
The ModuleLoader.load() method extracts arguments from the
com.rsa.cryptoj.jcm.JavaModuleProperties class, which is created using the
com.rsa.cryptoj.jcm.CryptoJModulePropertiesFactory class.
The following arguments are extracted:
– The module jar file.
– The security level, specified as the constant ModuleConfig.LEVEL_2.
This should have a value of 2.
– An optional SelfTestEventListener to use for logging power-up self-test
events.
– An optional java.util.concurrent.ExecutorService used for running
the power-up self-tests.
– An optional File for reading and writing the status of the algorithm power-up
self-tests.
Using the specified securityLevel ensures that the module is loaded for use in
compliance with FIPS 140-2 for Level 2 Roles, Services and Authentication.
Once the load method has been successfully called for the first time, the module PINs
must be initialized using the initFIPS140RolePINs method in the ModuleConfig
class. Please refer to the relevant API Javadoc for alternative overloaded options which
can be supplied to this method, such as PIN validity period and Cryptographic Module
Configuration File location.
Once the PINs have been initialized, the module is operational.
30 RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy
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.initFIPS140PINs method) must be used to authenticate the
operators before performing the authenticated services available to the Crypto Officer
role and the Crypto User role.
To access PIN management services as the Crypto Officer role, the Crypto Officer role
PIN must be supplied as input to the service APIs.
To access security services as the Crypto User role, the Crypto User role PIN must be
provided. The Crypto Officer is responsible for the secure distribution of the PINs to the
intended Crypto Users. The supplied PINs are used to create a FIPS140Context
object, which is required as input to the ModuleConfig.newCryptoModule method.
For the FIPS140Context.getFIPS140Context() method call, the:
• mode argument used must be the value FIPS140Context.MODE_FIPS140.
• role argument must be the value FIPS140Context.ROLE_USER.
The returned CryptoModule object provides access to all Crypto User security
functions.
To retrieve the current JCM FIPS 140-2 mode, call FIPS140Context.getMode().
2.3 Crypto User Guidance
This section provides guidance to the module user to ensure that the module is used in a
FIPS 140-2 compliant way.
Section 2.3.1 provides algorithm-specific guidance. The requirements listed in this
section are not enforced by the module and must be ensured by the module user.
Section 2.3.2 provides guidance on obtaining assurances for Digital Signature
Applications.
Section 2.3.3 provides guidance on the entropy requirements for secure key generation.
Section 2.3.4 provides information about the minimum length of passwords.
Section 2.3.5 provides general crypto user guidance.
12.12.23
RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy 31
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).
• When using an approved DRBG, the number of bytes of seed key input must be
equivalent to or greater than the security strength of the keys the caller wishes to
generate. For example, a 256-bit or higher seed key input when generating 256-bit
AES keys.
• When using an Approved DRBG to generate keys or DSA parameters, the requested
DRBG must have a security strength at least as great as the security strength of the
key being generated. That means that an Approved DRBG with an appropriate
strength must be used. For more information on requesting the DRBG security
strength, see the relevant API Javadoc.
• Since the module does not modify the output of an Approved DRBG, any generated
symmetric keys or seed values are created directly from the output of the Approved
DRBG.
• FIPS 186-2 RNG is not to be used in an approved FIPS 140-2 mode of operation.
• In case the power to the module is lost and then restored, the key used for the AES
GCM encryption/decryption shall be re-distributed.
• When generating key pairs using the KeyPairGenerator object, the
generate(boolean pairwiseConsistency) method must not be invoked with
an argument of false. Use of the no-argument generate() method is
recommended.
• When using GCM feedback mode for AES symmetric encryption, the authentication
tag length and authenticated data length may be specified as input parameters, but
the full IV must not be specified. It must be generated depending on whether the
AES-GCM cipher provided by the module is being used as the cipher implementation
in the TLS protocol or for symmetric encryption purposes other than TLS.
• The AES-GCM cipher, when used for symmetric encryption purposes other than TLS,
must use an IV in one of the two possible ways, to comply with SP 800-38D:
– allow the module to generate the IV deterministically by not supplying any IV
parameters during cipher initialization. The generated 96-bit (12-byte) IV consists
of a 32-bit fixed field followed by a 64-bit invocation field where
• the fixed field bytes are derived from the module name, version information
and memory address of a Java class within the module
• the invocation field is a 64-bit counter that is initialized, on module startup, to a
value consisting of the 42 bits of current time, as milliseconds since Epoch,
followed by 22 bits of zero. This counter value is incremented by one each
time a new IV is requested. By using the current time to prefix the counter start
value, in the event of module restart, the counter will be ahead of any previous
module states, ensuring that IV values cannot be reused. The module user
must ensure the system time is valid to prevent repetition of IVs.
– generate at least 12 bytes of IV using an Approved DRBG, and input the IV to the
cipher at initialization time using the RAW_IV parameter.
32 RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy
• The AES-GCM cipher used for the TLS protocol as the cipher implementation
complies with SP 800-52 and is compatible with RFC 5288 with the following
conditions:
– 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. This 32-bit part of the IV is also referred to as the nonce value
in FIPS 140-2 IG A.5 and is positioned in the name field of the IV as required
in FIPS 140-2 IG A.5 Scenario 3.
• The remaining eight bytes of IV, referred to as nonce_explicit in RFC 5288, are
generated deterministically by the module using the 64-bit counter used for
the invocation field described above.
• When the 64-bit counter exhausts the maximum number of possible values for
a given session key, the module will throw a SecurityException.
Whichever party, the client or the server, that encounters this condition must
trigger a handshake to establish a new encryption key.
– The TLS session is aborted if the keys for the client and server negotiated in the
handshake process, client_write_key and server_write_key, are
identical.
• For RSASSA-PSS: If nLen is 1024 bits, and the output length of the approved hash
function output block is 512 bits, then the length of the salt (sLen) shall be
0<=sLen<=hLen - 2
Otherwise, the length of the salt shall be 0 <=sLen<=hLen where hLen is the
length of the hash function output block (in bytes or octets).
• ECDSA key pairs must have named curve domain parameters from the set of
NIST-recommended named curves: P-224, P-256, P-384, P-521, B-233, B-283,
B-409, B-571, K-233, K-283, K-409, and K-571. Named curves P192, B163, and
K163 are allowed for legacy-use. The domain parameters can be specified by name
or can be explicitly defined.
• ECC-CDH primitives must use curve domain parameters from the set of
NIST-recommended named curves listed above. The domain parameters can be
specified by name, or can be explicitly defined.
• When using DSA key pair generation and signature generation, the domain
parameters must have prime P length (PRIME_LEN) and subprime Q length
(SUBPRIME_LEN) within the set of acceptable pair sets (PRIME_LEN,
SUBPRIME_LEN): (2048, 224), (2048, 256) or (3072, 256).
• When generating DSA domain parameters, generation shall comply with FIPS 186-4
by specifying the algorithm string “DSA” when creating the
AlgParameterGenerator object. Additionally:
– The PRIME_LEN and SUBPRIME_LEN must be from a set of acceptable pair set
as stated above.
– The digest algorithm parameter shall be selected from the set: SHA224, SHA256,
SHA384, SHA512. The digest algorithm shall be selected such that the output
length is at least as large as the subprime length. That is:
• For subprime 224, all four algorithms may be used.
• For subprime 256, only SHA256, SHA384, SHA512 may be used.
12.12.23
RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy 33
• For RSA digital signature generation, an Approved DRBG must be used.
• RSA keys used for signing shall not be used for any other purpose other than digital
signatures.
• When generating RSA key pairs, 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 or 3072.
– the SECURITY_STRENGTH parameter may be input. Acceptable values are:
• 112, when used for KEY_BITS of 2048.
• 128, when used for KEY_BITS of 3072.
– the PUB_EXP value must be an odd number and have a minimum value of
0x10001 (65537).
• The length of an RSA key pair for digital signature generation and verification must be
2048 or 3072 bits. For digital signature verification, 1024 bits is allowed for
legacy-use. RSA keys shall have a public exponent of at least 65537.
• SHA1 is disallowed for the generation of digital signatures.
• The key length for an HMAC generation or verification must be equal to or greater
than 112 bits. For HMAC verification, a key length greater than or equal to 80 and less
than 112 is allowed for legacy-use.
Note: JCE MAC APIs do not distinguish between generate and verify,
therefore a key length check is not explicitly performed in JCE.
• KDFs:
– For Single-step KDF:
• A FIPS 140-2 approved hash function must be used.
– For HKDF:
• A FIPS 140-2 approved HMAC must be used.
• The extracted key-derivation key must be used solely for the single
key-expansion step. For more information see SP 800-56C Rev.1
• The derived key must be used only as a secret key.
• The derived key shall not be used as a key stream for a stream cipher.
• When selecting an HMAC hash, the output block size must be equal to or
greater than the desired security strength of the derived key.
– For TLS 1.0, 1.1 and 1.2 Key Derivation:
The TLS 1.0 and 1.1 KDF is allowed only when the following conditions are
satisfied:
• The KDF is performed in the context of the TLS protocol
• SHA-1 and HMAC are as specified in FIPS 180-4 and FIPS 198-1,
respectively.
The TLS 1.2 KDF, is allowed only when the following conditions are satisfied:
• The KDF is performed in the context of the TLS protocol
34 RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy
• HMAC is as specified in FIPS 198-1
• P_HASH uses either SHA-256, SHA-384 or SHA-512.
For more information, see SP 800-135 Rev. 1.
The TLS protocols have not been tested by the CAVP and CMVP.
– For PBKDF:
• Keys generated using PBKDF shall only be used in data storage applications.
• The length of the randomly-generated portion of the salt shall be at least 16
bytes. For more information see SP 800-132.
• The iteration count shall be selected as large as possible, a minimum of
10,000 iterations is recommended.
• The minimum password length depends on the character set chosen.
For examples, see Information on Minimum Password Length.
• 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.
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. NIST Special
Publication 800-89: “Recommendation for Obtaining Assurances for Digital Signature
Applications” provides the methods to obtain these assurances.
The following tables describe the FIPS 186-4 requirements for signatories and verifiers
and the corresponding module capabilities and recommendations.
Table 10 Signatory Requirements
FIPS 186-4 Requirement Module Capabilities and Recommendations
Obtain appropriate DSA and
ECDSAparameters when using
DSA or ECDSA.
The generation of DSA parameters is in accordance with the
FIPS 186-4 standard for the generation of probable primes.
For ECDSA, use the NIST recommended curves as defined in
section 2.3.1.
Obtain assurance of the validity
of those parameters.
The module provides APIs to validate DSA parameters for
probable primes as described in FIPS 186-4.
For ECDSA, use the NIST recommended curves as defined in
section 2.3.1. For the JCM API,
AlgParamGenerator.verify()
Obtain a digital signature key
pair that is generated as
specified for the appropriate
digital signature algorithm.
The module generates the digital signature key pair according
to the required standards.
Choose a FIPS-Approved DRBG like HMAC DRBG to
generate the key pair.
12.12.23
RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy 35
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)
Obtain assurance that the
signatory actually possesses
the associated private key.
The module verifies the signature created using the private
key, but all other assurances are outside the scope of the
module.
Table 11 Verifier Requirements
FIPS 186-4 Requirement Module Capabilities and Recommendations
Obtain assurance of the
signatory’s claimed identity.
The module verifies the signature created using the private key,
but all other assurances are outside the scope of the module.
Obtain assurance of the
validity of the domain
parameters for DSA and
ECDSA.
The module provides APIs to validate DSA parameters for
probable primes as described in FIPS 186-4.
For the JCM API, AlgParamGenerator.verify()
For ECDSA, use the NIST recommended curves as defined in
section 2.3.1.
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)
Obtain assurance that the
claimed signatory actually
possessed the private key that
was used to generate the
digital signature at the time that
the signature was generated.
Outside the scope of the module.
Table 10 Signatory Requirements (continued)
FIPS 186-4 Requirement Module Capabilities and Recommendations
36 RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy
2.3.3 Crypto User Guidance on Key Generation and Entropy
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.
When generating secure keys, the DRBG used in key generation must be seeded with a
number of bits of entropy that is equal to or greater than the security strength of the key
being generated. The entropy supplied to the DRBG is referred to as the DRBG security
strength which represents the minimum amount of entropy that should be provided to the
DRBG prior to the key generation operation.
The following table lists each of the keys that can be generated by the JCM, with the key
sizes available, security strengths for each key size and the security strength required to
initialize the DRBG.
2.3.4 Information on Minimum Password Length
Minimum Password Length:
The minimum length (L) of a password generated using a cryptographically secure
random password generator to provide a search space of S entries depends on the size
(N) of the character set:
L= log2S/log2N
The following table provides some examples for:
• A password, used by PBKDF2: S = 4.32x 1020
• A password, used directly as the PIN by the KDF, used to secure the roles database:
S = 6 x 1021
Table 12 Generated Key Sizes and Strength
Key Type Key Size Security Strength
Required DRBG
Security Strength
AES Key 128, 192, 256 128, 192, 256 128, 192, 256
RSA Key Pair 2048, 3072 112, 128 112, 128
DSA Key Pair 2048, 3072 112, 128 112, 128
EC Key Pair 224, 256, 384, 521 112, 128, 192, 256 112, 128, 192, 256
Character Set N
L
S = 4.32 x 1020
S = 6 x 1021
Case sensitive (a-z, A-Z) 52 13 13
Case sensitive alpha numeric 62 12 13
All ASCII printable characters except
space
94 11 11
12.12.23
RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy 37
2.3.5 General Crypto User Guidance
JCM users should take care to zeroize CSPs when they are no longer needed. For more
information on clearing sensitive data, see section 1.5.3 and the relevant API Javadoc.
2.4 Crypto Officer Guidance
The Crypto Officer is responsible for installing the module. Installation instructions are
provided in the RSA BSAFE Crypto-J Installation Guide.
The Crypto Officer is responsible for loading the module, as specified in section 2.1
Module Configuration.
The Crypto Officer is responsible for configuring the PINs for their own role and the
Crypto User role.
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.
38 RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy
3 Acronyms
The following table lists the acronyms used with the JCM and their definitions.
Table 13 Acronyms used with the JCM
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. A block cipher mode of operation which provides a
means for the authenticated decryption function to verify the authenticity and
integrity of the data.
AEAD Authenticated Encryption with Associated Data.
AES Advanced Encryption Standard. A fast block cipher with a 128-bit block, and
keys of lengths 128, 192 and 256 bits. This will replace DES as the US
symmetric encryption standard.
API Application Programming Interface.
Attack Either a successful or unsuccessful attempt at breaking part or all of a
crypto-system. Attack types include an algebraic attack, birthday attack, brute
force attack, chosen ciphertext attack, chosen plaintext attack, differential
cryptanalysis, known plaintext attack, linear cryptanalysis, middleperson attack
and timing attack.
BPS BPS is a format preserving encryption mode.
BPS stands for Brier, Peyrin and Stern, the inventors of this mode.
CBC Cipher Block Chaining. A mode of encryption in which each ciphertext depends
upon all previous ciphertexts. Changing the IV alters the ciphertext produced
by successive encryptions of an identical plaintext.
CFB Cipher Feedback. A mode of encryption that produces a stream of ciphertext
bits rather than a succession of blocks. In other respects, it has similar
properties to the CBC mode of operation.
ChaCha20 A member of the ChaCha family of stream ciphers built on a pseudo-random
function, based on add-rotate-xor operations: 32-bit addition, bitwise addition
(XOR) and rotation operations.
ChaCha20 is standardized in RFC 7539.
ChaCha20/
Poly1305
A combination of the ChaCha20 and Poly1305 algorithms to provide an AEAD
algorithm. This is standardized in RFC 7539.
CKG Cryptographic Key Generation.
CMAC Cipher-based Message Authentication Code. A block cipher-based MAC
algorithm.
CRNG Continuous Random Number Generation.
CSP Critical Security Parameters.
12.12.23
RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy 39
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. A mode of encryption which enables block ciphers to be
used to process data not evenly divisible into blocks, without the length of the
ciphertext increasing.
DES Data Encryption Standard. A symmetric encryption algorithm which uses a
56-bit key with eight parity bits.
DH,
Diffie-Hellman
The Diffie-Hellman asymmetric key exchange algorithm. There are many
variants, but typically two entities exchange some public information (for
example, public keys or random values) and combines them with their own
private keys to generate a shared session key. As private keys are not
transmitted, eavesdroppers are not privy to all of the information that
composes the session key.
DPK Data Protection Key.
DRBG Deterministic Random Bit Generator.
DSA Digital Signature Algorithm. An asymmetric algorithm for creating digital
signatures.
EC Elliptic Curve.
ECB Electronic Code Book. A mode of encryption in which identical plaintexts are
encrypted to identical ciphertexts, given the same key.
ECC Elliptic Curve Cryptography.
ECDH Elliptic Curve Diffie-Hellman.
ECC-CDH ECC Cofactor Diffie-Hellman.
ECDHC Elliptic Curve Cryptography Diffie-Hellman
ECDSA Elliptic Curve Digital Signature Algorithm.
ECIES Elliptic Curve Integrated Encryption Scheme.
Encryption The transformation of plaintext into an apparently less readable form (called
ciphertext) through a mathematical process. The ciphertext may be read by
anyone who has the key that decrypts (undoes the encryption) the ciphertext.
FFC Finite Field Cryptography
FIPS Federal Information Processing Standards.
FPE Format Preserving Encryption.
HKDF HMAC-based Extract-and-Expand Key Derivation Function.
HMAC Keyed-Hashing for Message Authentication Code.
Table 13 Acronyms used with the JCM (continued)
Acronym Definition
40 RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy
IV Initialization Vector. Used as a seed value for an encryption operation.
JCE Java Cryptography Extension.
JVM Java Virtual Machine.
KAT Known Answer Test.
KDF Key Derivation Function. Derives one or more secret keys from a secret value,
such as a master key, using a pseudo-random function.
Key A string of bits used in cryptography, allowing people to encrypt and decrypt
data. Can be used to perform other mathematical operations as well. Given a
cipher, a key determines the mapping of the plaintext to the ciphertext. Various
types of keys include: distributed key, private key, public key, secret key,
session key, shared key, subkey, symmetric key, and weak key.
KW AES Key Wrap.
KWP AES Key Wrap with Padding.
MAC Message Authentication Code.
MD5 A secure hash algorithm created by Ron Rivest. MD5 hashes an
arbitrary-length input into a 16-byte digest.
NIST National Institute of Standards and Technology. A division of the US
Department of Commerce (formerly known as the NBS) which produces
security and cryptography-related standards.
OFB Output Feedback. A mode of encryption in which the cipher is decoupled from
its ciphertext.
OS Operating System.
PBE Password-Based Encryption.
PBKDF Password-Based Key Derivation Function.
PBKDF2 A method of password-based key derivation, originally defined in RFC 2988,
which applies a MAC algorithm to derive the key. In RFC 2988 the PRF used
by PBKDF2 is specified as SHA-1. SP 800-132 approves PBKDF2 where the
PRF may be any FIPS approved hash function. In this document PBKDF2
represents the expanded specification provided in SP 800-132.
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.
Table 13 Acronyms used with the JCM (continued)
Acronym Definition
12.12.23
RSA BSAFE Crypto-J JSAFE and JCE Software Module 6.2.5 Security Policy 41
RC2 Block cipher developed by Ron Rivest as an alternative to the DES. It has a
block size of 64 bits and a variable key size. It is a legacy cipher and RC5
should be used in preference.
RC4 Symmetric algorithm designed by Ron Rivest using variable length keys
(usually 40 bit or 128 bit).
RC5 Block cipher designed by Ron Rivest. It is parameterizable in its word size, key
length and number of rounds. Typical use involves a block size of 64 bits, a key
size of 128 bits and either 16 or 20 iterations of its round function.
RNG Random Number Generator.
RSA Public key (asymmetric) algorithm providing the ability to encrypt data and
create and verify digital signatures. RSA stands for Rivest, Shamir, and
Adleman, the developers of the RSA public key crypto-system.
SHA Secure Hash Algorithm. An algorithm which creates a hash value for each
possible input. SHA takes an arbitrary input which is hashed into a 160-bit
digest.
SHA-1 A revision to SHA to correct a weakness. It produces 160-bit digests. SHA-1
takes an arbitrary input which is hashed into a 20-byte digest.
SHA-2 The NIST-mandated successor to SHA-1, to complement the Advanced
Encryption Standard. It is a family of hash algorithms (SHA-256, SHA-384 and
SHA-512) which produce digests of 256, 384 and 512 bits respectively.
SHA-3 A family of hash algorithms which includes SHA3-224, SHA3-256, SHA3-384
and SHA3-512. It also includes the extendable-output functions SHAKE128
and SHAKE256. SHA-3 is an alternative to SHA-2, as no significant attacks on
SHA-2 are currently known.
Shamir Secret
Sharing
A form of secret sharing where a secret is divided into parts, and each
participant is given a unique part. Some or all of the parts are needed to
reconstruct the secret. This is also known as a (k,n) threshold scheme where
any k of the n parts are sufficient to reconstruct the original secret.
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.
Table 13 Acronyms used with the JCM (continued)
Acronym Definition
42 © 2023 Dell Inc. or its subsidiaries. All rights reserved. Dell, BSAFE and other trademarks are trademarks of Dell
Inc. or its subsidiaries. Other trademarks may be trademarks of their respective owners.
4 Change Summary
May 2023 Updated the FIPS 140-2 Allowed Algorithm section.
Clarification about the last date after which RSA algorithms will not be
considered as FIPS 140-2 allowed algorithms.
December 2022 Updated the vendor affirmed platforms.
Laboratory Validated Operating Environments
Affirmation of Compliance for other Operating Environments.
Moved KTS, Key Transport Scheme, algorithms to FIPS 140-2 Allowed
Algorithms.
Further clarification of DH, ECDH, and ECC-CDH references.
Further clarification of CSP generation.
June 2022 Move Triple-DES algorithm to non-approved.
Further clarification of ECDH and ECC-CDH references.
November 2021 Update - removal of DH references, and clarification of ECDH and
ECC-CDH references.
October 2021 Updated the vendor affirmed platforms.
Laboratory Validated Operating Environments
Affirmation of Compliance for other Operating Environments.
Update - Preface - Notice of Dell acquisition.
Update Table 7, Key and CSP Storage and Table 8, Key and CSP
Access.
May 2021 Moved non-compliant SP 800-56A references, according to FIPS 140-2
Implementation Guidance D.1 - Revision 2:
Crypto User Guidance on Algorithms
Table 5, Services Available only to the Crypto User Role
Table 8, Key and CSP Access
Table 9, JCM FIPS 140-2 Approved Algorithms
FIPS 140-2 Allowed Algorithms
Non-FIPS 140-2 Approved Algorithms