IBM JCE FIPS 140-2 Cryptographic Module Security Policy

The IBM® JCE (Java™ Cryptographic Extension) FIPS Provider (IBMJCEFIPS) for multi-platforms is a scalable, multi-purpose cryptographic module that supports FIPS-approved cryptographic operations through Java APIs.

Note:
  1. Start of changes for service refresh 8 fix pack 20The IBMJCEPlusFIPS and IBMJCEFIPS FIPS 140-2 cryptographic providers should be considered deprecated technology on platforms where FIPS 140-3 will be made available. Once the FIPS 140-3 IBMJCEPlusFIPS cryptographic provider is fully supported for production use, the FIPS 140-2 cryptographic providers on those platforms will be subject to removal in the future. All products and customers will need to move to the new FIPS 140-3 IBMJCEPlusFIPS provider for their FIPS certified cryptography.End of changes for service refresh 8 fix pack 20
  2. The FIPS 140-2 cryptographic module certification for the IBMJCEFIPS provider, as documented in Cryptographic Module Validation Program CMVP, Certificate #2715, expired on 21 August 2021 and will not be renewed. The ibmjcefips.jar file will remain part of the SDK however you should upgrade to service refresh 7 or later and use the IBMJCEPlusFIPS JCE cryptographic provider to achieve FIPS 140-2 compliance of applications in future. (The IBMJCEPlusFIPS provider was added in service refresh 6, fix pack 10 but was signed with the SHA256withRSA signature algorithm in service refresh 7, for enhanced security.)

Documentation

The certified JCE FIPS policy document is published on the Computer Security Resource Center website:
Table 1. JCE FIPS guide for various levels of the SDK
SDK level IBM JCE FIPS provider version URL
Service refresh 3, fix pack 10 and later 1.8
https://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp2715.pdf (IBM JCE FIPS module)
https://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp2837.pdf (IBM JCE FIPS module with CPACF, a cryptographic component of the IBM System z® architecture)
Service refresh 1, fix pack 10 and later 1.71 https://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp1993.pdf
Earlier levels 1.7 https://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp1993.pdf
If you need to see earlier versions, they are available in the IBM section of the vendor list: https://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401vend.htm.
Start of changes for service refresh 3 fix pack 10

Differences between IBM JCE FIPS Version 1.8 and Version 1.71

Version 1.71 complied with the older SP186-2 digital signature standards. It was certified as software-only without any hardware acceleration. Version 1.71 was partially compliant with SP800-38D symmetric key block cipher requirements, and used a SecureRandom implementation which was disallowed beginning in 2016. The new IBM JCE FIPS 1.8 provider is compliant with SP186-4 digital signature requirements. It is also certified on hardware platforms with crypto-capable processors, in addition to the software-only version. Version 1.8 is fully compliant with SP800-38D requirements and contains security fixes to vulnerabilities found since the last full certification. The newer version also meets the new FIPS random number rules and seeding requirements.

Version 1.8 is included from service refresh 3 fix pack 10. The following list describes the differences between the two versions in more detail. Some of these differences require changes to your application code when you upgrade to the relevant version of the SDK:
Handling of non FIPS-compliant algorithms

To be FIPS 140-2 compliant, your applications must use only the key sizes and algorithms that are specified in the JCE FIPS guide.

In version 1.8, the provider throws an exception for the following non FIPS-compliant algorithms:
  • MD5 for both signature generation and verification
  • SHAwithDSA, SHA224withDSA for key and signature generations using keys of any key size.

The provider continues to function in a non-compliant mode for SHAwithRSA and SHAwithECDSA algorithms for key and signature generation.

Caller-provided IBMSecureRandom number generators are ignored
To be FIPS 140-2 compliant during key pair generation, version 1.8 ignores caller-provided random number generators and instead uses the internal FIPS-approved SHA2DRBG generator. This update does not require changes to your application code. The update applies to the following key/parameter generation operations:
  • AES Key Generator
  • DESede Key Generator
  • DH Key Pairs
  • EC Key Pairs
  • DSA Key Pairs
  • RSA Key Pairs
  • Hmac SHA1
  • Hmac SHA224
  • Hmac SH256
  • Hmac SHA384
  • Hmac-SHA512
  • GCM Parameter Generator
  • DSA Parameter generator
  • EC Parameter Generator

Behavior of IBMSecureRandom and HASHDRBG random number generators

The IBMSecureRandom class is no longer a FIPS-approved SecureRandom number generator. For compatibility reasons, the algorithm aliases “IBMSecureRandom” and “FIPSPRNG” are changed to use the FIPS-approved SHA2DRBG implementation. IBMJCEFIPS version 1.71 required that applications modify the code to use alias “SHA2DRBG” instead of “IBMSecureRandom” or “FIPSPRNG”, as described in the section Differences between IBM JCE FIPS Version 1.71 and 1.7: Maintaining FIPS 140-2 compliance beyond 2015. Because the algorithm aliases are changed in version 1.8 to point to the FIPS-approved algorithm, this code modification is no longer required.

The HASHDRBG number generator now allows only digest algorithms that are supported by the IBMJCEFIPS provider. A call to the init method of the HASHDRBG class with a hash algorithm that is not supported by the IBMJCEFIPS provider throws an IllegalArgumentException. This exception indicates that the digest algorithm is not FIPS-compliant as a HASHDRBG SecureRandom implementation. The HASHDRBG number generator also ignores any external seed that is provided by the caller, and instead uses a seed that is auto-generated by a non-deterministic random number generator that meets FIPS certification requirements for an entropy source. The signature of the init method is preserved to avoid application compilation errors.

