Privacy is Dead?
In the recent past we have seen successful large scale hacking attacks against high profile targets like Sony, Opm, and Facebook. The sentiment among the average person is that privacy is dead and we should just accept this state of affairs. The truth is there is a slow eroding of your privacy and if you really value it you need to take steps to protect it. Your best weapon for digital privacy is encryption. In this post I'll show you a simple use case of AWS KMS; their encryption key management service.
There is certainly a lot to be said about encryption but I'm not trying to write a manuscript here that is comparable in length to Crime and Punishment. However, If you know anything about encryption it really all boils down key management. This is where KMS is an answer.
KMS is a centralized service to keep track of your encryption keys. KMS integrates through AWS services and in the sequel I'll show you a simple use case with the S3 service. One upside is that KMS has a very smooth integration with Cloudtrail so that you can audit the use of your keys. This gives you an extra level of security.
Let's do Some Trust Falls
The big question here is security. Can you trust AWS with your encryption keys? Can you really trust anyone? In any case, AWS uses validated hardware security modules (HSMs) where your encrypted keys are only used in memory. Nobody, including AWS employees can access your plain text keys from KMS. I know this because AWS told me?!? Your plain text keys are never written to disk and only exist in the volatile memory of the HSM in the time need to perform a given cryptographic operation. If you are the ultra paranoid type you can import your own master key. There is some overhead to this though. You become responsible for security that you could otherwise defer to AWS. Then the question becomes where do store that imported key?
KMS with S3
Here I'll login to the AWS console and create a new master KMS key. You can also create your own key and import it. I'll then add an object to an S3 bucket and encrypt it with that master key. Here is what it looks like.
You can see I've called my KMS key testKey. Next I'll make a new user and exclude them from having access to that key. Here is a new user named "Example:
Once "Example" is created I can log into the console as them. However, I will not have any access to S3. What we want to do is download the KMS encrypted object as the new user and see how the encryption obfuscates the payload despite user having "get" access to the object.
You can see here "Example" has no S3 access.
From my original account I can endow "Example" with S3FullACCESS.
Now we can attempt to download the encrypted file. Here are the properties of the file that I have called SomeFile.txt
Notice that Server-side encryption is enabled and you can see the ARN of the encryption key. This is the encryption key that I made earlier. Once I try to download the file you'll see my permission is denied because my account does not have access to that key.
However, from my original account I can download the file and the decryption is handled for me by AWS and KMS.
Trust is a Must
Overall, it makes sense to trust KMS. If they didn't deliver the type of security they promise they would ultimately have a lot to answer for. I've given you one use of a KMS integration but another useful case is encryption of EBS volumes. This provides you another layer of security for your data. Many big companies have been burned by faulty security solutions. Who will be next ?