Service refresh 1
Read about the changes in service refresh 1, and subsequent fix packs.
Skip to Service refresh 1 fix pack 1
Skip to Service refresh 1 fix pack 10
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.
- 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
toSSL
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 labelSSL
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:
- 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.
- Applications that call IBMSecureRandom must make a small code change to call HASHDRBG instead.
- 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.
- 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
andNativePRNGNonBlocking
. ANativePRNG
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.