AWS Key Management Service (KMS)


Unencrypted data can be read and seen by anyone who has access to it, and data stored at-rest or sent between two locations, in-transit, is known as ‘plaintext’ or ‘cleartext’ data. The data is plain to see and can be seen and understood by any recipient. There is no problem with this as long as the data is not sensitive in any way and doesn’t need to be restricted.

However, on the other hand, If you have data that IS sensitive and you need to ensure that the contents of that data is only viewable by a particular recipient, or recipients, then you need to add a level of encryption to that data.

But what is data encryption? : This post answers that question by first explaining at a high level what symmetric and asymmetric encryption is, before diving into how the Key Management Service (KMS) can help you achieve the required level of encryption of your data across different services.

We will understand why KMS is key to our data security strategy within our organization and how you can use this service to manage data encryption through a series of different encryption keys, either KMS generated or by using our own existing on-premise keys.

Goal: This post is focused entirely on how AWS KMS, the Key Management Service, can be used to encrypt your data within AWS.

Key Question: How to use KMS Key Encryption to protect your data?

What is KMS?

Let’s explore what the KMS service is and the function that it provides to enhance your data security. Before we dive into KMS itself, I want to first provide a high-level overview of encryption to help you understand which cryptography method AWS KMS uses.

What is data encryption?

Data encryption is the mechanism in which information is altered, rendering the plain text data unreadable through the use of mathematical algorithms and encryption keys. When encrypted, the original plain text is now known as cipher text which is unreadable. To decrypt the data, an encryption key is required to revert the cipher text back into a readable format of plain text. A key is simply a string of characters used in conjunction with the encryption algorithm and the longer the key the more robust the encryption. This encryption involving keys can be categorized by either being symmetric cryptography or asymmetric cryptography.

AWS KMS only uses symmetric cryptography.

Symmetric Key Encryption

So let’s take a look at what this is and what this means. With symmetric encryption, a single key is used to both encrypt and also decrypt the data. So for example if someone was using a symmetric encryption method, they would encrypt the data with a key and then when that same person needed to access that data, they would use the same key that they used to encrypt the data to decrypt the data.

However, if the encrypted data was being read by a different person, that person would need to be issued the same key. Remember, the same key is needed to decrypt the data that was used to encrypt it. As a result, this key must be sent securely between the two parties and here it exposes a weakness in this method. If the key is intercepted by anyone during that transmission, then that third party could easily decrypt any data associated with that key.

AWS KMS resolves this issue by acting as a central repository, governing and storing the keys required and only issues the decryption keys to those who have sufficient permissions to do so. Some common symmetric cryptography algorithms that are used are AES which is Advanced Encryption Standard, DES, Digital Encryption Standard, Triple DES and Blowfish.

Why not asymmetric key encryption?

Now let’s compare this to asymmetric encryption which involves two separate keys. One is used to encrypt the data and a separate key is used to decrypt the data. These keys are created both at the same time and are linked through a mathematical algorithm. One key is considered the private key and should be kept by a single party and should never be shared with anyone else. The other key is considered the public key and this key can be given and shared with anyone. Unlike with the symmetric encryption, this public key does not have to be sent over secure transmission. It doesn’t matter who has access to this public key as without the private key, any data encrypted with it cannot be accessed. Both the private and public key is required to decrypt the data when asymmetric encryption is being used. So how does it work?

If another party wanted to send you an encrypted message or data, they would encrypt the message using your own public key which can be made freely available to them or anyone. It’s public for a reason. The message is then sent to you where you will use your own private key which has that mathematical relationship with your public key to decrypt the data. This allows you to send encrypted data to anyone without the risk of exposing your private key, resolving the issue highlighted with symmetric encryption.

The advantage that symmetric has over asymmetric is the speed of encryption and decryption. Symmetric is a lot faster from a performance perspective. However, it does carry an additional risk as highlighted. Some common examples of asymmetric cryptography algorithms are RSA, Diffie-Hellman, and Digital Signature Algorithm. So now we know that AWS KSM uses symmetric cryptography for its encryption. Let me explain a little more about the service itself.

Key Management Service

The Key Management Service is a managed service used to store and generate encryption keys that can be used by other AWS services and applications to encrypt your data. For example, S3 may use the KMS service to enable S3 to offer and perform server-side encryption using KMS generated keys known as SSE-KMS. There are different types of keys used within KMS which perform different roles and functions. I will go into detail on these key types shortly.

