Sean Mullan's Blog

JDK 26 Security Enhancements

2026-03-17T00:00:00+00:00

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

Highlights of this release include a final version of the PEM API, API support for Hybrid Public Key Encryption, and Signed JAR support for the post-quantum ML-DSA algorithm.

Crypto
PKI
TLS
XML Signature
Tools

Crypto

Hybrid Public Key Encryption

We have added support for Hybrid Public Key Encryption, or HPKE. HPKE is a modern encryption scheme for encrypting arbitrary-sized plaintexts with a recipient’s public key. HPKE is defined in RFC 9180. It combines 3 different algorithms, a KEM, KDF, and an AEAD (authenticated encryption with associated data) algorithm to produce a ciphertext.

To use HPKE in your applications, you use the existing Cipher API with a new HPKEParameterSpec class which specifies the KEM, KDF, and AEAD algorithms you want to use.

Initially in JDK 26, we only support traditional, non-PQC algorithms. However, we plan to add support for PQC algorithms in a later JDK release once the Internet draft on Post-Quantum and Post-Quantum/Traditional Hybrid Algorithms for HPKE becomes an RFC.

This example from the HPKEParameterSpec javadoc shows a sender and a recipient using HPKE to securely exchange messages with an X25519 key pair:

    // Recipient key pair generation
    KeyPairGenerator g = KeyPairGenerator.getInstance("X25519");
    KeyPair kp = g.generateKeyPair();

    // The HPKE sender cipher is initialized with the recipient's public
    // key and an HPKEParameterSpec using specified algorithm identifiers
    // and application-supplied info.
    Cipher senderCipher = Cipher.getInstance("HPKE");
    HPKEParameterSpec ps = HPKEParameterSpec.of(
                    HPKEParameterSpec.KEM_DHKEM_X25519_HKDF_SHA256,
                    HPKEParameterSpec.KDF_HKDF_SHA256,
                    HPKEParameterSpec.AEAD_AES_128_GCM)
            .withInfo(HexFormat.of().parseHex("010203040506"));
    senderCipher.init(Cipher.ENCRYPT_MODE, kp.getPublic(), ps);

    // Retrieve the key encapsulation message (from the KEM step) from
    // the sender.
    byte[] kemEncap = senderCipher.getIV();

    // The HPKE recipient cipher is initialized with its own private key,
    // an HPKEParameterSpec using the same algorithm identifiers as used by
    // the sender, and the key encapsulation message from the sender.
    Cipher recipientCipher = Cipher.getInstance("HPKE");
    HPKEParameterSpec pr = HPKEParameterSpec.of(
                    HPKEParameterSpec.KEM_DHKEM_X25519_HKDF_SHA256,
                    HPKEParameterSpec.KDF_HKDF_SHA256,
                    HPKEParameterSpec.AEAD_AES_128_GCM)
            .withInfo(HexFormat.of().parseHex("010203040506"))
            .withEncapsulation(kemEncap);
    recipientCipher.init(Cipher.DECRYPT_MODE, kp.getPrivate(), pr);

    // Encryption and decryption
    byte[] msg = "Hello World".getBytes(StandardCharsets.UTF_8);
    byte[] ct = senderCipher.doFinal(msg);
    byte[] pt = recipientCipher.doFinal(ct);

    assert Arrays.equals(msg, pt);

Issue: JDK-8325448

PKCS#12 KeyStore support for RFC 9879: Use of Password-Based Message Authentication Code 1 (PBMAC1)

The JDK PKCS12 KeyStore implementation now supports the more modern PBMAC1 algorithm for integrity protection. To use the PBMAC1 algorithm, set the keystore.pkcs12.macAlgorithm property in the java.security configuration file to a PBMAC1 algorithm, for example, “PBEWithHmacSHA256”. Existing PKCS12 keystore files will continue to use the integrity algorithm it was created with, but new keystore files will use the PBMAC1 algorithm.

In a future JDK release, the default value of the keystore.pkcs12.macAlgorithm security property will be changed to a PBMAC1 algorithm.

Issue: JDK-8343232
JEP 524: PEM Encodings of Cryptographic Objects (Second Preview)

The second preview API for encoding and decoding cryptographic objects to/from the PEM format was delivered and defined in JEP 524. PEM is a widely used format for transferring and storing DER-encoded cryptographic data such as certificates, CRLs, private keys, and more. This was one of the most commonly requested features in a JCE survey a few years ago. The History section of the JEP contains a list of changes since the first preview.

There are two primary APIs, a PEMEncoder class for encoding cryptographic objects to PEM, and a PEMDecoder class for decoding PEM data into cryptographic objects. Also new is a marker interface named DEREncodable, and existing classes such as X509Certificate and X509CRL have been retrofitted to implement this interface, thereby making it easier to encode/decode these objects to/from PEM.

PEMEncoder can also be configured for encryption which makes it easier to encrypt and encode private keys in one step. Similarly, PEMDecoder can be configured for decryption to allow private keys to be decoded and decrypted in one step. For more advanced usage, the existing EncryptedPrivateKeyInfo class has been enhanced with several new methods that make it easier to encrypt and decrypt private keys.

Here is an example of encoding an X509Certificate retrieved from a KeyStore to PEM:
```
    X509Certificate cert = (X509Certificate)keystore.getCertificate("mycert");
    PEMEncoder encoder = PEMEncoder.of();
    String pem = encoder.encodeToString(cert);
```
Here is an example of decoding the PEM back into an X509Certificate:
```
    PEMDecoder decoder = PEMDecoder.of();
    X509Certificate cert = decoder.decode(pem, X509Certificate.class);
```
Here are two examples of encrypting a PrivateKey with a password and then encoding it into PEM. The first example configures PEMEncoder for encryption and encrypts and encodes the private key directly in one method call:
```
    PEMEncoder encoder = PEMEncoder.of();
    String pem = encoder.withEncryption(password).encodeToString(privateKey);
```
The above example uses default parameters when encrypting. This second example uses the EncryptedPrivateKeyInfo class to encrypt the private key with additional parameters such as the password-based encryption algorithm, and then encodes it to PEM:
```
    EncryptedPrivateKeyInfo epki =
        EncryptedPrivateKeyInfo.encrypt(privateKey, password,
            "PBEWithHmacSHA256AndAES_256", null, null);
    PEMEncoder encoder = PEMEncoder.of();
    String pem = encoder.encodeToString(epki);
```
New Security Property to Disable Algorithms at the JCE Layer

A new security property named jdk.crypto.disabledAlgorithms has been added which can be used to disable cryptographic algorithms at the JCE/JCA API level. This property takes a list of algorithm names as specified in the Standard Algorithm Names specification. The security property can be overridden by a system property of the same name.

Initially the property is empty and contains no algorithms.

This is a very useful property which allows you to detect usage of cryptographic algorithms at a comprehensive level across all code in your application.

For more details on the syntax of the algorithm and the JCE services that are supported, see the definition in the java.security configuration file.

Issue: JDK-8244336
Various Performance Improvements

A number of performance improvements in the AES, ML-DSA and Elliptic Curve (P256) algorithms were made. See the following issues for more details:

Issues: 8371820, 8371450, 8371259, 8365581
Removed Obsolete Algorithms from Implementation Requirements

The DESede (3DES) algorithms and Cipher algorithms using PKCS1Padding have been removed from the implementation requirements of Java SE. These algorithms are no longer recommended and should not be requirements. The complete list of requirements removed is:
```
AlgorithmParameters:
    DESede
Cipher:
    DESede/CBC/NoPadding
    DESede/CBC/PKCS5Padding
    DESede/ECB/NoPadding
    DESede/ECB/PKCS5Padding
    RSA/ECB/PKCS1Padding
KeyGenerator:
    DESede
SecretKeyFactory:
    DESede 
```
Issue: JDK-8361964

Added PBES2 Algorithms as New Implementation Requirements

The following PBES2 algorithms from RFC 8018: PKCS #5: Password-Based Cryptography Specification Version 2.1 have been added as new requirements:

AlgorithmParameters:
    PBEWithHmacSHA256AndAES_128
    PBEWithHmacSHA256AndAES_256
Cipher:
    PBEWithHmacSHA256AndAES_128
    PBEWithHmacSHA256AndAES_256
Mac:
    PBEWithHmacSHA256
SecretKeyFactory:
    PBEWithHmacSHA256AndAES_128
    PBEWithHmacSHA256AndAES_256
    PBKDF2WithHmacSHA256 

Issue: JDK-8361964

PKI

New Root CA Certificates

Several new root CA certificates have been added to the cacerts keystore:
- Four Sectigo root CA certificates, two for TLS, and two for code signing:
  - Sectigo Public Server Authentication Root E46 with the following distinguished name:
    CN=Sectigo Public Server Authentication Root E46, O=Sectigo Limited, C=GB
  - Sectigo Public Server Authentication Root R46 with the following distinguished name:
    CN=Sectigo Public Server Authentication Root R46, O=Sectigo Limited, C=GB
  - Sectigo Public Code Signing Root E46 with the following distinguished name:
    CN=Sectigo Public Code Signing Root E46, O=Sectigo Limited, C=GB
  - Sectigo Public Code Signing Root R46 with the following distinguished name:
    CN=Sectigo Public Code Signing Root R46, O=Sectigo Limited, C=GB
  These root certificates have also been added to the cacerts keystore in Oracle’s JDK 25, 24.0.2, 21.0.8, 17.0.16, 11.0.27, and 8u461 releases.
  
  Issue: JDK-8359170
Removed Root CA Certificates

Four AffirmTrust root certificates have been removed from the cacerts keystore. These root CAs were deactivated by Entrust (who owns them) and will no longer be supported. The four roots are:
- AffirmTrust Commercial with the following distinguished name:
  CN=AffirmTrust Commercial, O=AffirmTrust, C=US
- AffirmTrust Networking with the following distinguished name:
  CN=AffirmTrust Networking, O=AffirmTrust, C=US
- AffirmTrust Premium with the following distinguished name:
  CN=AffirmTrust Premium, O=AffirmTrust, C=US
- AffirmTrust Premium ECC with the following distinguished name:
  CN=AffirmTrust Premium ECC, O=AffirmTrust, C=US
These root certificates have also been removed from the cacerts keystore in Oracle’s JDK 25.0.1, 21.0.9, 17.0.17, 11.0.29, and 8u471 releases.

Issue: JDK-8361212

TLS

Improved Checking in SunX509 KeyManagerFactory

The default SunX509 KeyManagerFactory, which is used to provide certificates and key material for TLS connections, has been improved. It now implements additional checks on certificates to ensure the ones that are selected are compliant with current algorithm constraints settings. This makes its checking consistent with the PKIX KeyManagerFactory.

Specifically, selection is based on the following rules:
1. Local certificates are checked against peer supported certificate signature algorithms sent with the TLS signature_algorithms_cert extension.
2. Local certificates are checked against TLS algorithm constraints specified in the jdk.tls.disabledAlgorithms and jdk.certpath.disabledAlgorithms security properties.
3. Local certificates are prioritized based on validity period and certificate extensions.
The prior behavior can be re-enabled by setting the system property jdk.tls.SunX509KeyManager.certChecking to false.

Issue: JDK-8359956

XML Signature

Disabled the XPath Filtering Transform

XML Signatures that use the XPath Filtering Transform have been disabled by default. The XPath transform, while powerful, has a higher risk of introducing complexities and is not recommended in the XML Signature Best Practices document. If necessary, and at your own risk, the transform can be re-enabled by removing it from the jdk.xml.dsig.secureValidationPolicy security property.

Alternatively, users should consider replacing their usages with the XPath Filter 2 Transform, which was designed to address the issues associated with the XPath Filtering Transform.

Issue: JDK-8314180
New Property to Specify SecureRandom

A new XML Signature property named jdk.xmldsig.SecureRandom has been added which allows you to specify a specific SecureRandom instance to use instead of the default SecureRandom that the JDK implementation uses.

This can be useful if you want more control over the secure random numbers used in the generation of XML Signatures.

To use this property, you call the setProperty method of the XMLSignContext class with the property name and the instance of the SecureRandom object you would like to use.

Issue: JDK-8359395

Tools

Signed JAR Support for ML-DSA

In JDK 21, we added support ML-DSA, which is a quantum-resistant digital signature algorithm specified by NIST in FIPS 204 and defined in JEP 497 for the Java Platform.

In this release, we have extended that support and added support for signing JARs with ML-DSA. This can be done using the jarsigner utility or the JarSigner API.

Here is an example of using ML-DSA to sign a JAR with jarsigner:
```
    $ jarsigner -keystore ks –sigalg ML-DSA-65 -signedjar signed.jar
      test.jar mldsa
```
Issue: JDK-8349732

java -XshowSettings:security:tls Now Shows TLS Named Groups and Signature Schemes

The java -XshowSettings:security:tls diagnostic command now shows the TLS named groups (or key exchange algorithms) and signature schemes that are enabled for TLS handshakes, in addition to the enabled protocols and cipher suites.

Here is a sample run showing the new output:

    $ java -XshowSettings:security:tls
    Security TLS configuration (SunJSSE provider):
        Enabled Protocols:
            TLSv1.3
            TLSv1.2
   
        Enabled Cipher Suites:
            TLS_AES_256_GCM_SHA384
            TLS_AES_128_GCM_SHA256
            TLS_CHACHA20_POLY1305_SHA256
            TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
            TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
            TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
            TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
            TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
            TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
            TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
            TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
            TLS_DHE_DSS_WITH_AES_256_GCM_SHA384
            TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
            TLS_DHE_DSS_WITH_AES_128_GCM_SHA256
            TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
            TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
            TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
            TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
            TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
            TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
            TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
            TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
            TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
            TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
            TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
            TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
            TLS_DHE_RSA_WITH_AES_256_CBC_SHA
            TLS_DHE_DSS_WITH_AES_256_CBC_SHA
            TLS_DHE_RSA_WITH_AES_128_CBC_SHA
            TLS_DHE_DSS_WITH_AES_128_CBC_SHA
            TLS_EMPTY_RENEGOTIATION_INFO_SCSV

        Enabled Named Groups:
            X25519MLKEM768
            x25519
            secp256r1
            secp384r1
            secp521r1
            x448
            ffdhe2048
            ffdhe3072
            ffdhe4096
            ffdhe6144
            ffdhe8192

        Enabled Signature Schemes:
            ecdsa_secp256r1_sha256
            ecdsa_secp384r1_sha384
            ecdsa_secp521r1_sha512
            ed25519
            ed448
            rsa_pss_rsae_sha256
            rsa_pss_rsae_sha384
            rsa_pss_rsae_sha512
            rsa_pss_pss_sha256
            rsa_pss_pss_sha384
            rsa_pss_pss_sha512
            rsa_pkcs1_sha256
            rsa_pkcs1_sha384
            rsa_pkcs1_sha512
            dsa_sha256
            ecdsa_sha224
            rsa_sha224
            dsa_sha224
            ecdsa_sha1
            rsa_pkcs1_sha1
            dsa_sha1

Issues: JDK-8351354, JDK-8371074

Improved keytool Warning When Using JKS or JCEKS Keystores

The warning that keytool prints when a JKS or JCEKS keystore is used has been improved to alert users that these keystores will eventually be removed and also recommend migrating the keystores to PKCS12. The warning emitted for JKS is now the following:
```
    "JKS uses outdated cryptographic algorithms and will be removed in a future release. Migrate to PKCS12 using:
keytool -importkeystore -srckeystore <filename> -destkeystore <filename> -deststoretype pkcs12" 
```
The warning for JCEKS is the same.

Issue: JDK-8353749

JDK 26 Security Enhancements

2026-03-16T00:00:00+00:00

Highlights of this release include a second preview of the PEM API, API support for Hybrid Public Key Encryption, and signed JAR support for the post-quantum ML-DSA algorithm.

Crypto
PKI
TLS
XML Signature
Tools

Crypto

Hybrid Public Key Encryption

To use HPKE in your applications, you use the existing Cipher API with a new HPKEParameterSpec class which specifies the KEM, KDF, and AEAD algorithms you want to use.

This example from the HPKEParameterSpec javadoc shows a sender and a recipient using HPKE to securely exchange messages with an X25519 key pair:

    // Recipient key pair generation
    KeyPairGenerator g = KeyPairGenerator.getInstance("X25519");
    KeyPair kp = g.generateKeyPair();

    // The HPKE sender cipher is initialized with the recipient's public
    // key and an HPKEParameterSpec using specified algorithm identifiers
    // and application-supplied info.
    Cipher senderCipher = Cipher.getInstance("HPKE");
    HPKEParameterSpec ps = HPKEParameterSpec.of(
                    HPKEParameterSpec.KEM_DHKEM_X25519_HKDF_SHA256,
                    HPKEParameterSpec.KDF_HKDF_SHA256,
                    HPKEParameterSpec.AEAD_AES_128_GCM)
            .withInfo(HexFormat.of().parseHex("010203040506"));
    senderCipher.init(Cipher.ENCRYPT_MODE, kp.getPublic(), ps);

    // Retrieve the key encapsulation message (from the KEM step) from
    // the sender.
    byte[] kemEncap = senderCipher.getIV();

    // The HPKE recipient cipher is initialized with its own private key,
    // an HPKEParameterSpec using the same algorithm identifiers as used by
    // the sender, and the key encapsulation message from the sender.
    Cipher recipientCipher = Cipher.getInstance("HPKE");
    HPKEParameterSpec pr = HPKEParameterSpec.of(
                    HPKEParameterSpec.KEM_DHKEM_X25519_HKDF_SHA256,
                    HPKEParameterSpec.KDF_HKDF_SHA256,
                    HPKEParameterSpec.AEAD_AES_128_GCM)
            .withInfo(HexFormat.of().parseHex("010203040506"))
            .withEncapsulation(kemEncap);
    recipientCipher.init(Cipher.DECRYPT_MODE, kp.getPrivate(), pr);

    // Encryption and decryption
    byte[] msg = "Hello World".getBytes(StandardCharsets.UTF_8);
    byte[] ct = senderCipher.doFinal(msg);
    byte[] pt = recipientCipher.doFinal(ct);

    assert Arrays.equals(msg, pt);

