Unencrypted private keys in JKS files cannot be decrypted with the JKS passphrase

Our application creates JKS files using PyJKS version 17.1.0 using the following method:

def jks_key(alias: str, chain: list, key_der: bytes, passphrase: str) -> bytes:
    """ generate a java keystore with an alias for the given key """

    pke = jks.PrivateKeyEntry.new(alias, chain, key_der, 'rsa_raw')
    keystore = jks.KeyStore.new('jks', [pke])
    return keystore.saves(passphrase)

Up until recently the JKS files have worked well, and our Java application could read and decrypt the private key using the provided passphrase.

Since the pyasn1 module was updated to version 0.3.2 and pyasn1-modules to version 0.0.11, the JKS files created by the application no longer work. The passphrase can decrypt the JKS itself, but cannot decrypt the private key within it anymore.

http://pyjks.readthedocs.io/en/latest/jks.html#jks.jks.KeyStore.saves states: “If any of the private keys are unencrypted, they will be encrypted with the same password as the keystore.” This statement does not seem to hold true anymore.

[magnuswatn]

This broke by: https://github.com/etingof/pyasn1/commit/6fa0e312ea80713983b1a3c1e4529e7452b0e0fe

The problem is that the optional attributes field in the PrivateKeyInfo is now being included without anything in it. Before:

    0:d=0  hl=4 l=1213 cons: SEQUENCE          
    4:d=1  hl=2 l=   1 prim:  INTEGER           :00
    7:d=1  hl=2 l=  13 cons:  SEQUENCE          
    9:d=2  hl=2 l=   9 prim:   OBJECT            :rsaEncryption
   20:d=2  hl=2 l=   0 prim:   NULL              
   22:d=1  hl=4 l=1191 prim:  OCTET STRING      [HEX DUMP]:308204A3...

After:

    0:d=0  hl=4 l=1215 cons: SEQUENCE          
    4:d=1  hl=2 l=   1 prim:  INTEGER           :00
    7:d=1  hl=2 l=  13 cons:  SEQUENCE          
    9:d=2  hl=2 l=   9 prim:   OBJECT            :rsaEncryption
   20:d=2  hl=2 l=   0 prim:   NULL              
   22:d=1  hl=4 l=1191 prim:  OCTET STRING      [HEX DUMP]:308204A...
 1217:d=1  hl=2 l=   0 cons:  cont [ 0 ]  

We can fix this in our code, but it seems strange to me that we have to. I will create a bug in pyasn1 and ask if this is how it’s supposed to be. If it is, then I will create a fix.

[magnuswatn]

Yes, this should be fixed soon @jcdevil. Sorry that it has taken forever!