Key rotation is an essential practice in cryptography that involves regularly generating new versions of cryptographic keys used to encrypt data. By periodically rotating keys, organizations can reduce the risk of unauthorized access to sensitive information in the event that a key is compromised. Proper key rotation requires careful planning and execution to ensure data remains secure throughout the process.

Where did this come from?

This control comes from the CSA Cloud Controls Matrix v4.0.10 - 2023-09-26, which can be downloaded at https://cloudsecurityalliance.org/artifacts/cloud-controls-matrix-v4. The Cloud Controls Matrix (CCM) is a comprehensive set of cloud security controls mapped to various industry standards and regulations. It provides guidance for key rotation as part of the Cryptography, Encryption & Key Management domain.

For more information on AWS best practices for key rotation, refer to the AWS Key Management Service Developer Guide: https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html

Who should care?

• Security engineers responsible for designing and implementing cryptographic systems in the cloud
• Compliance officers tasked with ensuring adherence to industry standards and regulations around encryption
• Developers building applications that handle sensitive data encrypted with cryptographic keys
• IT managers overseeing the security posture of cloud infrastructure and services

What is the risk?

Failure to properly rotate cryptographic keys increases the risk of several adverse events:

• Data Breach: If a key is compromised and not rotated, an attacker could gain unauthorized access to all data encrypted with that key for an extended period. Regularly rotating keys limits the blast radius.
• Compliance Violations: Many regulations and standards mandate key rotation on a defined schedule. Non-compliance can result in fines, reputational damage, and loss of customer trust.
• Insider Threats: Employees or contractors with access to keys who become malicious have a longer window to abuse their privileges if keys are not frequently rotated. Rotation helps contain damage.

What's the care factor?

For any system handling sensitive data, especially in highly-regulated industries, key rotation should be a top priority. While it requires some overhead, it is one of the most effective ways to limit the potential impact of a key compromise. The consequences of a major data breach enabled by stale keys - financial, legal, and reputational - far outweigh the costs of implementing a rotation strategy.

That said, for lower-risk data and less sensitive systems, a longer rotation period may be acceptable based on the organization's risk appetite. The priority should be assessed based on data sensitivity and compliance requirements.

When is it relevant?

Key rotation is highly relevant in situations such as:

• Systems storing personally identifiable information (PII), protected health information (PHI), payment card data, and other sensitive information assets
• Cloud environments subject to strict regulatory standards like HIPAA, PCI DSS, GDPR, etc.
• Cryptographic systems using symmetric encryption, where the same key is used for encryption and decryption

It may be less critical for:

• Public-facing content that does not contain sensitive data
• Asymmetric cryptography used for digital signatures and identity verification, where private keys are closely held
• Archived/cold storage data that is rarely accessed and has a finite, defined lifetime

What are the trade-offs?

Implementing key rotation does introduce some costs and considerations:

• Computational Overhead: Decrypting and re-encrypting large volumes of data with new keys consumes CPU cycles and may impact application performance during the rotation process.
• Availability: If not planned carefully, rotation could cause downtime while data is re-encrypted and keys are redistributed and activated.
• Complexity: Key management becomes more complex when rotation is introduced, as there are multiple active keys to track and manage at any given time. This requires robust processes.
• Legacy Compatibility: Older systems may have hard-coded keys or lack APIs to facilitate easy key rotation, requiring upgrades or workarounds.

How to make it happen?

1. Define a Cryptoperiod Policy: Establish the maximum lifetime for each type of key based on sensitivity and exposure. Consider legal requirements and best practices.
2. Implement a Key Management System: Use a secure vault or service like AWS KMS to store, track, and rotate keys. Ensure it logs all key state transitions and enforces access controls.
3. Generate New Keys: When a key reaches the end of its cryptoperiod, generate a new version using a secure random number generator and specified algorithm/length.
4. Decrypt and Re-encrypt: Use the old key version to decrypt any data and then immediately re-encrypt it with the new key. Ensure all data is migrated within a defined window.
5. Distribute and Activate: Securely distribute the new key version to all authorized systems that need it. Activate it simultaneously to ensure there are no decryption failures.
6. Retire Old Keys: Once all data is migrated and validated, crypto-shred the old key version. Keep it in the key management system but mark it as retired/inactive.
7. Update Key Inventories: Ensure all key inventories, including backups and disaster recovery copies, are updated with the new key version and old key status.
8. Test and Monitor: Regularly test the rotation process to verify smooth operation. Monitor key management systems for any signs of unauthorized access or anomalies.

What are some gotchas?

• Permission Management: Ensure IAM policies restrict access to key management to only those roles and users absolutely required. For AWS KMS, this means ensuring the appropriate kms:CreateKey, kms:GetKeyRotationStatus, kms:RotateKey, etc. permissions are applied. See AWS KMS API Permissions Reference.
• Regionality: KMS keys are regional. If encrypted data is replicated across regions, each region needs its own key and rotation schedule.
• Encryption Context: When rotating keys used with envelope encryption, ensure the encryption context is carried forward to maintain mappings between the data key and new master key.
• Rollback Strategy: Have a tested rollback plan in case issues arise during a rotation, such as data corruption or too-narrow rotation windows.

What are the alternatives?

While key rotation is the recommended best practice, some alternatives or complements to consider:

• Perfect Forward Secrecy: Use ephemeral keys for each session/transaction that are discarded after use, rendering stolen keys useless after the fact. Relevant for securing communications.
• Hardware Security Modules: Store keys in tamper-resistant HSMs to reduce exposure risk and enable automation of key lifecycle operations.
• Split Key Schemes: Use techniques like Shamir's Secret Sharing to divide keys into shares which never exist in one place, reducing single points of failure.

Explore Further

• AWS Cryptography Best Practices Whitepaper: https://d0.awsstatic.com/whitepapers/aws-kms-best-practices.pdf
• NIST SP 800-57 Pt. 1 Rev. 5 - Recommendation for Key Management: https://csrc.nist.gov/publications/detail/sp/800-57-part-1/rev-5/final
• CIS Controls v8 - Control 3.11: Encrypt Sensitive Data at Rest - https://controls-assessment-specification.readthedocs.io/en/stable/control-3/control-3.11.html

?