Issue: JDK-8325448

PKCS#12 KeyStore support for RFC 9879: Use of Password-Based Message Authentication Code 1 (PBMAC1)

The JDK PKCS12 KeyStore implementation now supports the more modern PBMAC1 algorithm for integrity protection. To use the PBMAC1 algorithm, set the keystore.pkcs12.macAlgorithm property in the java.security configuration file to a PBMAC1 algorithm, for example, “PBEWithHmacSHA256”. Existing PKCS12 keystore files will continue to use the integrity algorithm it was created with, but new keystore files will use the PBMAC1 algorithm.

In a future JDK release, the default value of the keystore.pkcs12.macAlgorithm security property will be changed to a PBMAC1 algorithm.

Issue: JDK-8343232
JEP 524: PEM Encodings of Cryptographic Objects (Second Preview)

The second preview API for encoding and decoding cryptographic objects to/from the PEM format was delivered and defined in JEP 524. PEM is a widely used format for transferring and storing DER-encoded cryptographic data such as certificates, CRLs, private keys, and more. This was one of the most commonly requested features in a JCE survey a few years ago. The History section of the JEP contains a list of changes since the first preview.

There are two primary APIs, a PEMEncoder class for encoding cryptographic objects to PEM, and a PEMDecoder class for decoding PEM data into cryptographic objects. There is also a marker interface named DEREncodable, and existing classes such as X509Certificate and X509CRL have been retrofitted to implement this interface, thereby making it easier to encode/decode these objects to/from PEM.

PEMEncoder can also be configured for encryption which makes it easier to encrypt and encode private keys in one step. Similarly, PEMDecoder can be configured for decryption to allow private keys to be decoded and decrypted in one step. For more advanced usage, the existing EncryptedPrivateKeyInfo class has been enhanced with several new methods that make it easier to encrypt and decrypt private keys.

Here is an example of encoding an X509Certificate retrieved from a KeyStore to PEM:
```
    X509Certificate cert = (X509Certificate)keystore.getCertificate("mycert");
    PEMEncoder encoder = PEMEncoder.of();
    String pem = encoder.encodeToString(cert);
```
Here is an example of decoding the PEM back into an X509Certificate:
```
    PEMDecoder decoder = PEMDecoder.of();
    X509Certificate cert = decoder.decode(pem, X509Certificate.class);
```
Here are two examples of encrypting a PrivateKey with a password and then encoding it into PEM. The first example configures PEMEncoder for encryption and encrypts and encodes the private key directly in one method call:
```
    PEMEncoder encoder = PEMEncoder.of();
    String pem = encoder.withEncryption(password).encodeToString(privateKey);
```
The above example uses default parameters when encrypting. This second example uses the EncryptedPrivateKeyInfo class to encrypt the private key with additional parameters such as the password-based encryption algorithm, and then encodes it to PEM:
```
    EncryptedPrivateKeyInfo epki =
        EncryptedPrivateKeyInfo.encrypt(privateKey, password,
            "PBEWithHmacSHA256AndAES_256", null, null);
    PEMEncoder encoder = PEMEncoder.of();
    String pem = encoder.encodeToString(epki);
```
New Security Property to Disable Algorithms at the JCE Layer

A new security property named jdk.crypto.disabledAlgorithms has been added which can be used to disable cryptographic algorithms at the JCE/JCA API level. This property takes a list of algorithm names as specified in the Standard Algorithm Names specification. The security property can be overridden by a system property of the same name.

Initially the property is empty and contains no algorithms.

This is a very useful property which allows you to detect usage of cryptographic algorithms at a comprehensive level across all code in your application.

For more details on the syntax of the algorithm and the JCE services that are supported, see the definition in the java.security configuration file.

Issue: JDK-8244336
Various Performance Improvements

A number of performance improvements in the AES, ML-DSA and Elliptic Curve (P256) algorithms were made. See the following issues for more details:

Issues: 8371820, 8371450, 8371259, 8365581
Removed Obsolete Algorithms from Implementation Requirements

The DESede (3DES) algorithms and Cipher algorithms using PKCS1Padding have been removed from the implementation requirements of Java SE. These algorithms are no longer recommended and should not be requirements. The complete list of requirements removed is:
```
AlgorithmParameters:
    DESede
Cipher:
    DESede/CBC/NoPadding
    DESede/CBC/PKCS5Padding
    DESede/ECB/NoPadding
    DESede/ECB/PKCS5Padding
    RSA/ECB/PKCS1Padding
KeyGenerator:
    DESede
SecretKeyFactory:
    DESede 
```
Issue: JDK-8361964

Added PBES2 Algorithms as New Implementation Requirements

The following PBES2 algorithms from RFC 8018: PKCS #5: Password-Based Cryptography Specification Version 2.1 have been added as new requirements:

AlgorithmParameters:
    PBEWithHmacSHA256AndAES_128
    PBEWithHmacSHA256AndAES_256
Cipher:
    PBEWithHmacSHA256AndAES_128
    PBEWithHmacSHA256AndAES_256
Mac:
    PBEWithHmacSHA256
SecretKeyFactory:
    PBEWithHmacSHA256AndAES_128
    PBEWithHmacSHA256AndAES_256
    PBKDF2WithHmacSHA256 

Issue: JDK-8361964

PKI

New Root CA Certificates

Several new root CA certificates have been added to the cacerts keystore:
- Four Sectigo root CA certificates, two for TLS, and two for code signing:
  - Sectigo Public Server Authentication Root E46 with the following distinguished name:
    CN=Sectigo Public Server Authentication Root E46, O=Sectigo Limited, C=GB
  - Sectigo Public Server Authentication Root R46 with the following distinguished name:
    CN=Sectigo Public Server Authentication Root R46, O=Sectigo Limited, C=GB
  - Sectigo Public Code Signing Root E46 with the following distinguished name:
    CN=Sectigo Public Code Signing Root E46, O=Sectigo Limited, C=GB
  - Sectigo Public Code Signing Root R46 with the following distinguished name:
    CN=Sectigo Public Code Signing Root R46, O=Sectigo Limited, C=GB
  These root certificates have also been added to the cacerts keystore in Oracle’s JDK 25, 24.0.2, 21.0.8, 17.0.16, 11.0.27, and 8u461 releases.
  
  Issue: JDK-8359170
Removed Root CA Certificates

Four AffirmTrust root certificates have been removed from the cacerts keystore. These root CAs were deactivated by Entrust (who owns them) and will no longer be supported. The four roots are:
- AffirmTrust Commercial with the following distinguished name:
  CN=AffirmTrust Commercial, O=AffirmTrust, C=US
- AffirmTrust Networking with the following distinguished name:
  CN=AffirmTrust Networking, O=AffirmTrust, C=US
- AffirmTrust Premium with the following distinguished name:
  CN=AffirmTrust Premium, O=AffirmTrust, C=US
- AffirmTrust Premium ECC with the following distinguished name:
  CN=AffirmTrust Premium ECC, O=AffirmTrust, C=US
These root certificates have also been removed from the cacerts keystore in Oracle’s JDK 25.0.1, 21.0.9, 17.0.17, 11.0.29, and 8u471 releases.

Issue: JDK-8361212

TLS

Improved Checking in SunX509 KeyManagerFactory

The default SunX509 KeyManagerFactory, which is used to provide certificates and key material for TLS connections, has been improved. It now implements additional checks on certificates to ensure the ones that are selected are compliant with current algorithm constraints settings. This makes its checking consistent with the PKIX KeyManagerFactory.

Specifically, selection is based on the following rules:
1. Local certificates are checked against peer supported certificate signature algorithms sent with the TLS signature_algorithms_cert extension.
2. Local certificates are checked against TLS algorithm constraints specified in the jdk.tls.disabledAlgorithms and jdk.certpath.disabledAlgorithms security properties.
3. Local certificates are prioritized based on validity period and certificate extensions.
The prior behavior can be re-enabled by setting the system property jdk.tls.SunX509KeyManager.certChecking to false.

Issue: JDK-8359956

XML Signature

Disabled the XPath Filtering Transform

XML Signatures that use the XPath Filtering Transform have been disabled by default. The XPath transform, while powerful, has a higher risk of introducing complexities and is not recommended in the XML Signature Best Practices document. If necessary, and at your own risk, the transform can be re-enabled by removing it from the jdk.xml.dsig.secureValidationPolicy security property.

Alternatively, users should consider replacing their usages with the XPath Filter 2 Transform, which was designed to address the issues associated with the XPath Filtering Transform.

Issue: JDK-8314180
New Property to Specify SecureRandom

A new XML Signature property named jdk.xmldsig.SecureRandom has been added which allows you to specify a specific SecureRandom instance to use instead of the default SecureRandom that the JDK implementation uses.

This can be useful if you want more control over the secure random numbers used in the generation of XML Signatures.

To use this property, you call the setProperty method of the XMLSignContext class with the property name and the instance of the SecureRandom object you would like to use.

Issue: JDK-8359395

Tools

Signed JAR Support for ML-DSA

In JDK 24, we added support ML-DSA, which is a quantum-resistant digital signature algorithm specified by NIST in FIPS 204 and defined in JEP 497 for the Java Platform.

In this release, we have extended that support and added support for signing JARs with ML-DSA. This can be done using the jarsigner utility or the JarSigner API.

Here is an example of using ML-DSA to sign a JAR with jarsigner:
```
    $ jarsigner -keystore ks –sigalg ML-DSA-65 -signedjar signed.jar test.jar mldsa
```
Issue: JDK-8349732

java -XshowSettings:security:tls Now Shows TLS Named Groups and Signature Schemes

Here is a sample run showing the new output:

    $ java -XshowSettings:security:tls
    Security TLS configuration (SunJSSE provider):
        Enabled Protocols:
            TLSv1.3
            TLSv1.2
   
        Enabled Cipher Suites:
            TLS_AES_256_GCM_SHA384
            TLS_AES_128_GCM_SHA256
            TLS_CHACHA20_POLY1305_SHA256
            TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
            TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
            TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
            TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
            TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
            TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
            TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
            TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
            TLS_DHE_DSS_WITH_AES_256_GCM_SHA384
            TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
            TLS_DHE_DSS_WITH_AES_128_GCM_SHA256
            TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
            TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
            TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
            TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
            TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
            TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
            TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
            TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
            TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
            TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
            TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
            TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
            TLS_DHE_RSA_WITH_AES_256_CBC_SHA
            TLS_DHE_DSS_WITH_AES_256_CBC_SHA
            TLS_DHE_RSA_WITH_AES_128_CBC_SHA
            TLS_DHE_DSS_WITH_AES_128_CBC_SHA
            TLS_EMPTY_RENEGOTIATION_INFO_SCSV

        Enabled Named Groups:
            X25519MLKEM768
            x25519
            secp256r1
            secp384r1
            secp521r1
            x448
            ffdhe2048
            ffdhe3072
            ffdhe4096
            ffdhe6144
            ffdhe8192

        Enabled Signature Schemes:
            ecdsa_secp256r1_sha256
            ecdsa_secp384r1_sha384
            ecdsa_secp521r1_sha512
            ed25519
            ed448
            rsa_pss_rsae_sha256
            rsa_pss_rsae_sha384
            rsa_pss_rsae_sha512
            rsa_pss_pss_sha256
            rsa_pss_pss_sha384
            rsa_pss_pss_sha512
            rsa_pkcs1_sha256
            rsa_pkcs1_sha384
            rsa_pkcs1_sha512
            dsa_sha256
            ecdsa_sha224
            rsa_sha224
            dsa_sha224
            ecdsa_sha1
            rsa_pkcs1_sha1
            dsa_sha1

Issues: JDK-8351354, JDK-8371074

Improved keytool Warning When Using JKS or JCEKS Keystores

The warning that keytool prints when a JKS or JCEKS keystore is used has been improved to alert users that these keystores will eventually be removed and also recommend migrating the keystores to PKCS12. The warning emitted for JKS is now the following:
```
    "JKS uses outdated cryptographic algorithms and will be removed in a future release. Migrate to PKCS12 using:
keytool -importkeystore -srckeystore <filename> -destkeystore <filename> -deststoretype pkcs12" 
```
The warning for JCEKS is the same.

Issue: JDK-8353749

JDK 25 Security Enhancements

2025-09-23T00:00:00+00:00

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

Highlights of this release include a final version of the Key Derivation Function API and a new preview API for encoding and decoding cryptographic objects to/from PEM.

Crypto
TLS
Performance Improvements
Security Manager
Miscellaneous

Crypto

JEP 470: PEM Encodings of Cryptographic Objects (Preview)

A new preview API for encoding and decoding cryptographic objects to/from the PEM format has been introduced in JDK 25 and defined in JEP 470. PEM is a widely used format for transferring and storing DER-encoded cryptographic data such as certificates, CRLs, private keys, and more. This was one of the most commonly requested features in a JCE survey a few years ago.

Two primary APIs have been added, a PEMEncoder class for encoding cryptographic objects to PEM, and a PEMDecoder class for decoding PEM data into cryptographic objects. A new marker interface named DEREncodable has been added, and existing classes such as X509Certificate and X509CRL have been retrofitted to implement this interface, thereby making it easier to encode/decode these objects to/from PEM.

PEMEncoder can also be configured for encryption which makes it easier to encrypt and encode private keys in one step. Similarly, PEMDecoder can be configured for decryption to allow private keys to be decoded and decrypted in one step. For more advanced usage, the existing EncryptedPrivateKeyInfo class has also been enhanced with several new methods that make it easier to encrypt and decrypt private keys.

Here is an example of encoding an X509Certificate retrieved from a KeyStore to PEM:
```
    X509Certificate cert = (X509Certificate)keystore.getCertificate("mycert");
    PEMEncoder encoder = PEMEncoder.of();
    String pem = encoder.encodeToString(cert);
```
Here is an example of decoding the PEM back into an X509Certificate:
```
    PEMDecoder decoder = PEMDecoder.of();
    X509Certificate cert = decoder.decode(pem, X509Certificate.class);
```
Here are two examples of encrypting a PrivateKey with a password and then encoding it into PEM. The first example configures PEMEncoder for encryption and encrypts and encodes the private key directly in one method call:
```
    PEMEncoder encoder = PEMEncoder.of();
    String pem = encoder.withEncryption(password).encodeToString(privateKey);
```
The above example uses default parameters when encrypting. This second example uses the EncryptedPrivateKeyInfo class to encrypt the private key with additional parameters such as the password-based encryption algorithm, and then encodes it to PEM:
```
    EncryptedPrivateKeyInfo epki =
        EncryptedPrivateKeyInfo.encryptKey(privateKey, password,
            "PBEWithHmacSHA256AndAES_256", null, null);
    PEMEncoder encoder = PEMEncoder.of();
    String pem = encoder.encodeToString(epki);
```
JEP 510: Key Derivation Function API

A preview of the Key Derivation Function (KDF) API was delivered in JDK 24 and defined in JEP 478. This release delivers the final version of the API, without any changes. KDF is an API for deriving keys from key material and is more fully described in JEP 510. Also included is an implementation of the HMAC-based Extract-and-Expand Key Derivation Function (HKDF), which is defined in RFC 5869.

KDF will be a very valuable API for several future enhancements that depend on key derivation. These include PQC mechanisms such as Hybrid Key Exchange in TLS 1.3 (IETF Draft) and Hybrid Public Key Encryption (RFC 9180). The API is also designed to be used for strong and modern password-based algorithms such as Argon2 (RFC 9106).

The main new class is javax.crypto.KDF. The JEP gives an example of using the HKDF-SHA256 algorithm to derive a 32 byte AES key:
```
    // Create a KDF object for the specified algorithm
    KDF hkdf = KDF.getInstance("HKDF-SHA256"); 

    // Create an ExtractExpand parameter specification
    AlgorithmParameterSpec params =
        HKDFParameterSpec.ofExtract()
                 .addIKM(initialKeyMaterial)
                 .addSalt(salt).thenExpand(info, 32);

    // Derive a 32-byte AES key
    SecretKey key = hkdf.deriveKey("AES", params);
```
SHAKE128-256 and SHAKE256-512 MessageDigest Algorithms

Two new MessageDigest algorithms have been added to the SUN provider: SHAKE128-256 and SHAKE256-512. These are fixed-length versions of the SHAKE128 and SHAKE256 Extendable-Output Functions (XOFs) defined in NIST FIPS 202.

