Key revocation is a crucial process that removes cryptographic keys from use before they expire. This is necessary when a key is compromised or when someone with access to the key leaves the organization. Proper key revocation safeguards the ongoing security and integrity of encrypted data.
Where did this come from?
This article is based on Control CEK-13 from the CSA Cloud Controls Matrix v4.0.10 released on 2023-09-26. You can download the full Cloud Controls Matrix at https://cloudsecurityalliance.org/artifacts/cloud-controls-matrix-v4 to learn more. Additional helpful references include the AWS Key Management Service Developer Guide: https://docs.aws.amazon.com/kms/latest/developerguide/overview.html
Who should care?
- Security engineers designing and implementing encryption key management
- Compliance officers ensuring proper controls around encryption keys
- Developers building applications that use encryption to protect data
- IT managers overseeing teams handling encryption keys
What is the risk?
Failing to revoke keys greatly increases the risk of unauthorized data access. If a key is compromised or an employee with access leaves, the key could be used to decrypt sensitive information. The longer a key remains active unnecessarily, the higher the likelihood and impact of a breach. Key revocation is essential to mitigate this risk.
What's the care factor?
Organizations should prioritize key revocation as part of encryption key management. Leaked keys undermine the security encryption provides. While key revocation takes some effort, it's well worth it to maintain control over encrypted data access. The consequences of unauthorized decryption could be disastrous.
When is it relevant?
Key revocation is needed whenever keys are no longer required, such as when:
- An employee or contractor with key access departs the company
- A key is accidentally exposed or thought to be compromised
- The data a key protects is deleted or no longer sensitive
- Changing compliance rules require updating keys
Key revocation may not be needed for intentionally public or non-sensitive data. It also doesn't apply to hashing keys not used for encryption.
What are the trade-offs?
Revoking keys does require effort to implement processes and re-encrypt data. Overly short key lifetimes necessitate frequent revocation. But this is a small price compared to a breach. Start with the most sensitive data and work towards comprehensive coverage.
How to make it happen?
- Implement a system to inventory and track all encryption keys and access.
- Define criteria for when keys must be revoked (e.g. worker termination).
- Put a process in place to promptly revoke keys when needed. Remove all access and consider the key compromised.
- Have a way to distribute information about revoked keys, like Certificate Revocation Lists.
- Decrypt any data protected by the revoked key and re-encrypt it with a new key.
- Log all key transitions and activities in the inventory system.
- Regularly audit that unused keys are properly revoked and removed.
What are some gotchas?
- Revoking keys for large datasets can be time-consuming to decrypt and re-encrypt.
- Proper revocation requires removing access universally.
- Keys used across many systems and people are harder to fully revoke.
- The revocation process must abide by legal/regulatory requirements.
- API calls to revoke keys require specific permissions, like DisableKey in AWS KMS: https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html#key-policy-default-allow-root-enable-disable
What are the alternatives?
Rather than revoking keys, you could:
- Use short key lifetimes and rotate keys frequently
- Use envelope encryption to limit the impact of revoking one key
However, these aren't full alternatives, just complementary practices. Meeting this control still requires the ability to revoke active keys when needed.
Explore Further
