Do you think IIT Guwahati certified course can help you in your career?
Introduction
Hello Reader!
AWS Key Management Service (KMS) provides centralized management of the cryptographic keys required to secure our data. In this article, we will learn about the various concepts used in the AWS Key Management Service.
What is AWS Key Management Service?
AMS Key Management Service is a service provided by AWS for the creation and control of the cryptographic keys used for protecting data. Hardware security modules are used to protect and validate our AWS KMS keys. This service also integrates with most of the other AWS services that encrypt data.
We can use AWS KMS API for creating and managing KMS keys and their special features like custom key stores and use them in cryptographic operations.
We can create and manage the AWS KMS keys in the following ways:
This service helps in creating, editing, and viewing symmetric and asymmetric KMS keys.
Using this service, we can control the access to KMS keys by making use of key policies, IAM policies and grants. It also supports attribute-based access control, and we can refine policies using condition keys.
Creation, deletion, listing, and updating of aliases are also possible.
We can enable and disable KMS keys using this service.
Finally, we can delete the KMS keys to complete their key lifecycle.
Let us discuss the terminologies used in AWS Key Management Service and learn how they work together to help in the protection of data.
AWS Key Management Service Keys
AWS Key Management Service keys are the primary resource in the key management service. These keys can be used for encryption, decryption and re-encryption of the data. This service can also generate keys that can be used outside of AWS Key Management Service. Furthermore, we can create and use asymmetric keys along with symmetric keys for encryption or signing.
An AWS KMS Key is a logical representation of an encryption key. 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.
A basic KMS key is a symmetric encryption key that represents a cryptographic key used for encryption and decryption. We cannot delete just the material of the key and have to delete the KMS key entirely. The additional feature of using AWS KMS is that it supports multi-Region keys, which means that we can decrypt data in different AWS regions even when the data is encrypted in one AWS region.
Customer Keys and AWS Keys
The KMS keys that are created by a customer are termed Customer Managed Keys. While the KMS keys that are created in our AWS account by AWS services are AWS Managed Keys and the KMS keys that are created in a service account are called AWS Owned Keys.
Customer Managed Keys
Customer Managed Keys are created by the user or the customer. These keys can view the metadata and manage them; however, they are only used for the AWS account. The customers exercise full control over these keys and can establish and maintain key policies and grants, enable and disable them, create aliases and schedule the KMS keys for deletion.
DescribeKey operation can be used to definitively identify a Customer managed keys, and these keys appear on the Customer managed keys page of the AWS Management Console for AWS KMS. We can also use them in cryptographic operations and audit usage in AWS CloudTrail logs.
AWS Managed Keys
AWS Managed Keys are created in the user’s account and are used for creating and managing keys on the user’s behalf by an AWS service integrated with AWS KMS.
We can view AWS-managed keys in our account, view their key policies, and audit their use in AWS CloudTrail logs. However, these keys cannot be managed or rotated, and their key policies cannot be changed.
These keys can also be identified using the DescribeKey operation or using their aliases - aws/ service-name, for example, aws/redshift.
All AWS-managed keys are rotated automatically every three years, and we cannot change this rotation schedule. Also, we do not need to pay a monthly fee for these keys. They can be subjected to fees for use in excess of the free tier.
AWS Owned Keys
These keys are a collection of KMS keys that an AWS service owns and manages for use in multiple AWS accounts. Although AWS-owned keys are not in our AWS account, an AWS service can use the associated AWS-owned keys to protect the resources in our account.
We do not need to create or manage the AWS-owned keys, and neither can we view, use, track or audit them. The users are not charged for using AWS-owned keys, and the rotation of these keys varies across services.
Symmetric Encryption KMS Keys
When a KMS Key is created, by default, it is a symmetric key and is used for symmetric encryption.
In AWS KMS, a symmetric encryption KMS key represents a 256-bit encryption key that never leaves AWS KMS unencrypted. To use a symmetric encryption KMS key, we must call AWS KMS. Symmetric encryption keys are used in symmetric encryption, where the same key is used for encryption and decryption.
Technically, the key spec for a symmetric key is SYMMETRIC_DEFAULT, the key usage is ENCRYPT_DECRYPT, and the encryption algorithm is SYMMETRIC_DEFAULT.
We can use a symmetric encryption KMS key in AWS KMS to encrypt, decrypt, and re-encrypt data and generate data keys and data key pairs. We can also create multi-Region symmetric encryption KMS keys, import our own key material into a symmetric encryption KMS key, and create symmetric encryption KMS keys in custom key stores.
Asymmetric KMS keys
An asymmetric KMS key represents a mathematically related public key and private key pair. The private key never leaves AWS KMS unencrypted.
To use the private key, we must call AWS KMS. We can use the public key within AWS KMS by calling the AWS KMS API operations, or we can download the public key and use it outside of AWS KMS. Additionally, we can also create multi-Region asymmetric KMS keys.
Data keys
Data Keys are symmetric keys used for the encryption of data, including large amounts of data and other data encryption keys. Data keys are returned to us for usage outside of AWS KMS and hence are different from symmetric keys.
When AWS KMS generates data keys, it returns a plaintext data key for immediate use (optional) and an encrypted copy of the data key that we can safely store with the data. When we are ready to decrypt the data, we first ask AWS KMS to decrypt the encrypted data key.
Data keys can be encrypted, decrypted, and generated using AWS KMS. However, AWS KMS does not store, manage, or track your data keys or perform cryptographic operations with data keys.
How can we create a Data key?
For creating a data key, we use the GenerateDataKey operation. Then AWS KMS encrypts a copy of the data key under a symmetric encryption KMS key that we specify. The operation returns a plaintext copy of the data key and the copy of the data key encrypted under the KMS key. The following image shows this operation.
Data key pairs
Data key pairs are asymmetric data keys consisting of a mathematically-related public key and a private key. They are designed for use in client-side encryption and decryption or signing and verification outside of AWS KMS.
AWS KMS protects the private key in each data key pair under a symmetric encryption KMS key in AWS KMS that you specify. However, AWS KMS does not store, manage, or track our data key pairs or perform cryptographic operations with data key pairs. We must use and manage data key pairs outside of AWS KMS. Also, AWS KMS cannot enforce any restrictions on the use of data key pairs outside of AWS KMS.
AWS KMS supports the following types of data key pairs:
RSA key pairs: RSA_2048, RSA_3072, and RSA_4096
Elliptic curve key pairs, ECC_NIST_P256, ECC_NIST_P384, ECC_NIST_P521, and ECC_SECG_P256K1
Aliases
Alias is a user-defined name, generally a common and easy-to-use name, for a KMS key. For example, we can set the name of a KMS key to test-key or final-key.
Aliases are used for making the identification of KMS keys easier in the AWS Management Console. We can also allow and deny access to KMS keys based on their aliases without editing policies or managing grants.
In AWS KMS, aliases are independent resources, not properties of a KMS key. As such, we can add, change, and delete an alias without affecting the associated KMS key.
Custom key stores
A custom key store is an AWS KMS resource associated with FIPS 140-2 Level 3 hardware security modules (HSMs) in an AWS CloudHSM cluster that we own and manage.
When we create an AWS KMS key (KMS key) in our custom key store, AWS KMS generates a 256-bit, persistent, non-exportable Advanced Encryption Standard (AES) symmetric key in the associated AWS CloudHSM cluster. This key material never leaves the HSMs unencrypted. When we use a KMS key in a custom key store, the cryptographic operations are performed in the HSMs in the cluster.
Cryptographic operations
In AWS KMS, cryptographic operations are API operations that use KMS keys to protect data. Because KMS keys remain within AWS KMS, we must call AWS KMS to use a KMS key in a cryptographic operation.
To perform cryptographic operations with KMS keys, use the AWS SDKs, AWS Command Line Interface (AWS CLI), or the AWS Tools for PowerShell. We cannot perform cryptographic operations in the AWS KMS console.
For example, for encryption, the cryptographic operation is Encrypt, key usage is ENCRYPT_DECRYPT, and it can be used for any key type.
Key identifiers (Key ID)
Key identifiers are the names given to KMS keys. They help us recognize our KMS keys in the console. WE can use them to indicate which KMS keys we want to use in the AWS KMS API operations, key policies, etc.
AWS KMS defines several key identifiers. When we create a KMS key, AWS KMS generates a key ARN ( Amazon Resource Name) and key ID, which are properties of the KMS key. When we create an alias, AWS KMS generates an alias ARN based on the alias name that you define. We can view the key and alias identifiers in the AWS Management Console and in the AWS KMS API.
Key material
Key material is the secret string of bits used in a cryptographic algorithm and it must be kept secret to protect the cryptographic operations that use it. Each KMS key includes key material along with metadata, such as its key ID and key policy.
Key material origin
Key material origin is a KMS key property that identifies the source of the key material in the KMS key. We choose the key material origin when we create the KMS key, and we cannot change it. To find the key material origin of a KMS key, we can use the DescribeKey operation.
Key spec
Key spec is a property that represents the cryptographic configuration of a key. The meaning of the key spec differs with the key type.
AWS KMS Keys - For these keys, the key spec determines whether the KMS key is symmetric or asymmetric. It also determines the type of its key material and the cryptographic algorithms it supports. For finding the key spec of a key, we can use the DescribeKey operation, and the key spec of a key cannot be changed once created.
Data Keys - The key spec for these keys determines the length of an AES data key.
Data key pairs - The key pair spec determines the type of key material in the data key pair.
Key usage
Key usage is a property that determines whether a KMS key is used for encryption and decryption (ENCRYPT_DECRYPT) -or- signing and verification (SIGN_VERIFY) -or- generate and verify MAC (GENERATE_VERIFY_MAC). Each KMS key can have only one usage. Using a KMS key for more than one type of operation makes the product of both operations more vulnerable to attack.
Envelope encryption
Envelope encryption is the practice of encrypting plaintext data with a data key, and then encrypting the data key under another key.
Root key is a top-level plaintext key encryption and is used for encrypting the plaintext so that we can decrypt the keys and data encrypted under other encryption keys.
The root keys stored in AWS KMS are known as AWS KMS keys, and these keys can never leave the AWS KMS FIPS-validated hardware security modules unencrypted.
The benefits provided by Envelope Encryption are:
Protection of data keys
Encryption of the same data under multiple keys
Combining the strengths of multiple algorithms like symmetric key algorithm and public key algorithm together.
Encryption context
Encryption context is an optional set of key-value pairs that contain additional contextual information about the data. These contexts are accepted by all AWS KMS cryptographic operations with symmetric encryption KMS keys.
Only the order of the key-value pairs in the encryption context can vary. When we 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 decrypt request fails.
The encryption context is not secret. It appears in plaintext in AWS CloudTrail Logs, so we can use it to identify and categorize our cryptographic operations.
Key policy
Key policy is a document containing the permissions for creating a KMS key and determining who can use that KMS key. We can use key policy to add, remove, or change permissions at any time for a customer-managed key. But we cannot edit the key policy for AWS-managed keys.
Grant
A grant is a policy instrument that allows AWS principals to use AWS KMS keys in cryptographic operations. It also can let them view KMS keys (DescribeKey) and create and manage grants. When authorizing access to a KMS key, grants are considered along with key policies and IAM policies.
Grants are often used for temporary permissions because we can create one, use its permissions, and delete it without changing your key policies or IAM policies. Because grants can be very specific and are easy to create and revoke, they are often used to provide temporary permissions or more granular permissions.
Auditing KMS key usage
Key usage can be audited using AWS CloudTrail. CloudTrail creates log files that contain a history of AWS API calls and related events for your account. These log files include all AWS KMS API requests made with the AWS Management Console, AWS SDKs, and command line tools. The log files also include requests to AWS KMS that AWS services make on our behalf. We can use these log files to find important information, including when the KMS keys were used, the operation that was requested, the identity of the requester, and the source IP address.
Key management infrastructure
A Key management infrastructure is used to keep a key secret. A common practice in cryptography is to encrypt and decrypt with publicly available and peer-reviewed algorithms such as AES (Advanced Encryption Standard) and a secret key, and the job of a KMI is to keep the keys secret. AWS KMS operates the key infrastructure for us. AWS KMS creates and securely stores our root keys, called AWS KMS keys.
Frequently Asked Questions
Can customers bring their own keys to AWS KMS?
Yes, customers can use their own keys in AWS KMS by importing a copy of their key and using it with any integrated AWS service. However, they cannot import asymmetric keys into AWS KMS.
Can we use AWS KMS to help manage the encryption of data outside of AWS cloud services?
Yes, AWS KMS helps in the encryption of data within our own applications wherever they run.
Is there a limit to the number of keys one can create in AWS KMS?
We can keep up to 10000 KMS keys per account per region. However, there is no limit to the number of data keys that can be derived using a KMS key and used in our application or by AWS services to encrypt data on your behalf.
Conclusion
In this blog, we discussed various terminologies and concepts related to the AWS Key Management Service. We also learned about individual keys that can be used in the KMS and the other components of the key management service.
309+ registered 