Here is an example using MessageDigest to digest some bytes with SHAKE128-256:
```
    byte[] bytes = ...
    MessageDigest md = MessageDigest.getInstance("SHAKE128-256");
    byte[] digest = md.digest(bytes);
```
Issue: JDK-8354305
PKCS#11 Support for the HKDF-SHA256, HKDF-SHA384 and HKDF-SHA512 Key Derivation Function Algorithms

Support for the HKDF-SHA256, HKDF-SHA384 and HKDF-SHA512 Key Derivation Function algorithms has been added to the SunPKCS11 provider. These algorithms can be used with the new KDF API in JDK 25. See the SunPKCS11 Provider Supported Algorithms section of the PKCS#11 Reference Guide for more details.

Issue: JDK-8328119
Added TLSv1.3 and CNSA 1.0 Algorithms to Implementation Requirements

In the Java Security Standard Algorithm Names Specification, new requirements have been added to the list of cryptographic requirements all Java SE implementations must support. All cryptographic algorithms that are needed to implement the TLSv1.3 cipher suites and signature mechanisms and that are defined by RFC 8446 as MUST or SHOULD requirements have been added. All algorithms that are required by CNSA 1.0 have also been added. No required algorithms or protocols are being removed at this time. These are the new requirements:
- AlgorithmParameters
  - ChaCha20-Poly1305
  - EC with secp256r1 or secp384r1 curves
  - RSASSA-PSS with MGF1 mask generation function and SHA-256 or SHA-384 hash algorithm
- Cipher
  - AES/GCM/NoPadding with 256 bit key size
  - ChaCha20-Poly1305
- KeyAgreement
  - ECDH with secp256r1 or secp384r1 curves
  - X25519
- KeyFactory
  - EC
  - RSASSA-PSS
  - X25519
- KeyGenerator
  - AES with 256 bit key size
  - ChaCha20
- KeyPairGenerator
  - DH with 3072 bit key size
  - EC with secp256r1 or secp384r1 curves
  - RSA with 3072 bit key size
  - RSASSA-PSS with 2048, 3072, 4096 bit key sizes
  - X25519
- MessageDigest
  - SHA-384
- Signature
  - RSASSA-PSS with MGF1 mask generation function and SHA-256 or SHA-384 hash algorithm
  - SHA256WithECDSA with secp256r1 curve
  - SHA384WithECDSA with secp384r1 curve
  - SHA384WithRSA
- SSLContext
  - TLSv1.3
Issue: JDK-8283795
New Key Algorithms Section of the Java Security Standard Algorithm Names Specification

A new Key Algorithms section has been added to the Java Security Standard Algorithm Names Specification listing the standard names of keys generated or created by the KeyFactory, SecretKeyFactory, KeyGenerator, or KeyPairGenerator APIs. Two subsections distinguish between Asymmetric and SecretKey (or symmetric) algorithms.

Issue: JDK-8346736
Added PBES2 as a Standard AlgorithmParameters Algorithm

PBES2 had been added as a standard algorithm to the AlgorithmParameters section of the Java Security Standard Algorithm Names Specification. The PBES2 algorithm is defined in PKCS #5: Password-Based Cryptography Specification, Version 2.1. A PBES2 AlgorithmParameters implementation is supported by the SunJCE provider.

Issue: JDK-8348405

TLS

Support for TLS Keying Material Exporters

New methods have been added to the javax.net.ssl.ExtendedSession class that allow applications to generate additional application-level keying material from a connection’s negotiated TLS keys.

These new APIs are useful for various exporter mechanisms that depend on keying material, such as those listed in the TLS Exporter Labels section of the IANA registry.

Two new methods have been added:
```
    public SecretKey exportKeyingMaterialKey(String keyAlg,
        String label, byte[] context, int length) throws SSLKeyException
    public byte[] exportKeyingMaterialData(
        String label, byte[] context, int length) throws SSLKeyException 
```
The first method exports the keying material as a SecretKey and the second method as a byte array. The SecretKey method is useful for implementations that store keys on hardware or tokens.

Issue: JDK-8341346
New Mechanism to Disable Signature Schemes Based on Their TLS Scope

The jdk.tls.disabledAlgorithms security property has been enhanced to support selectively disabling algorithms in TLS handshake or certificate signatures. This new syntax allows you to more easily disable an algorithm only for handshake signatures or only for certificate signatures, which might be desirable depending on various factors.

The syntax extends the existing UsageConstraint to have a new UsageType component, ex:
```
    UsageConstraint:
        usage UsageType { UsageType }

    UsageType:
        HandshakeSignature | CertificateSignature 
```
The algorithm name can be a Signature algorithm (ex: SHA1withRSA), a Key algorithm (ex: RSA), or a TLS signature scheme (ex: rsa_pkcs1_sha1).

Issue: JDK-8349583
Disabled SHA-1 in TLS 1.2 and DTLS 1.2 Handshake Signatures

SHA-1 in TLS 1.2 and DTLS 1.2 handshake signatures is now disabled by default. SHA-1 is deprecated for use in handshake signatures as specified in RFC 9155.

Users can re-enable SHA-1 in handshake signatures, at their own risk, by removing “rsa_pkcs1_sha1 usage HandshakeSignature, ecdsa_sha1 usage HandshakeSignature, dsa_sha1 usage HandshakeSignature” from the jdk.tls.disabledAlgorithms security property in the java.security configuration file.

Issue: JDK-8353879

Performance Improvements

Several performance improvements have been made to the crypto and TLS implementations:

Optimize Java Implementation of ML-KEM

The performance of the ML-KEM KEM implementation has been improved by 1-2%.

Issue: JDK-8347608
Optimize Java Implementation of ML-DSA

The performance of the ML-DSA Signature implementation has been improved by approximately 10%.

Issue: JDK-8347606
Change ChaCha20 Intrinsic to use Quarter-Round Parallel Implementation on aarch64

The performance of the ChaCha20 Cipher implementation has been improved by 2-4% on aarch64 processors.

Issue: JDK-8349106
Reduce TLS Stateless Session Ticket Size

The size of TLS stateless session tickets has been significantly reduced.

Issue: JDK-8357033

Security Manager

Various Permission Classes Deprecated for Removal

Many permission classes have been deprecated for removal as they are no longer useful now that the Security Manager has been permanently disabled in JDK 24. The following classes are now terminally deprecated:
- java.security.UnresolvedPermission
- javax.net.ssl.SSLPermission
- javax.security.auth.AuthPermission
- javax.security.auth.PrivateCredentialPermission
- javax.security.auth.kerberos.DelegationPermission
- javax.security.auth.kerberos.ServicePermission
- com.sun.security.jgss.InquireSecContextPermission
- java.lang.RuntimePermission
- java.lang.reflect.ReflectPermission
- java.io.FilePermission
- java.io.SerializablePermission
- java.nio.file.LinkPermission
- java.util.logging.LoggingPermission
- java.util.PropertyPermission
- jdk.jfr.FlightRecorderPermission
- java.net.NetPermission
- java.net.URLPermission
- jdk.net.NetworkPermission
- com.sun.tools.attach.AttachPermission
- com.sun.jdi.JDIPermission
- java.lang.management.ManagementPermission
- javax.management.MBeanPermission
- javax.management.MBeanTrustPermission
- javax.management.MBeanServerPermission
- javax.management.remote.SubjectDelegationPermission
In addition, the getPermission method defined in java.net.URLConnection and its subclass java.net.HttpURLConnection has been deprecated for removal.

Issue: JDK-8348967

Miscellaneous

Turn on Timestamp and Thread Details by Default for java.security.debug

The “thread” and “timestamp” options that were added to the java.security.debug system property in JDK 23 are now on by default.

Each debug statement will now also include the thread id, thread name, caller information (source code and line number) and the date and time.

For example, below is a portion of the output of an application run with -Djava.security.debug=properties:

properties[0x1|main|Security.java:161|2024-09-20 09:31:39.929]: java.security
properties[0x1|main|Security.java:122|2024-09-20 09:31:39.931]: Initial security property: jdk.jar.disabledAlgorithms=MD2, MD5, RSA keySize < 1024, DSA keySize < 1024, SHA1 denyAfter 2019-01-01 
properties[0x1|main|Security.java:122|2024-09-20 09:31:39.931]: Initial security property: security.provider.13=SunPKCS11
properties[0x1|main|Security.java:122|2024-09-20 09:31:39.931]: Initial security property: security.provider.12=Apple 
properties[0x1|main|Security.java:122|2024-09-20 09:31:39.931]: Initial security property: http.auth.digest.disabledAlgorithms=MD5, SHA-1
properties[0x1|main|Security.java:122|2024-09-20 09:31:39.932]: Initial security property: jdk.security.legacyAlgorithms=SHA1, RSA keySize < 2048, DSA keySize < 2048, DES, DESede, MD5, RC2, ARCFOUR
properties[0x1|main|Security.java:122|2024-09-20 09:31:39.932]: Initial security property: securerandom.source=file:/dev/random

Issue: JDK-8350689

Javadoc for the java.security.debug Property

The java.security.debug property is now documented in the javadoc. This is a very useful property for debugging security code.

Issue: JDK-8328914

JDK 24 Security Enhancements

2025-04-07T00:00:00+00:00

JDK 24 was released on March 18, 2025! 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, PKI, etc) which should make it easier to find out what has changed in each specific area. The JDK 24 release notes also contain further details on these and other enhancements.

This is a significant release for Java Security as it contains two new core quantum-resistant cryptographic algorithms, ML-KEM for key encapsulation, and ML-DSA for digital signatures. It also includes a new Preview API for Key Derivation Functions, which will be an important building block for subsequent post-quantum cryptography work. This release also permanently disables the Security Manager.

In addition, JDK 24 includes one other important feature that improves security but is not part of the security libraries area:

JEP 498: Warn upon Use of Memory-Access Methods in sun.misc.Unsafe

A warning is now issued at run time on the first use of the memory-access methods in sun.misc.Unsafe. These methods were deprecated for removal in JDK 23 in JEP 471.

Crypto
PKI
TLS
Security Manager
Miscellaneous

Crypto

JEP 496: Quantum-Resistant Module-Lattice-Based Key Encapsulation Mechanism

The SunJCE provider now supports the quantum-resistant ML-KEM key encapsulation mechanism. This mechanism is specified in FIPS 203, and is based on lattices. New KeyPairGenerator, KeyFactory, and KEM implementations for ML-KEM have been added. Three parameter sets in increasing strength are supported: ML-KEM-512, ML-KEM-768, and ML-KEM-1024.

Here is an example which uses ML-KEM to establish a shared secret key between two parties, a sender and a receiver:

// The receiver generates an ML-KEM-768 key pair
KeyPairGenerator kpg = KeyPairGenerator.getInstance("ML-KEM");
kpg.initialize(NamedParameterSpec.ML_KEM_768);
KeyPair kp = kpg.genKeyPair();

// The sender obtains the receiver's public key from
// an X.509 certificate (this part is not shown)

// The sender generates a key encapsulation message and secret key
// from the receiver’s public key
KEM kem = KEM.getInstance("ML-KEM");
KEM.Encapsulator enc = kem.newEncapsulator(receiverCert.getPublicKey());
KEM.Encapsulated encap = enc.encapsulate();
SecretKey skey = encap.key();
byte[] msg = encap.encapsulation(); // send this to the receiver

// The sender then sends the encapsulated message to the receiver
// (this part is not shown)

// The receiver decapsulates the key encapsulation message with its
// private key to obtain the secret key
byte[] msg = …; // received from sender
KEM kem = KEM.getInstance("ML-KEM");
KEM.Decapsulator dec = kem.newDecapsulator(kp.getPrivateKey());
SecretKey skey = dec.decapsulate(msg);

The keytool utility also supports generating ML-KEM key pairs. Here is an example of generating an ML-KEM key pair and certificate:

$ keytool -keystore ks -storepass changeit \
       -genkeypair -alias ec -keyalg EC \
       -dname CN=EC -ext bc
Generating 384-bit EC (secp384r1) key pair and self-signed certificate (SHA384withECDSA) with a validity of 90 days
    for: CN=EC

$ keytool -keystore ks -storepass changeit \
        -genkeypair -alias mlkem -keyalg ML-KEM \
        -groupname ML-KEM-768 -dname CN=ML-KEM \
        -signer ec
Generating ML-KEM-768 key pair and a certificate (SHA384withECDSA) issued by <ec> with a validity of 90 days
    for: CN=ML-KEM

Note that in order to create the certificate, we need a different key to sign the certificate because ML-KEM itself is not a signature algorithm. The first command creates an EC key pair and self-signed certificate and the second command creates an ML-KEM-768 key pair and a certificate signed by the EC key.

JEP: 496: Quantum-Resistant Module-Lattice-Based Key Encapsulation Mechanism

JEP 497: Quantum-Resistant Module-Lattice-Based Digital Signature Algorithm

The SUN provider now supports the quantum-resistant ML-DSA signature algorithm. This algorithm is specified in FIPS 204, and is based on lattices. New KeyPairGenerator, KeyFactory, and Signature implementations for ML-DSA have been added. Three parameter sets in increasing strength are supported: ML-DSA-44, ML-DSA-65, and ML-DSA-87.

Using ML-DSA in your applications is very similar to other signature algorithms. Here is an example which uses ML-DSA to sign and verify a message:

// The signer generates an ML-DSA-65 key pair
KeyPairGenerator kpg = KeyPairGenerator.getInstance("ML-DSA");
kpg.initialize(NamedParameterSpec.ML_DSA_65);
KeyPair kp = kpg.genKeyPair();

// The signer signs a message using its private key
Signature sig = Signature.getInstance("ML-DSA");
sig.initSign(kp.getPrivate());
sig.update(message);
byte[] signature = sig.sign();

// The signer then sends the signed message to the verifier
// (this part is not shown)

// The verifier verifies the message using the signer’s public key
// (which in this case is in an X.509 certificate)
Signature sig = Signature.getInstance("ML-DSA");
sig.initVerify(signerCert);
sig.update(message);
assert sig.verify(signature);

The keytool utility also supports generating ML-DSA key pairs. Here is an example of generating an ML-DSA key pair and certificate:

$ keytool -keystore ks -storepass changeit \
        -genkeypair -alias mldsa -keyalg ML-DSA \
        -groupname ML-DSA-65 -dname CN=ML-DSA
Generating ML-DSA-65 key pair and self-signed certificate (ML-DSA-65) with a validity of 90 days
    for: CN=ML-DSA

This command creates an ML-DSA-65 key pair and a self-signed certificate.

JEP: 497: Quantum-Resistant Module-Lattice-Based Digital Signature Algorithm

JEP 478: Key Derivation Function API (Preview)

A new preview API for deriving keys from key material has been introduced in this release and is more fully described in JEP 478. It includes an implementation of the HMAC-based Extract-and-Expand Key Derivation Function (HKDF), which is defined in RFC 5869.

KDF will be a very valuable API for several future enhancements that depend on key derivation. These include PQC mechanisms such as Hybrid Key Exchange in TLS 1.3 (IETF Draft) and Hybrid Public Key Encryption (RFC 9180). The API is also designed to be used for strong and modern password-based algorithms such as Argon2 (RFC 9106).

The main new class is javax.crypto.KDF. The JEP gives an example of using the HKDF-SHA256 algorithm to derive a 32 byte AES key:
```
// Create a KDF object for the specified algorithm
KDF hkdf = KDF.getInstance("HKDF-SHA256"); 

// Create an ExtractExpand parameter specification
AlgorithmParameterSpec params =
    HKDFParameterSpec.ofExtract()
             .addIKM(initialKeyMaterial)
             .addSalt(salt).thenExpand(info, 32);

// Derive a 32-byte AES key
SecretKey key = hkdf.deriveKey("AES", params);
```
JEP: 478: Key Derivation Function API (Preview)
Standard Hash and MGF Algorithm Names Defined for RSASSA-PSS Signatures

A new PSSParameterSpec section has been added to the Java Security Standard Algorithm Names Specification listing the standard hash and MGF (Message Generation Function) algorithms that can be specified when instantiating a java.security.spec.PSSParameterSpec object.

Issue: JDK-8248981
SHA3 Performance Improved

The performance of the SHA3 MessageDigest implementations has improved by 6% to 27%, depending on the platform and the length of the message digest. This performance improvement applies to the SHA3-224, SHA3-256, SHA3-384, and SHA3-512 algorithms. An additional 30-40% can be experienced on AVX-512 capable platforms due to new intrinsic implementations on that platform.

Issue: JDK-8333867
PKCS#11 Support for AES CTS (Ciphertext Stealing) Mode

The SunPKCS11 provider has been enhanced to support AES Ciphertext Stealing mode, if the configured PKCS#11 token supports it. The “AES/CTS/NoPadding”, “AES_128/CTS/NoPadding”, “AES_192/CTS/NoPadding”, and “AES_256/CTS/NoPadding” Cipher algorithms are supported.

The PKCS#11 cipherTextStealingVariant attribute should be set to the CTS variant used by the PKCS#11 implementation. These correspond to the 3 variants defined by NIST SP 800-38A: CS1, CS2, and CS3. If NSS is used as the PKCS#11 implementation, it automatically sets it to CS1. If this attribute is not set, the CTS modes are disabled by default.

Issue: JDK-8330842

PKI

New Root CA Certificates

