AWS KMS Data Key Rotation

Question

I am using AWS KMS as a vault for my encryption key. Now what I am doing is that I am creating one data key, encrypt it using Customer Managed CMKs.

Now on every request, I just call AWS KMS Service to decrypt the data key and from the data key, I encrypt/decrypt the data.

I am using this to encrypt/decrypt the database fields for PII. For encryption/decryption, using AES-256. Now how would data key rotation works? Suppose I have 1 million emails which I have encrypted using DataKeyA. Now key rotation happens and new data key is DataKeyB. Now how do previous emails will decrypt. Or do I have to re-encrypt those prev 1 million email with DataKeyB?

Is it even necessary to rotate the data key? Or rotating master key every year is sufficient.

Answer 1

Let's break it apart. You have an encryption key:

YOUR_KEY

You use this to encrypt the data in your database:

ENCRYPTED_PII_DATA = AES(PII, YOUR_KEY)

You don't want your key stolen so you encrypt it with AWS KMS and it gets stored in your application as:

YOUR_KMS_ENCRYPTED_KEY

Therefore when your application launches it grabs YOUR_KMS_ENCRYPTED_KEY out of its own store and sends that to AWS KMS for decryption:

YOUR_KEY = KMS_DECRYPT(YOUR_KMS_ENCRYPTED_KEY)

Thus restoring the original YOUR_KEY which (presumably) you store in memory and use to decrypt all your PII as needed:

PII = AES_DECRYPT(ENCRYPTED_PII_DATA, YOUR_KEY)

So what happens when you ask AWS to rotate its master key? In your case: nothing. AWS KMS keeps all the old versions of its own encryption key around so that it can continue to decrypt any data it had previously encrypted. Your application doesn't know anything about the rotation of course, so the next time your app launches it will grab YOUR_KMS_ENCRYPTED_KEY out of its store, send it off to AWS again, ask for it to be decrypted, and AWS will return YOUR_KEY just as it always has. You will then be able to decrypt your data with YOUR_KEY just like you always did. However rotation will give you another option. After your app decrypts its key, it can go ahead and ask AWS KMS to re-encrypt it again:

YOUR_KMS_ENCRYPTED_KEY_V2 = KMS_ENCRYPT(YOUR_KEY)

This will return back a new encrypted version of YOUR_KEY which is encrypted using the new AWS master key. However, this is still just an encrypted version of YOUR_KEY, and when you ask AWS KMS to decrypt it again, you'll still end up with YOUR_KEY. As a result, from the perspective of your PII, your master key has never changed. You will still be able to decrypt your PII just as you did before, since your key has never changed (just the encrypted version of it).

In other words, since you aren't using KMS to encrypt your PII, but instead are using it to encrypt the encryption key used for your PII, you aren't actually rotating the key used for your PII. If you also wanted to rotate the key used to encrypt your PII then you would have to manage that process yourself, which would mean:

1. Generate YOUR_KEY_V2
2. Use YOUR_KEY to decrypt your PII
3. Re-encrypt your PII with YOUR_KEY_V2
4. Encrypt YOUR_KEY_V2 - YOUR_KEY_V2_KMS_ENCRYPTED = KMS_ENCRYPT(YOUR_KEY_V2)
5. Store YOUR_KEY_V2_KMS_ENCRYPTED and throw away YOUR_KMS_ENCRYPTED_KEY

(just make sure you do this in a way that you don't permanently lose access to data if any of the above steps are interrupted, which is probably the hard part)

Hopefully that was clear and answers your first question. Your last question however:

Is it even necessary to rotate the data key? Or rotating master key every year is sufficient.

Is unanswerable. Only you can decide if it is necessary to rotate the data key. Your company may have guidance about what kind of key rotations are necessary and when, but otherwise it's not like there is a law about this. You have to decide for yourself what risks you are trying to protect against, the best way to mitigate those risks, and which steps are worth the effort. As an example, rotating the KMS master key may provide some protection in the event that someone grabs an old key out of a stolen backup, but provides no protection in the event that someone manages to grab YOUR_KEY directly out of the running application. In the latter case all PII would be accessible to anyone who stole YOUR_KEY. The only way to protect against that would be by using AWS KMS to encrypt the PII directly, but of course doing that has monetary and performance costs.

Answer 2

Are you sure that you are using only one data key? Because every time you perform an encryption operation using KMS, by default, for every encryption operation a new data key is generated and encrypted using your Customer master key. It works seamlessly as all data keys are encrypted using a common CMK. This avoids data key reuse which is a best practice recommended by AWS.

It may be possible that you are using data key caching. This caches the data keys to save some costs by reducing the number of KMS calls. Even with this approach you would end up having multiple data keys. For these reasons. Data keys need not be rotated.

From AWS KMS FAQ:

Q. Do I have to re-encrypt my data after keys in AWS KMS are rotated?

If you choose to have AWS KMS automatically rotate keys, you don’t have to re-encrypt your data. AWS KMS automatically keeps previous versions of keys to use for decryption of data encrypted under an old version of a key. All new encryption requests against a key in AWS KMS are encrypted under the newest version of the key.

If you manually rotate your imported or custom key store keys, you may have to re-encrypt your data depending on whether you decide to keep old versions of keys available.

Update after OP's comment on question:

Based on your comment it looks like you are not using AWS RDS and only using the KMS service. AWS KMS is like your HSM in the cloud. It should be treated the same way. If you are fetching a data key and storing it in the memory for extended periods of time, it defeats the purpose of having an HSM. You may be better off using the encryption capabilities provided by the DB itself.

Answer 3

KMS is typically used in conjunction with other services (e.g. S3) and this is transparent to the user. But to answer your question:

1. KMS stores CMKs, which aren't just keys, but containers that can contain multiple keys, called HSM-Backing-Keys (HBKs). HBKs are the actual binary bits that we commonly refer to as 'keys'.
2. When you rotate your CMKS, the older HBKs are still stored within the CMK, they're just no longer the default HBK.

But here's the interesting part:

3. When you GenerateDataKey, the CipherTextBlob within the response, doesn't just contain the encrypted key, but metadata about the key, for KMS to figure out which HBK it points to.
4. Similarly, every S3 object encrypted with a CMK, contains the key id as part of its metadata. You can check an objects ssekms_key_id to determine which CMK was used to encrypt it.

Hence, you do NOT need to re-encrypt all your data again, and you don't need to (generally speaking) re-generate new data keys. By sending your CipherTextBlob to KMS, it can figure out which CMK was used for that encryption, and decrypt it for you.

Regenerating new data keys every time you rotate your Master Key is a lot of work, and it would only increase every year, as you add more data that needs to be re-encrypted -- so unless you're flushed with cash, this is a non-starter.

Also, by rotating your Master Keys every year, a single lost Master Key would expose one year's worth of data (at most!). But if you re-encrypt everything on each rotation, then a single lost Master Key would expose all your data.