JDK 15 Security Enhancements

JDK 15 was released on September 15, 2020! As with my previous blogs for JDK 14, JDK 13, and JDK 12, 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 15 Release Notes also contain further details on these and other enhancements.

The most significant security feature of this release is support for the Edwards-curve Digital Signature Algorithm, which offers improved security and performance over other signature algorithms. See the Crypto section for more information.

Crypto
PKI
TLS
Tools

Crypto

Edwards-curve Digital Signature Algorithm (EdDSA)

JDK 15 now supports the EdDSA signature algorithm. This feature is defined in JEP 339. The Ed25519 and Ed448 algorithms are both supported.

EdDSA was designed to be resistant to commonly used side-channel attacks. The platform-independent Java implementation does not branch on secrets and the timing is independent of secrets.

New standard classes and interfaces representing EdDSA keys have been added to the Java SE platform. The SunEC provider has been enhanced to support EdDSA for the Signature, KeyFactory, and KeyPairGenerator APIs.

Here is an example from the JEP of generating an EdDSA key pair and signing some content:
```
KeyPairGenerator kpg = KeyPairGenerator.getInstance("Ed25519");
KeyPair kp = kpg.generateKeyPair();
// algorithm is pure Ed25519
Signature sig = Signature.getInstance("Ed25519");
sig.initSign(kp.getPrivate());
sig.update(msg);
byte[] s = sig.sign();
```
More details on this feature can be found in the JEP and the CSR.
SHA-3 Mac algorithm support

The SHA-3 family of Hmac algorithms are now supported: HmacSHA3-224, HmacSHA3-256, HmacSHA3-384, HmacSHA3-512. SHA-3 is a digest algorithm that is considered as strong as SHA-2. Use the javax.crypto.Mac API to access these algorithms, ex:

Mac mac = Mac.getInstance("HmacSHA3-256");

This enhancement extends the support for SHA-3 in the JDK. In JDK 9, we added support for the SHA-3 hash algorithms. And in JDK 16, we will be adding support for SHA-3 signature algorithms.
The native elliptic curves have been disabled by default

The elliptic curves that are implemented in native C code in the SunEC provider have been disabled by default. These curves are no longer recommended and/or are not implemented using modern formulas and techniques. APIs that try to use one of these curves will throw an Exception with the message “Legacy SunEC curve disabled” and the name of the curve.

To re-enable them (at your own risk), set the jdk.sunec.disableNative system property to false. For example:

$ java -Djdk.sunec.disableNative=false ...

Note however, that if you re-enable them, they are still disabled by default when used in TLS, CertPath, or Signed JARs. See the JDK 14 release note for more information.

The curves that are disabled by this change are:
```
secp112r1, secp112r2, secp128r1, secp128r2, secp160k1, secp160r1,
secp160r2, secp192k1, secp192r1, secp224k1, secp224r1, secp256k1,
sect113r1, sect113r2, sect131r1, sect131r2, sect163k1, sect163r1,
sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1,
sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1,
X9.62 c2tnb191v1, X9.62 c2tnb191v2, X9.62 c2tnb191v3, X9.62 c2tnb239v1,
X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, X9.62 c2tnb431r1,
X9.62 prime192v2, X9.62 prime192v3, X9.62 prime239v1, X9.62 prime239v2,
X9.62 prime239v3, brainpoolP256r1 brainpoolP320r1, brainpoolP384r1,
brainpoolP512r1
```
The following curves are implemented in Java, use modern techniques, and are not affected by this change: secp256r1, secp384r1, secp521r1, x25519, x448, ed25519, and ed448.

PKI

Two root CA certificates have been removed

The following root CAs have expired and are removed from the cacerts keystore in the JDK:
1. AddTrust Class 1 CA Root
  
  This root certificate is owned by Sectigo and has the following distinguished name:
  
  CN=AddTrust Class 1 CA Root, OU=AddTrust TTP Network, O=AddTrust AB, C=SE
2. Keynectis Root CA
  
  This root certificate is owned by DocuSign and has the following distinguished name:
  
  CN=KEYNECTIS ROOT CA, OU=ROOT, O=KEYNECTIS, C=FR
Two other roots owned by Sectigo have also expired, but will remain in the cacerts keystore for now since code signing certificates have been issued that chain back to those roots and may still be in use with timestamped applications:
1. AddTrust Qualified CA Root
  
  This root certificate has the following distinguished name:
  
  CN=AddTrust Qualified CA Root, OU=AddTrust TTP Network, O=AddTrust AB, C=SE
