A Deep Dive Into AWS Key Management Service (KMS)

If you reveal your secrets to the wind, you should not blame the wind for revealing them to the trees.

I have created this article in a question-and-answer format to save readers time. I started with What KMS is, and the different types of keys, and covered the depth of Envelope Encryption and its implementation

What is KMS?

1. AWS KMS is a managed service that allows the creation, management, and control of the ENCRYPTION keys and it uses the HSMs to protect the security of the keys.
2. It’s a multi-tenant hardware
3. It doesn’t have any upfront cost and a pay-as-you-go model.
4. It supports Symmetric and Asymmetric keys
5. By default, AWS KMS creates the key material for a KMS key.
6. You cannot extract, export, view, or manage this key material. Also, you cannot delete this key material; you must delete the KMS key.
7. AWS KMS also supports multi-region keys, which let you encrypt data in one AWS Region and decrypt it in a different AWS Region.

AWS KMS Keys

1. AWS KMS keys are the primary resource in AWS KMS.
2. You can use a KMS key to encrypt, decrypt, and re-encrypt data. It can also generate data keys that you can use outside of AWS KM
3. An AWS KMS key is a logical representation of an encryption key.
4. In addition to the key material used to encrypt and decrypt data, a KMS key includes metadata, such as the key ID, creation date, description, and key state.
5. You create KMS keys in AWS KMS. Symmetric KMS keys and the private keys of asymmetric KMS keys never leave AWS KMS unencrypted.
6. By default, AWS KMS creates the key material for a KMS key. You cannot extract, export, view, or manage this key material.
7. Also, you cannot delete this key material; you must delete the KMS key.
8. However, you can import your key material into a KMS key or create the key material for a KMS key in the AWS CloudHSM cluster associated with an AWS KMS custom key store.
9. AWS KMS also supports multi-region keys, which let you encrypt data in one AWS Region and decrypt it in a different AWS Region.

What are the steps to create CMK in KMS?

1. Create KMS Key: Here, we go ahead and create Keys. Alias helps us reference the keys if we have multiple KMS Keys
2. Create Key Administrator: We define Key Administrators with full permission on the key.
3. Create Key Usage Permission: We define Key Usage Permission as who will have access to use this key for Encryption and Decryption.
4. Verify the Key policy: AWS will generate the Key policy. Accordingly, you just verify and click “Finish “

How can you Encrypt data using CMK from KMS?

Step 1: Plain text to Base64 Encrypted CipherText

Step 2: Base64 Encoded file to Binary Encoded File

The plaintext secret is provided as an option to the KMS Encrypt command via: ‘ — plaintext file://secrets.json’

1. KMS Encrypt encrypts the plaintext
2. AWS KMS Encodes the result to Base64.
3. The Base64 encoded ciphertext is returned in JSON format. Ordinarily, the standard AWS encrypt command will just return the results in JSON to the terminal, and the process would stop here.
4. The Base64 encoded ciphertext contained in the CiphertextBlob of the JSON results is decoded to binary. The binary results are saved to a file

How can you Decrypt using KMS?

Step 1: Decrypt the Cipher Text and Encoded into Base 64

Step 2: Finally, base64 is decoded into plaintext

The following diagram shows the steps:

Encryption Context

All AWS KMS cryptographic operations with symmetric CMKs accept an encryption context, an optional set of key-value pairs that can contain additional contextual information about the data.

AWS KMS uses the encryption context as additional authenticated data (AAD) to support authenticated encryption.

You cannot specify an encryption context in a cryptographic operation with an asymmetric CMK. The standard asymmetric encryption algorithms that AWS KMS uses do not support an encryption context.

When you include an encryption context in an encryption request, it is cryptographically bound to the ciphertext such that the same encryption context is required to decrypt (or decrypt and re-encrypt) the data.

If the encryption context provided in the decryption request is not an exact, case-sensitive match, the decrypted request fails. Only the order of the key-value pairs in the encryption context can vary.

The encryption context is not secret. It appears in plaintext in AWS CloudTrail Logs so you can use it to identify and categorize your cryptographic operations.

KMS Limitation

We can encrypt a maximum of 4 KB of data with CMK. Since data travels over the network, there can be latency issues.