Several new root CA certificates have been added to the cacerts keystore:
- Two SSL.com root CA certificates
  - SSL.com TLS ECC Root CA 2022 has the following distinguished name:
    CN=SSL.com TLS ECC Root CA 2022, O=SSL Corporation, C=US
  - SSL.com TLS RSA Root CA 2022 has the following distinguished name:
    CN=SSL.com TLS RSA Root CA 2022, O=SSL Corporation, C=US
  These root certificates have also been added to the cacerts keystore in Oracle’s JDK 23.0.1, 21.0.5, 17.0.13, 11.0.25, and 8u431 releases.
  
  Issue: JDK-8341057

TLS

New Wildcard Mechanism for Disabling TLS Cipher Suites

The jdk.tls.disabledAlgorithms security property has been enhanced to support disabling TLS cipher suites using a wildcard syntax. This new syntax allows you to more easily disable more than one cipher suite. For example, TLS_RSA_* would disable all cipher suites starting with “TLS_RSA_”. Only cipher suites starting with “TLS_” can be disabled using this mechanism.

Issue: JDK-8341964
Entrust TLS Server Certificates Distrusted

The JDK will no longer trust TLS Server certificates issued by Entrust. The list of affected certificates includes certificates branded as Entrust and AffirmTrust, which was managed by Entrust. TLS Server certificates issued on or before November 11, 2024 will continue to be trusted until they expire. Certificates issued after that date will be rejected. See the release note for more information and a list of Certificate Authorities that are affected.

This change has already been made in Oracle’s JDK 23.0.1, 21.0.5, 17.0.13, 11.0.25, and 8u431 releases.

Issue: JDK-8337664
TLS_RSA Cipher Suites Disabled by Default

The TLS_RSA cipher suites are now disabled by default. These cipher suites do not preserve forward secrecy and RFC 9325 recommends that they should not be used. This change disables any cipher suite starting with “TLS_RSA_”.

Users can re-enable these cipher suites, at their own risk, by removing “TLS_RSA_*” from the jdk.tls.disabledAlgorithms security property in the java.security configuration file.

Issue: JDK-8245545

Security Manager

Permanently Disable the Security Manager

In JDK 17, the Security Manager was deprecated for removal via JEP 411. This included the java.lang.SecurityManager API and several APIs related to the Security Manager.

In this release, we have taken the next major step and permanently disabled the Security Manager. It is no longer possible to enable a Security Manager at startup on the command line, or at run time by calling System.setSecurityManager. The Security Manager related APIs have been degraded to be non-functional or to behave as in prior releases when a Security Manager was not enabled.

Developers should take action to remove dependencies on the Security Manager, if applicable. There are several methods you can use to determine if your code is dependent on the Security Manager:
- Check scripts or documentation for Security Manager references
- Run the application on one of JDK 17 through 23 and look for deprecation warnings on the console
- Run the application on one of JDK 17 through 23 with the command-line option -Djava.security.manager=disallow. If the code is dynamically setting a Security Manager, it will throw an UnsupportedOperationException.
- Use the jdeprscan tool on JDK 17 or later to scan for uses of deprecated Security Manager APIs
The JVM will exit with a fatal error at startup if an application is run with a Security Manager, ex:
```
java –Djava.security.manager MyApp

Error occurred during initialization of VM
java.lang.Error: A command line option has attempted to allow or enable the Security Manager. Enabling a Security Manager is not supported.
        at java.lang.System.initPhase3(java.base@24-internal/System.java:2067)
```
If an application enables a Security Manager at run time, an UnsupportedOperationException will be thrown, ex:
```
java MyApp
    
Exception in thread "main" java.lang.UnsupportedOperationException: Setting a Security Manager is not supported
        at java.base/java.lang.System.setSecurityManager(System.java:320)
        ...
```
Libraries supporting the Security Manager typically use one or two common coding patterns, ex:
```
// checking permissions
SecurityManager sm = System.getSecurityManager();
if (sm != null) {
    sm.checkPermission(...);
}

// asserting privileges
SomeType v = AccessController.doPrivileged(
    (PrivilegedAction<SomeType>)() -> {
        ...
        return theResult;
});
```
These methods will behave the same as in previous JDK releases when a Security Manager was not enabled: System.getSecurityManager will always return null and AccessController.doPrivileged will execute the action immediately.

A small number of applications or libraries use advanced parts of the Security Manager APIs, ex: AccessController::checkPermission to check permissions directly, or Policy::setPolicy to use a custom policy implementation.

These APIs, among others, have been degraded to throw exceptions or provide an execution environment that disallows access to all resources by default.

For applications that use JAAS, Subject.getSubject has been changed to always throw UnsupportedOperationException. This API depends on the terminally deprecated AccessControlContext API. Replacement APIs were added in JDK 18. If using this API, you must replace calls to Subject.getSubject with Subject.current and you should replace calls to Subject.doAs with Subject.callAs.

See the CSR for a complete list of API changes.

In a future release the Security Manager APIs will be removed.

JEP: 486: Permanently Disable the Security Manager

Miscellaneous

Support for Including Security Properties Files

The java.security security properties file now supports including other properties files. A new include <file> directive can be added to include another properties file. The effect of including a file is equivalent to defining its properties inline at the inclusion point. This feature is very useful for defining different property files that can be included based on different security profiles.

For more information and examples, see the Security Properties Files Inclusion section of the Security Developer Guide.

Issue: JDK-8319332

JDK 23 Security Enhancements

2024-09-17T00:00:00+00:00

JDK 23 was released on September 17, 2024! 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, PKI, etc) which should make it easier to find out what has changed in each specific area. The JDK 23 release notes also contain further details on these and other enhancements.

Highlights of this release include new “thread” and “timestamp” debugging options, crypto related performance improvements, and a new KeyStore for accessing root certificates in the MacOS KeyChain.

Also, one other important JDK 23 feature that is not part of the security libraries area but is worth mentioning is:

JEP 471: Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal

This JEP deprecates the memory-access methods in sun.misc.Unsafe for removal in a future release. Quoting from the JEP: “Removing the memory-access methods in sun.misc.Unsafe is part of a long-term coordinated effort to ensure that the Java Platform has integrity by default.”

Crypto
PKI
Authorization
Kerberos
Miscellaneous

Crypto

Increased CipherInputStream buffer size

The buffer size of javax.crypto.CipherInputStream has been increased from 512 bytes to 8192 bytes. This change can improve performance and is more consistent with buffer sizes for other APIs such as java.io.FileInputStream.

Issue: JDK-833018
New SecureRandom() performance improved

The performance of constructing a java.security.SecureRandom object via new SecureRandom() has been improved.

Issues: JDK-8324646, JDK-8324648
New PKCS11 allowLegacy attribute

A new PKCS11 configuration attribute named allowLegacy has been introduced. Applications can set this value to “true” to bypass legacy checks. The default value is “false”.

As cryptographic algorithms weaken, some PKCS11 libraries may begin limiting the use of these algorithms. For example, a PKCS11 library may allow an application to verify existing signatures signed with a particular algorithm, but forbid new signatures to be generated with that algorithm. This attribute allows applications to workaround these restrictions if necessary, at their own risk.

Issue: JDK-8293345

PKI

New root CA certificates

Several new root CA certificates have been added to the cacerts keystore:
- Two Certainly root CA certificates
  - Certainly Root R1 has the following distinguished name:
    CN=Certainly Root R1, O=Certainly, C=US
  - Certainly Root E1 has the following distinguished name:
    CN=Certainly Root E1, O=Certainly, C=US
  These root certificates have also been added to the cacerts keystore in Oracle’s JDK 22.0.1, 21.0.3, 17.0.11, 11.0.23, 8u411, and 7u421 releases.
  
  Issue: JDK-8321408
- Two GlobalSign root CA certificates
  - GlobalSign Root R46 has the following distinguished name:
    CN=GlobalSign Root R46, O=GlobalSign nv-sa, C=BE
  - GlobalSign Root E46 has the following distinguished name:
    CN=GlobalSign Root E46, O=GlobalSign nv-sa, C=BE
  These root certificates have also been added to the cacerts keystore in Oracle’s JDK 22.0.2, 21.0.4, 17.0.12, 11.0.24, 8u421, and 7u431 releases.
  
  Issue: JDK-8316138

New KeyStore for MacOS root certificates

A new java.security.KeyStore named KeychainStore-ROOT has been added to the Apple security provider. This keystore contains root certificates stored in the system keychain on MacOS systems. The Apple provider now supports two KeyStores, KeychainStore-Root and the existing KeychainStore which contains private keys and certificates for the user’s keychain.

This enhancement will fix issues that caused HTTPs connections to fail because the JDK was unable to find a root certificate to establish trust in the peer’s certificate chain. After this change, users should set the javax.net.ssl.trustStoreType system property to KeychainStore-ROOT when making TLS connections.

Here is an example of using the keytool utility to list the roots in the MacOS KeyChain:

keytool -list -storetype KeychainStore-ROOT -keystore NONE
Enter keystore password:  

*****************  WARNING WARNING WARNING  *****************
* The integrity of the information stored in your keystore  *
* has NOT been verified!  In order to verify its integrity, *
* you must provide your keystore password.                  *
*****************  WARNING WARNING WARNING  *****************

Keystore type: KEYCHAINSTORE-ROOT
Keystore provider: Apple

Your keystore contains 153 entries

aaa certificate services, Sep 20, 2024, trustedCertEntry, 
Certificate fingerprint (SHA-256): D7:A7:A0:FB:5D:7E:27:31:D7:71:E9:48:4E:BC:DE:F7:1D:5F:0C:3E:0A:29:48:78:2B:C8:3E:E0:EA:69:9E:F4
ac raiz fnmt-rcm, Sep 20, 2024, trustedCertEntry, 
Certificate fingerprint (SHA-256): EB:C5:57:0C:29:01:8C:4D:67:B1:AA:12:7B:AF:12:F7:03:B4:61:1E:BC:17:B7:DA:B5:57:38:94:17:9B:93:FA
accvraiz1, Sep 20, 2024, trustedCertEntry, 
Certificate fingerprint (SHA-256): 9A:6E:C0:12:E1:A7:DA:9D:BE:34:19:4D:47:8A:D7:C0:DB:18:22:FB:07:1D:F1:29:81:49:6E:D1:04:38:41:13
actalis authentication root ca, Sep 20, 2024, trustedCertEntry, 
Certificate fingerprint (SHA-256): 55:92:60:84:EC:96:3A:64:B9:6E:2A:BE:01:CE:0B:A8:6A:64:FB:FE:BC:C7:AA:B5:AF:C1:55:B3:7F:D7:60:66
...

Issue: JDK-8320362

New system property to use POST for all OCSP requests

JDK 17 introduced a performance enhancement whereby the JDK uses the HTTP GET method for small OCSP requests, and POST for all other requests. However, some OCSP responders do not handle GET requests well, and this has caused issues that can’t be easily worked around.

Thus, a new system property named com.sun.security.ocsp.useget has been introduced. When set to “false”, the JDK will only use the HTTP POST method when submitting OCSP requests. The default if not set, is “true” with the behavior being the same as before.

Issue: JDK-8328638

Authorization

Subject.getSubject() now throws UnsupportedOperationException unless a Security Manager is allowed or enabled

The getSubject method of javax.security.auth.Subject has been changed to throw an UnsupportedOperationException. Users can revert to previous behavior by allowing or enabling a Security Manager on the command line, via -Djava.security.manager. The Subject.getSubject method does not depend on a Security Manager but requires the feature be “allowed” due to the AccessControlContext parameter.

This change was made to prepare users for a future release where this method will be changed to always throw UnsupportedOperationException. This method is problematic because it depends on AccessControlContext, which is one of the Security Manager APIs that was deprecated for removal in JDK 17.

The good news is that a replacement API (Subject.current()) was added in JDK 18. Applications and libraries should strongly consider replacing their calls to Subject.getSubject() with Subject.current().

Issue: JDK-8296244

Kerberos

New security/system property to support case-sensitive principal names

A new security property named jdk.security.krb5.name.case.sensitive has been introduced to allow Kerberos principal names to be looked up in keytab and credential cache files in a case-sensitive manner. Prior to this change, principal names were always treated as case-insensitive, meaning a principal name of SEAN@ACME.ORG would match sean@acme.org. However, some Kerberos implementations treat these principals as distinct.

If the property is set to “true”, the JDK Kerberos implementation will use a case-sensitive comparison when matching principal names. The default value of this property, if not set, is “false” to preserve existing behavior. A system property of the same name can also be used, and it will override the value of the security property.

Issue: JDK-8331975
Enhanced Kerberos debugging

Debug output of the Kerberos component is now directed to standard error instead of standard output. Each message is now prefixed with the Kerberos subcomponent that it applies to: krb5loginmodule, jgss, krb5, etc.

Here is example output of debugging code with the sun.security.krb5.debug system property set to “true”:
```
krb5: Java config name: null
krb5: Native config name: /etc/krb5.conf
krb5: Loading config file from /etc/krb5.conf
krb5: Loaded from native config
```
Issue: JDK-8327818

Miscellaneous

New “thread” and “timestamp” options for the java.security.debug system property

New “thread” and “timestamp” options have been added to the java.security.debug system property to help you debug applications.

The “thread” option will print the thread and caller information of each debug statement. The “timestamp” option will print the date and time of each debug statement. These new options can be extremely helpful when debugging multi-threaded applications.

The options can be appended with a “+” sign to a java.security.debug setting. For example, below is a portion of the output of an application run with -Djava.security.debug=properties+thread+timestamp. Each debug line contains a timestamp and the thread id and caller.

properties[0x1|main|Security.java:161|2024-09-20 09:31:39.929]: java.security
properties[0x1|main|Security.java:122|2024-09-20 09:31:39.931]: Initial security property: jdk.jar.disabledAlgorithms=MD2, MD5, RSA keySize < 1024, DSA keySize < 1024, SHA1 denyAfter 2019-01-01
properties[0x1|main|Security.java:122|2024-09-20 09:31:39.931]: Initial security property: security.provider.13=SunPKCS11
properties[0x1|main|Security.java:122|2024-09-20 09:31:39.931]: Initial security property: security.provider.12=Apple
properties[0x1|main|Security.java:122|2024-09-20 09:31:39.931]: Initial security property: http.auth.digest.disabledAlgorithms=MD5, SHA-1
properties[0x1|main|Security.java:122|2024-09-20 09:31:39.932]: Initial security property: jdk.security.legacyAlgorithms=SHA1, RSA keySize < 2048, DSA keySize < 2048, DES, DESede, MD5, RC2, ARCFOUR
properties[0x1|main|Security.java:122|2024-09-20 09:31:39.932]: Initial security property: securerandom.source=file:/dev/random

Issue: JDK-8051959

JDK 22 Security Enhancements

2024-03-20T00:00:00+00:00

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

Highlights of this release include a new security category for the java -XshowSettings option and several new root CA certificates.

Crypto
PKI
TLS
XML Signature
Tools

Crypto

New java.security.AsymmetricKey interface

A new standard interface named java.security.AsymmetricKey has been added. AsymmetricKey is a subinterface of java.security.Key and represents an asymmetric key, which can either be a private or public key. The existing java.security.PublicKey and java.security.PrivateKey classes have been retrofitted to be subinterfaces of AsymmetricKey.

The AsymmetricKey interface provides a default implementation of the getParams method which returns null.

All asymmetric key subclasses now have a getParams method. This has two primary benefits:
- Application code can retrieve parameters from a public or private key without using instanceof to first determine the subclass.
- Many asymmetric algorithm parameters can be represented using the existing NamedParameterSpec subclass. As future asymmetric algorithms are introduced, the AsymmetricKey interface will allow earlier versions of Java SE to more easily support new asymmetric algorithms that can represent their parameters as a NamedParameterSpec, thus avoiding the need to introduce new algorithm-specific AlgorithmParameterSpec APIs.
Issue: JDK-8318096
The jdk.crypto.ec module has been subsumed into java.base

The jdk.crypto.ec module is now deprecated with the intent to eventually remove it. All of the code in the jdk.crypto.ec module has been moved into the java.base module. This includes the SunEC security provider. The jdk.crypto.ec module still exists, but it is now empty.

This change will make it easier for users to deploy applications that depend on elliptic curve cryptographic algorithms.

Issue: JDK-8308398

PKI

New root CA certificates

Several new root CA certificates have been added to the cacerts keystore:
- Three eMudhra Technologies root CA certificates
  - emSign Root CA - G1 has the following distinguished name:
    CN=emSign Root CA - G1, O=eMudhra Technologies Limited, OU=emSign PKI, C=IN
  - emSign Root CA - G2 has the following distinguished name:
    CN=emSign Root CA - G2, O=eMudhra Technologies Limited, OU=emSign PKI, C=IN
  - emSign ECC Root CA - G3 has the following distinguished name:
    CN=emSign ECC Root CA - G3, O=eMudhra Technologies Limited, OU=emSign PKI, C=IN
  Issue: JDK-8319187
