0

A keystore (no matter if it's used for "keystores" or "truststores") is initialized after creation using the load() method. One version expects an InputStream corresponding to the keystore file, and the password to decrypt the file. Providing the password to the method programmatically seems strange to me.

For example, a server uses a keystore to store its private keys and the associated certificates. The information present in the keystore is sensible so it is protected by a password. What are the problems of passing the password to the load() method programmatically? What is the best practice?

The other example, but for now concerning truststores. The client has a truststore where it stores the certificates of trusted CAs. As I understand it, the truststore doesn't contain the certificate of the server but only the certificates of the CAs that allow verifying the server's certificate. One truststore example I see is the one present with the JRE (in the security folder - cacerts). By looking at the configuration, I can see it is protected by the default password changeit. I understand that a truststore is implemented using a keystore, so it has (or maybe it's optional?) to be encrypted using a password. But, since truststores generally store public information (trusted CA's certificates) in the file, why changing the password is recommended?

Thanks

manash
  • 6,985
  • 12
  • 65
  • 125

1 Answers1

2

Providing the password to the method programmatically seems strange to me.

I'm not sure why this would be strange. The application will need to be able to get hold of the content of the keystore at one point or another. The password will need to be passed to it, somehow. Passing it to the load() method doesn't make less sense than other solutions (avoid hard-coding, of course). Alternatively, you can use the method that uses a callback instead. If you don't think that's suitable, you can use a PKCS#11 provider and a hardware token (although you'll still need to enter the password/PIN somewhere) or use something like the Apple KeychainStore (where the password isn't used, but the OS keychain service takes care of that).

Regarding the truststore, there are in fact two passwords in use. They can be different, when using the JKS format. One protects the keystore itself, and one protects access to the private entries (getKey). In this case, the keystore password is used to prevent unauthorised parties from altering the truststore (and adding their own CA or server certificates).

Bruno
  • 119,590
  • 31
  • 270
  • 376
  • Thanks, I didn't think about modification for the truststore, it's obvious. – manash Jul 18 '12 at 13:17
  • I have another related question. Why a TrustManagerFactory doesn't need password for initialization while a KeyManagerFactory does? Also, the passwords for Keystore and Truststore have both been provided during the load(). – manash Jul 18 '12 at 13:51
  • The KMF password is for using the private key. In both cases, you'd already have loaded the keystore itself before passing it to either factories. – Bruno Jul 18 '12 at 13:52