Service refresh 8

Read about the changes in service refresh 8, and subsequent fix packs.

Skip to Service refresh 8 fix pack 5.

Skip to Service refresh 8 fix pack 10.

Skip to Service refresh 8 fix pack 15.

Skip to Service refresh 8 fix pack 20.

Service refresh 8

This release contains the latest IBM fixes, the most recent Oracle Critical Patch Update (CPU), and the following new features.

Technology preview for FIPS 140-3 evaluation (contains changes that might affect all users)
On AIX®, Linux®, and Windows, an unsupported technology preview is available for users who have existing FIPS 140-2 deployments to assess the changes that are required to those deployments to move to the FIPS 140-3 standard. The existing support for the FIPS 140-2 standard is unchanged.
Note: This technology preview contains the following changes that might affect you if you modify certain files or system properties, even if you do not use the technology preview or FIPS 140 cryptography. These changes should be temporary, lasting only as long as the technology preview is available:
  • The install_dir/jre/lib/security/java.policy file now contains the following extra permission:
    grant codeBase "file:${java.home}/fips${com.ibm.fips.mode}/lib/ext/*" {
    permission java.security.AllPermission;
};
    If you use your own java.policy file and it doesn't contain this permission, you might see a java.lang.ExceptionInInitializerError exception and messages similar to the following examples:
    Caused by: java.security.ProviderException: Failed to initialize IBMJCEPlus provider
    Caused by: java.security.ProviderException: Access denied ("java.util.PropertyPermission" "java.home" "read")
    To fix this problem, add the extra permission to your java.policy file.
  • The value of the java.ext.dirs system property is changed to add the path install_dir/jre/fips140-n/lib/ext, where n is the FIPS 140 version (either 3, if you enable the technology preview, or 2). The technology preview appends this path to the existing property value so if you already modified the value, your changes are preserved. However, if the technology preview does not work or your existing FIPS 140-2 deployment stops working, and you see a java.lang.ExceptionInInitializerError exception, check that the value of this property contains this path.
The technology preview is provided for evaluation purposes only and must not be used in a production environment. For more information, see FIPS 140-3 evaluation technology.
New system and security properties added for customizing the generation of a PKCS12 keystore
The following new system and security properties are added to enable users to customize the generation of a PKCS12 keystore:
  • keystore.pkcs12.keyProtectionAlgorithm
  • keystore.pkcs12.keyPbeIterationCount
  • keystore.pkcs12.certProtectionAlgorithm
  • keystore.pkcs12.certPbeIterationCount
  • keystore.pkcs12.macAlgorithm
  • keystore.pkcs12.macIterationCount

For more information about these properties, see PKCS12 KeyStore properties section of the $JAVA_HOME/jre/lib/security/java.security file.

New PBES2 algorithms added for cipher algorithms
Support for the following PBES2 algorithms is added for cipher algorithms:
  • PBEWithHmacSHA1AndAES_128
  • PBEWithHmacSHA224AndAES_128
  • PBEWithHmacSHA256AndAES_128
  • PBEWithHmacSHA384AndAES_128
  • PBEWithHmacSHA512AndAES_128
  • PBEWithHmacSHA1AndAES_256
  • PBEWithHmacSHA224AndAES_256
  • PBEWithHmacSHA256AndAES_256
  • PBEWithHmacSHA384AndAES_256
  • PBEWithHmacSHA512AndAES_256
Default algorithms to encrypt certificates and keys in a PKCS12 keystore are upgraded
The default algorithms that are used to encrypt certificates and keys in a PKCS12 keystore are upgraded to the following algorithms:
  • keystore.pkcs12.certProtectionAlgorithm = PBEWithHmacSHA256AndAES_256
  • keystore.pkcs12.keyProtectionAlgorithm = PBEWithHmacSHA256AndAES_256
You can adjust the iteration count security properties because the algorithms are stronger. The default values are as follows.
  • keystore.pkcs12.certPbeIterationCount = 10000
  • keystore.pkcs12.keyPbeIterationCount = 10000

