JDK 16 Security Enhancements

JDK 16 was released on March 16, 2021! 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 16 release notes also contain further details on these and other enhancements.

Also, one other feature in JDK 16 that is not specifically in the security libraries area but worth mentioning is JEP 396, Strongly Encapsulate JDK Internals by Default. With this change, “packages that existed in JDK 8 and do not contain critical internal APIs will no longer be open by default” meaning they cannot be accessed by code outside the JDK. This is a great improvement in out of the box security.

Crypto
PKI
TLS
Signed JARs

Crypto

SHA-3 signature algorithm support

The SHA-3 family of Signature algorithms are now supported for RSA, EC, and DSA keys. The algorithms for each key type are:
- RSA: SHA3-224withRSA, SHA3-256withRSA, SHA3-384withRSA, SHA3-512withRSA
- EC: SHA3-224withECDSA, SHA3-256withECDSA, SHA3-384withECDSA, SHA3-512withECDSA
- DSA: SHA3-224withDSA, SHA3-256withDSA, SHA3-384withDSA, SHA3-512withDSA, SHA384withDSA, SHA512withDSA
The EC and DSA algorithms also include algorithms using the P1363 format, by appending inP1363Format to the name.

SHA-3 is a digest algorithm that is considered as strong as SHA-2. Use the java.security.Signature API to access these algorithms, ex:

Signature sig = Signature.getInstance("SHA3-256withRSA");

This enhancement extends the support for SHA-3 in the JDK. In JDK 9, we added support for the SHA-3 hash algorithms. In JDK 15, we added support for the SHA-3 hmac algorithms.
The SunPKCS11 provider now supports SHA-3 algorithms

The SunPKCS11 provider has also been updated to support SHA-3 algorithms, so if you use a PKCS11 implementation, you can now access these algorithms from your Java application.

The complete list of algorithms is as follows:
- MessageDigest: SHA3-224, SHA3-256, SHA3-384, SHA3-512
- Mac: HmacSHA3-224, HmacSHA3-256, HmacSHA3-384, HmacSHA3-512
- Signature: SHA3-224withDSA, SHA3-256withDSA, SHA3-384withDSA, SHA3-512withDSA, SHA3-224withDSAinP1363Format, SHA3-256withDSAinP1363Format, SHA3-384withDSAinP1363Format, SHA3-512withDSAinP1363Format, SHA3-224withECDSA, SHA3-256withECDSA, SHA3-384withECDSA, SHA3-512withECDSA, SHA3-224withECDSAinP1363Format, SHA3-256withECDSAinP1363Format, SHA3-384withECDSAinP1363Format, SHA3-512withECDSAinP1363Format, SHA3-224withRSA, SHA3-256withRSA, SHA3-384withRSA, SHA3-512withRSA, SHA3-224withRSASSA-PSS, SHA3-256withRSASSA-PSS, SHA3-384withRSASSA-PSS, SHA3-512withRSASSA-PSS.
- KeyGenerator: HmacMD5, HmacSHA1, HmacSHA224, HmacSHA256, HmacSHA384, HmacSHA512, HmacSHA512/224, HmacSHA512/256, HmacSHA3-224, HmacSHA3-256, HmacSHA3-384, HmacSHA3-512.
The default PKCS12 algorithms have been strengthened

The default algorithms used to encrypt certificates and keys and protect the integrity of a PKCS12 keystore have been upgraded to stronger algorithms.

The following security properties in the java.security configuration file are now set to stronger algorithms based on PBES2 which use SHA256 and AES-256:
```
keystore.pkcs12.certProtectionAlgorithm = PBEWithHmacSHA256AndAES_256
keystore.pkcs12.keyProtectionAlgorithm = PBEWithHmacSHA256AndAES_256
keystore.pkcs12.macAlgorithm = HmacPBESHA256
```
If you experience interoperability problems with an existing PKCS12 keystore that has been protected using the previous algorithm defaults, you can set the system property keystore.pkcs12.legacy to load this keystore and read its contents using the older algorithms.

This change is also targeted to be backported to Oracle’s JDK 11, 8 and 7 releases in July 2021 and is listed on the Oracle JRE and JDK Cryptographic Roadmap (see the row with the Action named “Upgrade the default PKCS12 encryption/MAC algorithms”).

The native elliptic curve implementations have been removed

The elliptic curves that were implemented in native C code in the SunEC provider have been removed. These curves are no longer recommended and/or were not implemented using modern formulas and techniques.

The curves that are removed 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

Several java.security.cert APIs that represent X.500 distinguished names as String or Principal objects have been deprecated

Representing distinguished names as String or Principal objects can cause issues due to differences in encoding or loss of information. Each of these APIs have alternative methods that represent distinguished names as X500Principal and/or byte[]. The deprecated APIs are:
Root CA certificates with 1024-bit keys have been removed

Five root certificates with 1024-bit RSA public keys have been removed from the cacerts keystore. Keys of this size are weak and are no longer recommended. The five roots are:
1. Thawte Premium Server CA
  
  This root certificate is owned by DigiCert and has the following distinguished name:
  
  EMAILADDRESS=premium-server@thawte.com, CN=Thawte Premium Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA
2. VeriSign Class 2 Public Primary Certification Authority - G2
  
  This root certificate is owned by DigiCert and has the following distinguished name:
  
  OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 2 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US
3. VeriSign Class 3 Public Primary Certification Authority
  
  This root certificate is owned by DigiCert and has the following distinguished name:
  
  OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US
4. VeriSign Class 3 Public Primary Certification Authority - G2
  
  This root certificate is owned by DigiCert and has the following distinguished name:
  
  OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 3 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US
5. Thawte Timestamping CA
  
  This root certificate is owned by DigiCert and has the following distinguished name:
  
  CN=Thawte Timestamping CA, OU=Thawte Certification, O=Thawte, L=Durbanville, ST=Western Cape, C=ZA
This change is also targeted to be backported to Oracle’s JDK 11, 8 and 7 releases in July 2021 and is listed on the Oracle JRE and JDK Cryptographic Roadmap (see the row with the Action named “Remove root certificates with 1024-bit keys”).

The compatibility risk associated with this change is considered to be low. However, if users encounter issues, they can download the certificates from the links above and import them into the cacerts keystore, at their own risk.
New Entrust Root CA certificate added

The “Entrust Root Certification Authority - G4” certificate has been added to the cacerts keystore.

This root certificate is owned by Entrust and has the following distinguished name:

CN=Entrust Root Certification Authority - G4, OU="(c) 2015 Entrust, Inc. - for authorized use only", OU=See www.entrust.net/legal-terms, O="Entrust, Inc.", C=US

This root certificate has also been added to the cacerts keystore in Oracle’s JDK 11.0.9, 8u271, and 7u281 releases.
New SSL Root CA certificates added

Three new root CA certificates from SSL.com have been added to the ‘cacerts` keystore:
1. SSL.com Root Certification Authority RSA
  
  This root certificate has the following distinguished name:
  
  CN=SSL.com Root Certification Authority RSA, O=SSL Corporation, L=Houston, ST=Texas, C=US
2. SSL.com EV Root Certification Authority RSA R2
  
  This root certificate has the following distinguished name:
  
  CN=SSL.com EV Root Certification Authority RSA R2, O=SSL Corporation, L=Houston, ST=Texas, C=US
3. SSL.com Root Certification Authority ECC
  
  This root certificate has the following distinguished name:
  
  CN=SSL.com Root Certification Authority ECC, O=SSL Corporation, L=Houston, ST=Texas, C=US
These root certificates have also been added to the cacerts keystore in Oracle’s JDK 11.0.9, 8u271, and 7u281 releases.

TLS

TLS support for the EdDSA signature algorithm

Support for the EdDSA signature algorithm has been added to the TLS implementation in the JDK.

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. JCE support for EdDSA was added in JDK 15 and specified in JEP 339.

The support applies to TLS versions 1.0 - 1.3 and is specified in RFC 8422 for TLS 1.0 - 1.2 and RFC 8446 for TLS 1.3.

In particular, certificates with EdDSA keys or signed with the EdDSA signature algorithm are now supported and can be used to authenticate clients or servers.

The following signature schemes are also now supported: ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, and ecdsa_secp521r1_sha512.
TLS 1.0 and 1.1 are now disabled by default

The TLS 1.0 and 1.1 protocols have been disabled by default, improving out of the box security. These protocols have various weaknesses and are no longer recommended. See RFC 8996 for more information.

Applications should be using the more secure TLS 1.2 or 1.3 protocols, both of which are supported by the JDK. However, if you encounter issues and need to get your application working, you can (at your own risk), re-enable TLS 1.0 or 1.1 by removing “TLSv1” and/or “TLSv1.1” from the jdk.tls.disabledAlgorithms security property in the java.security configuration file.

This change is also targeted to be backported to Oracle’s JDK 11, 8 and 7 releases in April 2021 and is listed on the Oracle JRE and JDK Cryptographic Roadmap (see the row with the Action named “Disable TLS 1.0 and TLS 1.1”).

Signed JARs

Signed JAR support for RSASSA-PSS and EdDSA

JARs can now be signed with the RSASSA-PSS and EdDSA signature algorithms. Support for these algorithms has been added to the jarsigner tool and the JarSigner API.

The -sigalg option of jarsigner now accepts "RSASSA-PSS”, "EdDSA", "Ed25519", and "Ed448" as values for the signature algorithm.

Here is an example of signing a JAR with the Ed25519 algorithm:

jarsigner -keystore keystore -sigalg Ed25519 -verbose App.jar edkey
Enter Passphrase for keystore: 
   adding: META-INF/MANIFEST.MF
   adding: META-INF/EDKEY.SF
   adding: META-INF/EDKEY.EC
  signing: App.class

>>> Signer
    X.509, CN=edkey
    Signature algorithm: Ed25519, 255-bit key
    [trusted certificate]
    
jar signed.
    
Warning: 
The signer's certificate is self-signed.

JDK 16 Security Enhancements

Table of Contents

Crypto

PKI

TLS

Signed JARs