JDK-8242897 : KeyFactory.generatePublic( x509Spec ) failed with java.security.InvalidKeyException
  • Type: Bug
  • Component: security-libs
  • Sub-Component: java.security
  • Affected Version: 11
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2020-04-14
  • Updated: 2021-04-30
  • Resolved: 2020-06-03
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 15
15 b26Fixed
Related Reports
Relates :  
Description
ADDITIONAL SYSTEM INFORMATION :
works in java 10-.  Broken in java 11.0+. checkKeyAlgo was added to RSAKeyFactory.java in java 11 

A DESCRIPTION OF THE PROBLEM :
java.security.spec.InvalidKeySpecException: java.security.InvalidKeyException: Expected a RSA key, but got 1.3.14.3.2.15
	at java.base/sun.security.rsa.RSAKeyFactory.engineGeneratePublic(RSAKeyFactory.java:239)
	at java.base/java.security.KeyFactory.generatePublic(KeyFactory.java:352)
	at com.mycompany.rsatest.Test.main(Test.java:23)
Caused by: java.security.InvalidKeyException: Expected a RSA key, but got 1.3.14.3.2.15
	at java.base/sun.security.rsa.RSAKeyFactory.checkKeyAlgo(RSAKeyFactory.java:104)
	at java.base/sun.security.rsa.RSAKeyFactory.generatePublic(RSAKeyFactory.java:332)
	at java.base/sun.security.rsa.RSAKeyFactory.engineGeneratePublic(RSAKeyFactory.java:235)

REGRESSION : Last worked in version 10

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
1.3.14.3.2.15 should be a valid RSA key?

---------- BEGIN SOURCE ----------
package com.mycompany.rsatest;

import java.security.KeyFactory;
import java.security.interfaces.RSAPublicKey;
import java.security.spec.X509EncodedKeySpec;
//import sun.security.rsa.RSAPublicKeyImpl;


public class Test {
    
    static byte[] certData = {48, 88, 48, 9, 6, 5, 43, 14, 3, 2, 15, 5, 0, 3, 75, 0, 48, 72, 2, 65, 0, -41, 21, 124, 101, -24, -14, 37, 87, -40, -88, 87, 18, 44, -2, -123, -67, -33, -85, -93, 6, 76, 33, -77, 69, -30, -89, -51, -40, -90, 117, 30, 81, -102, -72, 97, -59, 16, -97, -72, -116, -50, 69, -47, 97, -71, -127, 123, -64, -20, -51, -61, 15, -38, 105, -26, 44, -59, 119, 119, 95, 44, 29, 102, -67, 2, 3, 1, 0, 1 };

    public static void main(String[] args) {
        try {
            X509EncodedKeySpec x509Spec = new X509EncodedKeySpec( certData,"RSA" );
            KeyFactory kf = KeyFactory.getInstance( "RSA" );
            System.out.println( "KF type " + kf.getAlgorithm() );
            RSAPublicKey rsaKey = (RSAPublicKey)kf.generatePublic( x509Spec );
//            RSAPublicKey rsaKey = RSAPublicKeyImpl.newKey( x509Spec.getEncoded() );

            System.out.println( "key algo: " + rsaKey.getAlgorithm() );
        }
        catch( Exception e ) {
            e.printStackTrace();
        }
   }
}
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Circumvent KeyFactory.generatePublic() by calling RSAPublicKeyImpl.newKey();

FREQUENCY : always



Comments
Changed existing code in SunRsaSign provider to allow this particular RSA signature oid in the RSA key encoding for max backward compatibility. The key encoding is preserved, but will return RSA as key algorithm.
03-06-2020

URL: https://hg.openjdk.java.net/jdk/jdk/rev/22118fdcb534 User: valeriep Date: 2020-06-03 04:31:20 +0000
03-06-2020

As part of changes under JDK-8146293, RSA keys are changed to take the oids encoded in the DER encoding as key algorithms and additional checks added to ensure the consistency. This leads to keys constructed from DER encoding using oddball RSA oids failed to parse as the resulting key algorithm (either oid string or signature algorithm if we add support for this oddball oid) is different from the requested key factory algorithm (RSA or RSASSA-PSS).
21-04-2020

Note that this particular oid 1.3.14.3.2.15 is not supported by JDK and it happened to work in earlier releases due to the lack of checking. To maintain backward compatibility and parse this oddball key, we probably have to loosen the impl up and not set the key algorithm based on the underlying algorithm oid.
21-04-2020

The observation on Windows 10: JDK 11: Fail ILW=HLM=P3
15-04-2020