The Key Management Service (KMS) provided by AWS acts as a central store for generating, managing and controlling cryptographic keys. AWS services can use these for encryption, decryption and digital signing.

KMS supports AWS-managed and customer-managed keys, which support symmetric and asymmetric encryption. With symmetric-based keys, the same key is used for both encryption and decryption, whereas asymmetric encryption uses separate keys.

The difference between symmetric and asymmetric encryption.

The difference between symmetric and asymmetric encryption.

Just like regularly changing passwords, regular key rotation is an essential security best practice for any organization. This article will explore AWS KMS key rotation in detail, including the problems key rotation solves, key rotation methods, costs, and best practices. 

AWS KMS key rotation executive summary

The following table outlines this article’s key concepts and recommendations to help you understand AWS KMS keys and key rotation.

Topic Key points
Types of key
  • AWS-managed vs Customer-managed.
  • Symmetric vs asymmetric-based encryption.
Key usage
  • Use separate keys for different data types and usages, e.g. different data classifications or specific AWS services.
  • This process limits the potential “blast radius” of a compromise.
Automatic rotation
  • AWS automatically rotates key material for AWS-owned and AWS-managed keys.
  • Rotation is done annually for AWS-managed keys, whilst customers can choose to enable annual rotation for some Customer-managed keys. 
  • Old key material is automatically stored for decryption purposes.
  • AWS recommends automatic rotation for most purposes.
Manual rotation
  • Implement manual rotation for AWS-managed keys and Customer-managed keys where automatic rotation is not suitable.
  • Examples are where compliance requires more frequent rotation of keys or using Customer-managed keys outside of AWS.
Costs
  • AWS-owned and AWS-managed have no monthly charge, but AWS-managed keys are subject to fees when usage exceeds the free tier.
  • Customer-managed keys have a monthly charge.
  • Customer-managed keys have a usage fee (per 10,000 requests after the free tier).
  • No charge for the rotation of keys, but customer-managed keys have a monthly charge per retained key.
Recommendations
  • Ensure the key rotation strategy is fit for your business.
  • Use aliases to reduce the effort and risk of key rotation and management.
  • Use auditing and alerting tools for compliance.
  • Use envelope encryption to reduce costs when encrypting/decrypting at scale.
  • Use security tools like MFA and policy to control key use/access, especially the deletion of rotated material.

Primary types of encryption

Encryption is the bedrock of secure data storage and transport in any environment, including backend systems. Many security compromises have resulted in hackers stealing a company’s confidential data, including their customers’ personal information. Often the compromised data was either unencrypted or poorly encrypted, allowing the hackers to then use or sell this data. 

Even when strong encryption methods are used, one area organizations often neglect  is the regular rotation of encryption keys. If a key is compromised, hackers can decrypt the data even if administrators used a strong encryption algorithm.

To understand why let’s examine the two primary types of encryption:

  • Symmetric – With symmetric encryption, the same key is used for encryption and decryption. It requires a shorter key length (typically 256 bits today), so the process is quicker and takes less computing resources. However, because symmetric encryption uses a shared key, it has a higher risk of compromise and is prone to key exhaustion. This is where usage of the key leaks information allowing a malicious user to reconstruct the key to decrypt and read the data.
  • Asymmetric – Asymmetric encryption uses different keys for encryption and decryption. Typically, the key used for encryption is known as the “public” key. A public key is safely shared with other people since it only allows them to encrypt data. The “private” key is kept private by the user or service which needs to decrypt the data. Asymmetric key lengths must be much longer to be secure, typically 2048 bits, though newer cryptographic algorithms have dramatically reduced the size. As a result of the extra complexity, the encryption/decryption process is generally much slower and more resource-intensive than with symmetric encryption.

Symmetric and asymmetric encryption in practice

In practice, symmetric and asymmetric encryption are often used together. The HTTPS protocol clients and servers use to transmit data over the Internet is a good example.

