First release

Learn about the new security features and functions available with this release.

KeyStore enhancements

  • A new command option, -importpassword, is available in the keytool utility. This command accepts a password and stores it securely as a secret key. For more information, see importpassword.
  • Other new classes such as java.security.PKCS12Attribute are added, and other security APIs are modified to support KeyStore enhancements.

The SecureRandom class: enhanced support for high-entropy random number generation

The SecureRandom class provides the generation of cryptographically strong random numbers that are used for private or public keys, ciphers, signed messages, and so on. Some SecureRandom implementations are stronger than others. This release adds the getInstanceStrong() method, which returns an instance of the strongest SecureRandom implementation available on each operating system.

Additional algorithms that have hardware acceleration

The following additional algorithms have hardware acceleration (if that is available on your platform) in this release:
  • Encryption: AES, DES, DESede
  • Key Agreement: ECDH
  • Signature: ECDSA
  • Message Digest: SHA-1, SHA-256, and SHA-512

Stronger algorithms for password-based encryption

Several AES-based, password-based encryption (PBE) algorithms are added to the IBMJCE provider:
  • PBEWithHmacSHA1And128BitAES
  • PBEWithHmacSHA224And128BitAES
  • PBEWithHmacSHA256And128BitAES
  • PBEWithHmacSHA384And128BitAES
  • PBEWithHmacSHA512And128BitAES
  • PBEWithHmacSHA1And256BitAES
  • PBEWithHmacSHA224And256BitAES
  • PBEWithHmacSHA256And256BitAES
  • PBEWithHmacSHA384And256BitAES
  • PBEWithHmacSHA512And256BitAES

AES-NI acceleration is enabled by default

Support for Intel Advanced Encryption Standard New Instructions (AES-NI) is enabled by default. The com.ibm.crypto.provider.doAESInHardware system property, which was provided in earlier releases to enable this support, therefore does not exist in this release.

Deprecation of algorithm name aliases

Support for the following Signature algorithm name aliases is deprecated in this release for both the IBMJCE and IBMPKCS11Impl providers:
  • SHA3WithRSA, SHA3/RSA
  • SHA5WithRSA, SHA5/RSA
  • SHA3WithECDSA, SHA3/ECDSA
  • SHA5WithECDSA, SHA5/ECDSA
The following Signature algorithm names should be used instead:
  • SHA384withRSA
  • SHA512withRSA
  • SHA384withECDSA
  • SHA512withECDSA
Support for the following MessageDigest algorithm name aliases is deprecated in this release for both the IBMJCE and IBMPKCS11Impl providers:
  • SHA-3, SHA3
  • SHA-5, SHA5
The following MessageDigest algorithm names should be used instead:
  • SHA-384 or SHA384
  • SHA-512 or SHA512

Although no changes are required to existing applications, further use of the deprecated algorithm name aliases is discouraged.

New XML Digital Signature provider

A new provider of XML Digital Signature services is available in this release. The IBMXMLCRYPTORI provider (org.jcp.xml.dsig.internal.dom.XMLDSigRI) is a port of the Oracle XMLDSig provider and is referred to in this documentation as the JSR 105 Reference Implementation provider. This new provider is not included in the list of default security providers. For more information about IBM security providers, see General information about security providers.

Client-side TLS 1.1 and 1.2 enabled by default.

In the IBMJSSE2 provider, the TLS V1.1 and TLS V1.2 protocols are now enabled by default on the client. For more information about default protocol settings, see Protocols.

Server Name Indication (SNI) Extension support in the IBM JSSE2 provider

The SNI extension is a feature of the JSSE2 provider that extends the SSL/TLS protocols to indicate what server name the client is attempting to connect to during handshaking. Servers can use SNI information to decide whether specific SSLSocket or SSLEngine instances should accept a connection. The SNI extension for client applications is enabled by default in the IBM JSSE2 provider in IBM® SDK, Java™ Technology Edition Version 7. This release supports the SNI extension for server applications. For more information, see Server Name Indication (SNI) Extension.

Support for stronger strength ephemeral Diffie-Hellman (DH) keys in the IBMJSSE2 provider

From this release, an ephemeral DH key must match the length of the certificate key during SSL/TLS handshaking in the IBMJSSE2 provider. A new system property, jdk.tls.ephemeralDHKeySize, is defined to customize the ephemeral DH key sizes. The minimum acceptable DH key size is 1024 bits, except for exportable cipher suites or legacy mode (jdk.tls.ephemeralDHKeySize=legacy). For more information, see Customizing the size of Ephemeral Diffie-Hellman Keys.

Support for server-side cipher suites preference customization in JSSE

By default, the IBMJSSE2 provider accepts the client's cipher suite preference. However, the behavior can be changed to respect the server's cipher suite preference by calling SSLParameters.setUseCipherSuitesOrder(true) in the server. For more information, see Cipher Suite Preference.

New CertPath PKIXRevocationChecker class

An application can obtain an instance of the new PKIXRevocationChecker class from either the CertPathBuilder.getRevocationChecker( ) method or from the CertPathValidator.getRevocationChecker( ) method. An instance of the PKIXRevocationChecker class is used by an invoking application to pass new revocation check arguments to either the CertPathBuilder or the CertPathValidator. For more information about this class and the options that are available, see The PKIXRevocationChecker Class.

Improvement in Kerberos replay caching

In earlier releases, Memory Replay Cache was the only available type of replay cache. This version introduces the com.ibm.security.krb5.rcache property, which provides the following additional options:
  • dfl: stores replay data in one file
  • none: do not check replay
By default, the JGSS implementation still uses Memory Replay Cache.

When mutual authentication is required, the acceptor side can generate a subkey to be used in the communication that follows. You control this behaviour by using the new com.ibm.security.krb5.acceptor.subkey system property . When this property is set to true, the acceptor generates a new subkey to be sent back together with the token for authentication, so that even if a replayed authenticator is not detected, a replayed message will not work. By default, the com.ibm.security.krb5.acceptor.subkey property is set to false.

Weak encryption type is disabled by default

The Kerberos configuration file contains an allow_weak_crypto entry in the libdefaults section to indicate whether weak cryptographic algorithms, DES_CBC_CRC and DES_CBC_MD5, are allowed. From Version 8, if this entry is not explicitly set to true, the IBM JGSS implementation does not allow weak cryptographic algorithms.

Constrained Kerberos delegation, S4U for Microsoft

If a service account is trusted for delegation, it can request service tickets on behalf of an authenticated user to any other service accounts. Constrained delegation is a way to restrict the service accounts for which service tickets can be obtained. This release introduces constrained Kerberos delegation, S4U2Proxy and S4U2Self.

Microsoft SPNEGO interoperation

Microsoft has implemented variations of the SPNEGO protocol. To interoperate with these implementations, this release introduces a new system property: com.ibm.security.spnego.msinterop. This property is set to true by default, which enables Microsoft mode. Set the property to false to disable Microsoft mode.