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.
|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|
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.
- 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
- 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
- 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
- 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:
Differences between IBM JCE FIPS Version 1.71 and 1.7: Maintaining FIPS 140-2 compliance beyond 2015
- HASHDRBG and variants (SHA2DRBG, SHA5DRBG)
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.
- All 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 10
- Applications that call IBMSecureRandom must make a small code change to call HASHDRBG instead, as shown in the examples.
SecureRandom.getInstance("IBMSecureRandom", "IBMJCEFIPS") SecureRandom.getInstance("FIPSPRNG", "IBMJCEFIPS")
new SecureRandom() SecureRandom.getInstance("IBMSecureRandom") SecureRandom.getInstance("FIPSPRNG")
SecureRandom.getInstance("SHA2DRBG", "IBMJCEFIPS"); SecureRandom.getInstance("HASHDRBG", "IBMJCEFIPS"); SecureRandom.getInstance("SHA5DRBG", "IBMJCEFIPS");
SecureRandom.getInstance("SHA2DRBG"); SecureRandom.getInstance("HASHDRBG"); SecureRandom.getInstance("SHA5DRBG");