Service refresh 1

Service refresh 1

KeyStore enhancements

The IBM® implementation of Oracle's PKCS12 keystore type (PKCS12S2) is now updated to include support for trusted certificate and secret key entries.

RSA-PSS signature scheme

RSA-PSS is a new signature scheme that is based on the RSA cryptography system and provides enhanced security. PSS refers to the original Probabilistic Signature Scheme that was designed by Bellare and Rogaway.

Like other digital signature schemes, the following processing steps take place:

• The signature scheme hashes the message to be signed by using a hash function.
• The resulting hash is transformed into an encoded message.
• A signature primitive is applied to the encoded message by using the private key to produce the signature.

Unlike other digital signature schemes, the transform operation uses padding that is much more random. During the signature verification process, the following processing steps take place:

• The scheme hashes the message to be signed by using the same hash function that was used to sign the message.
• A verification primitive is then applied to the signature by using the public key of the key pair to recover the message.
• The scheme verifies that the encoded message is a valid transformation of the hash value.

To use this signature scheme, specify the algorithm name "RSAPSS" in the getInstance(algorithm, provider) method of the Signature class.

The PSSParameterSpec class specifies a parameter specification for the RSA-PSS signature scheme. You can set the following parameters:

• The algorithm name of the hash function (default SHA-1).
• The name of the mask generation function (default "MGF1").
• The parameters for the mask generation function (default MGF1ParameterSpec.SHA1).
• The length of salt (default 20).
• The value of the trailer field (default 1).

Note: The default values are the only supported values for the name of the mask generation function and trailer field.

By using one of the constructors for this class, you can construct a PSSParameterSpec class and then specify it as an argument to the set(PSSParameterSpec) method of the Signature class. This action sets the parameters for the RSA-PSS signature scheme. For more information about how to set parameters, see the PSSParameterSpec class documentation.

For more information about RSA-PSS, see RFC 3447.

RC4 cipher suites are disabled by default

To address security vulnerability CVE-2015-2808, RC4 cipher suites are disabled by default and Cipher-Block Chaining (CBC) protection is enabled. For more information, see Bar Mitzvah security vulnerability CVE-2015-2808.

Matching SSLv3 to SSL behavior

To address the POODLE security vulnerability, the SSL V3.0 protocol is disabled by default. If your application hardcodes the protocol label SSLv3, you can use the com.ibm.jsse2.convertSSLv3 property to automatically match the behavior for protocol label SSL without modifying your source code. For more information about this property, see Matching SSLv3 to SSL behavior

Service refresh 1 fix pack 1

This fix pack addresses the logjam security vulnerability, CVE-2015-4000. To address this vulnerability, Diffie-Hellman keys that are less than 768-bits are disabled by default. For more information, see Logjam security vulnerability CVE-2015-4000.

Service refresh 1 fix pack 10

Important changes to maintain FIPS 140-2 compliance

IBMJCEFIPS, Version 1.71, is FIPS certified and includes a fix for the reseeding of HASHDRBG. Two actions are necessary to maintain compliance beyond 2015:

1. All applications must install the updated versions of IBMJCEFIPS and IBM JSSE Provider JAR files (ibmjcefips.jar and ibmjsseprovider2.jar) that are provided in this fix pack.
2. Applications that call IBMSecureRandom must make a small code change to call HASHDRBG instead.

For more information about these changes, see IBM JCE FIPS 140-2 Cryptographic Module Security Policy.

Keystore updates

The following keystore types are updated:

PKCS12

The PKCS12 implementation now supports secret key entries, in addition to previously supported private key entries, and trusted certificate entries.

PKCS12S2

The PKCS12S2 implementation now supports both trusted certificate entries and secret key entries, in addition to previously supported private key entries.

Both implementations automatically update earlier IBM SDK PKCS#12 keystore formats. The update occurs the first time that the keystore is persistently written to a keystore file in the new format. Afterward, the keystore provides the additional storage capabilities that were not previously supported in the older format. Although an updated keystore file can be read by earlier IBM SDK PKCS#12 versions, unsupported keystore entry types are ignored during the keystore load and store processes. Therefore, once the keystore is persistently written to a keystore file in the older format, it contains only entry types that are explicitly supported by the earlier version.

Ephemeral Diffie-Hellman key size changes

There is a change to the key size of a DH key when the jdk.tls.ephemeralDHKeySize property is used with the legacy option. For more information about these changes, see Customizing the size of Ephemeral Diffie-Hellman Keys.

Change to JSSE2 behavior when a minimum DH key size is not set in the java.security file

If the java.security file is not updated with DH keySize < 768 for the jdk.tls.disabledAlgorithms property, IBMJSSE2 applies a minimum default key size of 768 for DH keys. For more information, see Logjam security vulnerability CVE-2015-4000.

New SecureRandom functions

The SHA1PRNG implementation for the IBMJCE and IBMSecureRandom providers is updated to support a customizable source for seed data. By default, an attempt is made to use the entropy gathering device that is specified by the securerandom.source security property in the java.security file. The entropy gathering device can also be specified with the system property java.security.egd. Specifying this system property overrides the securerandom.source security property.

For operating systems like AIX® and Linux®, three new implementations are introduced for the IBMJCE provider. Two of the implementations provide blocking and non-blocking behavior: NativePRNGBlocking and NativePRNGNonBlocking. A NativePRNG implementation is also introduced, which uses the customizable seed source for obtaining seed bytes, and a non-blocking source for obtaining random data. For more information, see Appendix A: Standard Names.

For the z/OS operating system, when configured to acquire entropy from /dev/random and /dev/urandom, special consideration must be given to RACF permissions. The use of /dev/random and /dev/urandom on z/OS places a dependency on ICSF for generating the random data. As a consequence, the RACF CSFSERV Access Permission for CSFRNG (random number generate callable service) must be granted to the exploiter to permit execution of those ICSF services that provide the requested cryptographic support for random number generation.

For more information about IBMSecureRandom, see IBM SecureRandom Provider.