0

I'll start by saying I understand wanting to make data as safe as possible.

I have an app and I would like to just encrypt all of the information that can be used to personally identify someone in the database.

So I have read that it is terrible to store your key on the same server as the data. Okay so separate servers, no problem. Then I've read that It's terrible to put the key in the code on the app server (away from the data). People say that the proper way to store an encryption key is by using a HSM or a Key vault like Azure Key Vault. Ok, I am on-board with that but if my code has access to the HSM or the Azure Key Vault (which it would need to have in order to decrypt or access the data AT ALL...

If my code is stolen from the app server (which is why storing the key in the code itself would be insecure) Why couldn't an attacker just use the same method that my code uses to decrypt the data from the HSM or Key vault?

Assuming that it isn't safe to just store the key inside of the code itself.. How is it any different to have a method or a function that can decrypt the data in the code? That would essentially tell the attacker how to get the key from the vault anyway, wouldn't it?

What is the extra vector or layer that using an HSM or Keyvault prevents?

I don't mind paying for and implementing the extra layer. I am genuinely curious as I can't really see any difference.

ZCT
  • 141
  • 1
  • 1
  • 9

2 Answers2

0

I think your question is mainly about protecting secret keys in software vs. hardware key management solutions. the following links have useful information about their differences:

Usage of software/hardware-backed Android Keystore and possible security/usability drawbacks

https://www.itprotoday.com/iaaspaas/software-vs-hsm-protected-keys-azure-key-vault

0

if I understand your question correctly, it's because the application never sees the actual cryptographic keys. the HSM just exposes the primitive crypto operations, but never the keys themselves.

an attacker would therefore need to be logged into your "app server" in order to perform the operations, which is (hopefully) relatively easy to revoke/deny. if you had the keys available to the code itself then they could continue using the keys on any existing encrypted data until it has been re-encrypted after rotating in a new key. this also has associated assurance difficulties, e.g. how do you know the attacker didn't manipulate some data while this rotation was happening

Sam Mason
  • 11,177
  • 1
  • 29
  • 42