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 provide in-depth support in order to achieve the best possible data protection available.

“Encryption” is a critical component of a defence-in-depth strategy, which is a security approach with a series of defensive mechanisms designed. It can also further mitigate weaknesses in primary access control mechanisms.

There are multiple cryptography services offered by AWS.

  1. AWS Key Management Service (KMS)

  2. AWS Certificate Manager

  3. AWS Secrets Manager

  4. AWS Cloud HSM

Theoretically, all of the above services are working as Hardware Security Modules (HSMs). Out of these, Cloud HSM gives you the most control and you’re basically responsible for managing it. All the other services are basically managed by AWS.

However, out of these services, I am only going to discuss the key features and trends relating to AWS KMS in this blog post. Most of the content is an extract of AWS documentation and AWS re:Invent conference videos. I’m hoping this blog post will help you have a more concise picture of key points related to this topic.

KMS Features

  1. Managed service that enables you to easily create and control the keys used for cryptographic operations

  2. shared key management infrastructure with FIPS 140–2 Level 2 compliance

  3. Currently supports 50+ AWS services

  4. regional service

  5. Highly Available (HA). Keys are kept as multiple copies in a single region to make sure of 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 key encryption. But now it supports both key encryption aspects [3]. With the support of asymmetric key encryption, it widened the aspect of inter-operability 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 the data to be encrypted is more than 4KB, you will 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 can encrypt your data using Data Key A. Then, in order to keep Data Key A safe, it will be encrypted using Data Key B. Now Data Key B is not safe and again it will be encrypted using Data Key C. You get the drift. This will go on till it reaches the point where the infrastructure itself needs to protect the last key, which is the Customer Master Key (CMK). This process of having multiple layers of encryption is referred to as envelope encryption.

Customer Master Keys (CMK)


CMK is a logical representation of a key. These keys can be generated by KMS or by being imported. CMKs are always protected by AWS KMS infrastructure and always resides within KMS HSM housing. Any external party communication takes place via API.

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.

There are three types of CMK.

  1. Customer Managed 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. AWS Owned 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 region-specific and if it needs to be used in another region then you need to use a different CMK in the target region.

KMS Encryption (Symmetric)


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

The Symmetric Encryption process can be explained in several steps (see Figure 3 (b)).

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 stored along with the encrypted data.

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

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

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

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

Step 6: The returned encrypted data key will be stored alongside the encrypted cipher text.

In order to keep all the keys safe, CMK should also be encrypted as the last key of the envelope encryption chain. However, AWS ensures that it is kept as is by confirming its security within its infrastructure.

When you want to decrypt the Encrypted Data (following symmetric data encryption rules), you have to send a request to KMS (via an API call) for CMK to decrypt the Encrypted Data Key and use the 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, the 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. These 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 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.

Don’t forget to make sure to NOT 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.

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 keyfor encryption and decryption.
  3. Maintains inter-operability: Unlike in KMS symmetric key encryption, this is more inter-operable 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 idalong with your operations. This is not a requirement in symmetric API calls.

Now, let’s discuss the steps involved in a KMS asymmetric encryption (see Figure 6).

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 an API call) if you require 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 dedicated access to HSM appliances. It is important to note that, only you have access to your keys and operations on the keys. HSMs are located in AWS data centers and are managed and monitored by AWS. They are FIPS 140–2 Level 3 compliant and are handled inside your VPC, in isolation from the rest of the network. We will discuss more about 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/

Crishantha Nanayakkara

Vice President - Technology