- Four DigiCert root CA certificates
  - DigiCert TLS RSA4096 Root G5 has the following distinguished name:
    CN=DigiCert TLS RSA4096 Root G5, O="DigiCert, Inc.", C=US
  - DigiCert TLS ECC P384 Root G5 has the following distinguished name:
    CN=DigiCert TLS ECC P384 Root G5, O="DigiCert, Inc.", C=US
  - DigiCert CS RSA4096 Root G5 has the following distinguished name:
    CN=DigiCert CS RSA4096 Root G5, O="DigiCert, Inc.", C=US
  - DigiCert CS ECC P384 Root G5 has the following distinguished name:
    CN=DigiCert CS ECC P384 Root G5, O="DigiCert, Inc.", C=US
  Issue: JDK-8318759
- Let’s Encrypt ISRG Root X2 has the following distinguished name:
  CN=ISRG Root X2, O=Internet Security Research Group, C=US
  
  Issue: JDK-8317374
- Telia Root CA v2 has the following distinguished name:
  CN=Telia Root CA v2, O=Telia Finland Oyj, C=FI
  
  Issue: JDK-8317373
- Certigna Root CA has the following distinguished name:
  CN=Certigna Root CA, OU=0002 48146308100036, O=Dhimyotis, C=FR
  
  Issue: JDK-8314960

Each of these root certificates have also been added to the cacerts keystore in Oracle’s JDK 21.0.2, 17.0.10, 11.0.22, 8u401, and 7u411 releases.

TLS

Additional system properties to control maximum length of client and server certificate chains

Additional system properties named jdk.tls.client.maxInboundCertificateChainLength and jdk.tls.server.maxInboundCertificateChainLength have been added to allow users to control the maximum length of TLS server and client certificate chains. These properties provide flexibility by having separate properties for client and server configurations.

On the client side, a user would set jdk.tls.client.maxInboundCertificateChainLength to an integer value if they want to control the maximum size of a server’s certificate chain, for example:
```
$ java -Djdk.tls.client.maxInboundCertificateChainLength=7 ... <rest of command line>
```
On the server side, a user would set jdk.tls.server.maxInboundCertificateChainLength to an integer value if they want to control the maximum size of a client’s certificate chain, for example:
```
$ java -Djdk.tls.server.maxInboundCertificateChainLength=5 ... <rest of command line>
```
These properties, if set, override the existing jdk.tls.maxCertificateChainLength system property. If properties are not set, a default of 10 is used for server certificate chains, and 8 for client certificate chains.

Issue: JDK-8311596

XML Signature

Support for SHA-3 based RSA signature algorithms

The JDK XML Signature implementation now supports XML signatures signed with RSA signature algorithms with SHA-3 digests.

Four new standard SignatureMethod URIs have also been added:
- SignatureMethod.SHA3_224_RSA_MGF1: the RSA signature algorithm with SHA3-224 and MGF1.
- SignatureMethod.SHA3_256_RSA_MGF1: the RSA signature algorithm with SHA3-256 and MGF1.
- SignatureMethod.SHA3_384_RSA_MGF1: the RSA signature algorithm with SHA3-384 and MGF1.
- SignatureMethod.SHA3_512_RSA_MGF1: the RSA signature algorithm with SHA3-512 and MGF1.
Issue: JDK-8319124

Tools

keytool and jarsigner support for the HSS/LMS signature algorithm

In JDK 21, we added JCE support for the HSS/LMS signature algorithm (see my JDK 21 blog for more details). In this release, we have extended that functionality by also adding HSS/LMS support to the jarsigner and keytool utilities.

jarsigner now supports signing and verifying JAR files with the HSS/LMS algorithm. keytool now supports generating HSS/LMS public keypairs.

Note that the JDK only supports HSS/LMS signature verification, so in order to sign JAR files with HSS/LMS, you will need to use a 3rd party provider that supports signing. Similarly, in order to generate key pairs you will also need to use a 3rd party provider that supports generation of HSS/LMS keypairs.

An example of generating an HSS/LMS keypair with keytool is as follows:
```
$ keytool -genkeypair -alias Duke -dname CN="Duke" -keystore <keystore> -keyalg HSS/LMS \
  -groupname LMS_SHA256_M24_H5,LMOTS_SHA256_N24_W1,LMS_SHA256_M24_H5,LMOTS_SHA256_N24_W1
```
This will generate an HSS/LMS keypair with the specified group names. You may also need to specify additional options to specify the third party JCE provider that supports HSS/LMS keypair generation.

An example of signing a JAR with HSS/LMS with jarsigner is as follows:
```
$ jarsigner -keystore <keystore> -sigalg HSS/LMS <jarfile> Duke
```
This will sign a JAR file with the HSS/LMS signature algorithm using the private key stored in the specified keystore with an alias name of “Duke”. You may also need to specify additional options to specify the third party JCE provider that supports HSS/LMS signing. Also, note that it isn’t necessary to specify the -sigalg option as it will by default be determined based on the private key’s algorithm.

Issue: JDK-8302233

New security category for the java -XshowSettings option

The java -XshowSettings option can be used to print useful information about the current JDK configuration, such as system properties, VM settings, and more. In JDK 22, this option has been enhanced to show details about security related settings. The syntax of the new option is as follows:

-XshowSetttings:security will show all security settings.
-XshowSetttings:security:properties will show the values of security properties.
-XshowSetttings:security:providers will show the installed security providers and their supported algorithms.
-XshowSetttings:security:tls will show the enabled TLS protocols and cipher suites.

Here are sample runs showing each of these options:

$ java -XshowSettings:security:properties
Security properties:
    crypto.policy=unlimited
    http.auth.digest.disabledAlgorithms=MD5, SHA-1
    jceks.key.serialFilter=
        java.base/java.lang.Enum;
        java.base/java.security.KeyRep;
        java.base/java.security.KeyRep$Type;
        java.base/javax.crypto.spec.SecretKeySpec;
        !*
    jdk.certpath.disabledAlgorithms=
        MD2,
        MD5,
        SHA1 jdkCA & usage TLSServer,
        RSA keySize < 1024,
        DSA keySize < 1024,
        EC keySize < 224,
        SHA1 usage SignedJAR & denyAfter 2019-01-01
    jdk.io.permissionsUseCanonicalPath=false
    jdk.jar.disabledAlgorithms=
        MD2,
        MD5,
        RSA keySize < 1024,
        DSA keySize < 1024,
        SHA1 denyAfter 2019-01-01
    jdk.sasl.disabledMechanisms=
    jdk.security.caDistrustPolicies=SYMANTEC_TLS
    jdk.security.legacyAlgorithms=
        SHA1,
        RSA keySize < 2048,
        DSA keySize < 2048,
        DES,
        DESede,
        MD5,
        RC2,
        ARCFOUR
    jdk.tls.alpnCharset=ISO_8859_1
    jdk.tls.disabledAlgorithms=
        SSLv3,
        TLSv1,
        TLSv1.1,
        DTLSv1.0,
        RC4,
        DES,
        MD5withRSA,
        DH keySize < 1024,
        EC keySize < 224,
        3DES_EDE_CBC,
        anon,
        NULL,
        ECDH
<remaining output snipped>

    $ java -XshowSettings:security:providers
    Security provider static configuration: (in order of preference)
        ----------------------------------------
        Provider name: SUN
        Provider information: SUN (DSA key/parameter generation; DSA signing;
            SHA-1, MD5 digests; SecureRandom; X.509 certificates; PKCS12, JKS &
            DKS keystores; PKIX CertPathValidator; PKIX CertPathBuilder; LDAP,
            Collection CertStores, JavaPolicy Policy; JavaLoginConfig
            Configuration)
        Provider services: (type : algorithm)
            AlgorithmParameterGenerator.DSA
              aliases: [OID.1.2.840.10040.4.1, 1.3.14.3.2.12, 1.2.840.10040.4.1]
            AlgorithmParameters.DSA
              aliases: [OID.1.2.840.10040.4.1, 1.3.14.3.2.12, 1.2.840.10040.4.1]
            CertPathBuilder.PKIX
            CertPathValidator.PKIX
            CertStore.Collection
            CertStore.com.sun.security.IndexedCollection
            CertificateFactory.X.509
              aliases: [X509]
            Configuration.JavaLoginConfig
            KeyFactory.DSA
              aliases: [1.3.14.3.2.12, 1.2.840.10040.4.1, OID.1.2.840.10040.4.1]
            KeyFactory.HSS/LMS
              aliases: [OID.1.2.840.113549.1.9.16.3.17,
                1.2.840.113549.1.9.16.3.17]
            KeyPairGenerator.DSA
              aliases: [1.2.840.10040.4.1, OID.1.2.840.10040.4.1, 1.3.14.3.2.12]
            KeyStore.CaseExactJKS
            KeyStore.DKS
            KeyStore.JKS
            KeyStore.PKCS12
            MessageDigest.MD2
              aliases: [OID.1.2.840.113549.2.2, 1.2.840.113549.2.2]
            MessageDigest.MD5 
              aliases: [OID.1.2.840.113549.2.5, 1.2.840.113549.2.5]
            MessageDigest.SHA-1
              aliases: [SHA1, SHA, 1.3.14.3.2.26, OID.1.3.14.3.2.26]
            MessageDigest.SHA-224
              aliases: [OID.2.16.840.1.101.3.4.2.4, SHA224,
                2.16.840.1.101.3.4.2.4]
            MessageDigest.SHA-256
              aliases: [SHA256, OID.2.16.840.1.101.3.4.2.1,
                2.16.840.1.101.3.4.2.1]
            MessageDigest.SHA-384
              aliases: [OID.2.16.840.1.101.3.4.2.2, SHA384,
                2.16.840.1.101.3.4.2.2]
            MessageDigest.SHA-512
              aliases: [OID.2.16.840.1.101.3.4.2.3, 2.16.840.1.101.3.4.2.3,
                SHA512]
            MessageDigest.SHA-512/224
              aliases: [SHA512/224, OID.2.16.840.1.101.3.4.2.5,
                2.16.840.1.101.3.4.2.5]
            MessageDigest.SHA-512/256
              aliases: [SHA512/256, OID.2.16.840.1.101.3.4.2.6,
                2.16.840.1.101.3.4.2.6]
            MessageDigest.SHA3-224
              aliases: [OID.2.16.840.1.101.3.4.2.7, 2.16.840.1.101.3.4.2.7]
            MessageDigest.SHA3-256
              aliases: [OID.2.16.840.1.101.3.4.2.8, 2.16.840.1.101.3.4.2.8]
            MessageDigest.SHA3-384
              aliases: [OID.2.16.840.1.101.3.4.2.9, 2.16.840.1.101.3.4.2.9]
            MessageDigest.SHA3-512
              aliases: [2.16.840.1.101.3.4.2.10, OID.2.16.840.1.101.3.4.2.10]
            SecureRandom.DRBG
            SecureRandom.NativePRNG
            SecureRandom.NativePRNGBlocking
            SecureRandom.NativePRNGNonBlocking
            SecureRandom.SHA1PRNG
            Signature.HSS/LMS
              aliases: [1.2.840.113549.1.9.16.3.17,
                OID.1.2.840.113549.1.9.16.3.17]
            Signature.NONEwithDSA
              aliases: [RawDSA]
            Signature.NONEwithDSAinP1363Format
            Signature.SHA1withDSA
              aliases: [DSS, 1.3.14.3.2.13, OID.1.2.840.10040.4.3, SHA1/DSA, DSA,
                SHA-1/DSA, SHAwithDSA, DSAWithSHA1, SHA/DSA, 1.2.840.10040.4.3,
                1.3.14.3.2.27]
            Signature.SHA1withDSAinP1363Format
            Signature.SHA224withDSA
              aliases: [2.16.840.1.101.3.4.3.1, OID.2.16.840.1.101.3.4.3.1]
            Signature.SHA224withDSAinP1363Format
            Signature.SHA256withDSA
              aliases: [2.16.840.1.101.3.4.3.2, OID.2.16.840.1.101.3.4.3.2]
            Signature.SHA256withDSAinP1363Format
            Signature.SHA3-224withDSA
              aliases: [2.16.840.1.101.3.4.3.5, OID.2.16.840.1.101.3.4.3.5]
            Signature.SHA3-224withDSAinP1363Format
            Signature.SHA3-256withDSA
              aliases: [2.16.840.1.101.3.4.3.6, OID.2.16.840.1.101.3.4.3.6]
            Signature.SHA3-256withDSAinP1363Format
            Signature.SHA3-384withDSA
              aliases: [2.16.840.1.101.3.4.3.7, OID.2.16.840.1.101.3.4.3.7]
            Signature.SHA3-384withDSAinP1363Format
            Signature.SHA3-512withDSA
              aliases: [2.16.840.1.101.3.4.3.8, OID.2.16.840.1.101.3.4.3.8]
            Signature.SHA3-512withDSAinP1363Format
            Signature.SHA384withDSA
              aliases: [2.16.840.1.101.3.4.3.3, OID.2.16.840.1.101.3.4.3.3]
            Signature.SHA384withDSAinP1363Format
            Signature.SHA512withDSA
              aliases: [2.16.840.1.101.3.4.3.4, OID.2.16.840.1.101.3.4.3.4]
            Signature.SHA512withDSAinP1363Format
    <remaining output snipped>

---
---
    $ java -XshowSettings:security:tls
    Security TLS configuration (SunJSSE provider):
        Enabled Protocols:
            TLSv1.3
            TLSv1.2

        Enabled Cipher Suites:
            TLS_AES_256_GCM_SHA384
            TLS_AES_128_GCM_SHA256
            TLS_CHACHA20_POLY1305_SHA256
            TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
            TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
            TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
            TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
            TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
            TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
            TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
            TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
            TLS_DHE_DSS_WITH_AES_256_GCM_SHA384
            TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
            TLS_DHE_DSS_WITH_AES_128_GCM_SHA256
            TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
            TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
            TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
            TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
            TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
            TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
            TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
            TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
            TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
            TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
            TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
            TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
            TLS_DHE_RSA_WITH_AES_256_CBC_SHA
            TLS_DHE_DSS_WITH_AES_256_CBC_SHA
            TLS_DHE_RSA_WITH_AES_128_CBC_SHA
            TLS_DHE_DSS_WITH_AES_128_CBC_SHA
            TLS_RSA_WITH_AES_256_GCM_SHA384
            TLS_RSA_WITH_AES_128_GCM_SHA256
            TLS_RSA_WITH_AES_256_CBC_SHA256
            TLS_RSA_WITH_AES_128_CBC_SHA256
            TLS_RSA_WITH_AES_256_CBC_SHA
            TLS_RSA_WITH_AES_128_CBC_SHA
            TLS_EMPTY_RENEGOTIATION_INFO_SCSV

--- 