To change these values, edit the java.security file, uncomment (remove the leading "#"), and modify the values of these security properties.

Support for SHA-2 HmacPBE algorithms for MAC is added
Support is added for the following SHA-2 HmacPBE algorithms to the IBMJCE provider:
  • HmacPBESHA224
  • HmacPBESHA256
  • HmacPBESHA384
  • HmacPBESHA512
  • HmacPBESHA512/224
  • HmacPBESHA512/256

You can specify one of these algorithms when you create an instance of the javax.crypto.Mac class.

Default PKCS12 MAC and encryption algorithms are upgraded
The default MAC and encryption algorithms that are used in a PKCS12 keystore are updated. The new algorithms are based on AES-256 and SHA-256 and are stronger than the old algorithms that were based on RC2, DESede, and SHA-1. The default values of the security properties are as follows.
  • keystore.pkcs12.macAlgorithm = HmacPBESHA256
  • keystore.pkcs12.macIterationCount = 10000

Some PKCS12 tools and libraries might not support algorithms that are based on PBES2 and AES. For compatibility, a new system property that is called keystore.pkcs12.legacy is defined in the java.security file. When set, this system property (which does not have a value) reverts the behavior to use the older, weaker algorithms. The PKCS12 keystores that were created with the old (weaker) algorithms can be read without specifying the keystore.pkcs12.legacy option. However, the keystores that were created with the new (stronger) algorithms cannot be read by JVM before Java8 SR8. For more information, see the PKCS12 KeyStore properties section of the java.security file.

SHA-1 signed JAR files are restricted
JAR files that are signed with SHA-1 algorithms are now restricted by default and treated as if they were unsigned. This restriction applies to the following items:
  • Algorithms that are used to sign, digest, and timestamp the JAR file.
  • Algorithms that are used to sign, and digest the certificates in the certificate chain of the code signer, the timestamp authority, and any responses that are used to verify whether the certificates are revoked.
  • Signed JCE providers.

To reduce the compatibility risk for JAR files that were previously timestamped, the following exception applies. This exception might be removed in future to make the policy more restrictive.

  • Any JAR file that is signed with SHA-1 algorithms and timestamped before 1 January 2019 is not restricted.
To determine whether your signed JAR files are affected by this change, run jarsigner -verify -verbose -certs on the signed JAR file. Look for instances of SHA1 or SHA-1 and disabled and a warning that the JAR file is treated as unsigned in the output that is generated. For example,
-  Signed by "CN="Signer""
     Digest algorithm: SHA-1 (disabled)
     Signature algorithm: SHA1withRSA (disabled), 2048-bit key
WARNING: The jar will be treated as unsigned, because it is signed with a weak algorithm that is now disabled by the security property:
  jdk.jar.disabledAlgorithms=MD2, MD5, RSA keySize < 1024, DSA keySize < 1024, SHA1 denyAfter 2019-01-01

If you find any JAR files that are affected by this restriction, replace or re-sign with stronger algorithms.

You can remove this restriction at your own risk by modifying the java.security configuration file or overriding it by using the java.security.properties system property. To remove the restriction, delete SHA1 usage SignedJAR & denyAfter 2019-01-01 from the jdk.certpath.disabledAlgorithms security property and SHA1 denyAfter 2019-01-01 from the jdk.jar.disabledAlgorithms security property.

The security properties in the java.security file are as shown in the following example:

jdk.certpath.disabledAlgorithms=MD2, MD5, SHA1 jdkCA & usage TLSServer, \
    RSA keySize < 1024, DSA keySize < 1024, EC keySize < 224, \
    SHA1 usage SignedJAR & denyAfter 2019-01-01
jdk.jar.disabledAlgorithms=MD2, MD5, RSA keySize < 1024, \
    DSA keySize < 1024, SHA1 denyAfter 2019-01-01
