'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.
- Disabled SHA-1 JARs signed after 2019-01-01
- Upgraded the default PKCS#12 MAC algorithm
- 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)