Issue: [JDK-8281658](https://bugs.openjdk.org/browse/JDK-8281658)

JDK 21 Security Enhancements

2023-09-22T00:00:00+00:00

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.

Crypto
PKI
TLS
XML Signature
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

JDK 20 Security Enhancements

2023-03-22T00:00:00+00:00

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

Highlights of this release include further improvements that strengthen the default security of the Java Platform, improved crypto performance, and new JFR events for security monitoring.

One other important JDK 20 feature that is related to security but not part of the security libraries area is the introduction of new system and security properties to control what object factory classes are allowed to reconstruct Java objects from JNDI/LDAP and JNDI/RMI contexts. See the release note for more details on these new properties.

General
Crypto
TLS
Tools

General

New InvalidParameterException constructors that take cause as a parameter

New constructors have been added to the InvalidParameterException API that take a cause (Throwable) as a parameter. This provides a more convenient option than having to separately call the initCause method.

For example, you can now throw an InvalidParameterException as:
```
    throw new InvalidParameterException(new NullPointerException())
```
or:
```
    throw new InvalidParameterException("parameter is null", new NullPointerException())
```
Issue: JDK-8296226
New service attributes added to the Standard Algorithm Names specification

Four additional service attributes have been added to the Service Attributes section of the Java Security Standard Algorithm Names specification. The attributes are SupportedKeyClasses, SupportedKeyFormats, SupportedModes, and SupportedPaddings. These attributes were previously defined and used in the JDK security providers, but had not been defined as standard attributes until now.

Issue: JDK-8297161
An error is now thrown if the java.security file fails to load

An InternalError is now thrown at runtime if a security property is retrieved but the java.security file does not exist or fails to load. Prior to this change, if there was a problem loading the java.security file, a subset of critical properties with hard-coded defaults was used.

If this issue occurs, you will see an exception stack trace like the following:
```
    Exception in thread "main" java.lang.InternalError: Error loading java.security file
    	at java.base/java.security.Security.initialize(Security.java:105)
    	at java.base/java.security.Security.lambda$static$0(Security.java:84)
    	at java.base/java.security.AccessController.doPrivileged(AccessController.java:319)
    	at java.base/java.security.Security.<clinit>(Security.java:83)
            ...
```
Issue: JDK-8155246

Crypto

Crypto performance related improvements

Several performance related improvements have been made in the crypto area. Below are details on each of the more significant improvements and a pointer to the corresponding issue.
- ChaCha20 intrinsics for x86_64 and aarch64 platforms
  
  The SunJCE provider implementation of the ChaCha20 Cipher algorithm now provides an optimized intrinsic for x86_64 and aarch64 platforms, yielding a significant improvement in performance. These optimized routines are designed for x86_64 chipsets that support the AVX, AVX2 and/or AVX512 instruction sets, and aarch64 chips that support the Advanced SIMD instruction set. The intrinsics are enabled by default on the supported platforms, but can be disabled by providing the -XX:-UseChaCha20Intrinsics command-line option to Java. Flags that control intrinsics require the option -XX:+UnlockDiagnosticVMOptions.
  
  Issue: JDK-8247645
- Poly1305 intrinsics for ByteBuffers
  
  The x86_64 intrinsic for the SunJCE provider implementation of Poly1305 (used as the authenticator for the ChaCha20 Cipher algorithm) has been enhanced to also apply to ByteBuffers. The intrinsic is now enabled for the CipherSpi.engineUpdate(byte[], ...) and CipherSpi.engineUpdate(ByteBuffer, ...) methods.
  
  Issue: JDK-8297379
- Improved MD5 intrinsics for x86_64 platforms
  
  The performance of the MD5 MessageDigest intrinsic for x86_64 platforms has been significantly improved.
  
  Issue: JDK-8296548
- Improved EC point multiplication for secp256r1 curve
  
  The performance of the elliptic curve point multiplication for the secp256r1 curve has been significantly improved by using pre-computed tables and more efficient algorithms. This performance improvement applies to the SunEC security provider.
  
  Issue: JDK-8295011
- Improved ECC math operations
  
  Improved BigInteger and curve point operations result in a modest performance improvement for elliptic curve calculations. This performance improvement applies to the SunEC security provider.
  
  Issue: JDK-8294997

TLS

DTLS 1.0 is now disabled by default

The DTLS 1.0 protocol has been disabled by default, improving out of the box security. This protocol has various weaknesses and is no longer recommended. See RFC 8996 for more information.

Applications should be using the more secure DTLS 1.2 protocol, which is supported by the JDK. However, if you encounter issues and need to get your application working, you can (at your own risk), re-enable DTLS 1.0 by removing “DTLSv1.0” from the jdk.tls.disabledAlgorithms security property in the java.security configuration file.

Issue: JDK-8256660
ECDH cipher suites disabled by default

The TLS_ECDH cipher suites have been added to the jdk.tls.disabledAlgorithms security property and are now disabled by default. These ciphers do not preserve forward secrecy and are rarely used in practice. Some TLS_ECDH cipher suites are already disabled because they use 3DES, RC4, anon, or NULL, which were previously disabled. This action disables all remaining ECDH cipher suites.

However, if you encounter issues and need to get your application working, you can (at your own risk), re-enable these cipher suites by removing “ECDH” from the jdk.tls.disabledAlgorithms security property in the java.security configuration file.

Issue: JDK-8279164
New APIs for customizing TLS and DTLS named groups

Two new APIs have been added which allow applications to customize and retrieve the prioritized list of named groups used to negotiate the key exchange mechanism in a TLS or DTLS connection: javax.net.ssl.SSLParameters::setNamedGroups and javax.net.ssl.SSLParameters::getNamedGroups.

An example of setting named groups is the following:
```
    SSLParameters params = new SSLParameters();
    params.setNamedGroups(new String[] { "x25519", "secp256r1" });
```
Issue: JDK-8281236

Tools

New JFR event for recording initial security properties

A new event for recording the initial values of security properties has been added to the Java Flight Recorder tool. This is useful for recording an initial snapshot of the security configuration. The event is named jdk.InitialSecurityProperty and is enabled by default. When used together with the jdk.SecurityPropertyModification event, JFR will record the initial and subsequent settings for all security properties, which can provide important details of the security environment used by the application.

Below is a sample screenshot of the jdk.InitialSecurityProperty event and some of the values captured for each of the security properties.

Issue: JDK-8292177
New JFR event for security provider usage

A new event has been added to the Java Flight Recorder tool for recording each time a security provider is accessed. This is useful for recording each cryptographic algorithm or service that an application uses, providing additional insight into the security of the application. The event is named jdk.SecurityProviderService and contains three fields for the type of service, the algorithm, and the provider name. This event is disabled by default but can be enabled via the JFR configuration files or standard JFR options.

Below is a sample screenshot of the jdk.SecurityProviderService event and some of the values captured for each algorithms requested.

Issue: JDK-8254711

JDK 19 Security Enhancements

2022-09-22T00:00:00+00:00

JDK 19 was released on September 20, 2022! 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, PKI, etc) which should make it easier to find out what has changed in each specific area. The JDK 19 release notes also contain further details on these and other enhancements.

Highlights of this release include further improvements that strengthen the default security of the Java Platform and improved TLS performance. There are also several other really useful enhancements such as adding KeyStore support for accessing local machine certificates on Windows and support for TLS channel binding tokens with HTTPS and Kerberos.

Crypto
PKI
TLS
Tools
Networking

Crypto

Default key sizes increased

The default sizes for keys generated by JDK implementations of KeyPairGenerator and KeyGenerator have been increased as follows:
- For the “RSA”, “RSASSA-PSS”, and “DH” algorithms, the default size has been increased from 2048 bits to 3072 bits
- For the “EC” algorithm, the default size has been increased from 256 bits to 384 bits
- For the “AES” algorithm, the default size has been increased from 128 bits to 256 bits (if permitted by crypto policy), otherwise the default falls back to 128 bits
Issue: JDK-8267319
SHA3 performance increased up to 2x

The JDK “SUN” provider SHA3 message digest algorithm performance has been increased up to 2x.

Issue: JDK-8275914
OAEPParameterSpec.DEFAULT is deprecated

The DEFAULT static field of the javax.crypto.spec.OAEPParameterSpec class has been deprecated. This constant uses default algorithms such as SHA-1 that have weakened. Applications should avoid using this constant and explicitly specify the parameters using the OAEPParameterSpec(String, String, AlgorithmParameterSpec, PSource) constructor.

Issue: JDK-8284553
PSSParameterSpec(int) and PSSParameterSpec.DEFAULT are deprecated

The PSSParameterSpec(int) constructor and DEFAULT static field have been deprecated. This constructor and constant uses SHA-1 as the default hash algorithm which has weakened and is no longer recommended. Applications should avoid using this constructor or constant and explicitly specify the parameters using the PSSParameterSpec(String, String, AlgorithmParameterSpec, int, int) constructor.

PKI

New Windows KeyStore types for accessing local machine certificates

Two additional KeyStore types have been added, “Windows-MY-LOCALMACHINE” and “Windows-ROOT-LOCALMACHINE”, which provide access to keys and certificates stored on the Windows Operating System that are available to all accounts.

The other Windows KeyStore types, “Windows-MY” and “Windows-ROOT” provide access to keys and certificates associated with the current user’s account only. To avoid confusion, new names for these types have also been introduced, “Windows-MY-CURRENTUSER” and “Windows-ROOT-CURRENTUSER” which map to “Windows-MY” and “Windows-ROOT”, respectively.

The new KeyStore types are documented in the SunMSCAPI Provider section of the JDK Providers Guide.

Issue: JDK-6782021
Enhanced support for OtherNames in X.509 certificates

The JDK implementation of the getSubjectAlternativeNames and the getIssuerAlternativeNames methods of the X509Certificate API have been enhanced to return more useful information for OtherName types. The returned list now has a 3rd and 4th entry which contain the OID (as a String) and the ASN.1 encoded value (as a String if it is a character string, otherwise a byte array). These additional values can help applications to more easily identify what type the OtherName is, and avoid additional parsing of the encoded value to determine the OID and value.

Issue: JDK-8277976

TLS

TLS performance related improvements

Several performance related improvements have been made which speedup and reduce the amount of memory used during a TLS handshake. See the following issues for more details:
3DES suites removed from default enabled TLS cipher suites

3DES cipher suites have been removed from the default enabled TLS cipher suites. Note that these cipher suites were already disabled since “3DES” is included in the jdk.tls.disabledAlgorithms security property and by default the suites will not be considered for a TLS connection handshake.

This change makes it much harder to enable 3DES cipher suites either accidentally or maliciously. Per RFC 7525, implementations SHOULD NOT negotiate cipher suites that use algorithms offering less than 128 bits of security. The strength of 3DES is 112 bits, which is less than 128 bits of security.

We don’t recommend re-enabling the suites, but the release note contains instructions for doing that, if necessary.

Issue: JDK-8163327
New APIs for customizing TLS and DTLS signature schemes

Two new APIs have been added which allow applications to customize and retrieve the prioritized list of signature schemes used when negotiating a TLS or DTLS connection: javax.net.ssl.SSLParameters::setSignatureSchemes and javax.net.ssl.SSLParameters::getSignatureSchemes.

Issue: JDK-8280494
RFC 6125 endpoint identification algorithm fully supported

RFC 6125 defines procedures for verifying identities in TLS certificates. The JDK implementation was mostly compliant except for one case which has now been corrected: the implementation will not attempt to match wildcard domains in TLS certificates where the wildcard character comprises a label other than the left-most label (ex: we won’t match “foo.*.example.net”).

If necessary, applications can workaround this restriction by implementing their own HostnameVerifier or TrustManager.

Issue: JDK-7192189
New SSLException constructors that take cause as a parameter

New constructors have been added to the SSLHandshakeException, SSLKeyException, SSLPeerUnverifiedException, and SSLProtocolException APIs that take a cause (Throwable) as a parameter. This provides a more convenient option than having to separately call the initCause method.

Issue: JDK-8282723

Tools

Default digest and signature algorithms strengthened for jarsigner

The default digest and signature algorithms used by jarsigner when signing JAR files have been strengthened.

The default digest algorithm has been changed from SHA-256 to SHA-384.

The default signature algorithm for RSA and RSASSA-PSS keys greater than or equal to 624 bits has been changed from SHA256withRSA to SHA384withRSA, except for keys greater than 7680 bits where SHA512withRSA is used. Similarly, the default signature algorithm for EC keys has been changed from SHA256withECDSA to SHA384withECDSA, except for keys greater than or equal to 512 bits where SHA512withECDSA is used.

Here is the complete table of signature algorithm defaults from the jarsigner tool specification:

Issue: JDK-8267319
RC2 and RC4 added to jdk.security.legacyAlgorithms security property

“RC2” and “ARCFOUR” (RC4) have been added to the jdk.security.legacyAlgorithms security property in the java.security configuration file. Keys using these algorithms are no longer recommended.

keytool will now emit warnings if keys of this algorithm are used in any commands associated with secret key entries of a keystore. Here is an example:
```
$ keytool -genseckey -keyalg RC2 -keysize 128 -keystore keystore
Enter keystore password:  
Generated 128-bit RC2 secret key

Warning:
The generated secret key uses the RC2 algorithm which is considered a security risk.
```
Issue: JDK-8286090
DES, DESede, and MD5 added to jdk.security.legacyAlgorithms security property

“DES”, “DESede” (3DES) and “MD5” have been added to the jdk.security.legacyAlgorithms security property in the java.security configuration file. Keys using these algorithms are no longer recommended.

keytool will now emit warnings if keys or certificates use any of these algorithms. Here is an example:
```
$ keytool -genseckey -keyalg DES -keystore keystore
Enter keystore password:
Generated 56-bit DES secret key

Warning:
The generated secret key uses the DES algorithm which is considered a security risk.
```
Issue: JDK-8255552
New jarsigner -providerPath option

A new -providerPath option has been added to the jarsigner tool. This option allows the user to specify the class path of an alternate keystore implementation and can be used in conjunction with the -providerClass option. Here is an example:
```
$ jarsigner -keystore keystore -storetype MYKS -providerPath mods/test.myks \
  -providerClass org.test.MyProvider signed.jar mykey
Enter keystore password:  
jar signed.
```
Issue: JDK-8281175
New Kerberos ktab options for providing salt values

Two new options have been added to the Windows ktab tool to allow users to provide alternate salt values when using the -a option to generate keys. These salt values are used instead of using the default salt which is a concatenation of the realm and username. The -s <salt> option allows the user to provide their own salt, and the -f option will fetch the salt from the KDC. These options are useful if the KDC uses a different salt value, or the user simply wants to use a different salt value.

Issue: JDK-8279064

Networking

Two other important JDK 19 security related enhancements in the networking area that provide significant security benefits and are worth mentioning are:

HTTPS Channel Binding support for Java GSS/Kerberos

This enhancement adds support for TLS channel binding for Negotiate/Kerberos authentication over HTTPS through javax.net.HttpsURLConnection.

A new system property named jdk.https.negotiate.cbt has been introduced to allow users to configure how channel binding tokens are used by HttpsURLConnection.

See the release note for more details.

Issue: JDK-8279842
Disable http DIGEST mechanism with MD5 and SHA-1 by default

The MD5 and SHA-1 HTTP DIGEST mechanisms have been disabled by default. These algorithms have weaknesses and are no longer recommended.

A new system property named http.auth.digest.reEnabledAlgorithms has been introduced which can be used to re-enable these mechanisms, if necessary, and at your own risk.

Issue: JDK-8281561

JDK 18 Security Enhancements

2022-03-23T00:00:00+00:00

JDK 18 was released on March 22, 2022! 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, PKI, etc) which should make it easier to find out what has changed in each specific area. The JDK 18 release notes also contain further details on these and other enhancements.

Highlights of this release include further improvements that strengthen the default security of the Java Platform, support for new crypto algorithms, and new alternative JAAS APIs that do not depend on deprecated Security Manager APIs. See below for more details on these and other enhancements.

Several performance improvements have also been made in the crypto, TLS and JAAS/Kerberos components. See JDK-8270317, JDK-8276660, JDK-8273299, JDK-8268427, JDK-8267125, and JDK-8273026 for more details.

Also, one other important JDK 18 feature that is not part of the security libraries area but is definitely worth mentioning is:

JEP 421: Deprecate Finalization for Removal

This JEP deprecates finalization for removal in a future release. Finalizers can cause various security issues and require special care when using. More robust replacements and techniques are already available and are listed in the JEP.

Crypto
PKI
Kerberos
Security Manager
Tools
Signed JARs

Crypto

PKCS#11 support for AES Key Wrap and AES Key Wrap With Padding (KWP) modes

The SunPKCS11 provider now supports the AES Key Wrap and AES Key Wrap With Padding (KWP) cipher modes if the underlying PKCS11 native library supports them.

These standard modes are designed to protect cryptographic keys and are defined in NIST SP 800-38F.

This enhancement builds on the enhancement in JDK 17 which added and improved support for these modes to the SunJCE provider.

Use these modes in your Java application with the javax.crypto.Cipher API with the algorithm transformations "AES/KW/NoPadding", "AES/KW/PKCS5Padding" or "AES/KWP/NoPadding".

The JCE algorithm mappings to the PKCS11 mechanisms are as follows:
```
AES/KW/NoPadding Cipher => CKM_AES_KEY_WRAP mechanism
AES/KW/PKCS5Padding Cipher => CKM_AES_KEY_WRAP_PAD mechanism
AES/KWP/NoPadding Cipher => CKM_AES_KEY_WRAP_KWP mechanism
```
See the PKCS#11 Reference Guide for more information about PKCS#11 support in the JDK.

Issue: JDK-8264849
New KeyStore::getAttributes() API

A new getAttributes(String alias) method has been added to the java.security.KeyStore API. This method returns a set of attributes associated with a KeyStore alias, or entry. Before this change, the attributes of an entry could only be obtained by calling the getAttributes method of a KeyStore.Entry. If the entry was a PrivateKeyEntry, the application needed to provide the proper password to unlock the entry, even if the attributes associated with the entry were not protected. This new API avoids that issue.

A corresponding engineGetAttributes(String alias) method has also been added to the KeyStoreSpi class for providers to implement. If not overridden by a provider, the KeyStore::getAttributes method will return an empty set. Third party providers should add support for this API when adding support for JDK 18.

See the Key Management section of the JCA Reference Guide for more information about KeyStores.

Issue: JDK-8225181
A passwordless PKCS12 keystore is now easier to create

Passwordless keystores (a keystore with no password required to unlock it) are useful when the keystore is stored in a secure location and is only intended to store non-sensitive information, such as public X.509 certificates. With a passwordless PKCS12 keystore, certificates are not encrypted and there is no Mac applied as an integrity check is not necessary.

Prior to this change, creating a passwordless PKCS12 keystore was difficult, and required setting various security properties. Now, a passwordless PKCS12 keystore can be created by simply specifying a null password to the KeyStore::store(outStream, password) API. The keystore can then be loaded with a null (or any) password with the KeyStore::load() API.

Issue: JDK-8231107

PKI

The cacerts keystore is now in PKCS12 format

The cacerts keystore, which holds the root CA certificates bundled with the JDK, has been converted from the non-standard JKS format to the standard PKCS12 format.

This change has several benefits. It moves cacerts away from the obsolete JKS format. And it transitions cacerts to the PKCS12 format which supports a passwordless keystore – this means that you no longer have to specify (or change) the default password “changeit”, unless you intend to store sensitive material within it.

See the Crypto section for more details on passwordless keystores.

Issue: JDK-8275252
OCSP responses support for RSASSA-PSS

OCSP responses signed with the RSASSA-PSS signature algorithm are now supported.

Issue: JDK-8274471
Removal of Google’s GlobalSign Root Certificate

The “GlobalSign” Root CA certificate is now expired and has been removed from the cacerts keystore. This root certificate is owned by Google and has the following distinguished name:

CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R2

This root certificate has also been removed from the cacerts keystore in Oracle’s JDK 17.0.2, 11.0.14, 8u321, and 7u331 releases.

