Service refresh 3

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

Service refresh 3

This release contains a NIST compliance change for the IBMJCE provider. The AES-GCM cipher algorithm internal IV generation feature is improved to comply with the NIST SP 800-38D specification. The specification requires that the number of encryption operations, for a cipher instance that uses the same encryption key, must be limited to a maximum allowable number of iterations. When that number of iterations is exhausted, the following exception is thrown to notify the caller that a fresh encryption key must be used to reinitialize the cipher instance before encryption can continue:

IllegalStateException ("The maximum number of IV invocations for the current key have been exhausted.")

The maximum number of iterations is 18,446,744,073,709,551,615.

Service refresh 3 fix pack 10

This release contains a new version of the IBM® JCE FIPS provider, new system properties (one of which affects previous behavior), support for the IBMJCECCA provider for Linux® on IBM Z, and new aliases for the JCE provider.

New version of the JCE FIPS provider

This release includes version 1.8 of the IBM JCE FIPS provider. There are behavior differences between this version and the previous version, 1.71. These differences might require you to modify your application code if you are using the IBMJCEFIPS provider or the JSSE provider in FIPS mode. For more information, see IBM JCE FIPS 140-2 Cryptographic Module Security Policy.

Support for the IBMJCECCA provider for Linux on IBM Z

Java Cryptography Extension Common Cryptographic Architecture (IBMJCECCA) is a security provider that exploits hardware cryptography, and is used to supplement the Java Cryptography Extension (JCE). From this release, IBMJCECCA is supported for Linux on IBM Z as well as for z/OS®.

For more information, see: The IBMJCECCA provider.

Matching the behavior of SSLContext.getInstance("TLS") to Oracle

Compared to the Oracle implementation, differences exist in the versions of TLS that are enabled when you set an SSL context object to enable the protocol. A new system property is available to match the behavior of SSLContext.getInstance("TLS") in the IBM SDK with the Oracle implementation. For more information, see Matching the behavior of SSLContext.getInstance("TLS") to Oracle.

JGSS: Specifying Kerberos encryption types

You can now specify Kerberos encryption types by using the com.ibm.security.krb5.enctypes Java system property. For more information, see Some JGSS Used Java Properties.

Security: New PBE alias names

Several AES-based, password-based encryption (PBE) aliases are added to the IBMJCE provider. These PBE aliases correspond to the algorithm names used by Oracle:

PBEWithHmacSHA1AndAES_128
PBEWithHmacSHA224AndAES_128
PBEWithHmacSHA256AndAES_128
PBEWithHmacSHA384AndAES_128
PBEWithHmacSHA512AndAES_128
PBEWithHmacSHA1AndAES_256
PBEWithHmacSHA224AndAES_256
PBEWithHmacSHA256AndAES_256
PBEWithHmacSHA384AndAES_256
PBEWithHmacSHA512AndAES_256

Service refresh 3 fix pack 20

This release contains updates to the IBMJCECCA provider (z/OS and Linux on IBM Z® only).

You can now use the hwkeytool command line utility to create an HMAC Java key object (com.ibm.crypto.hdwrCCA.provider.HMACKey) from an existing CKDS entry that contains a secure HMAC key, then store that key object in the IBMJCECCA keystore (JCECCAKS).

The IBMJCECCA provider now supports HMACSHA1, HMACSHA224, HMACSHA256, HMACSHA384, and HMACSHA512 SecretKeyFactory algorithms for creating a Java key object from a key specification that contains the label of an existing CKDS secure HMAC key entry.

The IBMJCECCA provider is also updated such that HmacSHA1, HmacSHA224, HmacSHA256, HmacSHA384, and HMACSHA512 Mac algorithms now include support for key objects that represent secure HMAC keys.

For more information about JCECCA, see IBMJCECCA.