Some hardware cryptographic cards are no longer supported
The following hardware cryptographic cards are no longer supported by the manufacturer and so are no longer supported by the IBMPKCS11Impl crypto provider:
  • SafeNet Luna SA 4.0, 4.5, 5.0, 6.0
  • Entrust nShield Connect 500+, 1500+, 6000+
  • Entrust Solo 500+, 6000+
Note: nCipher is rebranded as Entrust and so all the nCipher cryptographic cards are now part of the Entrust product line.

Service refresh 8 fix pack 5

This release contains the latest IBM fixes, the most recent Oracle Critical Patch Update (CPU), and the following new features.

Updates to the technology preview for FIPS 140-3 evaluation
The following RSA key exchange ciphers are now not allowed in FIPS 140-3 technology preview because NIST is deprecating the use of RSA key transport for key exchange and disabling its use. DHE_RSA key exchange ciphers with AES bulk encryption are allowed.
  • TLS_RSA_WITH_AES_128_CBC_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA256
  • TLS_RSA_WITH_AES_128_GCM_SHA256
  • TLS_RSA_WITH_AES_256_GCM_SHA384
For more information, see NIST special publication 800-52, Revision 2.

The technology preview is provided for evaluation purposes only and must not be used in a production environment. For more information, see FIPS 140-3 evaluation technology.

Service refresh 8 fix pack 10

This release contains the latest IBM fixes, and the most recent Oracle Critical Patch Update (CPU).

Service refresh 8 fix pack 15

This release contains the latest IBM fixes, and the most recent Oracle Critical Patch Update (CPU), and the following new features.

CCM mode for the AES cipher algorithm is added

Counter with CBC-MAC (CCM) mode for the AES cipher algorithm is added to the IBMJCEPlus and IBMJCEPlusFIPS providers.

New CCMParameterSpec class

The IBMJCEPlus and IBMJCEPlusFIPS security providers support encryption and decryption with the AES-CCM mode. You can specify AES-CCM cipher parameters within the CCMParameterSpec class. For more information, see CCMParameterSpec class documentation.

Support for Kerberos Cross-Realm Referrals (RFC 6806) is added

The Kerberos client is enhanced with support for principal name canonicalization and cross-realm referrals, as defined by the RFC6806 protocol extension. The Kerberos client can now take advantage of more dynamic environment configurations, and does not necessarily need to know in advance how to reach the realm of a target principal (user or service). Support is enabled by default and the maximum number of referral hops allowed is set to 5. To disable it, set the com.ibm.security.krb5.disableReferrals security, or system property to false. To configure a custom maximum number of referral hops, set the com.ibm.security.krb5.maxReferrals security, or system property to any positive value.

Note: The com.ibm.security.krb5.disableReferrals and com.ibm.security.krb5.maxReferrals Java™ Generic Security Service (JGSS) configuration options can be set statically in the java.security file as a security property, or dynamically at runtime as a system property.
Support for the canonicalize flag in krb5.conf is added

The Kerberos implementation now supports the canonicalize flag in the krb5.conf file. When set to true, RFC6806 name canonicalization is requested by clients in TGT requests to KDC services (AS protocol). Otherwise, by default it is not requested.

Support for Cross-Realm Kerberos MS-SFU Extensions is added

The support for the Kerberos MS-SFU extensions is now extended to cross-realm environments through the addition of resource-based constrained delegation support. By using the Kerberos cross-realm referrals enhancement, the S4U2Self and S4U2Proxy extensions might be used to impersonate user and service principals that are located on different realms.

New system property for controlling the enforcement of RFC 5246 - TLS 1.2 Section 7.4.1.4.1. Signature Algorithms
A new system property, com.ibm.jsse2.strictServerSigCheck, is added to control the enforcement of RFC 5246 - TLS 1.2 Section 7.4.1.4.1. Signature Algorithms. This property has the following possible values:
  • true: The implementation validates that the server's certificate chain is in compliance with the client's signature algorithm extension.
  • false (default): The implementation validates only the server’s end entity certificate..

This property is documented along with other system properties in Customization.

New PKCS #11 card support