Due to the nature of this service, the contents contain highly sensitive data, the key is to decrypt your private data. As a result, administrators at AWS do not have access to your keys within KMS and they cannot recover your keys for you should you delete them. AWS simply administers the underlying operating system and application. All administrative actions performed by Amazon on the underlying system require dual authentication by two Amazon administrators to make sure the action is correct and will not cause any issues with the service. As AWS has no access to your keys, it’s our responsibility as the customer and users of the KMS service to administer our own encryption keys and administer and restrict how those keys are deployed and used within our own environment against the data that we want to protect.

KMS is only for encryption at rest

It is important to understand that the KMS service is for encryption at rest only which can include for example S3 Object Storage, RDS, EMR and EBS Encryption to name a few. KMS does not perform encryption for data in transit or in motion. If you want to encrypt data while in transit, then you would need to use a different method such as SSL.

However, if your data was encrypted at rest using KMS, then when it was sent from one source to another, that data would be a cipher text which could only be converted to plain text with the corresponding key.

Server-side vs Client-side encryption

Another important aspect of encryption at rest is whether it is done server-side by the server or client-side by the end user. Examples of server-side encryption are back end servers that encrypt the data as it arrives transparent to the end user such as the example I gave earlier with SSE-KMS. The overhead of performing the encryption and managing the keys is handled by the server, in this case S3, not by the client-side application or the end user. Client-side encryption is quite different. Client-side encryption requires the user to interact with the data to make the data encrypted and the overhead of encryption process is on the client rather than the server.

Compliance and Regulation

When working with encrypted data, compliance and regulations are often tightly integrated. As a result, KMS works seamlessly with AWS CloudTrail to audit and track how your encryption keys are being used and by whom in addition to other metadata captured by the APIs used such as the source IP address, et cetera. The CloudTrail logs that are stored in S3 record KMS API calls such as Decrypt, Encrypt, GenerateDataKey and GetKeyPolicy among others as shown on the screen.

When architecting your environment with regards to data encryption, you need to be aware that AWS KMS is not a multi-region service like IAM is for example. It is region specific. Therefore, if you are working in a multi-region system with multi-region failover, you need to establish a Key Management Service in each region that you want to encrypt data.

Components of KMS

Let’s drill down into the different elements and components that make up the KMS service to allow you to understand how it operates and functions. This section will consist of customer master keys, data keys, or data encryption keys, key policies and grants.

Customer Master Key (CMK)

Let me start off by explaining the CMK, the customer master key. This is the main key type within KMS. This key can encrypt data up to 4 kilobytes in size, however it is typically used in relation to your data encryption keys, DEKs. The CMK can generate, encrypt and decrypt these DEKs, which are then used outside of the KMS service by other AWS services to perform encryption against your data.

Types of CMK: Customer managed and AWS managed

It’s important to understand that there are two types of customer master keys.

  • Firstly, those which are managed and created by you and I, as customers of AWS, which can either be created by using KMS or by importing key material from existing key management applications into a new CMK. CMKs that are generated and created by us, rather than AWS, provide the ability to implement greater flexibility, such as being able to manage the key, including rotation, governing access and key policy configuration, along with being able to both enable and disable the key when it is no longer required.
  • And secondly, those that are managed and created by AWS themselves. The CMKs which are managed by AWS, are used by other AWS services that have the ability to interact with KMS directly to perform encryption against data. For example, Amazon S3, in particular, SSE KMS, these AWS managed keys can only be used by the corresponding AWS service that created them within a particular region. As remember, AWS KMS is a regional service. These CMKs that are used by the services, are generally created the first time you implement encryption using that particular service.

Disabling a CMK vs Deleting a CMK: Now there is a big difference between disabling a CMK and deleting a CMK, which can have significant effect on being able to access your data, governed by the CMK that encrypts it. I shall discuss more on these differences in an upcoming lecture, where I’ll talk about key management.

Like the AWS managed CMKs, AWS services can be configured to use your own customer CMKs, too. Depending on the service and your own internal security policies, the choice is yours as to which CMK the supported services uses to encrypt your data. Any CMKs created within KMS are protected by FIPS, validated cryptography modules.

Envelope Encryption

