The Derby Database supports encryption with a key or password. Traditionally thi

Question

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?

Explanation / Answer

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.

Related Questions

Navigate

• Browse (All)
• Browse T
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.