The IBM® PKCS #11 cryptographic provider now supports the use of the IBM Crypto Express 8 hardware cryptographic card. For more information, see IBM PKCS11 Cryptographic Provider.

SafeNet is rebranded as Thales

SafeNet is rebranded as Thales. All SafeNet cryptographic cards are now part of the Thales product line.

Service refresh 8 fix pack 20

This release contains the latest IBM fixes, and the most recent Oracle Critical Patch Update (CPU), and the following new features.

IBMJCEPlusFIPS and IBMJCEFIPS FIPS 140-2 cryptographic providers are deprecated and subject to removal in future
The 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, which is currently available as a technology preview, is fully supported for production use, the FIPS 140-2 cryptographic providers on those platforms will be subject to removal.
Note: FIPS 140-3 validation is ongoing for IBMJCEPlusFIPS, one of the security components in the IBM SDK. In the meantime, this unsupported technology preview is available for users who have existing FIPS 140-2 deployments to assess the changes that are required to those deployments to move to the FIPS 140-3 standard. For more information about the technology preview, see FIPS 140-3 evaluation technology.
Support for Password Based Encryption (PBE)
The implementation of PBEWithSHA1AndDESede used by the IBMJCE cryptographic provider was changed to use a stronger cryptographic algorithm that matches Oracle's SunJCE provider reference implementation. This change was made in Java 8 SR8. Data encrypted with an IBM JDK that is Java 8 SR8 or later can be decrypted with an IBM JDK prior to Java 8 SR8 by using the algorithm name PBEWithSHAAnd3KeyTripleDES.
The default TLS Diffie-Hellman group size increased from 1024-bit to 2048-bit
The JDK implementation of TLS 1.2 now uses a default Diffie-Hellman keysize of 2048 bits when a TLS_DHE cipher suite is negotiated and either the client or server does not support Finite Field Diffie-Hellman Ephemeral (FFDHE), which can negotiate a stronger keysize. The JDK TLS implementation supports FFDHE and it is enabled by default. You can revert to the previous size by setting the jdk.tls.ephemeralDHKeySize system property to 1024 but that is risky. This change does not affect TLS 1.3 because the minimum DH group size is already 2048 bits.
Server cipher suites preference used by default
For TLS connections, the cipher suite selection, by default, is updated to use the server cipher suites preference. Applications can configure the behavior by using the SSLParameters.setUseCipherSuitesOrder​() method.
RSA encryption and decryption support removed from the IBMJCEPlusFIPS provider
When JSSE is enabled to run in FIPS 140-2 mode, RSA key exchange cipher suites are disabled due to the Timing Oracle in RSA Decryption CVE-2023--33850 issue. As the fix could not be provided, the RSA encryption and decryption support has been removed from the IBMJCEPlusFIPS provider for FIPS 140-2.

For more information, see IBMJCEPlus and IBMJCEPlusFIPS providers.

The FIPS 140-3 provider is a technology preview only and is not supported for production use. The FIPS 140-3 IBMJCEPlusFIPS provider is undergoing FIPS certification, and due to FIPS certification rules, the fix is not yet included in that provider. As FIPS 140-3 does not allow the RSA key exchange, when JSSE is enabled to run in FIPS 140-3, TLS is not vulnerable to this issue.

For more information, see FIPS 140-3 evaluation technology.

New system property, -Dcom.ibm.fips.silentUsage added
When the JVM is in FIPS 140-2 mode and the IBMJCEPlusFIPS provider is used, a message is displayed to convey that the 140-2 configuration might be removed in the future. You can turn off this message display with the new system property configuration, -Dcom.ibm.fips.silentUsage=true. For more information, see Enabling the IBMJCEPlus and IBMJCEPlusFIPS providers.
New system property, org.jcp.xml.dsig.secureValidation added
You can enable XML Signature secure validation mode by setting the org.jcp.xml.dsig.secureValidation property to TRUE with the javax.xml.crypto.XMLCryptoContext.setProperty() method. Set this property to TRUE before validating an XML Signature. For more information, see Service providers.