As I mentioned in the previous few slides, data encryption keys, or data keys, are created by the CMK and are used to encrypt your data of any size. When a request to generate a key is issued, the CMK specified in the request will create a plain text data encryption key and an encrypted version of the same data encryption key. Both of these keys are then used to complete the encryption process. As a part of this process, your plain text data is encrypted with the plain text data key using an encryption algorithm. Once encrypted, the plain text data is deleted from memory and the encrypted data key is stored alongside the encrypted data. If anyone gains access to the encrypted data, they will not be able to decrypt it, even if they have access to the encrypted key, as this key was encrypted by the CMK, which remains within the KMS service. This process of having one key encrypted by another key is known as envelope encryption. The only way you would be able to decrypt the object is if you have the relevant decrypt permission for that CMK that the data keys are associated to.

Let me explain the process of how these data keys are used with the CMK outside of KMS, such as S3. And I shall stick with the example of SSE KMS, server side encryption, using KMS keys.

Example: Upload document to S3 with SSE-KMS (Encryption)

Suppose that Bob wants to upload a document that contains sensitive information to an S3 bucket. Bob wants to make sure it’s encrypted, and he’s going to select server side encryption using KMS. So S3 will handle the encryption process for him using keys that are generated by the KMS service. So when he uploads it to his S3 bucket, he specifies that he wants to use SSE KMS.

At this point S3 realizes that it needs to invoke services from the KMS service. So it calls upon KMS to generate some data keys for us. So it then sends a request over to KMS. At this point, KMS uses the customer master key, the CMK, to generate two keys. Now the first key is just a plain text data key, and the second key that’s generated is the same key but an encrypted version of that key.

Now both of these keys are then sent back to S3. So S3 receives both those keys, both the plain text key and the encrypted data key. Now S3 has all the keys it needs to perform the encryption process. So S3 will take the object uploaded by Bob, which is his document. It will then combine this with the plain text data key, and it will perform an encryption algorithm, and then that will generate an encrypted version of Bob’s document. So now his document is encrypted. And S3 will store and associate the encrypted data key alongside this object. So these two objects are then stored on S3. Meanwhile, the plain text data key is then deleted from memory. So that’s how encryption works using SSE KMS.

So just to recap. The end user or client will upload the object to S3, specifying that SSE KMS should be used. S3 will then contact KMS, and using the specified CMK, it will generate two data keys, a plain text data key and an encrypted version of that data key. Both of these keys are then sent back to S3, at which point S3 can then encrypt the object that was uploaded, using the plain text data key, to generate an encrypted version of your object. And then S3 will associate and store the encrypted data key alongside your encrypted object.

Example: Retrieve encrypted document from S3 (Decryption)

So Bob will request the object from S3. At this point, S3 knows that the object is encrypted and it has the associated encrypted data key. So what it does, it sends that associated encrypted data key over to KMS, and it asks KMS to generate a plain text data key. So what it’ll do, it’ll use the same CMK plus the encrypted data key. And this will generate a plain text version of that data key. Now just this single plain text data key is then returned to S3. At this point, S3 can then access the encrypted object and use the plain text data key that it just got back from KMS, perform an encryption algorithm again to decrypt the object. And this will generate a plain text version of the object, at which point this can then be returned to Bob.

So just to recap. The user will request access to the encrypted object. S3 will then send the associated encrypted data key to KMS, to generate a plain text version of that encrypted data key, using the associated CMK. This plain text data key is then sent back to S3. The plain text data key is then used to decrypt the encrypted object, generating a plain text version of the object, which can then be returned to the user. So that’s how the encryption process works for S3, SSE KMS.

Key Policies

The key policy is a security feature within KMS that allows you to define who can use and access a particular key within KMS. These policies are tied to the CMKs, making these resource-based policies, and different key policies can be created for different CMKs. These permissions are defined within this key policy document, which is JSON-based, much like IAM policies are.


Grants are another method of controlling access and use of the CMKs held within KMS. Again, they are a resource-based policy, but they allow you to delegate a subset of your own access to a CMK for principals, such as another AWS service within your AWS account. The benefit of this is that there is less risk of someone altering the access control permissions for that CMK.

If anyone has the KMS put key policy permission, then they could simply replace the key policy with a different one. Using grants eliminates this possibility, as a grant is created and applied to the CMK for each principle requiring access. Again, coming up in the following lecture, I shall dive deeper into grants and how they work.