Steps to use your KEY MATERIAL in KMS

1. A customer master key (CMK) contains the key material used to encrypt and decrypt data.
2. When we create a CMK, by default, AWS creates key material for that CMK. However, we do have the option to create a CMK without key material and then import our key material into the CMK.
3. The following are the main steps to use your key material to create CMK:

a. Create a “symmetric CMK” with NO key material — To get started with importing key material, first create a symmetric CMK whose origin is EXTERNAL.

NOTE: You CAN NOT use Asymmetric CMK to use your key material

This indicates that the key material was generated outside of AWS KMS and prevents AWS KMS from generating key material for the CMK. In a later step, you will import your key material into this CMK.

b. Download the wrapping key and import token — After completing step a, download a wrapping key and an import token. These items protect the import of your key material to AWS KMS.

c. Encrypt the wrapping key material — Use the wrapping key that you downloaded in step b to encrypt the key material that you created on your system.

If you use OPEN SSL, the following commands will be used to create key material:

1. OpenSSL rand -out PlantextKeyMaterial.bin 32
2. OpenSSL rsautl -encrypt -in PlantextKeyMaterial.bin -oaep -inkey wrappingKey_65803750–222b-413a-ac0d-3bab20a77630_04202211 -keyform DER -pubin -out EncryptedMaterial.bin

d. Import the key material — Upload the Encrypted key material that you created in step c and the import token that you downloaded in step c.

What happened if you accidentally deleted the imported key material in CMK?

When you import key material, you have the option of specifying a time at which the key material expires. When the key material expires, AWS KMS deletes the key material, and the customer master key (CMK) becomes unusable. You can also delete key material on demand. Whether you wait for the key material to expire or you delete it manually, the effect is the same. AWS KMS deletes the key material, the CMK’s key state changes to the pending import, and the CMK is unusable. To use the CMK again, you must reimport the same key material.

You can download the new wrapping key and import the token and import the original key material into the existing CMK.

NOTE: You CAN NOT use the Original Wrapping key and import token. It needs to be a NEW wrapping key and import token.

Why do you need to import your Key material?

Prove that randomness meets your requirements (Company Compliance)

To be able to delete key material without a 7–30 days wait. Then be able to import them again

To be resilient to AWS failure by storing keys outside of AWS

Deleting CMK

Deleting CMK in AWS KMS would delete the key material and all the associated metadata associated with the CMK. This process is irreversible.

After CMK is deleted, we can no longer decrypt the data that was encrypted by that CMK.

Before it is an irreversible process, AWS KMS enforces a waiting period.

The waiting period can be from a minimum of 7 days to up to a maximum of 30 days. The default is 30.

During the waiting period, CMK cannot be used in any cryptographic operation.

Types of KMS Keys

1. AWS Managed Customer Master Keys (CMK)
2. Customer Managed Customer Master Keys (CMK) in KMS (here the key material is generated by AWS)
3. Customer Generate Keys in KMS with External Key Material
4. AWS Owned CMK — NOTE this is not as same as AWS-managed Keys

KMS Key Rotation

The following chart summarizes the key differences and similarities between AWS-managed CMKs and customer-managed CMKs.

Automatic Key Rotation is not supported in the following types:

1. Asymmetric CMKs
2. CMKs in custom key stores
3. CMKs that have imported key material
4. AWS Owned CMK

KMS Access Control

In KMS, by default, all the CMKs have a key policy attached to them.

We can control access to KMS CMK using the following three ways:

i) Using Key Policies

ii) Using IAM Policy in combination with key policies

iii) Using KMS Grants

What is KMS Grant?

Grant is like a secret token. It provides temporary and granular permission (encrypt, decrypt, re-encrypt, describe key)

A Grant programmatically delegates the use of your CMK to the user in your account or another account

Using Grants, you can ONLY ALLOW the access and you CAN NOT PERFORM EXPLICIT DENY

Create-grant — adds a grant and defines the operations the grantees can perform

User Key policies for relatively static permissions, or explicit deny

KMS ViaService

Using kms:ViaService to allow or deny access to your CMK according to which service originates the request — eg. S3, RDS, EBS, Lambda, SQS, SSM, etc.

