views:

41

answers:

1

I've got an application which generates SecretKeys, one per client. These need to be persisted in our database. I'm REALLY unfamiliar with common security patterns or implementations, and I'm looking for advice.

The KeyStore class seems to be widely used, especially to protect SecretKeys. However, I've seen little mentioning using KeyStore with databases, and I'm trying to figure out if it's because it's elementary usage (and thus not mentioned), or if it's because this is a bad or redundant approach, and I should really be using a different technique.

The basic design is that each user would have their own keystore, which would be saved/loaded to and from the database by conversion to bytes (using load() and store(), I think).

Anything wrong with this design so far? I'm also wondering how I should handle the password to the KeyStore. We're thinking of only using a single password for all KeyStores, but how do we store THIS securely without a keystore?

This is meant to be used in a back-end app, and the client will never transfer a password to us, nor is there a human operator on the server-side to supply a password.

A: 

In the real world, secret keys are stored securely (emphasis mine) in a HSM if they're meant to be stored securely, for an extended period of time (ranging from hours to years). There is the PKCS#11 standard that is meant to aid in interfacing with such systems, but I'll state the least - most HSMs have their own preferred mechanisms for interfacing with the HSM, and the PKCS#11 interface usually turns out to be a crippled one.

Secret keys can also be stored securely in other devices like smart cards and USB tokens, but that is meant for key distribution among a mass populace, rather than key storage for a back-end system.

Not everyone gets a budget for HSMs however, and a lot of other less secure (and obviously cheaper) alternatives are used. Some systems (I'll take the case of the Glassfish application server) store a master password, that is used to protect other passwords. The same holds good for keys - there would be a master key that is used to protect other keys (in a way, this is similar to how HSMs work internally). Of course, you're then stuck with securing the master key. In certain environments, this is easy, as you can place the key in a file that is restricted to a system administrator and the application, and no one else.

Disclaimer: None of this should be treated as advice that is to be ingested blindly :-). If your keys need to be protected at all costs, invest in a HSM.

Vineet Reynolds