Here is a step-by-step breakdown of the process:

  1. The client’s web browser contacts the web server via HTTPS protocol and requests to set up a secure session.
  2. The server responds with its public server certificate. The browser uses this to confirm the identity of the web server.
  3. Assuming the identity is confirmed, the browser sets up a session symmetric encryption key, then encrypts this using the server’s public key (the certificate) and sends it to the web server.
  4. The web server is the only device that can decrypt this session key using the corresponding private key.
  5. Now, both server and client have access to the symmetric session key – all subsequent communication is encrypted and decrypted with it.

HTTPS encryption using both asymmetric and symmetric encryption.

HTTPS encryption using both asymmetric and symmetric encryption.

Symmetric and asymmetric encryption in AWS KMS

AWS supports both symmetric and asymmetric keys within their KMS service. They also offer three key types for encrypting data within their services:

  • AWS-owned keys are created and managed by AWS. They can make these keys available in other AWS accounts, so you should limit their use. There is no charge for using these keys.
  • AWS-managed keys are also created and managed by AWS. They are linked to your AWS account and are automatically generated as required and linked to an AWS service, e.g. EBS for EC2 disks, S3, Lambda, and DynamoDB. Their use integrates with AWS CloudTrail, allowing the audit of the user or resource which uses them and when it uses them.
  • Customer-managed keys are manually generated keys. The customer fully manages them, and they are limited to the customer’s AWS account. When generated, the customer chooses between three key material origins:
    • KMS – AWS will create and manage the cryptographic material used in the key. KMS supports automatic key rotation.
    • External – Key material is generated outside of AWS and then imported. The customer is responsible for securing the key material outside of AWS. External keys do not support automatic key rotation within KMS.
    • Custom key store – used in conjunction with the AWS CloudHSM service, the key material is generated and stored securely in the CloudHSM and cannot be extracted. These keys do not support automatic key rotation within KMS.

The problem with encryption keys

While generating a single encryption key and using it to encrypt all your data is much better than no encryption, it still leaves you open for compromise. Here is why:

  1. Encryption keys are fallible – Keys can be compromised. The longer and more frequently they are used, the more likely a breach will occur.
  2. Using a single key for all data increases risk – Using a single key for all your data will increase your use and therefore increase the chance of the key becoming compromised.
  3. Compromised keys enable unauthorized decryption – If a key is compromised, the attacker can read all that encrypted data. If they have taken a copy of that data, they can read all of it, no matter what you do at the source.

This last point is important to remember – if an attacker can take a copy of encrypted data and then subsequently compromise the key used to encrypt it, they will be able to decrypt and read that data. This may not be important for some datasets if the information is quickly outdated. But for some data, unauthorized decryption risk exists for years.

Key rotation is the solution!

One solution to this problem is to increase the number of keys used to encrypt data. This measure reduces the amount each key is used and limits the “blast radius” of any compromise. If a key is compromised, the attacker is limited to only the data encrypted by that specific key. Putting a strategy in place formalizes this process:

  1. Encrypt data with different security classifications with different keys – Consider using stronger key algorithms and lengths for confidential/personally identifiable information, sacrificing speed and cost for increased security.
  2. Use different keys for different AWS services – AWS easily enables this with AWS-managed keys since each service will automatically generate its own key for encryption, which can be used free of charge.

Below is a suggested example of a key management strategy. However, you could introduce further subdivision by the project and the environment, e.g. HR data compared to financial data, development environments vs production environments etc.

AWS Service Data Classification Key Used Key Type
EC2 (EBS volumes) Public (webserver) aws/ebs AWS-managed
RDS Confidential (customer data) customer-rds Customer-managed
S3 Public (webserver) SSE-S3 AWS-owned
Confidential (company data) customer-s3 AWS-managed
EFS Confidential (customer data) customer-efs Customer-managed

Take this concept to its next logical step, and you arrive at key rotation. This is how the underlying cryptographic key used to encrypt new data is regularly changed. 

Old data continues to be encrypted with the older key unless modified, in which case it would be re-encrypted with the new key. Maintaining the older key is necessary to decrypt the older data and prevents the need to re-encrypt all data.

Regular key rotation provides a more robust solution since it further decreases the use of each key and further limits the blast radius of any compromise. A single compromised key can only decrypt a subset of data of a specific type and timeframe. 

The effect of key rotation on data encryption.

Key rotation within AWS KMS

AWS provides two methods for key rotation:

  • Automatic
  • Manual

