3

It appears that Java Keystore is often used by web server using a configuration file, with the password opening the JKS written in it and also the password protecting the specific entry.

How could that be considered secure ? With this scheme, the "secret problem" has moved to the file. Even if the file is protected by user rights, it needs to be encrypted, doesn't it ? But that would mean that each time webserver is started, admin must enter a password to generate the symmetric key (PBKDF2) and decrypt the file ?

I would like to know more about how this is managed in secure way.

2

As @whoami mentioned, it does just move the issue to another place. As you mentioned it allows you to move it out of code (if you've hardcoded it), password protect it (if it was originally just a PEM or whatever on disk), and ACL it to the requisite permissions.

The problem is that you do need to know the key to unlock it, and that of course requires protection of some sort, and well, you get turtles all the way down.

What you're basically doing is moving the bar for the attackers so they have to put in more effort to break the thing. At some point they just say screw it, and move on. You can make it harder by introducing complexity to key generation, but if attackers know how this works they can do it themselves easily enough, or worse they can just steal the file and try brute forcing the key since its not particularly random. In some cases the OS does provide a mechanism of protecting the random keys, but in this case you'd need something that is exposed to the JVM.

More practical solutions involve moving the key to better-protected areas, and that usually means hardware of some sort. In some cases we're talking TPMs, HSMs, or simply smart cards (though they are all really the same thing, but with different features). The basic principle is that the key never leaves the hardware, so its impossible to steal it. A side effect of this is that all crypto usually occurs in the hardware itself, so all you're doing is shoving data in, and getting data out, without needing to worry about the crypto itself.

This then means you need to protect the interface to the hardware so only authorized systems can talk to it. See the turtles yet?

0

Yes, you are right, all it does is it moves the issue to another place.

There are several ways to protect the password of the Keystore using PBKDF2.

  1. Using a password that is needed at start up of the application server(as you mention).
  2. Composing the password of PBKDF2 out of 'things' you know about your deployment environment; for example: concatenating the hostname, username and MAC address.

Number 2, has the benefit that no one person will have to remember (or write down) the password; It also helps when you keystore is copied/stolen by an insider -> unless they understand how the password is composed.

The draw back of using 2. is that if for example your network card fails and is replaced you won't be able to derive the key needed to decrypt your Keystore password.

Both the above mentioned ways are how I have personally seen it been implemented.

  • This doesn't exactly answer the question. Please add details on what the specific security issues are, and how the recommended remediation resolves the issues. – Xander May 15 '15 at 12:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.