AWS KMS

The fully managed, highly available AWS Shared Key Management Infrastructure

An effective security strategy begins with stringent access control and the least privilege necessary for persons or systems accessing data [4]. Therefore, AWS requires that you manage your own access control policies and also support in depth to achieve the best possible data protection available.

“Encryption” is one of the critical components of the popular Zero-Trust Architecture [8] strategy, where a series of defensive mechanisms are defined. It further can mitigate weaknesses in your primary access control mechanisms to a greater extent.

There are multiple cryptography services are offered by AWS.

1. AWS Key Management Service (KMS)
2. AWS Certificate Manager
3. AWS Secrets Manager
4. AWS Cloud HSM

Out of these services, I am only going to discuss key features and trends related to AWS KMS in this blog post. Hope this will help to have a more concise picture of key points related to the topic. So, lets dive in!

KMS Features

1. Managed service that enables you to easily create and control the keys used for cryptographic operations.
2. A shared key management infrastructure with FIPS 140–2 Level 2 compliance
3. Currently supports 50+ AWS services.
4. A regional service
5. Highly Available (HA). Keys are kept as multiple copies in a single region to make sure its durability and reliability.
6. It integrates fully with IAM and CloudTrail for Permission Management and Auditing respectively.
7. Supports both symmetric and asymmetric key encryption. Until 2019, it only supported symmetric but now it supports both key encryption aspects [3]. With the support of asymmetric key encryption, it widened the aspect of interoperability by being able to connect to many other Key Management Infrastructures in the market [3].

KMS supports two types of keys

1. Customer Master Keys (CMK)
2. Data Encryption Keys.

By default, CMK can encrypt data up to 4KB.

If data to be encrypted is more than 4KB, you have to use (CMK + Data Encryption Key) combination, which is known as the KMS Two Tier Architecture.

KMS Two Tier Architecture / Envelope Encryption

In KMS Two Tier Architecture, you may encrypt your data using Data Key A, then in order to keep Data Key A safe, it will encrypted using Data Key B. Now Data Key B not safe and again it will be encrypted using Data Key C. This will go on like until it reaches where the infrastructure itself needs to protect the last key, which is Custmer Master Key (CMK). This process of having multiple layers of encryption is called as envelop encryption.

Customer Master Keys (CMK)

CMK is a logical representation of a key. These keys can be generated by KMS or imported. CMKs are always protected by AWS KMS infrastructure and always resides within KMS HSM housing. If any external party needs to communicate, it is via API only.

CMKs can encrypt or decrypt data up to 4KB in size. They are being created, managed and deleted entirely within KMS. They never leave the KMS region or KMS infrastructure unencrypted.

Figure 1 — CMK within KMS (Source: AWS Documentation)

There are three types of CMK.

1. AWS owned CMK — Keys used by AWS on a shared basis across many AWS accounts. You normally do not interact with this CMK.
2. AWS managed CMK — Used as the default CMK within most of the AWS services and named under the AWS service name (aws/<service-name>). You are not able to manage or change its configurations (Key Policies, Rotation)
3. Customer managed CMK — You are able to create your own CMK. You are allowed to rotate keys, key policies can be defined and can be enabled / disabled. Customer Managed CMKs are regional specific and if you want to use in another region you need to use a different CMK in the target region.

Figure 2 — The CMK comparison

KMS Encryption (Symmetric)

As explained, until recently KMS encryption and decryption was supported through symmetric encryption (See Figure 3(a)).

Figure 3(a) — KMS Symmetric Key Encryption and Decryption (Source: AWS Documentation)

The Symmetric Encryption process can be explained with multiple steps (See Figure 3 (b)).

Figure 3 (b) — KMS Symmetric Encryption Process

This diagram explains how a plain text gets encrypted and how this key, which is used to encrypt the plain text is again encrypted by KMS and store along with the encrypted data.

Step 1: Create a Customer Managed Key (CMK) either using AWS console or via AWS CLI

Step 2: You application (which is running KMS SDK) or any other AWS service request for a Data Key (via an API call) in order to encrypt a plain text.

Step 3: KMS returns both Data Key and the encrypted Data Key (encrypted by CMK)

Step 4 and 5: You application or the AWS service will consume the Data Key to encrypt the plain text and generate the cipher text (encrypted data).

Step 6: Returned encrypted data key will be stored along side the encrypted cipher text.

In order to keep all the keys safe, CMK should also be encrypted as the last key of the envelop encryption chain. But AWS makes sure keep it as it is by confirming its security within the infrastructure.

When you want to decrypt the Encrypted Data (following the symmetric data encryption rules), you have to send a request to KMS (via an API call) for requesting CMK to decrypt the Encrypted Data Key and use that Unencryted Data Key to decrypt the Encrypted Data.

In KMS symmetric encryption, for both encryption and decryption we need to make API calls to KMS. This is a significant feature in the KMS symmetric encryption mechanism.

P.Note: After this process, Data Encryption Key (unencrypted) will be deleted. When you want to decrypt the data, we can request a Data Key from KMS. This is all done to enhance security in the system.

CMK Key Policy

