Are Java PKCS #12 key stores reasonably secure with average strength passwords?

Question

Suppose:

• We are using an application that stores sensitive private key information in a standard Java PKCS #12 keystore.
• Users are expected to provide an overall store password and also a password for each key in the store.

ASSUMING:

• The user chooses reasonable passwords that are not trivial to guess (empty, own name, "password" etc.) but are also not extremely strong. Let's say 40 bits of entropy.
• Attackers obtain access to the keystore .pfx file (as stored on disk)
• Attackers are UNABLE to obtain one or both of the passwords
• Attackers are sophisticated, have significant compute power etc.

Are the private keys likely to be safe? If not, how could you improve the protection?

Answer 1

Let's assume Java 21 here, as it is a long term support version.

There are some issues with the passwords:

• the default amount of iterations for the password-based key derivation function 2, i.e. PBKDF2, is 1000, which was the default very long ago;
• there are no methods of protecting the password when entered from console;
• there is no indication of password strength, other than requiring a minimum amount of 6 characters, which is of course not enough to be secure.

This basically means that any password used is hard to enter securely, while also making it easy to enter an altogether insecure password. Note that this is password based encryption (PBE), so attackers are able to crack the store using parallel processes having direct access to the data in the file. Basically you need to enter a password that has the strength of a symmetric key to have any kind of security, and this won't change much even if the number of iterations is set to e.g. 1,000,000. Using a password manager with at least a 16 character fully randomized password if you want to rely on the confidentiality.

---

In earlier Java versions (which I haven't all tested) they also used older algorithms:

• they are using 3DES to encrypt the private keys (not sure if it was 2 or 3 key 3DES, but both should not be used anymore);
• the 40-bit RC2 algorithms is used to encrypt the certificates, while the RC2 algorithm has been known to be broken for some time;

Certificates are not as sensitive as private keys of course, but they may still contain e.g. personal information which you might not want to leak, even if they are usually considered "public".

There are also some good things with newly generated key stores:

• they use SHA-256 for PBKDF2 but also for HMAC to provide authentication / integration;
• the newer key stores use AES-256 in CBC mode for providing confidentiality.

Using a hardware key store is currently one of the more logical options, or having a separate key store.

You can have a look at the inner construction of a new PKCS#12 / PFX key store here

Answer 2

A secret with 40 bits of entropy is not secure, it can be brute forced. NIST currently wants a minimum of 112 bits of entropy for security.

In addition, my notes show that PKCS#12 uses RC2, which is not secure even with passwords that have that good entropy. You might consider using Bouncy Castle BCFKS format which is much more secure as it uses AES 256 and SHA 512. That of course, requires using Bouncy Castle.