AWS Key Management Service – Asymmetric/Symmetric Encryption Keys
Read Time: 08 min
Data encryption on the cloud is the most prominent thought every security professional has in their mind these days. While performing data encryption, Security keys are of the utmost importance. When it comes to managing a single security key manually, it is relatively easy, however, if the number of security keys in use are huge, the task of managing those keys becomes cumbersome. Thus, the need arises for automated key management services for data encryption.
AWS KMS (Key Management Service) provides an easy to use WebUI to deal with the management of security keys to protect data-at-rest and data-in-use. AWS KMS is a placeholder for CMK (Customer Master Key) resources containing key metadata to encrypt & decrypt the data. Also, AWS KMS can be integrated with various other AWS services, such as Redshift, EBS, EFS, S3, and Secret Manager, to name a few.
Key Types
- AWS Managed CMKs
These CMKs are created, managed and used by an AWS service integrated with KMS on behalf of the customer in theirs AWS account. For example, “aws/s3” is the default key in S3 and is used only for your account to encrypt your S3 buckets.
- Customer Managed CMKs
These CMKs are created, managed and used by the customer in the AWS account. This is the most widely used method while using KMS, as it provides complete granular level access control over the security keys in an AWS account.
- AWS Owned CMKs
These CMKs are owned and managed by AWS service/s for use in multiple AWS accounts. The key for these CMKs is not visible to users. For example, if you choose S3 default encryption, S3 uses its own KMS CMKs that are shared across multiple AWS accounts.
Data Keys
Access Control to KMS CMKs
- IAM Policies
Policies attached to an IAM identity are called identity-based policies.
- Key Policies
Policies attached to resources are called resource-based policies.
| Type of CMK | CMK management via IAM Policy | CMK management via Key Policy | Can view **CMK Metadata | Used only for specific user account | Automatic Rotation |
|---|---|---|---|---|---|
| Customer Managed | Yes | Yes | Yes | Yes | Optional* |
| AWS Managed | No | No | Yes | Yes | Every 3 Years |
| AWS Owned | No | No | No | No | Varies |
* Be default “Automatic Rotation” is disabled, however, user can enable it upto 1 year.
For example, the metadata type “Origin” signifies the source of the CMK’s key material. When this value is AWS_KMS, AWS KMS created the key material. When this value is EXTERNAL, the key material was imported from external key management infrastructure. When this value is AWS_CLOUDHSM, the key material was created in the AWS CloudHSM cluster associated with a custom key store.
Symmetric and Asymmetric CMKs:
AWS KMS protects the CMK that you use to protect your data and data keys. The CMKs are generated and used only in hardware security modules designed so that no one can access the plaintext key material.
AWS KMS supports symmetric and asymmetric CMKs:
- Symmetric CMK: This represents a single 256-bit secret encryption key that never leaves AWS KMS unencrypted.
- Asymmetric CMK: This represents a mathematically related public key and private key pair that you can use for encryption and decryption or signing and verification, but not both. The private key never leaves AWS KMS unencrypted. You can use the public key within AWS KMS by calling the AWS KMS API operations, or download the public key and use it outside of AWS KMS.
KMS Custom Key store
A key store is a secure location for storing cryptographic keys. By default, the customer master keys (CMKs) that you create in AWS KMS are generated in and protected by hardware security modules (HSMs) that are FIPS 140-2 Level 2 compliant cryptographic modules. The CMKs never leave the modules unencrypted.
A custom key store is an AWS KMS resource that is associated with an AWS CloudHSM cluster backed by FIPS 140-2 Level 3 HSMs that are owned and managed by user.
What is Bring Your Own Key (BYOK):
A CMK is a logical representation of a master key in which the key material is generated and owned by the AWS. However, users can create a CMK without any key material, and then import external key material into that CMK. This is known as BYOK i.e. Bring Your Own Key
When imported key material is used, the users remain responsible for the key material while allowing AWS KMS to use a copy of it. This is a common use case where the user wants to have complete control over the key material for regulatory/business/compliance/legal purpose.
Conclusion
AWS KMS is a widely used KMS service among all the KMS as-a-service options available from Cloud vendors. Since AWS KMS provides multiple options for CMKs, it becomes difficult to decide at times which option one should choose under different scenarios. Considering the functionality and feature set available in each CMK, if a user wants to use a key available to all IAM entities in its AWS account, AWS Managed CMK is better choice as the CMK is available for all the IAM users in the same account. However, if user wants to have a granular access control over keys then Customer Managed CMK or BYOK appears to be a better option.