The IBMSecureRandom number generator, and the HASHDRBG number generator and its variants, limit the number of random bits for each request to 219. Requests greater than 219 bits result in an IllegalArgumentException with the following message: 
The input parameter exceeds length requirement per request
SP186-4 compliance changes
Version 1.71 complied with the FIPS SP186-2 digital signature standard. Version 1.8 complies with the newer SP186-4 standard, which results in some differences in behavior. You must change your application code if it uses non-approved algorithms and key sizes, as described in the following list:
  • If you specify key sizes other than 2048 or 3072 for DSA key and signature generation, your application is not compliant.
  • The FIPS 186-4 standard states, for DSA in section 4.2, that a hash function that provides a lower security strength than the (L, N) pair ordinarily should not be used. DSA-related signature methods are therefore changed in Version 1.8 to check the strength of the key being used and to throw an InvalidKeyException if the key is too strong for the signature algorithm. Additionally, during DSA key and signature generation, specifying digest algorithms whose lengths are less than 32 bytes results in a ProviderException, with the message The signature algorithm is not supported.
  • MD5 signed certificates are not accepted.
  • Elliptic Curve P-192 is not a FIPS-compliant algorithm.

AES, Triple-DES encryption and decryption changes

During AES encryption and decryption operations, version 1.71 allowed block sizes of CFB-8 and CBF-64 in addition to other modes that are in the range and multiples of 8 bits. Version 1.8 is more restrictive and accepts only modes CFB-8 bits and CFB-64 bits. You must change your application code if it uses modes other than CFB-8 and CFB-64 bits.

During Triple-DES encryption and decryption operations, version 1.71 allowed modes CFB-8 and CBF-128 in addition to other modes that are in the range and multiples of 8 bits. Version 1.8 is more restrictive and accepts only modes CFB-8 bits and CFB-128 bits. You must change your application code if it uses modes other than CFB-8 and CFB-128 bits.

Triple-DES keys changes

To meet the new FIPS 140-2 requirements, version 1.8 verifies that none of the Triple-DES key parts are equal. The provider throws a FIPSRuntimeException if the verification fails. This check was not performed in version 1.71 of the provider. You might need to change your application code if it generates or uses key parts that are equal.

Other changes
Version 1.8 also includes fixes and the following new features:
  • Use of hardware acceleration on hardware with crypto-capable processors. See the JCE FIPS guide for more information about tested environments. When the IBMJCEFIPS provider is loaded, it automatically detects the hardware on which it is running and determines whether hardware acceleration is supported. You can disable hardware acceleration by specifying the following VM runtime argument:
    • -Dcom.ibm.crypto.fips.provider.enableHardwareAcceleration=false
  • Support for RFC5915-encoded EC private keys
  • Support for the following SHA224 algorithms:
    • Key Pair generation: HmacSHA224
    • Message Authentication Code: HmacSHA224
    • Message Digest: SHA224
    • Signature: SHA224wtihECDSA
    • Signature: SHA224withRSA
    • Ciphers: RSA/OAEPPaddingSHA-224
End of changes for service refresh 3 fix pack 10

Differences between IBM JCE FIPS Version 1.71 and 1.7: Maintaining FIPS 140-2 compliance beyond 2015

IBMJCEFIPS, Version 1.7, has two random number generators:
  • IBMSecureRandom
  • HASHDRBG and variants (SHA2DRBG, SHA5DRBG)
By the end of 2015, due to changes in NIST rules, the use of IBMSecureRandom will result in non-compliance with FIPS140-2 random number rules.

In the IBMJCEFIPS V1.7 jar, HASHDRBG is not being re-seeded properly by the RSA algorithm resulting in a shorter seed. This seed causes applications that call HASHDRBG via RSA to encounter an exception. To avoid this defect, the Java Secure Socket Extension (JSSE) provider, when running in FIPS 140-2 compliance mode, explicitly calls IBMSecureRandom when applications call HASHDRBG via RSA.

IBMJCEFIPS, Version 1.71 is FIPS certified and provides a seed of adequate length to the re-seeding of HASHDRBG. Two actions are necessary to maintain compliance beyond 2015:
  1. Start of changes for service refresh 1 fix pack 10All applications must install the updated versions of IBMJCEFIPS and IBM JSSE Provider jar files (ibmjcefips.jar and ibmjsseprovider2.jar) provided in service refresh 1 fix pack 10End of changes for service refresh 1 fix pack 10
  2. Applications that call IBMSecureRandom must make a small code change to call HASHDRBG instead, as shown in the examples.

Existing code

Where IBM JCEFIPS is explicitly specified as the provider: 
   SecureRandom.getInstance("IBMSecureRandom", "IBMJCEFIPS")
   SecureRandom.getInstance("FIPSPRNG", "IBMJCEFIPS")
Where IBMJCEFIPS is first in the provider list: 
   new SecureRandom()
   SecureRandom.getInstance("IBMSecureRandom")
   SecureRandom.getInstance("FIPSPRNG")

Required code

Where IBM JCEFIPS is explicitly specified as the provider: 
   SecureRandom.getInstance("SHA2DRBG", "IBMJCEFIPS");
   SecureRandom.getInstance("HASHDRBG", "IBMJCEFIPS");
   SecureRandom.getInstance("SHA5DRBG", "IBMJCEFIPS");
Where IBMJCEFIPS is first in the provider list: 
   SecureRandom.getInstance("SHA2DRBG");
   SecureRandom.getInstance("HASHDRBG");
   SecureRandom.getInstance("SHA5DRBG");