Policies attached to IAM identities are called Identity-based Policies (IAM Policies). Policies attached to resources outside of IAM are called Resource-based Policies. In AWS KMS, you “must” attach resource-based policies to your CMKs. They are called Key Policies.

All CMKs have a Key Policy, and you must use it to control access to a CMK. IAM Policies are not sufficient to allow access to CMK, although you can use them in combination with a CMK Key Policy.

For example, even with Amazon S3 Full Access (An IAM Policy) for a given IAM user or an IAM role, this full access permission will be limited by the permission criteria defined within the CMK Key Policy.

By default, unless you specify any IAM user or role restrictions, it enables the root user in the account to add IAM polices that reference the key (See Figure 4). However, it is highly recommended that you change the default CMK policy to align with your organization’s best practices for least privilege.

Figure 4 — KMS default Key Policy

Please do make sure NOT to include kms:* permissions in an IAM policy. This policy would grant the principal both administrative and usage permissions on all CMKs to which the principal has access. Similarly, including kms:* permissions for the principals within your key policy gives them both administrative and usage permissions on the CMK.

CMK Key Rotation

Cryptographic best practices discourage extensive reuse of encryption keys. When you enable automatic key rotation for a customer managed CMK, AWS KMS generates new cryptographic material for the CMK every year. AWS KMS also saves the CMK’s older cryptographic material in perpetuity so it can be used to decrypt data that it encrypted. AWS KMS does not delete any rotated key material until you delete the CMK.

The key rotation changes only the CMK’s backing key, which is the cryptographic material that is used in encryption operations (See Figure 5). Old backing keys are still kept within KMS for any decryption in the future.

The CMK is the same logical resource, regardless of whether or how many times its backing key changes. The properties of the CMK do not change, as shown in the following image.

Figure 5— Key Rotation with Backing Keys (Source: AWS Documentation)

AWS Managed CMK key rotation happens every three years by default and you cannot change it. Customer Managed CMK key rotation happens every year (if you enable it).

Automatic key rotation is not supported for imported keys, asymmetric keys, or keys generated in an AWS CloudHSM cluster using the AWS KMS custom key store feature. If you choose to import keys to AWS KMS or asymmetric keys or use a custom key store, you can manually rotate them by creating a new CMK and mapping an existing key alias from the old CMK to the new CMK.

If you choose to have AWS KMS automatically rotate keys, you don’t have to re-encrypt your data. AWS KMS automatically keeps previous versions of keys to use for decryption of data encrypted under an old version of a key. All new encryption requests against a key in AWS KMS are encrypted under the newest version of the key.

If you manually rotate your imported or custom key store keys, you may have to re-encrypt your data depending on whether you decide to keep old versions of keys available.

KMS Encryption (Asymmetric)

Some of the key features are:

1. Using key pairs (public and private keys): These will be leveraged for encryption/decryption and signing / verification purposes.
2. Encryption and decryption happens outside of KMS HMS: Unlike in symmetric KMS encryption, where you have a single data key for encryption and decryption.
3. Maintains interoperability: Unlike in KMS symmetric key encryption, this is more interoperable with other key management systems by not maintaining any proprietary meta-data along with its encryption/ decryption operations. Each time when you do a KMS API call, you need to pass the key id along with your operations. This is not a requirement in symmetric API calls.

Now, lets discuss the steps involved in an KMS asymmetric encryption (See Figure 6).

Figure 6 — KMS Asymmetric Encryption and Decryption

Step 1: Request (via an API call) KMS to create a key pair (public and private).

Step 2: After creating the key pair, as the user, you can download the public key of the key pair and use it outside of KMS.

Step 3: You or a third party can use this public key for message encryption.

Step 4: This encrypted message can be sent to KMS (via API call) if you required to decrypt the message.

Step 5: KMS decrypts the message with the help of the private key of the key pair.

What is Cloud HSM?

The Hardware Security Module (HSM) is a dedicated hardware security module under your exclusive control. That means you get the dedicated access to HSM appliances. Only you have access to your keys and operations on the keys. HSMs are located in AWS data centers and it is managed and monitored by AWS. They are FIPS 140–2 Level 3 complied and handled inside your VPC, isolated from the rest of the network. We will discuss more about the CloudHSM capabilities in another blog post.

Until then happy encrypting with AWS!

References

1. Rotating Customer Keys: https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html#rotate-keys-how-it-works
2. AWS re:Invent 2019: Using AWS KMS for data protection, access control, and audit: https://www.youtube.com/watch?v=hxWvbNvj2lg
3. Digital Signing with the new asymmetric keys feature: https://aws.amazon.com/blogs/security/digital-signing-asymmetric-keys-aws-kms/
4. AWS re:Invent 2019: Achieving Security Goals with AWS CloudHSM: https://www.youtube.com/watch?v=Vox-PDRHIUs
5. The importance of encryption and how AWS can help: https://aws.amazon.com/blogs/security/importance-of-encryption-and-how-aws-can-help/
6. AWS KMS Best Practices : https://d0.awsstatic.com/whitepapers/aws-kms-best-practices.pdf
7. Introducing Asymmetric Key Support : https://www.youtube.com/watch?v=rIOhMEnvVrs
8. Zero Trust Architecture: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf