JDK 21 Security Enhancements

JDK 21 was released on September 19, 2023! As with my previous blogs, I have compiled a list of what I think are the most interesting and useful security enhancements in this release. I have also grouped them into appropriate categories (crypto, TLS, etc) which should make it easier to find out what has changed in each specific area. The JDK 21 release notes also contain further details on these and other enhancements.

Highlights of this release include a new API for KEM (Key Encapsulation Mechanism) and a signature verification implementation of HSS/LMS (Leighton-Micali Signature system with the Hierarchical Signature System). Both of these are important initial pieces for providing Java applications with the tools they will need to withstand large-scale quantum computer attacks.

Table of Contents

1. Crypto
2. PKI
3. TLS
4. XML Signature
5. Tools

Crypto

• Key Encapsulation Mechanism API

  A new standard API for Key Encapsulation Mechanism (KEM) has been introduced in this release and is more fully described in JEP 452. A KEM is a modern cryptographic mechanism that uses properties of a public key to securely establish a shared symmetric key between two parties. KEMs are increasing in popularity and will be an important component of new algorithms being developed for Post-Quantum Cryptography (PQC).

  The JDK includes an implementation of KEM for the DHKEM algorithm as defined in RFC 9180.

  The main new class in the API is javax.crypto.KEM. The KEM API description provides an example of using the API:

  ---

  // Receiver side
  var kpg = KeyPairGenerator.getInstance("X25519");
  var kp = kpg.generateKeyPair();
  
  // Sender side
  var kem1 = KEM.getInstance("DHKEM");
  var sender = kem1.newEncapsulator(kp.getPublic());
  var encapsulated = sender.encapsulate();
  var k1 = encapsulated.key();
  
  // Receiver side
  var kem2 = KEM.getInstance("DHKEM");
  var receiver = kem2.newDecapsulator(kp.getPrivate());
  var k2 = receiver.decapsulate(encapsulated.encapsulation());
  
  assert Arrays.equals(k1.getEncoded(), k2.getEncoded());
  

  ---

  JEP: JEP 452

• Leighton-Micali Signature (HSS/LMS) verification

  The SUN provider now supports signature verification for the Leighton-Micali Signature (LMS) system with its multi-tree variant, the Hierarchical Signature System (HSS).

  Defined in RFC 8554, HSS/LMS is a stateful hash-based signature system and is one of the signature algorithms that NIST recommends for providing protection against quantum attacks. It is believed that this algorithm will not be broken by large-scale quantum computers.

  New standard algorithms named “HSS/LMS” have been defined for KeyFactory and Signature. The “HSS/LMS” KeyFactory and Signature implementations only support public keys and signature verification. This is because the NIST recommendation requires that the key and signature generation be done on hardware. If you try to generate a signature, the initSign method of Signature will throw an InvalidKeyException. If you try to generate a private key, the generatePrivate method of KeyFactory will throw an InvalidKeySpecException.

  Issue: JDK-8298127

• Support for PKCS#11 PBES2 password-based cryptography algorithms

  The SunPKCS11 provider now supports PBES2 password-based cryptography algorithms for Cipher, Mac, and SecretKeyFactory. These algorithms use the PKCS#11 standard mechanisms for password-based cryptography. With this enhancement, it is now possible to use the SunPKCS11 provider for integrity and privacy protection with a PKCS12 KeyStore. The list of new algorithms for each service are:

  • Cipher
    • PBEWithHmacSHA1AndAES_128
    • PBEWithHmacSHA224AndAES_128
    • PBEWithHmacSHA256AndAES_128
    • PBEWithHmacSHA384AndAES_128
    • PBEWithHmacSHA512AndAES_128
    • PBEWithHmacSHA1AndAES_256
    • PBEWithHmacSHA224AndAES_256
    • PBEWithHmacSHA256AndAES_256
    • PBEWithHmacSHA384AndAES_256
    • PBEWithHmacSHA512AndAES_256
  • Mac
    • HmacPBESHA1
  • SecretKeyFactory
    • PBEWithHmacSHA1AndAES_128
    • PBEWithHmacSHA224AndAES_128
    • PBEWithHmacSHA256AndAES_128
    • PBEWithHmacSHA384AndAES_128
    • PBEWithHmacSHA512AndAES_128
    • PBEWithHmacSHA1AndAES_256
    • PBEWithHmacSHA224AndAES_256
    • PBEWithHmacSHA256AndAES_256
    • PBEWithHmacSHA384AndAES_256
    • PBEWithHmacSHA512AndAES_256
    • PBKDF2WithHmacSHA1
    • PBKDF2WithHmacSHA224
    • PBKDF2WithHmacSHA256
    • PBKDF2WithHmacSHA384
    • PBKDF2WithHmacSHA512
    • HmacPBESHA1

  Support for several additional PBES2 algorithms have also been added which do not yet have PKCS#11 standard mechanisms defined:

  • Mac
    • HmacPBESHA224
    • HmacPBESHA256
    • HmacPBESHA384
    • HmacPBESHA512
  • SecretKeyFactory
    • HmacPBESHA224
    • HmacPBESHA256
    • HmacPBESHA384
    • HmacPBESHA512

  Issue: JDK-8301553

• Support for PBES2 Cipher and Mac algorithms with SHA-512/224 and SHA-512/256 digests

  The SunJCE provider now supports PBES2 AlgorithmParameters, Cipher, Mac, and SecretKeyFactory algorithms with SHA-512/224 and SHA-512/256 digests. The list of new algorithms for each service are:

  • AlgorithmParameters
    • PBEWithHmacSHA512/224AndAES_128
    • PBEWithHmacSHA512/256AndAES_128
    • PBEWithHmacSHA512/224AndAES_256
    • PBEWithHmacSHA512/256AndAES_256
  • Cipher
    • PBEWithHmacSHA512/224AndAES_128
    • PBEWithHmacSHA512/256AndAES_128
    • PBEWithHmacSHA512/224AndAES_256
    • PBEWithHmacSHA512/256AndAES_256
  • Mac
    • PBEWithHmacSHA512/224
    • PBEWithHmacSHA512/256
  • SecretKeyFactory
    • PBEWithHmacSHA512/224AndAES_128
    • PBEWithHmacSHA512/256AndAES_128
    • PBEWithHmacSHA512/224AndAES_256
    • PBEWithHmacSHA512/256AndAES_256
    • PBKDF2WithHmacSHA512/224
    • PBKDF2WithHmacSHA512/256

  Issue: JDK-8288050

PKI

• Enhanced OCSP, certificate, and CRL fetch timeouts

  Several new system properties have been introduced that allow you to control the connect and read timeouts for network connections related to certificate and CRL fetching, and OCSP:

  • com.sun.security.cert.timeout: for controlling connection timeouts when fetching certs from locations in an AuthorityInformationAccess extension of an X.509 certificate.

  • com.sun.security.cert.readtimeout: for controlling read timeouts when fetching certs from locations in an AuthorityInformationAccess extension of an X.509 certificate.

  • com.sun.security.ocsp.readtimeout: for controlling read timeouts when using OCSP to check the revocation status of an X.509 certificate.

  These new properties have a flexible syntax that allow timeout values to be specified in seconds or milliseconds. In addition, the existing com.sun.security.ocsp.timeout, com.sun.security.crl.timeout and com.sun.security.crl.readtimeout properties have been enhanced to use this syntax (previously they only supported seconds). The syntax allows timeouts in milliseconds to be specified as a decimal integer ending in ms, and in seconds as a decimal integer or a decimal integer ending in s.

  Here is an example of setting the com.sun.security.cert.timeout property to 100 milliseconds:

  java -Dcom.sun.security.cert.timeout=100ms ...

  Here is another example of setting the com.sun.security.cert.timeout property to 2 seconds:

  java -Dcom.sun.security.cert.timeout=2s ...

  Issue: JDK-8179502

• New root CA certificates

  Several new root CA certificates have been added to the cacerts keystore:

  • Four Google Trust Services (GTS) root CA certificates

    • GTS Root R1 has the following distinguished name:

      CN=GTS Root R1, O=Google Trust Services LLC, C=US

    • GTS Root R2 has the following distinguished name:

      CN=GTS Root R2, O=Google Trust Services LLC, C=US

    • GTS Root R3 has the following distinguished name:

      CN=GTS Root R3, O=Google Trust Services LLC, C=US

    • GTS Root R4 has the following distinguished name:

      CN=GTS Root R4, O=Google Trust Services LLC, C=US

    These root certificates have also been added to the cacerts keystore in Oracle’s JDK 20.0.2, 17.0.8, 11.0.20, 8u381, and 7u391 releases.

    Issue: JDK-8307134

  • TWCA Global Root CA has the following distinguished name:

    CN=TWCA Global Root CA, OU=Root CA, O=TAIWAN-CA, C=TW

    This root certificate has also been added to the cacerts keystore in Oracle’s JDK 20.0.2, 17.0.8, 11.0.20, 8u381, and 7u391 releases.

    Issue: JDK-8305975

  • Two Microsoft root CA certificates

    • Microsoft ECC Root CA 2017 has the following distinguished name:

      CN=Microsoft ECC Root Certificate Authority 2017, O=Microsoft Corporation, C=US

    • Microsoft RSA Root CA 2017 has the following distinguished name:

      CN=Microsoft RSA Root Certificate Authority 2017, O=Microsoft Corporation, C=US

    These root certificates have also been added to the cacerts keystore in Oracle’s JDK 20.0.2, 17.0.8, 11.0.20, 8u381, and 7u391 releases.

    Issue: JDK-8304760

  • Certigna Root CA has the following distinguished name:

    CN=Certigna, O=Dhimyotis, C=FR

    This root certificate has also been added to the cacerts keystore in Oracle’s JDK 20.0.1, 17.0.7, 11.0.19, 8u371, and 7u381 releases.

    Issue: JDK-8245654

