Hacker News Reader

Comment by chrisfarms | Hacker News Reader

This is encrypting the disk that the RDS instance is using to store the data right? And amazon are holding the decryption key.

What exactly is this protecting against? (Genuine question not rhetoric).

Without encryption, I guess someone with physical access to an Amazon data center could pull a drive somewhere and grab the data.

With encryption, that same person would also have to get hold of the key as well, but nothing seems to be said about the key storage being in some separate super secure location, so could that same malicious employee with physical access not also go on a key hunt and end up getting access anyway? So it's just another "layer" of protection not totally impossible.

.... or am I missing something crazy obvious where an unencrypted RDS disk is accessible by some other means? Maybe via to nature of disks being reused without proper cleaning or similar?

View on HN

Keys are stored within AWS Key Management Service, which relies on Hardware Security Appliances (a dedicated tamper-proof hardware appliance just for storing secrets). For EBS, encryption works like this (I imagine RDS will work similarly):

  The basic steps to encrypt data being written to an EBS volume are:

  1. Amazon EBS obtains an encrypted volume key under a customer master key through AWS KMS, and stores the encrypted key with the volume metadata.

  2. When the EBS volume is mounted, the encrypted volume key is retrieved.

  3. A call to AWS KMS over SSL is made to decrypt the encrypted volume key. AWS KMS will identify the CMK and make an internal request to an HSA in the fleet to decrypt the volume key, and will return the volume key back to the customer over the SSL session.

  4. The volume key is stored in memory and used to encrypt and decrypt all data going to and from the attached EBS volume. Amazon EBS retains the encrypted volume key for later use in case the volume key in memory is no longer available.

More info: https://d0.awsstatic.com/whitepapers/KMS-Cryptographic-Detai...

I see, thanks.

So there _is_ extra¹ care taken over the protection of the keys vs the protection of disks to significantly raise the barrier.

¹not saying that they just leave their data centers open to the public, but you know what I mean :)

I went to an Encryption and Key Management in AWS presentation at the pop-up loft in San Francisco, and they explained how their KMS system is built on shared Hardware Security Modules (HSMs) that are tamper evident and have hardcoded logging. So any decryption event is logged and you'd have to physically break into the HSMs to prevent a log entry (and thus have to replace lots of equipment).

This basically meant that it would cost millions of dollars to secretly decrypt something where the user wouldn't be able to see a log of it. It's basically a "porcupine defense" where governments won't bother asking for secret decryption since it would cost so much money. They specifically designed the infrastructure to be extremely expensive to hide any log altering. It also means that governments will more likely try compromising the targets system first, rather than send a secret decryption order to Amazon.

EDIT: Additionally, since the HSMs are shared, any physical tampering would require them to notify and migrate all the other users on that HSM that are under regulations (HIPAA, PCI DSS, etc.). AWS would charge a lot of money for this sort of migration.

It's to comply with IT policies that require data to be encrypted on disk. Now, businesses that wouldn't use RDS before can now tick that last box off on the IT security audit.

It is a requirement for HIPPA compliance.

Basically, it's protecting you against a screw-up in Amazon procedures where somebody physically gets the disk media that your data is stored on. It may also protect you against a compromise affecting the hosts that your VMs or storage are running on.

Is it useful? If it prevents you having to do a breach disclosure, absolutely yes.

The keys used by KMS are stored in an AWS-managed hardware security module (HSM) on-site and never go outside that data center. This means that even if the person had physical access to the data center, they should not be able to extract the decryption keys because HSMs are specifically designed to prevent that. If it was an Amazon employee that had super-user privileges over that HSM for management purposes...who knows.

Stealing physical hard drives is really the only thing being protected against here, as far as I can tell. It seems that any instance in your account can access any encrypted volume in your account - there's no access control. I imagine Amazon is working on that, but right now if someone were to e.g. get permission to spin up an instance with stolen API keys, then they'd have access to all your encrypted volumes. Someone correct me if I'm wrong.

I've actually rolled my own device encryption in the OS layer using LUKS and puppet. The puppet master is heavily locked down, and holds the decryption keys, which are only available to the correct client and then only ever stored in memory. So this provides somewhat more defense in depth than the AWS native solution.

I wonder if it has anything to do with the fact that the CIA is now an Amazon customer. Hopefully they don't also become Amazon's employees.

Your comment implies that the American surveillance apparatus hasn't already infiltrated Amazon... but do you really think that is possible?

The NSA almost certainly has staff posing as Amazon Web Services employees. They would be negligent not to have infiltrated the company.

One idea is to audit the use of the encryption key.

I'm curious how one could implement dual control of keys on Amazon, or if auditing would have ot be a compensating control for it.

Calls made to KMS are logged in CloudTrail where they can be used for auditing.

I'm assuming CloudTrail logs can be sent to another AWS account with no delete access from the sending account?

Reply on news.ycombinator.com