AWS Key Management Service - An Introduction

The next topic in our series would be about Key Management Service before we can discuss how encryption happens in the S3 buckets. This is a separate topic in itself. Lets start.

AWS Key Management Service (AWS KMS) lets us create, manage, and control cryptographic keys across your applications and more than 100 AWS services.

AWS KMS is a secure and resilient service that uses hardware security modules that have been validated under FIPS 140-2, or are in the process of being validated, to protect your keys.

Any AWS service using encryption uses KMS.It is a regional and public service. Every region is isolated when using KMS. It helps to create, store and manage cryptographic keys. These keys can be used to create plain text information to cipher text information and vice-versa. It is able to handle both symmetric and asymmetric keys (private asymmetric and public asymmetric keys)

It is capable of performing actual cryptographic operations. (encrypt, decrypt etc.)

The KMS keys never leave the KMS service. Can create, import, manage keys etc. But keys are locked inside KMS

It provides FIPS 140-2 compliant service which is a US security standard. Some features are compliant with level three standard. The keys were earlier known as CMK but currently they are known as KMS keys. They Are used by KMS within cryptographic operations

Users can use them, apps can use them and other AWS services can use them. KMS Keys are logical.

They can be thought of as containers for physical key material

KMS Keys contains:

• key ID: unique identifier for the key

• creation date

• key policy (a type of resource policy)

• description and state of key (active or inactive)

Every KMS Key is supported by physical key material. It is this material that is used to encrypt and decrypt things. Physical material can be generated by KMS or imported into KMS. This physical material inside KMS Keys are used to encrypt or decrypt data that’s upto 4kB in size. It has other features to overcome the 4 kB limitation.

Lets assume that there is a user who interacts with KMS. The first interaction after picking a region is creating a key. So user runs createkey operation to create KMS key. Then KMS key contains physical backing key material. This is the most important thing that KMS creates, stores and manages. KMS keys are encrypted before they are store persistently on disk. Now there is an encrypted KMS key

Next interaction might be to encrypt some data. The encrypt call is used providing the key to use and some data to encrypt. Provided that user has required permissions to access the key, KMS decrypts key & uses it to encrypt the plain-text data and returns the encrypted data to the user.

So KMS is handling this cryptographic operation

If the data needs to be decrypted, then user uses Decrypt operation and provides the encrypted data. The key to be used to decrypt data is encoded in the cipher text of the data to be decrypted. If user has decrypt permissions, KMS decrypts the KMS keys and uses it to decrypt the cipher text and provides the data in plain-text

The permissions to generate keys, encrypt and decrypt are all different. The permissions are granular Note that the KMS key does not leave KMS at any stage or stored in plain-text at any stage. To perform each operation like creating the keys, assigning the permissions, for encrypt and decrypt operations, separate permissions are required

Different users can be given different permissions w.r.t KMS. (a.k.a role separation), For example, some people might have permission to encrypt but not generate keys and assign permissions and decrypt.

Data Encryption Keys

KMS can only perform cryptographic operations only on data that has upto 4kb in size. Then how is the 4kb limitation is overcome?

KMS has another type of keys – data encryption keys (DEK)– created using KMS keys Using GenerateDataKey operation and KMS Key, a DEK is generated and this DEK can be used to encrypt data that is greater than 4kb size. DEK is linked to a specific KMS Key that was used in creating them. So KMS knows which DEK is created using which KMS key.

The DEK is not stored in KMS. It is provided to user or service using KMS and then discards it. Because KMS itself does not encrypt/decrypt using DEKs. That is done either by the user or the service that uses the DEK

Data is encrypted using plaintext DEK and then it is discarded. Generally the encrypted data and the encrypted DEK are stored together. KMS by itself doesn’t encrypt the data greater than 4 kb. Either the user or the service using the DEK does it. KMS doesn’t track usage of DEK

The same DEK can be used to encrypt multiple files or new DEKs can be generated for each of them The data and the DEK used to encrypt it are stored on same disk in an encrypted form. So the administration is easy and security is maintained

Data encrypted by DEK can be decrypted by passing the encrypted DEK back to KMS Then use the decrypted DEK is used to decrypt the data and the decrypted DEK is discarded.

Key concepts:

KMS key are stored within KMS specific to that region and never leave the region or the service

KMS Keys cannot be extracted and any interactions with KMS keys is done through APIs provided by KMS.

They are either AWS Owned or Customer owned

AWS Owned KMS keys are owned and managed by AWS services to be used in multiple accounts

Customer Owned KMS Keys are 2 types

AWS Managed Customer owned KMS keys and Customer managed and owned KMS keys.

AWS Managed KMS keys are created when a service such as S3 use KMS for encryption

Customer managed KMS keys are created by customer.

Customer managed KMS keys are much more configurable, meaning we could allow cross account access

Can edit the key policy. Can allow other AWS accounts to access KMS keys to perform ops.

Both key types support key rotation.

Rotation is the process in which the physical backed key is changed.

With AWS managed KMS keys, the keys are rotated for every 365 days or 1 year and key rotation can’t be disabled.

With customer managed KMS keys, rotation is optional. If rotation is enabled then it can happen once an year.

The backing key, physical key material [ and all previous ones are stored, even after rotation so that data encrypted by older keys can be decrypted

A shortcut to a particular KMS key , called an alias, can be created, per region.

Neither aliases or keys are global

KMS has to be explicitly told that keys trust the AWS account they are in.

Key Policies and Security

Permissions on keys are handled in a separate manner

Many services will trust the account they are contained in. If we grant access via an identity policy, it is alllowed unless there’s an explicit deny

In KMS this trust is added explicitly added on a key policy or its not added

Starting point of kms keys are key policy - similar to resource policies.

Every KMS key has a key policy

Every customer managed key can have its policy changed

Unlike other services, KMS has to be told that the keys trust the account that they are part of.

We need key policy to grant access to a key using Identity services

Generally KMS is managed using key policies, trusting the account and then using identity policies to let IAM users interact with the key

In high security environments, this trust should be removed and permissions be added in the key policy
The IAM permissions for KMS are granular and split based on functions. This way the product admins or others aren’t given rights to access the data encrypted by KMS