3

I'm designing a small tool (web interface and web services), for signing some blob's of data with a private RSA key. The application will have more than one private key (ie. for different types of blob's), and in the future we might deprecate some of the keys (and add new ones).

The question is where should I store the KeyStore file? Adding it to META-INF doesn't seems like a good idea, as it would be overwritten with a software update. Other options, would be to store to something like /etc/myapp/keys.keystore or to a table in a blob column.

So, what is the "canonical" way of storing a keystore?

pedrokiefer
  • 41
  • 4

3 Answers3

3

I don't think there's a canonical way. Perhaps the best option would be to have the keystore external to the application, and configure it's location (for example via -Dkeystore.location=/home/.. (something similar to this).

Bozho
  • 588,226
  • 146
  • 1,060
  • 1,140
0

In the past, I've stored keystores on the file system, as a file with the .jks extension. The app in question always runs as a particular user, so we put the file in (a subdirectory of) the user's home directory. We then had some code along the lines of

String keystorePath = System.getProperty("ourapp.keystore.path");
File keystoreFile;
if (keystorePath!=null)
    keystoreFile = new File(keystorePath);
else
    keystoreFile = new File(System.getProperty("user.home"), "ourapp.jks");
if (!f.exists()) {
    // Some sort of whining, return
}
// ...load and deal with keystore...

I don't think there's a canonical way to do this (though I might be wrong). This way has worked well for our use case.

Jon Bright
  • 13,388
  • 3
  • 31
  • 46
0

I've not tried this, but it looks like the recommended way to do this is using environment entries in context.xml.

Tomcat docs here

Related stackoverflow question here

Also, how you are describing how you're going to implement the encryption sounds like there are potentially some problems with it. Read the user erickson's recommendations in various answers to see how to do this right. Here is a question to start with: Java 256-bit AES Password-Based Encryption

Community
  • 1
  • 1
Sarel Botha
  • 12,419
  • 7
  • 54
  • 59
  • Erickson's recommendation is really good, if the other side receiving the ciphered data is a JVM. In my case it is a FPGA with a simple RSA implementation, so I don't have the resources for deriving the key. – pedrokiefer Sep 26 '11 at 13:20
  • Also, that only applies if you have a user entering a password, which it sounds like you don't. He had other recommendations too such as using a unique initialization vector for each file or BLOB you encrypt. – Sarel Botha Sep 26 '11 at 13:31
  • Each blob has a salt and an unique 53 bits field (the FPGA "DNA"), that matches only one FPGA, so as long as I keep my private keys '_safe_' (I know, nothing is really safe) that should work just fine. – pedrokiefer Sep 26 '11 at 13:47