2. AddTrust External CA Root
  
  This root certificate has the following distinguished name:
  
  CN=AddTrust External CA Root, OU=AddTrust External TTP Network, O=AddTrust AB, C=SE

TLS

Support for the Certificate Authorities extension

The JDK TLS 1.3 implementation now supports the “certificate_authorities” extension.

This extension is used by a client or server to indicate what CAs it supports. This can help the receiver determine which certificate to use for authentication.

This extension is always sent by the server if client authentication is requested. By default, this extension is not sent by the client. To enable the extension on the client, set the jdk.tls.client.enableCAExtension system property to true. However, be aware that there are some limits associated with the number of CAs that can be specified in the extension, see the release note for more information.
The SSLSession.getPeerCertificateChain() method has been modified to throw UnsupportedOperationException

SSLSession.getPeerCertificateChain() API is now a default method that throws UnsupportedOperationException by default. This API is deprecated for removal and should no longer be used, as it depends on the deprecated for removal javax.security.cert.X509Certificate type. Throwing an UnsupportedOperationException will help developers identify and remove any remaining usages in their applications.

Applications should use SSLSession.getPeerCertificates() instead.
New system properties for configuring TLS signature schemes

Two new system properties have been introduced that allow you to configure the names of the signature schemes used in the digital signatures of TLS connections. These properties can be useful if you wish to have more control over what signature schemes are enabled or if some signature schemes are not supported by another TLS implementation and are causing TLS handshake failures.
1. jdk.tls.client.SignatureSchemes: supported signature schemes used on the client side.
2. jdk.tls.server.SignatureSchemes: supported signature schemes used on the server side.
Each system property should contain a comma-separated list of supported signature scheme names defined in the Signature Schemes section of the Java Security Standard Algorithm Names Specification. For example:

$ java -Djdk.tls.server.SignatureSchemes=rsa_pkcs1_sha256,rsa_pss_pss_sha256 ...

Tools

The jarsigner tool now has an option to check certificate revocation

A new option named -revCheck has been added to jarsigner. If specified, it will check the revocation status of each certificate in the signer’s certificate chain, and the TSA’s chain if the JAR is timestamped. Here is an example:
```
$ jarsigner -verify -revCheck HelloWorld.jar
Contacting OCSP server at http://s2.symcb.com ...
Contacting OCSP server at http://sv.symcd.com ...
Contacting OCSP server at http://s.symcd.com ...
Contacting OCSP server at http://ts-ocsp.ws.symantec.com ...

jar verified.
```
jarsigner and keytool now emit warnings if you are using weak cryptographic algorithms before they are disabled

These warnings notify you if your security artifacts are using algorithms that are weakening, but not yet disabled by default. This alerts you to potential security risks and also provides you with advance notice so that you can upgrade to stronger algorithms before those weak algorithms are disabled.

In this version, warnings are emitted when SHA-1 or RSA/DSA keys greater than or equal to 1024 but less than 2048 bits are used. Here is an example:
```
$ jarsigner -keystore ks -digestalg SHA-1 HelloWorld.jar signer
Enter Passphrase for keystore:

jar signed.

Warning: 
The SHA-1 algorithm specified for the -digestalg option is considered a security risk. This algorithm will be disabled in a future update.
No -tsa or -tsacert is provided and this jar is not timestamped. Without a timestamp, users may not be able to validate this jar after the signer certificate's expiration date (2021-04-27).

The signer certificate will expire on 2021-04-27.
```
This change will also be backported to Oracle JDK 11, 8, and 7 in the October 2020 CPU Release and is listed on the Java Cryptographic Roadmap.
The com.sun.jarsigner APIs have been deprecated for removal

The ContentSigner and ContentSignerParameters APIs in the com.sun.jarsigner package were previously deprecated in JDK 9, but now they are marked for removal and will be removed in a subsequent version of the JDK.

These APIs were seldom used and there is now an alternate JarSigner API that is much more powerful and should be used instead.

In addition, the jarsigner -altsigner option which depends on these APIs will also be removed in a subsequent JDK release and now emits a warning:
```
$ jarsigner -altsigner path foo.jar
This option is deprecated and will be removed in a future release: -altsigner
```

JDK 15 Security Enhancements

Table of Contents

Crypto

PKI

TLS

Tools