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.
Table of Contents
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
SunECprovider has been enhanced to support EdDSA for the
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-512. SHA-3 is a digest algorithm that is considered as strong as SHA-2. Use the
javax.crypto.MacAPI to access these algorithms, ex:
Mac mac = Mac.getInstance("HmacSHA3-256");
The native elliptic curves have been disabled by default
The elliptic curves that are implemented in native C code in the
SunECprovider 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
Exceptionwith the message “Legacy SunEC curve disabled” and the name of the curve.
To re-enable them (at your own risk), set the
jdk.sunec.disableNativesystem 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:
Two root CA certificates have been removed
The following root CAs have expired and are removed from the
cacertskeystore in the JDK:
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
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
cacertskeystore for now since code signing certificates have been issued that chain back to those roots and may still be in use with timestamped applications:
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
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
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.enableCAExtensionsystem 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.
SSLSession.getPeerCertificateChain()method has been modified to throw
SSLSession.getPeerCertificateChain()API is now a default method that throws
UnsupportedOperationExceptionby 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
UnsupportedOperationExceptionwill help developers identify and remove any remaining usages in their applications.
Applications should use
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.
jdk.tls.client.SignatureSchemes: supported signature schemes used on the client side.
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 ...
jarsignertool now has an option to check certificate revocation
A new option named
-revCheckhas 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.
keytoolnow 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.
com.sun.jarsignerAPIs have been deprecated for removal
ContentSignerParametersAPIs in the
com.sun.jarsignerpackage 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
JarSignerAPI that is much more powerful and should be used instead.
In addition, the
jarsigner -altsigneroption 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