Let's say I have sensitive data in the database server that needs to be encrypted (i.e emails, etc..) and I want to make sure that in the event that the server is compromised, the attacker shouldn't be able to decrypt these data (at the very least make it harder).

I've read some solutions online, and it seems like I can either

  1. Use Hardware Security Modules (i.e. Amazon KMS/Vault) such that a separate server handles encryption/decryption.
  2. Use Public Key Encryption (where the public key in database server encrypts data, and a private key is stored in separate server that solely handles decryption)

Which one is a better solution?

  • Define "better". PKE will be cheaper, but a HSM means that even if they break into a server, they shouldn't be able to obtain decryption keys (although they could use the same calls you do to decrypt - it's not an excuse to reduce security elsewhere)
    – Matthew
    Commented Jun 9, 2016 at 15:20
  • @Matthew I see. By better, initially, I meant more secure + more straightforward to implement + doesn't add too much technical debt. But I guess now that you mentioned cost, its definitely a factor to consider as well.
    – redgetan
    Commented Jun 9, 2016 at 15:41
  • 1
    A cloud-based HSM will almost certainly do a much better job of security then you setting up a "seperate server" that you then have to rely on your own ability to (a) secure correctly (b) run software that doesn't have exploitable vulnerabilities. Commented Jun 9, 2016 at 17:04
  • @redgetan " you mentioned cost, its definitely a factor to consider as well" with cloud-HSMs cost is no longer an excuse for not using HSMs, just look at Microsoft Azure HSM pricing ! Commented Jun 9, 2016 at 17:10

1 Answer 1


There are two different, but related problems here. One is the security of the key; the other is the security of the data decrypted by the key.

An HSM and "a separate server" are essentially the same thing from the point of view of your app server. It's sending the encrypted data "elsewhere" for decryption, but the cleartext data will end up back in your app server. The app server will always need enough protection to protect against an attacker inside it, siphoning off your secrets. So you can ignore the security of the cleartext data in making this choice, because the cleartext problem is the same regardless of which option you choose.

Let's consider HSMs first. It's usually true that protecting the key is more important than protecting any one single piece of data (unless leaking a single piece of data could result in a catastrophic loss); and that's where an HSM is a very good tool for the job. The drawbacks of an HSM approach are that they're quite expensive to purchase, maintain, and operate. They're usually priced on transaction throughput, so the more data you need to decrypt at a time, the more expensive the HSM. Any accounting for the expense also needs to include the complexity needed to interact with it - you'll probably spend a lot of time learning how to use it, how to perform key ceremonies, integrating it into your existing systems, etc. But you'll have the best protected keys money can offer.

On the other hand, if you build your own server to perform the decryption of the data, you'll have to spend time hardening it against attack, issuing certificates to authorized app servers, performing audits, etc. And be aware that an admin on the machine will always have enough access to get to the key. (This is not true of an HSM that requires a number of shares of a master key in order to access the keys, meaning a number of trusted people would have to collude to violate the security.) So building your own server will cost less than buying an HSM, but it isn't cheap; and the key is at more risk than an HSM. It's especially problematic if you don't know how to properly secure it.

Given all that, it becomes a matter of money vs risk. (Welcome to Security!) How critical is it to your organization's continued existence that you secure those keys? What security classification have you given to the data stored in those emails? Will it store data in scope for PCI, HIPAA, SOX, GLBA, or some other regulated industry? Does your data contain industrial secrets so valuable that a foreign government might bring all their resources to hack into it? Does it protect so much money that you would go bankrupt if a hacker siphoned it off? Will stealing from the database put your organization out of business? Next, price out buying an HSM vs building and securing your own decryption server.

If the answers to the above add up to "it's not really worth all this", then you have to consider more affordable means of securing it.

  • I see. Thanks for the thorough answer. Does the statement "drawbacks of an HSM approach are that they're quite expensive to purchase, maintain, and operate" still hold true for something like vaultproject.io/intro, which is open source, provides TLS backed HTTP API, and i can self-host myself ?
    – redgetan
    Commented Jun 9, 2016 at 16:38
  • @JohnDeters " The drawbacks of an HSM approach are that they're quite expensive to purchase, maintain, and operate. " with cloud based HSMs that is no longer an excuse ! The risk of you stuffing up a "seperate server" vs the risk of something happening to the cloud-HSM is firmly on the side of you stuffing up the "seperate server" Commented Jun 9, 2016 at 17:05
  • @redgetan just use the cloud HSM, don't roll your own software based solution ! HSMs were invented for a reason, using an HSM in the cloud only introduces a tiny security risk compared to the many risks you could introduce by running your own software-based "Seperate server" Commented Jun 9, 2016 at 17:06
  • @LittleCode , I'm not picking one or the other, those are choices he has to make. If an HSM in the cloud is cheap and easy, that will be reflected in the cost when he compares them. But yes, rolling his own is very risky, which he needs to take into account. Commented Jun 9, 2016 at 18:12

You must log in to answer this question.

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