The AWS
Key Management Service (KMS) provides a capability to manage encryption keys with transparent integration to many other AWS services. Of particular significance is transparent data at rest encryption for the AWS Elastic Block Store (EBS) service. When using KMS encryption, the data stream from the underlying storage medium is encrypted/decrypted at the hypervisor level. KMS is a regional AWS account bound service leveraging software key generation and underlying Hardware Security Module (HSM) appliances for encrypted storage of key material. Keys are decrypted as needed, stored in memory for the duration of the operation and then immediately erased from memory. The end user has the ability to effect controls over access to keys used for customer data encryption. As part of a security management plan, the customer may desire or have the requirement to effect a key rotation strategy. Keys may require rotation by policy with a defined validity period or could require rotation due to compromise. AWS encourages customers to encrypt all data both in motion and at rest. This ensures customer privacy while providing an ability to crypto erase data by deleting its encryption key as a mitigation to data spill or need to enforce deleted data protection.
Envelope Encryption
KMS uses an
envelope encryption scheme providing two layers of protection for customer data and enabling access controls for the encrypted customer data itself. A data key is stored alongside the customer data that it encrypts in an envelope; containing key and cypher text. The data key is encrypted with a Customer Master Key (CMK) that has management facilities provided via the AWS Console, CLI and SDKs. In order to decrypt a dataset, an end user must have access to the CMK used to encrypt the data key with a forensic audit trail. Without the CMK, a data key cannot be decrypted and hence the underlying customer data cannot be decrypted. The CMK is itself encrypted by an AWS master key stored with physical security controls audited by third party for recovery of CMKs from the underlying HSM if a full region outage were ever to occur and the in-memory copy were lost. There are two different types of CMKs supported by KMS with the difference being ley material origin, these are an AWS generated CMK, “AWS managed CMK”, and a customer imported external CMK “customer managed CMK”.
EBS Service, Snapshots and AMIs
The EBS service provides block storage in the form of mountable volumes for Elastic Compute Cloud (EC2) instances. These volumes are similar to logical volumes presented to a virtual machine with underlying SAN storage. An EBS volume backup can be taken using a Snapshot feature that copies backups of blocks that have changed since the prior snapshot point offering an ability to capture the point in time contents of a volume. Snapshots are taken from an EBS volume and can be used to create new copies of that volume with identical data as of a given point in time. As such, they serve as the primary backup mechanism for EC2 instances as part of a disaster recoverability plan. Snapshots however are without instance configuration as they represent only a single volume and not the machine to which the source volume was attached. For this purpose , AWS offers an instance imaging feature which captures that instance’s current configuration and creates snapshots of all volumes attached to that instance producing what’s called an Amazon Machine Image (AMI). AMIs and Snapshots are store for you in an AWS managed S3 construct making both a regional service component. A copy feature is provided for both an AMI, really just an abstraction of the snapshots tied to the AMI, and an individual snapshot that allows the enablement of encryption and selection of a master key. This selection causes KMS to generate a data key for each of the specific snapshots in question, which is used to encrypt the customer data.
KMS AWS Managed CMK Behaviors
An AWS managed CMK is generated by and populated with key material through the software constructs of the KMS service. A default AWS managed key is automatically generated at the point of AWS account creation for each service that offers native KMS integration across each AWS region. AWS managed CMKs offer an automated rotation feature, when enabled, with a 1-year life cycle. That rotation process would cause the generation of new key material and the archival of old key material within that CMK. This old, deprecated key material is maintained to facilitate decryption of data keys previously encrypted with that key material. The new key material is then used for all encryption operations on customer data for new data sets going forward. In this process, the data keys for customer data are not rotated and existing data keys are not decrypted and re-encrypted with the new key material.
KMS Customer Managed CMK Behaviors
A customer managed CMK is generated as an empty container to which a customer can
import a 256-bit symmetric encryption key. The advantage here being that the customer can generate a key either in software or thru their own hardware key management tools. The customer must maintain a copy of that key within their own IT infrastructure and is solely responsible for recovery of that key in the event of a full AWS region outage by re-importing the key material to the CMK. A customer managed CMK can only contain a single set of key material and does not have the capability to manage a history of key material as the AWS managed CMKs do. The ability to re-import key material to such a CMK is provided purely for recovery purposes and if different key material were ever uploaded, all customer data with the CMK in its envelope chain previously encrypted by that CMK would not be decryptable.
Key Rotation Strategies
When using AWS managed CMKs, the customer has minimal control over the deprecation of legacy key material. Though automated rotation does phase out the future use of legacy key material, it does not cause a re-encryption of data keys and customer data remains encrypted with the same data key. Use of customer managed CMKs enables a greater degree of control over key material source but places a responsibility on the customer to implement a key rotation strategy. In each scenario, there are strategies, leveraging behaviors of the KMS service to force certain desired rotation outcomes.
Rotating Only A CMK
For either an AWS managed or customer managed CMK, a customer can effect complete master key rotation. In the case of AWS managed CMKs, this includes phasing out use of legacy key material. A strategy to achieve this outcome would be to initiate a copy of source customer data within the same region and account. This does not cause a change to data keys or cause customer data re-encryption however; it does cause data keys to be re-encrypted with the new CMK.
Rotating Both A CMK and Data Key
For either an AWS managed or customer managed CMK, a customer can effect complete master and data key rotation. In the case of AWS managed CMKs, this would completely phase out use of legacy key material. A strategy to achieve this outcome would be to initiate a copy of source customer data that crosses an AWS Account and/or AWS Region boundary and then additional copy back to the source. This will cause a new data key to be generated at the destination and enable the selection of an arbitrary CMK at the destination. Note that this will require configuration of KMS CMK access permissions, see
https://aws.amazon.com/blogs/aws/new-cross-account-copying-of-encrypted-ebs-snapshots/. Following the reverse process to copy data back to the source will cause a new data key to be generated in the source AWS Account/AWS Region for the customer data and enable the selection of a new CMK in the source AWS Account/AWS Region. Cross region copies would result in cross region data transfer charges.
Conclusion
It is possible to implement a key rotation strategy that meet security and/or compliance requirements through manipulation of AWS service behaviors. The rule of thumb being that data copy actions enable new key selection and crossing an AWS account or AWS Region boundary causes customer data re-encryption with new keys.
