The Derby Database supports encryption with a key or password. Traditionally this key is stored in the file systems, now I am looking to store and protect this key in the HSM instead, but I couldn't figure out how I should be doing it.

  1. The most simplest approach seems to be just putting the key itself into the HSM? Then on server startup, the application will query the HSM for the key, use it to boot the Derby database, and then discard the key. However, I have read that it seems ineffective because the key can then be simply extracted, but I do not really understand what's the security issue with this appraoch, is this the approach that I should be taking?

  2. The second way that I read about is hybrid encryption, but I am not really sure whether it is applicable to my case. I will generate a symmetric key, then generate a keypair in the HSM. Then I will use the Public Key from the HSM to encrypt the symmetric key and store it locally in the file system. On server start up, I will pass this encrypted symmetric key to the HSM to decrypt it using the unextractable Private Key. Is there any merits using this approach or its overkill for this purpose?

From the way I understand, most of the usage of HSM revolves around having different senders (encrypt) and receivers (decrypt), hence the use of KeyPairs instead of symmetric keys?

2 Answers 2


What some database engines do is to derive keys in the HSM and use different keys for different parts of the data. On top of that, they can also cycle keys (e.g. read/decrypt with key A, encrypt/write same block with key B). These operations are embedded in the database engine and I'm not sure Derby goes any close to that degree of sophistication.

On top of this, the benefit of database encryption is that if someone steals a harddrive (or a back up of your DB), they won't be able to access the data.

This changes completely in the case an attacker gets access to the server, as they will be able to connect to the database and extract the data, or alternatively they'll be able to scrap the key from memory.

My suggestion would be (similar to your first point): Use the HSM to derive a key (just getting the key our of an HSM feels dirty to me), and know that this is only to prevent the scenarios I mentioned above.


You can use the HSM to store and manage your keys but you should also be able to use the HSM to perform encrypt and decrypt functions on behalf of your database or application. It depends on the functionality available on the HSM you have or are considering using. Here are a some examples of how you could use it:

1) Store a symmetric encryption key within the HSM. Your application/database can request this key from the HSM and use if for encryption and decryption operations. This means the key will leave the HSM and be available in clear text in memory to do its work. This key will be vulnerable to memory scraping.

2) Store a symmetric encryption key within the HSM. You application/database can send data to the HSM to be encrypted or decrypted. In this case the key never leaves the HSM.

3) Store a symmetric or asymmetric encryption key within the HSM. Use this encryption key to encrypt your Data Encryption Key (DEK). Store this cryptogram wherever you want. Request the Key Encrypting Key (KEK) from the HSM to decrypt your DEK and use your DEK for encryption/decryption operations.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .