Bug ID: JDK-8278027 X509Key.decode exception while using JSafeJCE FIPS provider

Type: Bug
Component: security-libs
Sub-Component: javax.crypto
Affected Version: 8u271

Priority: P3
Status: Resolved
Resolution: Fixed

Submitted: 2021-11-30
Updated: 2024-08-28
Resolved: 2022-11-02

JDK 11	JDK 17	JDK 8
11.0.19-oracleFixed	17.0.7-oracle b01Fixed	8u351Fixed

Oracle Reports product failing since upgrading to 8u281 in this environment. If the FIPS provider is disabled, the product works ok.

java.security.InvalidKeyException: IOException: Could not decode parameters.
        at sun.security.x509.X509Key.decode(X509Key.java:397)
        at sun.security.x509.X509Key.readObject(X509Key.java:419)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)

JSafeJCE support confirmed that this is a known issue and have fixed it in Crypto-J7.0. The bug was fixed in BSFCRYJ-4956 - Update to the DH and DSA parameter decoding to support no algorithm OID.
23-09-2022
reproducer details. First - Set up JsafeJCE FIPS env in the JDK. Using just "security.provider.1=com.rsa.jsafe.provider.JsafeJCE" for provider config is enough for this test case. (1 provider) $ cat DecodeErr3.java import java.security.*; import sun.security.pkcs.PKCS8Key; import sun.security.util.DerValue; public class DecodeErr3 { public static void main(String[] args) throws Exception { KeyPairGenerator keyPairGen = KeyPairGenerator.getInstance(args[0]); keyPairGen.initialize(Integer.parseInt(args[1])); KeyPair pair = keyPairGen.generateKeyPair(); PKCS8Key.parseKey(new DerValue(pair.getPrivate().getEncoded())); } } $ ./jdk1.8.0_341/bin/javac -XDignore.symbol.file=true DecodeErr3.java $ ./jdk1.8.0_341/bin/java DecodeErr3 DSA 2048 Exception in thread "main" java.io.IOException: Could not decode parameters. at com.rsa.cryptoj.o.ms.engineInit(Unknown Source) at java.security.AlgorithmParameters.init(AlgorithmParameters.java:293) at sun.security.x509.AlgorithmId.decodeParams(AlgorithmId.java:150) at sun.security.x509.AlgorithmId.<init>(AlgorithmId.java:132) at sun.security.x509.AlgorithmId.parse(AlgorithmId.java:416) at sun.security.pkcs.PKCS8Key.parseKey(PKCS8Key.java:132) at DecodeErr3.main(DecodeErr3.java:13)
26-08-2022
internal reproducer set up with JSafeJCE provider. JDK-8242556 is responsible for the change of behaviour here. Up until that fix, DSA AlgorithmParameters requests which were made in sun.security.x509.AlgorithmId.decodeParams() and which has the algid instance variable constructed with OID type rather than the textual representation OID value. The 3rd party provider in this scenario, does't register for the UUID format OID (via aliases field) -- see output below. (i.e only takes requests for "DSA" AlgorithmParameters types) == Provider: SUN.putService(): SUN: AlgorithmParameters.DSA -> sun.security.provider.DSAParameters aliases: [1.2.840.10040.4.1, 1.3.14.3.2.12, OID.1.2.840.10040.4.1] attributes: {ImplementedIn=Software} Provider: JsafeJCE.putService(): JsafeJCE: AlgorithmParameters.DSA -> DSA == as a result of JDK-8242556, JsafeJCE now takes more AlgorithmParameters.DSA operations and seems to barf at some requests : Exception in thread "main" java.security.UnrecoverableKeyException: Could not decode parameters. at sun.security.provider.KeyProtector.recover(KeyProtector.java:325) at sun.security.provider.JavaKeyStore.engineGetKey(JavaKeyStore.java:143) at sun.security.provider.JavaKeyStore$JKS.engineGetKey(JavaKeyStore.java:57) at sun.security.provider.KeyStoreDelegator.engineGetKey(KeyStoreDelegator.java:96) at sun.security.provider.JavaKeyStore$DualFormatJKS.engineGetKey(JavaKeyStore.java:71) at java.security.KeyStore.getKey(KeyStore.java:1023) at com.rsa.sslj.x.co.<init>(Unknown Source) at com.rsa.sslj.x.ch.engineInit(Unknown Source) at javax.net.ssl.KeyManagerFactory.init(KeyManagerFactory.java:256) at DecodeErr.main(DecodeErr.java:77) (cause captured in debugger:) stackTrace = {StackTraceElement[16]@1831} 0 = {StackTraceElement@1833} "com.rsa.cryptoj.o.ms.engineInit(Unknown Source)" 1 = {StackTraceElement@1834} "java.security.AlgorithmParameters.init(AlgorithmParameters.java:293)" 2 = {StackTraceElement@1835} "sun.security.x509.AlgorithmId.decodeParams(AlgorithmId.java:150)" 3 = {StackTraceElement@1836} "sun.security.x509.AlgorithmId.<init>(AlgorithmId.java:132)" 4 = {StackTraceElement@1837} "sun.security.x509.AlgorithmId.parse(AlgorithmId.java:416)" 5 = {StackTraceElement@1838} "sun.security.pkcs.PKCS8Key.parseKey(PKCS8Key.java:132)" 6 = {StackTraceElement@1839} "sun.security.provider.KeyProtector.recover(KeyProtector.java:323)" 7 = {StackTraceElement@1840} "sun.security.provider.JavaKeyStore.engineGetKey(JavaKeyStore.java:143)" 8 = {StackTraceElement@1841} "sun.security.provider.JavaKeyStore$JKS.engineGetKey(JavaKeyStore.java:57)" 9 = {StackTraceElement@1842} "sun.security.provider.KeyStoreDelegator.engineGetKey(KeyStoreDelegator.java:96)" 10 = {StackTraceElement@1843} "sun.security.provider.JavaKeyStore$DualFormatJKS.engineGetKey(JavaKeyStore.java:71)" 11 = {StackTraceElement@1844} "java.security.KeyStore.getKey(KeyStore.java:1023)" 12 = {StackTraceElement@1845} "com.rsa.sslj.x.co.<init>(Unknown Source)" 13 = {StackTraceElement@1846} "com.rsa.sslj.x.ch.engineInit(Unknown Source)" 14 = {StackTraceElement@1847} "javax.net.ssl.KeyManagerFactory.init(KeyManagerFactory.java:256)" 15 = {StackTraceElement@1848} "DecodeErr.main(DecodeErr.java:77)" === Not sure why JsafeJCE doesn't handle such a request but we should look at altering the fix to restore 8u261 behaviour in this area.
25-08-2022
The X509Key.decode code could be enhanced to include the stacktrace of the cause of the InvalidKeyException. I suspect we'll get a better understanding of the issue from such a stacktrace.
01-12-2021