PemUtils can't handle PKCS#5 v2.0 encrypted Private Keys in PKCS#8 format

[jkakavas]

When storing encrypted Private Keys in PKCS#8 format, a number of PKCS#5 v1.5, PKCS#5 v2.0 and PKCS#12 can be used to generate the encryption key from the provided passphrase.

It turns out that Java support for PKCS#5 2.0 has some issues ( this bug report is open for three years now ). The manifestation of this bug is that when a PKCS#8 formatted Private Key that has been encrypted with a key derived using one of PKCS#5 v2.0 ciphers, PemUtils will fail to parse the key with the following exception

Caused by: java.io.IOException: ObjectIdentifier() -- data isn't an object ID (tag = 48)
	at java.base/sun.security.util.ObjectIdentifier.<init>(ObjectIdentifier.java:257)
	at java.base/sun.security.util.DerInputStream.getOID(DerInputStream.java:320)
	at java.base/com.sun.crypto.provider.PBES2Parameters.engineInit(PBES2Parameters.java:268)
	at java.base/java.security.AlgorithmParameters.init(AlgorithmParameters.java:312)
	at java.base/sun.security.x509.AlgorithmId.decodeParams(AlgorithmId.java:132)
	at java.base/sun.security.x509.AlgorithmId.<init>(AlgorithmId.java:114)
	at java.base/sun.security.x509.AlgorithmId.parse(AlgorithmId.java:372)
	at java.base/javax.crypto.EncryptedPrivateKeyInfo.<init>(EncryptedPrivateKeyInfo.java:98)
	at org.elasticsearch.xpack.core.ssl.PemUtils.parsePKCS8Encrypted(PemUtils.java:324)
	at org.elasticsearch.xpack.core.ssl.PemUtils.readPrivateKey(PemUtils.java:85)

Example of generating a key that will fail to be parsed:

openssl genrsa -out key.pem
openssl pkcs8 -topk8 -v2 des3 -in key.pem -out key_pkcs8_v2.pem

(-v2 selects a PKCS#5 2.0 algorithm, aes128 and aes256` are other options - all fail )

Example of generating a key that can be parsed:

openssl genrsa -out key.pem
openssl pkcs8 -topk8 -v1 PBE-SHA1-RC4-128 -in key.pem -out key_pkcs8_v1.pem

-v1 selects a PKCS#5 v1.5 or PKCS#12 algorithm, copying from openssl manpage, options include

PKCS#5 v1.5 and PKCS#12 algorithms.
       Various algorithms can be used with the -v1 command line option, including PKCS#5 v1.5 and PKCS#12. These are described in more detail below.

       PBE-MD2-DES PBE-MD5-DES
           These algorithms were included in the original PKCS#5 v1.5 specification.  They only offer 56 bits of protection since they both use DES.

       PBE-SHA1-RC2-64 PBE-MD2-RC2-64 PBE-MD5-RC2-64 PBE-SHA1-DES
           These algorithms are not mentioned in the original PKCS#5 v1.5 specification but they use the same key derivation algorithm and are supported by some software. They are mentioned in PKCS#5 v2.0. They use either 64 bit RC2 or 56 bit DES.

       PBE-SHA1-RC4-128 PBE-SHA1-RC4-40 PBE-SHA1-3DES PBE-SHA1-2DES PBE-SHA1-RC2-128 PBE-SHA1-RC2-40
           These algorithms use the PKCS#12 password based encryption algorithm and allow strong encryption algorithms like triple DES or 128 bit RC2 to be used.

[elasticmachine]

Pinging @elastic/es-security

[hxnan]

Any news about this issue?
This bug report is open for five years now.

[jkakavas]

Hi @hxnan , we haven't prioritized work on this yet ,is this something that affects you when running elasticsearch?

This bug report is open for five years now

Just to be clear, if you are interested in the upstream bug, then probably the jvm bug tracker is the best way to keep track of this

[hxnan]

I met the same issue when I use the netty tls feature, =new EncryptedPrivateKeyInfo();
The pkcs#5 V1 PBE-SHA1-3DES is not right choice in production env.
So maybe I can get get some advice from here.
Thanks.

[jkakavas]

resolved by #78904