Issue: JDK-8225083
Removal of IdenTrust Root Certificate

The “DST Root CA X3” Root CA certificate is now expired and has been removed from the cacerts keystore. This root certificate is owned by IdenTrust and has the following distinguished name:

CN=DST Root CA X3, O=Digital Signature Trust Co.

This root certificate has also been removed from the cacerts keystore in Oracle’s JDK 17.0.1, 11.0.13, 8u311, and 7u321 releases.

Issue: JDK-8225082

Kerberos

Weak encryption types (DES, 3DES, RC4) have been removed from the default list of Kerberos encryption types

The DES, 3DES, and RC4 encryption types have been removed from the default list of Kerberos encryption types. Note that these weak encryption types were already disabled by default prior to this release, and would not be used unless the allow_weak_crypto property was set to true in the krb5.conf file, but once that was done, any of the weak encryption types could then be used. With this change, in order to use them, you have to also specifically add the weak algorithm(s) that you want to use to the permitted_enctypes property (or alternatively, the default_tkt_enctypes or default_tgt_enctypes properties) in the krb5.conf file.

Re-enabling these weak encryption types is not recommended and should be done at your own risk.

See the Kerberos 5 GSS-API Mechanism Guide for more information on the supported krb5.conf properties.

Issue: JDK-8273670
The krb5.conf default_checksum and safe_checksum_type properties are no longer supported

The default_checksum and safe_checksum_type properties in the krb5.conf configuration file are no longer supported.

The checksum type used in TGS-REQ requests is derived from the encryption type and therefore the default_checksum property is no longer necessary.

The safe_checksum_type property specifies the type of checksum to use for KRB-SAFE requests and was never used directly by the JDK.

Issue: JDK-8274656

Security Manager

New APIs for Subject based authorization that do not depend on the Security Manager

In JDK 17, as specified in JEP 411, the Security Manager was deprecated for removal. As part of that change, several Security Manager APIs were deprecated for removal, such as AccessControlContext. The JAAS Subject::doAs() and Subject::getSubject() APIs depend on Security Manager related APIs, even though they do not require a Security Manager to be installed to use them.

These APIs are important for developers that want to write secure applications that authorize subjects and perform sensitive operations based on their credentials. Thus, JEP 411 outlined plans to provide replacement JAAS APIs that did not have dependencies on Security Manager APIs.

These replacement JAAS APIs have now been added to JDK 18. Subject::callAs() is a replacement for Subject::doAs(), and Subject::current() is a replacement for Subject::getSubject(). The usage of these new replacement APIs is similar and simpler than the previous APIs. For example, here is an example of code using the old APIs:
```
Subject s1 = new Subject();
Subject.doAs(s1,
    (PrivilegedExceptionAction<Void>)() -> {
        AccessControlContext acc = 
            AccessController.getContext();
    Subject s2 = Subject.getSubject(acc);
    return null;
});
```
using the new APIs, this code now looks like:
```
Subject s1 = new Subject();
Subject.callAs(s1, () -> {
    Subject s2 = Subject.current();
    return null;
});
```
With the addition of these new APIs, the Subject::doAs() methods have been deprecated for removal. Subject::getSubject() was already deprecated for removal in JDK 17.

See the JAAS Reference Guide for more information about JAAS.

Issue: JDK-8267108
New default for the java.security.manager system property

JEP 411 also announced that we would be changing the default value of the java.security.manager system property from allow to disallow in JDK 18. This change improves the performance of applications that do not run with a Security Manager.

The implication of this change means that applications that dynamically install a Security Manager (by calling System::setSecurityManager()) must now explicitly set the java.security.manager system property to allow on the command-line, for example as follows:
```
java -Djava.security.manager=allow MyApp
```
Issue: JDK-8270380

Tools

New keytool and jarsigner --version option

A new option named --version has been to the keytool and jarsigner tools. If specified, it will print the JDK version that the tool is using. Here is an example:
```
$ keytool --version
keytool 18
```
See the keytool and jarsigner tool specifications for more details about these tools.

Issue: JDK-8272163

Signed JARs

SHA-1 JARs are disabled by default

JARs signed with SHA-1 algorithms are now disabled by default. SHA-1 is a digest algorithm that has become increasingly weak and should no longer be used for digital signatures.

With this change, maintaining compatibility with previously signed JARs was an important consideration, so the restrictions do not apply to SHA-1 JARs that have been timestamped before 2019-01-01. However, this compatibility constraint is subject to change so it is in your best interest to re-sign any SHA-1 JARs with stronger algorithms.

If a JAR is signed with SHA-1 and does not meet the compatibility constraints above, then it will be restricted and treated as if it were unsigned. This applies to the algorithms used to digest and sign the JAR, as well as the signer’s certificate chain and any revocation data such as CRLs or signed OCSP responses. If the JAR is timestamped, it also applies to the timestamp digest and the TSA’s certificate chain and any revocation data.

This change is also planned to be backported to Oracle’s update releases later in the year – check the Java Crypto Roadmap for the latest status and targeted dates.

The jarsigner tool has also been enhanced to more accurately detect and warn you if your JAR is affected by these restrictions. We encourage you to use this tool to see if your JARs are affected. Here is an example of jarsigner when used to verify a SHA-1 JAR that violates the restrictions (note that SHA-1 as the Digest algorithm is flagged as “(disabled)” and a warning is emitted by jarsigner):
```
$ jarsigner -verify -verbose signed.jar 

          57 Tue Mar 22 14:25:08 EDT 2022 META-INF/MANIFEST.MF
         249 Tue Mar 22 14:25:08 EDT 2022 META-INF/SIGNER.SF
        2005 Tue Mar 22 14:25:08 EDT 2022 META-INF/SIGNER.RSA
 m  ?      1 Tue Mar 22 14:24:16 EDT 2022 A

  s = signature was verified 
  m = entry is listed in manifest
  k = at least one certificate was found in keystore
  ? = unsigned entry

- Signed by "CN=signer"
    Digest algorithm: SHA-1 (disabled)
    Signature algorithm: SHA256withRSA, 2048-bit key

WARNING: The jar will be treated as unsigned, because it is signed with a weak algorithm that is now disabled by the security property:

  jdk.jar.disabledAlgorithms=MD2, MD5, RSA keySize < 1024, DSA keySize < 1024, SHA1 denyAfter 2019-01-01
```
Issue: JDK-8269039

JDK 17 Security Enhancements

2021-09-14T00:00:00+00:00

JDK 17 was released on September 14, 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 17 release notes also contain further details on these and other enhancements.

Probably the most significant security related change in JDK 17 is JEP 411: Deprecate the Security Manager for Removal. JDK 17 begins that process by deprecating a number of Security Manager APIs and adding run time warnings for applications using the Security Manager. See the Security Manager section below for further details.

Also, three other important JDK 17 features that are not part of the security libraries area but have beneficial security benefits include:

JEP 403: Strongly Encapsulate JDK Internals

With JEP 403, JDK 17 continues to strengthen the strong encapsulation of JDK internals by disabling the command line switch to enable relaxed strong encapsulation. Instead you must use the --add-opens or --add-exports command-line options to individually open/export packages if necessary.
JEP 409: Sealed Classes

Sealed classes allow you to restrict what classes are allowed to extend or implement a specific class. This has obvious security benefits as it can be used to prevent unauthorized implementations of the class.
JEP 415: Context-Specific Deserialization Filters

Deserialization filters were introduced in JDK 9 and allow applications and libraries to validate incoming serialized streams before deserializing them. This can be done statically via security properties or dynamically via a new ObjectInputFilter API that applies to the ObjectInputStream.

JEP 415 improves on this feature by introducing filter factories which can be used to apply different filters depending on the object stream.

Crypto
PKI
TLS
Kerberos
XML Signature
Security Manager

Crypto

Support KWP in addition to KW

The SunJCE provider now supports the AES Key Wrap With Padding (KWP) mode. Also, the AES Key Wrap mode (KW) has been enhanced to support encryption of keys (in addition to wrapping), and custom IVs and padding schemes.

These standard modes are designed to protect cryptographic keys and are defined in NIST SP 800-38F.

Use these modes in your Java application with the javax.crypto.Cipher API with the algorithm transformations "AES/KWP/NoPadding", "AES/KW/PKCS5Padding" or "AES/KW/NoPadding".

Alternatively, you can specify "AESWrap" as the Cipher algorithm which is equivalent to KW mode with NoPadding, or "AESWrapPad" which is equivalent to KWP mode with NoPadding.

Issue: JDK-8248268
JCE doesn’t provide any class to handle RSA private key in PKCS#1

The "RSA" implementation of KeyFactory can now generate private and public keys from a PKCS#1 encoding (in addition to PKCS#8).

Issue: JDK-8023980
Add ChaCha20 and Poly1305 support to SunPKCS11 provider

The SunPKCS11 provider now supports the ChaCha20 and Poly1305 stream ciphers, if the underlying PKCS#11 implementation also supports them.

Issue: JDK-8255410

PKI

Add support for RFC 8954: Online Certificate Status Protocol (OCSP) Nonce Extension

Support for the OCSP Nonce Extension has been added to the PKIX implementation. The Nonce extension can help prevent replay attacks where a previous good OCSPResponse for a certificate has not expired but the status of the certificate has changed (for example, it is now revoked) and the prior good OCSPResponse can be replayed.

For compatibility reasons, the extension is not enabled by default, but can be enabled by setting the jdk.security.certpath.ocspNonce system property to true. If not enabled, the default JDK implementation uses a time-based approach as specified by RFC 5019.

Issue: JDK-8256895
Java should support GET OCSP calls

The JDK PKIX implementation now uses HTTP GET (instead of POST) to submit OCSP requests if the request is less than 255 bytes. Using GET allows requests to be cached which can improve performance.

Issue: JDK-8179503
New HARICA root CA certificates added

Two new root CA certificates owned by HARICA have been added to the cacerts keystore:
1. HARICA Root CA 2015
  
  This root certificate has the following distinguished name:
  
  CN=Hellenic Academic and Research Institutions RootCA 2015, O=Hellenic Academic and Research Institutions Cert. Authority, L=Athens, C=GR
2. HARICA ECC Root CA 2015
  
  This root certificate has the following distinguished name:
  
  CN=Hellenic Academic and Research Institutions ECC RootCA 2015, O=Hellenic Academic and Research Institutions Cert. Authority, L=Athens, C=GR
These root certificates have also been added to the cacerts keystore in Oracle’s JDK 16.0.1, 11.0.11, 8u291, and 7u301 releases.

Issue: JDK-8256421

TLS

Configurable extensions with system properties

TLS interoperability issues can sometimes occur if an implementation does not properly handle TLS extensions that it does not support. To help workaround these issues, two new system properties have been introduced that allow you to customize the extensions that are not enabled (i.e. disabled) when establishing a TLS connection.

The system properties apply to the client (jdk.tls.client.disableExtensions) or the server (jdk.tls.server.disableExtensions). The value of the property is a comma separated list of standard TLS extension names. For example:

java -Djdk.tls.client.disabledExtensions="status_request,signature_algorithms_cert" ...

Issue: JDK-8217633

Kerberos

Deprecate 3DES and RC4 in Kerberos

3DES and RC4 Kerberos encryption types have now been disabled by default. Both 3DES and RC4 are weak encryption algorithms that should not be used. The Kerberos 3DES and RC4 encryption types are officially deprecated in RFC 8429.

By default the des3-hmac-sha1 and rc4-hmac encryption types are now disabled, but can be re-enabled, at your own risk, by setting the allow_weak_crypto property to true in the krb5.conf configuration file. However, note that will also re-enable other weak encryption types that are already disabled such as des-cbc-crc and des-cbc-md5. Alternatively, set the default_tkt_enctypes, default_tgs_enctypes, and permitted_enctypes properties to the encryption types that are allowed.

Issue: JDK-8139348

XML Signature

Add SignatureMethodParameterSpec subclass for RSASSA-PSS params

A new class named javax.xml.crypto.dsig.spec.RSAPSSParameterSpec has been added to the XML Signature API and can be used to specify parameters for the RSASSA-PSS signature algorithm. Also, a new String constant for the signature algorithm (RSA_PSS) has been defined.

The new API takes a java.security.spec.PSSParameterSpec as the input parameter.

Issue: JDK-8259575
Disable SHA-1 XML Signatures

XML Signatures that contain SHA-1 based digest or signature algorithms are now disabled by default. SHA-1 is a weak digest algorithm that is no longer recommended for digest and signature algorithms. Validation of XML signatures that violate this constraint will fail.

If necessary, and at their own risk, users can re-enable SHA-1 by modifying or overriding the jdk.xml.dsig.secureValidationPolicy security property defined in the java.security configuration file.

Issue: JDK-8259709
Enable XML Signature secure validation mode by default

The XML Signature secure validation mode has been enabled by default. Previously, applications had to explicitly enable this mode by setting the org.jcp.xml.dsig.secureValidation property to true with the javax.xml.crypto.XMLCryptoContext.setProperty() method, or by running the code with a SecurityManager enabled.

The secure validation mode provides additional protection against XML Signatures that contain potentially hostile content, use weak algorithms, or contain constructs that may cause denial-of-service. Currently, this mode enforces the following restrictions:
- Forbids the use of XSLT transforms
- Restricts the number of SignedInfo or Manifest Reference elements to 30 or less
- Restricts the number of Reference transforms to 5 or less
- Forbids the use of MD5 signature or MAC algorithms
- Forbids the use of SHA-1 signature algorithms
- Ensures that Reference IDs are unique to help prevent signature wrapping attacks
- Forbids Reference URIs of type http, https, or file
- Does not allow a RetrievalMethod element to reference another RetrievalMethod element
- Forbids RSA or DSA keys less than 1024 bits and EC keys less than 224 bits
For more information about this mode see the XML Signature Secure Validation Mode in the XML Signature API Overview and Tutorial.

Issue: JDK-8259801

Security Manager

Deprecate the Security Manager for Removal

In JDK 17, the Security Manager has been deprecated for removal. This includes the java.lang.SecurityManager API and several APIs related to the Security Manager – see the Deprecate APIs for removal section of the JEP for a full list of impacted APIs.

There are several reasons why the Security Manager is being deprecated, and these are covered in more detail in the Motivation section of the JEP.

Note that the Security Manager will still be fully supported in JDK 17 – however warnings will be emitted at run time if a Security Manager is enabled – this will help alert users and developers of the deprecation and prepare for the future removal.

JEP: https://openjdk.java.net/jeps/411

JDK 16 Security Enhancements

2021-03-18T00:00:00+00:00

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 15 Security Enhancements

2020-10-13T00:00:00+00:00

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 14 Security Enhancements

2020-03-19T00:00:00+00:00

JDK 14 has been released! As with my previous blogs for 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 14 Release Notes also contain details on these and other enhancements.

General
Crypto
TLS
XML Signature
Tools

General

The deprecated java.security.acl APIs have been removed

These APIs were initially deprecated in Java SE 9 and marked for removal in Java SE 10. These APIs have been considered legacy for a long time. Applications should use the java.security.Policy and related APIs instead.
New Amazon Root CAs have been added

Four new Amazon Root Certificate Authorities (CAs) have been added to the JDK cacerts keystore. The Distinguished Names of the CAs are:
- CN=Amazon Root CA 1, O=Amazon, C=US
- CN=Amazon Root CA 2, O=Amazon, C=US
- CN=Amazon Root CA 3, O=Amazon, C=US
- CN=Amazon Root CA 4, O=Amazon, C=US
New LuxTrust Root CA has been added

One new LuxTrust Root Certificate Authority (CA) has been added to the JDK cacerts keystore. The Distinguished Name of the CA is:
- CN=LuxTrust Global Root 2, O=LuxTrust S.A., C=LU

Crypto

Legacy elliptic curves have been deprecated and will be removed in a future release

The implementations of 47 named elliptic curves in the SunEC provider have been deprecated. These curves are not implemented using modern techniques and many of them are no longer recommended by standard groups. The implementations of these curves will be removed or replaced in a future release of the JDK.

See the Deprecated Legacy Curves section of the JDK Providers Doc for the complete list of affected curves.

Legacy elliptic curves have been disabled by default in TLS, CertPath, and Signed JARs

Related to the previous issue, these curves have also been disabled by default if used in TLS protocol exchanges, certification paths, or signed JARs. A new security property named jdk.disabled.namedCurves has been added to the java.security configuration file that contains the names of the disabled curves. Certificates or protocol exchanges using these curves will be blocked or negotiated to use other acceptable curves.

Below is the definition of the property in the java.security file:

#
# This property contains a list of disabled EC Named Curves that can be included
# in the jdk.[tls|certpath|jar].disabledAlgorithms properties.  To include this
# list in any of the disabledAlgorithms properties, add the property name as
# an entry.
jdk.disabled.namedCurves = 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 OracleUCrypto provider has been deprecated for removal

The OracleUCrypto provider is supported only on the Solaris platform and provides access to the algorithms in the native Solaris Ucrypto cryptographic library. It has been deprecated as part of JEP 362 (Deprecate the Solaris SPARC Ports). The provider will be removed from a future JDK release when the Solaris ports are officially removed.

TLS

Standard Names for Signature Schemes and Named Groups defined

