AWS KMS in a Nutshell
AWS KMS simplified
Introduction
KMS is one of the important services offered by AWS to perform cryptographic operations on sensitive data. KMS stands for Key Management Service. We can use KMS to encrypt variety of things like your Logs, API keys, DB Details, S3 Objects etc…
Envelop Encryption
Envelop Encryption is a mechanism of encrypting Data using a Key and re-encrypting the Key used for Encryption using a different Key. It will be confusing when we look at the statement, but it all makes sense when we start experimenting with this stuff.
Let’s say we have some Data which needs to be encrypted. We need a key to encrypt the Data, let us call that key as Plain_Text_Data_Key. We need to encrypt this Plain_Text_Data_Key with another key, let us call it as Master Key.
So now we have 2 Keys — 1) Plain_Text_Data_Key which is directly used to encrypt the Data, 2) Master_Key which is used to encrypt the Plain_Text_Data_Key. As we are talking about Symmetric encryption, if data is encrypted using Plain_Text_Data_Key, the same key should be used for decryption.
Operations Performed
- Encrypt Data using Plain_Text_Data_Key → Plain_Text_Data_Key[Data]
- Encrypt Plain_Text_Data_Key using
Master_Key →Master_Key[Plain_Text_Data_Key] which produces Encrypted_Data_Key.
Now we end up having 3 keys. Once Encrypted_Data_Key is created, we delete the Plain_Text_Data_Key straight away, so that the decryption isn’t possible directly.
We store the Encrypted_Data_Key with Encrypted Data itself, so that it is easier to identify what Data got encrypted using which Key.
When we need to decrypt the Data, we need to first decrypt the Encrypted_Data_Key with Master_Key which produces Plain_Text_Data_Key, this key can be used to Decrypt the Data. So Decryption is not a straight operation. And the requests to Master_Key can be controlled in such a way that only authorized users can ask Master_Key to decrypt the Encrypted_Data_Key.
If this explanation is put in an image, it looks something like this —
Step: 1 — Data will be encrypted using a Data Key, result is Encrypted Data.
Step: 2 — Data Key will be encrypted using Master Key, result is Encrypted Data Key.
Step: 3 — Encrypted Data key is stored with Encrypted Data only.
Step: 4 — Data Key will be deleted.
Decryption Process
Step: 1 — In order to decrypt the Data, the Data Key should be available, which can be obtained by asking Master key to Decrypt the Encrypted_Data_Key.
Step: 2 — As we have Decrypted the Encrypted_Data_Key which resulted in Data_Key, this key is now used to Decrypt the Data.
With all this said, now we have enough understanding of what two-tier/envelop encryption is. Now let us talk about the same stuff in terms of AWS KMS. The Master_Key which we have talked about is called as Customer Master Key(CMK) in KMS and the Data Key is still called as Data Key.
AWS offers us three types of CMKs for flexible operations —
Customer managed CMKs — We as Customers are allowed to create, own and manage these keys in our Account. We are allowed to control and manage these keys including defining the Key Policies, Rotating the Cryptographic Material, enabling/disabling them, scheduling them for deletion etc…
AWS managed CMKs — These CMKs are created in our account and managed on our behalf by AWS. We are allowed to view these CMKs in our account but are not allowed to rotate them or change their Key Policies as such. Cryptographic operations are performed by AWS Services and not directly by us.
AWS owned CMKs — The primary difference between this CMK and the other two CMKs is that, the other two CMKs live in our account and are only used for our account unlike this CMK which is shared with other other AWS Accounts as well. We are not allowed to view, track or audit these CMKs.
KMS vs CloudHSM
CloudHSM is just another service by AWS which allows us to perform all the cryptographic operations just like KMS does. While KMS is a multi-tenant Service — it also uses HSM(Hardware Security Module), but is shared across multiple tenants whereas Cloud HSM is a dedicated Hardware Security Module in cloud for a single customer. In Cloud HSM you can manage your own encryption keys using FIPS 140–2 Level 3 validated HSMs.
Conclusion
This is just an overview of how KMS works and supports cryptographic operations in AWS. We will discuss on KMS & Cloud HSM in upcoming articles in much more detail.
Some Key Points to keep in mind about KMS —
- KMS supports Audit, all API calls are recorded in Cloud Trail.
- Supports Resource level policies, apart from IAM Policy definitions, Key Policies can be defined, at a much more granular level. For example, a user may encrypt something but may not be able to decrypt the object which he encrypted.
- KMS is a regional service. Keys created in a region are specific to that particular region, cannot be used for Cryptographic operations in an other region.
- KMS is a managed service and you need not worry about the availability and durability of Keys, and is highly scalable.
- At this point of time, it supports 75+ services.
There are two comprehensive White Papers by AWS on KMS, please go through them if this interests you..
AWS KMS Best Practices —
https://d0.awsstatic.com/whitepapers/aws-kms-best-practices.pdf
KMS Cryptographic Details —
https://d0.awsstatic.com/whitepapers/aws-kms-best-practices.pdf
Thank you for reading. You can connect with me on Linkedin . Happy to answer your queries.