Automatic AWS KMS key rotation

AWS provides the ability to rotate certain key types automatically. AWS-owned and AWS-managed keys are automatically rotated by AWS, with AWS-managed keys rotated once a year. Old key material is automatically stored and seamlessly used for the decryption of any data encrypted with it. There is no charge for creating or storing old AWS-owned or AWS-managed keys.

Automatic key rotation in AWS KMS.

Automatic key rotation in AWS KMS. (Source)

With Customer-managed keys, automatic rotation is disabled by default, but customers can enable automatic rotation as long as they were originally created with KMS-generated cryptographic material. If enabled, keys are rotated by AWS annually, and customers are charged a monthly fee for each key that is stored.

Note that AWS performs all automatic key rotations annually, and customers cannot modify this.

Manual AWS KMS key rotation

With manual key rotation, the customer effectively creates a new KMS key and replaces the old key with the new key. This can be done by either updating the application or service with the updated key ID or with aliases. 

Similar to the concept of DNS with IP addresses, aliases can be created for a KMS key and used to refer to it in applications or other code. At the point of key rotation, the alias is then updated to refer to the new key ID. This removes the need for the developer to update their code and gives the security team full control over encryption key rotation. Aliases also simplify using the same code in different regions since the same alias name created in each region can point to the respective key created in that region.

Automatic key rotation in AWS KMS.

Automatic key rotation in AWS KMS. (Source)

Manual rotation is suitable for customer-managed keys which don’t support automatic rotation or when circumstances require it, such as the need to rotate keys more frequently than annually.

7 best practices for rotating keys in AWS KMS

Now that you know what AWS KMS key rotation is and how it works, here are 7 best practices to help you secure your AWS keys. 

  1. Use different keys for different data usage types and classifications and control the “blast radius” if a key is compromised.
  2. Rotate your cryptographic keys regularly and annually at a minimum using automatic rotation.
    • Depending upon laws, regulations, and corporate policies, rotate more frequently using manual rotation.
    • If manual rotation is required, consider using a service like AWS Lambda to automate the process and effectively enable automatic rotation.
  3. Use aliases for KMS keys to reduce administration, and simplify key usage and the rotation of key material as and when needed.
  4. Audit key usage and rotation.
    • KMS integrates into Amazon CloudTrail to audit key rotation, deletion, and when imported key material expires.
    • Consider using a free and open-source tool like Paladin Cloud, which can enhance the AWS native tools through its continuous monitoring, unified visibility, and proactive threat detection of risks, such as KMS key permissions and usage.
  5. Use envelope encryption with AWS KMS when using encryption at scale to reduce costs and enable disaster recovery. With envelope encryption data is encrypted with the same data encryption key, and only the customer master key is different in each region.An example of envelope encryption in AWS

    An example of envelope encryption in AWS

  6. For essential keys, use MFA authentication to prevent accidental or malicious deletion of key material.
  7. Use the key policy to provide access to key operations where possible in favor or conjunction with an IAM policy. This gives greater granular control over who and what can use that key.

Open Source, Security-as-Code platform for developers and security teams

Reduce risks in your cloud environments, improve cloud security posture

Identify and eliminate cloud misconfigurations with pre-built policies and connectors

Prioritize violations & automate remediation with auto-fixes

Conclusion

KMS keys are crucial within AWS and are used to encrypt, decrypt and re-encrypt data hosted within AWS services. Cryptographic keys are complex and almost impossible to crack through brute force attacks, but they can be compromised through vulnerabilities or exploits such as key exhaustion.

A key rotation strategy puts procedures in place to easily rotate keys and help prevent damage at such an event or when implementing a stronger encryption policy is desired or required. Alongside other best practices, key rotation adds another layer of defense to your overall cloud security strategy.

It’s a laborious task to ensure credentials used and stored are secure across countless assets and disparate systems. To alleviate the overwhelming manpower needed to do so, consider using a free and open-source tool like Paladin Cloud’s open-source Cloud Security Posture Management (CSPM) platform. It’ll improve your clouds’ situational awareness with its continuous monitoring, unified visibility, proactive threat detection of risks (such as KMS key permissions and usage), and automated remediation of security violations.