'Could not derive key' or 'Could not decrypt key' Errors After Upgrading JDK or Applying the October 2022 CPU


Applies To

Jave SE JDK and JRE - Version 8 and later.
Any Platform.


Symptoms

Since upgrading to JDK 1.8.0_351, code to generate certificates stopped working with the following error:

java.io.IOException: Could not derive key
        at oracle.security.pki.OracleWallet.a(Unknown Source)
        at oracle.security.pki.OracleWallet.a(Unknown Source)
        at oracle.security.pki.OracleWallet.createSelfSigned(Unknown Source)
        at oracle.security.pki.textui.OracleWalletTextUI.add(Unknown Source)
        at oracle.security.pki.textui.OracleWalletTextUI.command(Unknown Source)
        at oracle.security.pki.textui.OraclePKITextUI.main(Unknown Source)
Caused by: java.lang.IllegalStateException: Could not derive key
        at
sun.security.ec.ECDHKeyAgreement.deriveKeyNative(ECDHKeyAgreement.java:272)
        at sun.security.ec.ECDHKeyAgreement.lambda$engineGenerateSecret$0(ECDHKeyAgreement.java:171)
        at java.util.Optional.orElseGet(Optional.java:267)
        at sun.security.ec.ECDHKeyAgreement.engineGenerateSecret(ECDHKeyAgreement.java:170)
        at javax.crypto.KeyAgreement.generateSecret(KeyAgreement.java:590)
        at oracle.security.pki.OracleKeyStoreSpi.a(Unknown Source)
        at oracle.security.pki.OracleSSOKeyStoreSpi.a(Unknown Source)
        at oracle.security.pki.OracleWallet.internalAddUserCert(Unknown Source)
        ... 6 more
Caused by: java.security.InvalidAlgorithmParameterException
        at sun.security.ec.ECDHKeyAgreement.deriveKey(Native Method)
        at sun.security.ec.ECDHKeyAgreement.deriveKeyNative(ECDHKeyAgreement.java:269)
        ... 13 more

Other errors seen are:

keytool error: java.security.UnrecoverableKeyException: Could not decrypt key: Could not decrypt data.

Cause

In the October 2022 Java CPU release, there were three changes introduced in Java Security which can be seen in the Crypto Roadmap.

  1. Disabled SHA-1 JARs signed after 2019-01-01
  2. Upgraded the default PKCS#12 MAC algorithm
  3. Disabled 3DES and RC4 in Kerberos

The second in this list, “Upgrade the default PKCS12 MAC algorithm,” has to do with the algorithm that is used when a keystore is created.

From the Java 8 java.security file:

# PKCS12 KeyStore properties
#
# The following properties, if configured, are used by the PKCS12 KeyStore
# implementation during the creation of a new keystore.
.
.
.
# The algorithm used to calculate the optional MacData at the end of a PKCS12
# file. This can be any HmacPBE algorithm defined in the Mac section of the
# Java Security Standard Algorithm Names Specification. When set to "NONE",
# no Mac is generated. The default value is "HmacPBESHA1".
#keystore.pkcs12.macAlgorithm = HmacPBESHA1

The HmacPBESHA1 algorithm is considered weak, and in JDK 11.0.12 Oracle both introduced a new algorithm and made it the default.

It was discovered that this caused a compatibility issue. Older JDK releases, such 11.0.11, could not read keystores created by newer JDK releases, such as 11.0.12. JDK 11.0.11 did not know about the newer PKCS12 MAC algorithm and would throw an “Invalid keystore format” exception. Oracle rolled-back the value of keystore.pkcs12.macAlgorithm to the previous HmacPBESHA1 for the short term.

Now, in the October 2022 CPU, HmacPBESHA256 is the default algorithm again. Refer to OpenJDK Bug JDK-8267880. This has been documented in the October 2022 CPU Release Notes which can be found in OpenJDK Bug JDK-8288297.


Solution

Some PKCS12 tools and libraries may not support algorithms based on PBES2 and AES. You may need to upgrade to later versions of these third-party tools and libraries that support these algorithms.

For compatibility, use the keystore.pkcs12.legacy system property, which will revert the algorithms to use the older, weaker algorithms. There is no value defined for this property.

For example:

keytool -J-Dkeystore.pkcs12.legacy -importkeystore -srckeystore ks -destkeystore ks
store ks -destkeystore ks

Last reviewed on Sat Feb 01 2025 00:00:00 GMT+0000 (Coordinated Universal Time)