KMS Cross-Account Access

2 policies need to be updated.

1. KMS Key Policy
2. IAM Policy

Step 1: Enable access in the Key Policy for the account which owns the CMK

Step 2: Enable access to KMS in the IAM Policy for the external account

Let’s look at an example:

Step 1: Change the key policy for the CMK in account 44445555666

Step 2: Add an IAM policy for the users or roles in account 111122223333

KMS Custom Key Store and Default Key Store

KMS default key store: AWS-managed KMS keys that are created on your behalf by other AWS services to encrypt your data are always generated and stored in the AWS KMS default key store.

KMS custom key store: Only customer-managed KMS keys can be stored and managed in an AWS KMS custom key store.

Required Key Policy for public key Encryption and Decryption

Remember the actions.

Okay, time for Envelope Encryption

When you want to encrypt any data that is higher than 4 KB. then we need to use Envelope Encryption.

Envelope Encryption is the practice of encrypting plaintext data with a data key and encrypting the data key under another key.

It is a process where you encrypt plaintext data with a DATA KEY and then encrypt the DATA KEY with a top-level plaintext MASTER KEY.

Steps to create Envelope Encryption

Step 1: The user will create a Customer Master Key in KMS.

Step 2: Generate a Data Key using the CMK. (GenerateDataKey API Call)

Step 3: GenerateDataKey return the following two keys: Plaintext Data Key and Encrypted Data Key

Step 4: The user will use the Plaintext Data Key to Encrypt the Actual data using KMS and after Encryption make sure to delete the Plaintext Data Key

Step 5: Now, we have Encrypted Data and if we want to decrypt the data, we need to send the Encrypted Data Key to KMS and it will return the Plaintext Data Key

Step 6: Using the Plaintext Data Key, and Decrypted data we can decrypt the data in KMS.

Important points to remember

1. GenerateDataKey will generate the following two keys: Plaintext Data Key and Encrypted Data Key
2. Plain text will be encrypted using the Plaintext Data Key
3. After deleting the Plaintext Data Key, we can get it by using the Encrypted Data Key. We need to send it to KMS to Decrypt it.
4. Encrypted Data will be decrypted using the Plaintext Data Key

NOTE: Consider a scenario you are asked that the API must return only the encrypted copy of the data key which will be used later for encryption. Then you will have to choose **GenerateDataKeyWithoutPlaintext** This will return only the Encrypted Data Key

Data Key Caching

AWS has recently introduced a feature called “Data Key Caching” in its AWS Encryption SDK.

Data key caching lets us reuse the data keys that protect our data, instead of generating new data keys for each of the encryption operations.

This comes with security tradeoffs, as the encryption best practices discourage extensive re-use of the data keys. In AWS Encryption SDK, by default, there is a new data key generated for each encryption operation that is performed.

Important Pointers for Data Key Caching

Data key caching saves the plaintext and ciphertext of the data keys you use in a configurable cache. When you need a key to encrypt or decrypt data, you can reuse a data key from the cache instead of creating a new data key.

It is preferred to use data-key caching when there is high frequency needed, the latency involved, and slow master key operations.

KMS Migration

KMS Keys are region-specific. (NOT ANYMORE)

We cannot call a KMS CMK from one region for services in different regions.

If you copy an encrypted snapshot within the same AWS Region, you can encrypt the copy with the same KMS encryption key as the original snapshot, or you can specify a different KMS encryption key.

For cross-region, we cannot use the same KMS key as a snapshot. Instead, we must specify a different KMS CMK that belongs to the destination region.

If you have been using envelope encryption and have encrypted data with data keys, then you will have to decrypt all those data before migrating to a different region

We CAN NOT use KMS to generate a public key/ private key to log in to EC2.

We CAN NOT use EC2 key pair to encrypt EBS volumes, we must use KMS or 3rd party application/tools

KMS through a VPC endpoint

You can connect directly to AWS KMS through a private endpoint in your VPC instead of connecting over the internet.

When you use a VPC endpoint, communication between your VPC and AWS KMS is conducted entirely within the AWS network.

AWS KMS supports Amazon Virtual Private Cloud (Amazon VPC) interface endpoints that are powered by AWS PrivateLink