Standard names have been defined for TLS signature schemes and named groups in the Standard Algorithm Names Specification. This improves compatibility by providing standard names for signature schemes and elliptic curves which can be specified by applications in various APIs and properties.

Below is a snapshot of the names from the Signature Schemes and Named Groups sections of the Java Security Standard Algorithm Names specification.
SSLv2Hello and SSLv3 have been removed from the default enabled TLS protocols

As a further strengthening measure, SSLv2Hello and SSLv3 have been removed from the default list of enabled TLS protocols. Note that SSLv3 had already been restricted by default as it is included in the jdk.tls.disabledAlgorithms security property in the system-wide java.security configuration file. With this change, SSLv3 is not enabled by default even if it is removed from the jdk.tls.disabledAlgorithms security property.

XML Signature

XML Signature implementation updated to Apache Santuario v2.1.4

The XML Signature implementation in the JDK has been updated to version 2.1.4 of Apache Santuario XML Security for Java, which it is based on.

With this update, one new system property has been added: com.sun.org.apache.xml.internal.security.parser.pool-size. This can be set to the pool size of the internal DocumentBuilder cache used to process XML Signatures. The default value is 20. Setting this property may improve performance depending on the application’s use case.

Tools

The default algorithms for keytool -keyalg have been removed

Key algorithm defaults are no longer supported and keytool now exits with an error if a specific algorithm is not specified using the -keyalg option when generating keys with the -genkeypair or -genseckey commands.

Here is an example output of running the command:
```
$ keytool -genkeypair 
Enter keystore password:  
keytool error: java.lang.Exception: The -keyalg option must be specified.
```

JDK 13 Security Enhancements

2019-08-05T00:00:00+00:00

JDK 13 has been released! As with my JDK 12 blog, I have gathered up a list of the most interesting and useful security enhancements in this release. And as before, I have 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 13 Release Notes also contains details on these and other enhancements.

Crypto
TLS
GSS-API and Kerberos
SASL
XML Signature
Tools

Crypto

Support for Microsoft Cryptography Next Generation (CNG) API

On Windows, the SunMSCAPI JCE provider has been enhanced to support CNG. The provider can now load RSA and EC keys in CNG format from Windows keystores. The provider also now supports elliptic curve Signature algorithms (SHA1withECDSA, SHA256withECDSA, etc.).

Issue: https://bugs.openjdk.java.net/browse/JDK-8026953

PKCS#11 version 2.40

The SunPKCS11 provider has been updated to PKCS#11 v2.40. This update adds support for additional PKCS#11 mechanisms, attributes, key types and adds support for several new algorithms:

Java Algorithm                     PKCS#11 Mechanism       

MessageDigest.SHA-512/224          CKM_SHA512_224                     
MessageDigest.SHA-512/256          CKM_SHA512_256
MAC.HmacSHA512/224                 CKM_SHA512_224_HMAC
MAC.HmacSHA512/256                 CKM_SHA512_256_HMAC
Signature.RSASSA-PSS               CKM_RSA_PKCS_PSS
Signature.SHA1withRSASSA-PSS       CKM_SHA1_RSA_PKCS_PSS
Signature.SHA224withRSASSA-PSS     CKM_SHA224_RSA_PKCS_PSS
Signature.SHA256withRSASSA-PSS     CKM_SHA256_RSA_PKCS_PSS
Signature.SHA384withRSASSA-PSS     CKM_SHA384_RSA_PKCS_PSS
Signature.SHA512withRSASSA-PSS     CKM_SHA512_RSA_PKCS_PSS
Signature.SHA224withDSA            CKM_DSA_SHA224
Signature.SHA256withDSA            CKM_DSA_SHA256
Signature.SHA384withDSA            CKM_DSA_SHA384
Signature.SHA512withDSA            CKM_DSA_SHA512
Cipher.AES/GCM/NoPadding           CKM_AES_GCM

Issue: https://bugs.openjdk.java.net/browse/JDK-8080462

TLS

javax.security.cert APIs marked for removal

The deprecated javax.security.cert APIs have been marked for removal and are subject to removal in a future release. These APIs exist only to support applications written against early versions of the Java Secure Socket Extension (JSSE), prior to its inclusion in JDK 1.4. Applications should use the java.security.cert package instead.

Issue: https://bugs.openjdk.java.net/browse/JDK-8160247
X25519 and X448 Diffie-Hellman elliptic curve support

The SunJSSE provider has been enhanced to support the x25519 and x448 elliptic curve named groups with x25519 being the highest preferred group. These curves are supported for TLS versions 1.0, 1.1, 1.2, and 1.3. The default list of named groups is now:
```
x25519, secp256r1, secp384r1, secp521r1, x448, 
sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, 
secp256k1, ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192
```
This order can be overridden using the jdk.tls.namedGroups system property.

Issue: https://bugs.openjdk.java.net/browse/JDK-8171279
Stateless Server

The SunJSSE provider now supports stateless sessions, which can significantly improve the performance and scalability of a TLS server under large workloads.

For this release, the feature is not yet enabled by default. On the client side, it can be enabled by setting the jdk.tls.client.enableSessionTicketExtension system property to “true” and on the server side, by setting the jdk.tls.server.enableSessionTicketExtension system property to “true”.

Issue: https://bugs.openjdk.java.net/browse/JDK-8211018
Enabled cipher suites order changed to improve security

The order of the default list of enabled TLS cipher suites has been modified with several changes to improve security. See the CSR for full details.

Issue: https://bugs.openjdk.java.net/browse/JDK-8163326
Server-side cipher suite order now preferred

The TLS cipher suite selection algorithm has been modified to use the server’s cipher suite order, rather than the client’s.

Issue: https://bugs.openjdk.java.net/browse/JDK-8168261

GSS-API and Kerberos

Kerberos cross-realm referrals

Client support for principal name canonicalization and cross-realm referrals, as specified in RFC 6806 has been added to the Kerberos implementation.

This feature can greatly simplify usability and configuration in a Kerberos environment of multiple realms.

Issue: https://bugs.openjdk.java.net/browse/JDK-8215032
Native GSS-API library on Windows

A Windows implementation of the GSS-API library has been added to the JDK. This provides better interoperability and integration with Windows. For example, it can directly read Windows login user credentials.

This implementation is supported on the client-side only and it is not enabled by default. To enable it, set the sun.security.jgss.native system property to “true”.

Issue: https://bugs.openjdk.java.net/browse/JDK-6722928

SASL

SASL mechanisms can now be restricted

A new security property named jdk.sasl.disabledMechanisms has been introduced to allow you to disable SASL mechanisms that you no longer want to be used. There are no mechanisms disabled by default. Mechanisms can be added to the property in the java.security configuration file. Here is the definition of the property:

# Disabled mechanisms for the Simple Authentication and Security Layer (SASL)
#
# Disabled mechanisms will not be negotiated by both SASL clients and servers.
# These mechanisms will be ignored if they are specified in the mechanisms argument
# of `Sasl.createClient` or the mechanism argument of `Sasl.createServer`.
#
# The value of this property is a comma-separated list of SASL mechanisms.
# The mechanisms are case-sensitive. Whitespaces around the commas are ignored.
#
# Note: This property is currently used by the JDK Reference implementation.
# It is not guaranteed to be examined and used by other implementations.
#
# Example:
#   jdk.sasl.disabledMechanisms=PLAIN, CRAM-MD5, DIGEST-MD5
jdk.sasl.disabledMechanisms=

Issue: https://bugs.openjdk.java.net/browse/JDK-8200400

XML Signature

String constants for Canonical XML 1.1

New public constants named INCLUSIVE_11 and INCLUSIVE_11_WITH_COMMENTS have been added to the javax.xml.crypto.dsig.CanonicalizationMethod API. These represent the URIs for the Canonical XML 1.1 and Canonical XML 1.1 with Comments algorithms for XML Signature. Now you can use the constants instead of the URIs in your application, ex:
```
TransformService.getInstance(CanonicalizationMethod.INCLUSIVE_11);
```
Issue: https://bugs.openjdk.java.net/browse/JDK-8224767
javax.xml.crypto.dsig.keyinfo.KeyValue.EC_TYPE constant

A new public constant (EC_TYPE) representing the URI of the ECKeyValue element has been added to the javax.xml.crypto.dsig.keyinfo.KeyValue API. This allows you to identify this type in your applications using the constant instead of the URI.

Issue: https://bugs.openjdk.java.net/browse/JDK-8223053

Tools

keytool command for displaying TLS configuration information

The keytool utility has a new command (-showinfo is the command and -tls is the option) that displays information about the TLS configuration of the system that the command is run on. This information includes a list of the enabled protocols and cipher suites, ordered by priority.

Here is an example output of running the command:

$ keytool -showinfo -tls
Enabled Protocols
-----------------
TLSv1.3
TLSv1.2
TLSv1.1
TLSv1

Enabled Cipher Suites
---------------------
TLS_AES_256_GCM_SHA384
TLS_AES_128_GCM_SHA256
TLS_CHACHA20_POLY1305_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
TLS_DHE_DSS_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_DSS_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_EMPTY_RENEGOTIATION_INFO_SCSV

Issue: https://bugs.openjdk.java.net/browse/JDK-8219861

JDK 12 Security Enhancements

2019-03-19T00:00:00+00:00

JDK 12 has been released! Although there are no major security features in this release, there are quite a few smaller enhancements and useful additions. Below, I have enumerated the enhancements which I think are most interesting. I have also grouped them into appropriate categories (TLS, crypto, etc) which should make it easier to find out what has changed in each specific area.

Crypto

New HmacPBE Mac algorithm support

New standard HmacPBE algorithms have been added to the Standard Algorithm Names specification and are implemented in the SunJCE provider: HmacPBESHA1, HmacPBESHA224, HmacPBESHA256, HmacPBESHA384, HmacPBESHA512, HmacPBESHA512/224, and HmacPBESHA512/256. These are used by the PKCS12 KeyStore JDK implementation, but now can also be used independently in your applications as javax.crypto.Mac algorithms, ex:
```
Mac mac = Mac.getInstance("HmacPBESHA256");
```
More information: https://docs.oracle.com/en/java/javase/12/docs/specs/security/standard-names.html#mac-algorithms

Issue: https://bugs.openjdk.java.net/browse/JDK-8215450
More informative Cipher.toString()

The toString method of javax.crypto.Cipher has been overridden to print more useful information such as the algorithm, mode, and provider used by the Cipher object, ex:
```
Cipher.AES/GCM/NoPadding, mode: encryption, algorithm from: SunJCE
```
Issue: https://bugs.openjdk.java.net/browse/JDK-8210838
PKCS12 KeyStore configuration properties

New system and security properties have been added for customizing the security algorithms used in the PKCS12 KeyStore implementation. This includes algorithms and parameters for key protection, certificate protection, and MacData. For example, there is a property named keystore.pkcs12.certProtectionAlgorithm that specifies the algorithm that is used to encrypt a certificate. More details, including the default values for these properties are listed in the java.security configuration file.

Issue: https://bugs.openjdk.java.net/browse/JDK-8076190

TLS

ChaCha20 and Poly1305 TLS Cipher Suites

Support for the ChaCha20 and Poly1305 TLS cipher suites has been added to the SunJSSE provider. The TLS_CHACHA20_POLY1305_SHA256 cipher is for TLS 1.3 and the TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256, TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256, and TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 ciphers are for TLS 1.2. Each of these ciphers is enabled by default.

Issue: https://bugs.openjdk.java.net/browse/JDK-8140466
New methods to access the SSLSession

A getSSLSession method has been added to the javax.net.ssl.HttpsURLConnection and java.net.SecureCacheResponse APIs. This method allows applications to obtain full details of the underlying TLS session, such as the negotiated TLS version, which can be very useful. This information was not previously available from these APIs.

More information:
- https://docs.oracle.com/en/java/javase/12/docs/api/java.base/javax/net/ssl/HttpsURLConnection.html#getSSLSession()
- https://docs.oracle.com/en/java/javase/12/docs/api/java.base/java/net/SecureCacheResponse.html#getSSLSession()
Issue: https://bugs.openjdk.java.net/browse/JDK-8212261
Anon and NULL cipher suites disabled by default

The TLS anon (anonymous) and NULL cipher suites have been added to the jdk.tls.disabledAlgorithms security property and are now disabled by default. These ciphers have known security risks and should only be used in special cases. Note that these ciphers were not previously enabled by default (applications still had to explicitly enable them to use them, for example by calling SSLSocket.setEnabledCipherSuites()). With this change, these ciphers are no longer available without additional configuration by a user or administrator via the jdk.tls.disabledAlgorithms security property.

Issue: https://bugs.openjdk.java.net/browse/JDK-8211883
DES cipher suites disabled by default

All TLS cipher suites that use DES have been added to the jdk.tls.disabledAlgorithms security property and are now disabled by default. DES has known security weaknesses and is no longer recommended. Note that these ciphers were not previously enabled by default. With this change, these ciphers are no longer available without additional configuration by a user or administrator via the jdk.tls.disabledAlgorithms security property.

Issue: https://bugs.openjdk.java.net/browse/JDK-8208350
Symantec TLS Server Certificates to be distrusted

The JDK will stop trusting TLS Server certificates issued by Symantec. The list of affected certificates includes certificates branded as GeoTrust, Thawte, and VeriSign, which were managed by Symantec. TLS Server certificates issued on or before April 16, 2019 will continue to be trusted until they expire. Certificates issued after that date will be rejected. See the release note for more information and a list of Certificate Authorities that are affected.

Issue: https://bugs.openjdk.java.net/browse/JDK-8207258
Removed TLS v1 and v1.1 from required algorithms

TLS 1.0 and 1.1 are no longer required to be implemented by Java SE implementations.

Issue: https://bugs.openjdk.java.net/browse/JDK-8214140
TLS 1.2 support for SunPKCS11 provider

The SunPKCS11 provider now supports TLS 1.2. TLS 1.2 algorithms for key and MAC derivation have been added to the SunPKCS11 provider.

Issue: https://bugs.openjdk.java.net/browse/JDK-8029661

Tools

New keytool -groupname option

A new -groupname option has been added to the keytool -genkeypair command so that a user can specify a named group when generating a key pair. For example:
```
keytool -genkeypair -keyalg EC -groupname secp384r1
```
will generate an EC key pair by using the secp384r1 curve.

Issue: https://bugs.openjdk.java.net/browse/JDK-8213400
Deprecated the default algorithms for keytool -keyalg

A warning is now emitted if the -keyalg option is not specified with the -genkeypair or -genseckey keytool commands. The current default for -genkeypair is DSA and -genseckey is DES. In a future release, the -keyalg option will be required.

Issue: https://bugs.openjdk.java.net/browse/JDK-8212003
keytool -printcert now recognizes the -providername option

The -providername option can be useful for inspecting the contents of a certificate that is using an algorithm that is not supported by the builtin JDK security providers.

Issue: https://bugs.openjdk.java.net/browse/JDK-8201290

SecurityManager

Pure-Java implementation of AccessController.doPrivileged

The implementation of the AccessController.doPrivileged methods are now all Java code (they no longer call into the JVM). Micro-benchmarks of these methods have shown up to a 50x performance improvement.

Issue: https://bugs.openjdk.java.net/browse/JDK-8212605
New runtime mode for applications that don’t use a SecurityManager

New “disallow” and “allow” token options have been added to the java.security.manager system property. The “disallow” option can improve run-time performance for applications that never set a SecurityManager. If the Java Virtual Machine starts with the system property java.security.manager set to “disallow”, then the System.setSecurityManager method cannot be used to set a security manager and will throw an UnsupportedOperationException.

For further details on the behavior of these options, see the class description of java.lang.SecurityManager.

Issue: https://bugs.openjdk.java.net/browse/JDK-8191053

Miscellaneous

New Java Flight Recorder (JFR) security events

New security-related events have been added to the Java Flight Recorder tool. These events are disabled by default and can be enabled via JFR configuration files or via standard JFR options. See the release note for more information on the new events.

Issue: https://bugs.openjdk.java.net/browse/JDK-8148188

Sean Mullan's Blog

JDK 26 Security Enhancements

Table of Contents

Crypto

PKI

TLS

XML Signature

Tools

JDK 26 Security Enhancements

Table of Contents

Crypto

PKI

TLS

XML Signature

Tools

JDK 25 Security Enhancements

Table of Contents

Crypto

TLS

Performance Improvements

Security Manager

Miscellaneous

JDK 24 Security Enhancements

Table of Contents

Crypto

PKI

TLS

Security Manager

Miscellaneous

JDK 23 Security Enhancements

Table of Contents

Crypto

PKI

Authorization

Kerberos

Miscellaneous

JDK 22 Security Enhancements

Table of Contents

Crypto

PKI

TLS

XML Signature

Tools

JDK 21 Security Enhancements

Table of Contents

Crypto

PKI

TLS

XML Signature

Tools

JDK 20 Security Enhancements

Table of Contents

General

Crypto

TLS

Tools

JDK 19 Security Enhancements

Table of Contents

Crypto

PKI

TLS

Tools

Networking

JDK 18 Security Enhancements

Table of Contents

Crypto

PKI

Kerberos

Security Manager

Tools

Signed JARs

JDK 17 Security Enhancements

Table of Contents

Crypto

PKI

TLS

Kerberos

XML Signature

Security Manager

JDK 16 Security Enhancements