TLS

• The default Diffie-Hellman group size has been increased from 1024 bits to 2048 bits

  The JDK implementations of TLS 1.0, 1.1, and 1.2 now use a default Diffie Hellman keysize of 2048 bits when a TLS_DHE cipher suite is negotiated and either the client or server do not support FFDHE, which can be used to negotiate a stronger keysize. The JDK TLS implementation supports FFDHE and it is enabled by default; however the peer that the JDK is negotiating a TLS session with may not support it.

  As a workaround, users can revert to the previous size by setting the jdk.tls.ephemeralDHKeySize system property to 1024, but this is not recommended and should be done at your own risk. Also, while this change also applies to TLS 1.0 and 1.1, those protocols are no longer recommended and are disabled by default.

  This change does not affect TLS 1.3 as the minimum DH group size is already 2048 bits.

  This change is also listed on the Java Cryptographic Roadmap and is targeted for Oracle’s October 2023 JDK releases for 21u, 17u, 11u, and 8u.

  Issue: JDK-8301700

XML Signature

• Support for the EdDSA signature algorithm

  The JDK XML Signature implementation now supports the Edwards-Curve Digital Signature Algorithm (EdDSA), which means that XML Signatures can now be signed or verified with the EdDSA algorithm.

  Two new standard SignatureMethod URIs have also been added:

  • SignatureMethod.ED25519: URI representing the Edwards-Curve signature algorithm with Ed25519.
  • SignatureMethod.ED448: URI representing the Edwards-Curve signature algorithm with Ed448.

  Issue: JDK-8305972

• New system property to toggle XML Signature secure validation mode

  A new system property named org.jcp.xml.dsig.secureValidation has been added that allows you to more easily enable or disable the XML Signature secure processing mode. The property should be set to “true” to enable or “false” to disable.

  Note that the secure processing mode is enabled by default, and provides additional security by restricting weak algorithms and other potentially unsafe constructs in XML signatures. See the jdk.xml.dsig.secureValidationPolicy security property in the java.security file for more details.

  There may be circumstances where you may need to disable the secure processing mode (for example, to verify a legacy signature that uses a weak algorithm), but in general disabling the secure processing mode is not recommended and should be done at your own risk.

  Issue: JDK-8301260

• New security property to enable or disable support for the here() function

  The here() function is an XPath function defined by the W3C Recommendation for XML Signature that can be used to help select node-sets for use in XPath transforms. However, the here() function is not a standard XPath function and is not supported by the standard Java XPath API, and supporting it requires an implementation-specific dependency on Xalan internal APIs. We intend to eventually disable support for this function by default.

  With this release, we have added a new security property named jdk.xml.dsig.hereFunctionSupported and set its default value to true (which means the here() function is still supported by default). We encourage users to set this property to false and test their applications to see if anything breaks.

  Issue: JDK-8305972

Tools

• keytool now warns if weak PBE algorithms are used

  The keytool utility now emits warnings if weak password-based encryption (PBE) algorithms are specified with the -genseckey or -importpass options.

  Here is an example showing this warning when using keytool -genseckey with a weak PBE algorithm (in this case, “PBEwithMD5andDES”):

  ---

  $ keytool -genseckey -keystore ks -keyalg PBEwithMD5andDES
  Enter keystore password:  
  Enter the password to be stored:  
  Re-enter password: 
  
  Warning:
  The generated secret key uses the PBEwithMD5andDES algorithm which is considered a security risk.
  

  ---

  Issue: JDK-8286907

• The jarsigner -altsigner and -altsignerpath options are removed

  The -altsigner and -altsignerpath options have been removed from the jarsigner utility. The com.sun.jarsigner.ContentSigner and com.sun.jarsigner.ContentSignerParameters APIs, which these options depended on, have also been removed. These APIs were originally deprecated in JDK 9 and marked for removal in JDK 15. There is an alternate JarSigner API that is much more powerful and should be used instead.

  Running jarsigner with one of these options (ex: -altsigner) now produces the following error:

  ---

  $ jarsigner -altsigner
  Illegal option: -altsigner
  
  Please type jarsigner --help for usage
  

  ---

  Issue: JDK-8303410