Can you please help me understand the meaning of sentence from KMS documentation
https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html
automatic key rotation has no effect on the data that the KMS key protects.
It does not rotate the data keys that the KMS key generated
or re-encrypt any data protected by the KMS key,
**and it will not mitigate the effect of a compromised data key.**
what does
... it will not mitigate the effect of a compromised data key.
mean in this context.
I need to enable KMS Rotation in multiple repos and I want to be 100% sure
Your CMK can create data keys, which you can use outside of AWS to manually encrypt and decrypt your data. The important thing about data keys is that they are symmetric. Which means same key is used for encryption and decryption of a secret.
If AWS rotation happens, it affects only key material stored in KMS. Any data keys generated before that, are not affected as they are for external use and are symmetric. The rotation only applies to the keys stored in KMS itself, not to data keys that you generated and used outside of AWS.
So if anyone has your data key, it can be used to decrypt your secretes, as rotation do not apply to these keys.
"It does not mitigate the effect of compromised key means"
For understanding sake consider KMS Key is a logic unit of two components
1.Key attributes (Key metadata) - Key ID, Key Specification , Key Usage etc
2.Reference to Key material
(In essence a KMS key means these two things)
There are three types of KMS Keys.
AWS owned keys - used by AWS for internal purpose
AWS managed Keys - used by AWS services - only metadata can be accessed
AWS CMK Keys - Customer can control the key but is managed by AWS on behalf of the customer
Data keys are generated from AWS KMS CMK Keys.
Firstly we have to understand What are data keys and how they are generated ?
Ans: As known KMS Keys do not leave the KMS modules. So the maximum file can encrypt is of the only 4KB. To encrypt more data we will be using a data key that is generated form the KMS Keys. Using envelope encryption the data key encrypts the data objects in EBS or S3 while data key is encrypted by KMS Key and stored where the data is stored unlike KMS Keys that do not leave the AWS KMS HSM Modules.
Now in case of key-rotation you are changing the key material you are not changing the Key metadata nor reference to the key material i.e .AWS will decrypt the data key by the KMS Key that it was encrypted aka the previous version of the KMS Key. We cannot instruct a particular version of KMS Key.
Related
I want to implement an envelope encryption using KMS.
I would encrypt few properties in a no sql db, is the first time that I'm doing it and for what I have read I will need to save my encrypted data key along the data.
My question is, at some point I would like to rotate the CMK key that KMS is using to encrypt the data key, for that scenario, I would need to write a process to re-encrypt my data key with the new CMK that KMS will use?, do I need to change the encrypted data key with a new one?
would need to write a process to re-encrypt my data key with the new CMK that KMS will use?, do I need to change the encrypted data key with a new one?
If you use automated rotation, you don't have to do anything in terms of data keys. They are not affected by rotation. From docs:
automatic key rotation has no effect on the data that the KMS key protects. It does not rotate the data keys that the KMS key generated or re-encrypt any data protected by the KMS key, and it will not mitigate the effect of a compromised data key.
But if you use manual rotation, you may have to re-encrypt everything. From docs:
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.
How exactly does encryption key rotation work? I understand it's a very good practice to continuously rotate your encryption keys for security purposes, but rotating a key would require too much work.
Case:
Let's just say I have a database storing 30GB of data, and we're using an internal key to encrypt data at rest, and I plan to rotate my keys every month.
Questions:
Does that mean all my data will be decrypted by the old key and re-encrypted by the new one every month?
The whole encryption-decryption would take a lot of time and compute resources.
If my DB ( or any encrypted dataset ) scales tomorrow, does that mean the same process would duplicate when my key rotates? This does not look like a scalable solution.
Other Details:
I've also seen AWS KMS rotates it's keys if we've selected the rotation option. How does AWS manage to rotate it's keys and all encrypted data for all the underlying services?
You need to familiarize yourself with Envelope Encryption. Each time you want to encrypt data in AWS, you first generate a unique data-key. You then encrypt your data with this key. This key is not the key that is rotated!
Then you take this key, and you encrypt it with a key from KMS. Now if you want to decrypt this data, you must first get the decrypted data key, and to decrypt this data key, you will need the KMS key.
Now if you want to rotate the key, you don't need to re-encrypt all the data, instead you need to decrypt the data key using your key to be rotated from KMS, and then get a new key, and re-encrypt the unencrypted data key. That way you don't need to re-encrypt all the data.
Here are two important links that can help you understand envelop encryption and key rotation in AWS.
https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html
https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html
I have quoted some important concepts from the above links:
Envelop encryption:
When you encrypt your data, your data is protected, but you have to protect your encryption key. One strategy is to encrypt it. Envelope encryption is the practice of encrypting plaintext data with a data key, and then encrypting the data key under another key.
Customer Master Keys
CMKs are created in AWS KMS. Symmetric CMKs and the private keys of asymmetric CMKs never leave AWS KMS unencrypted. This strategy differs from data keys. AWS KMS does not store, manage, or track your data keys. You must use them outside of AWS KMS.
Data Keys
Data keys are encryption keys that you can use to encrypt data, including large amounts of data and other data encryption keys. You can use AWS KMS customer master keys (CMKs) to generate, encrypt, and decrypt data keys. However, AWS KMS does not store, manage, or track your data keys, or perform cryptographic operations with data keys. You must use and manage data keys outside of AWS KMS.
Key rotation
When you enable automatic key rotation for a customer managed CMK, AWS KMS generates new cryptographic material for the CMK every year. AWS KMS also saves the CMK's older cryptographic material in perpetuity so it can be used to decrypt data that it encrypted. AWS KMS does not delete any rotated key material until you delete the CMK.
An important concept in Key rotation is the HSM backing key(HBK):
(https://docs.aws.amazon.com/kms/latest/cryptographic-details/key-hierarchy.html)
Within the hierarchy of a specific CMK, the HBK can be thought of as a version of the CMK. When you want to rotate the CMK through AWS KMS, a new HBK is created and associated with the CMK as the active HBK for the CMK. The older HBKs are preserved and can be used to decrypt and verify previously protected data. But only the active cryptographic key can be used to protect new information.
Does that mean all my data will be decrypted by the old key and re-encrypted by the new one every month?
As already answered, the simple answer is no. But the previous answers miss the purpose of the key rotation
The reason behind the key rotation is limit amout of data encrypted by a single key.
How does AWS manage to rotate it's keys and all encrypted data for all the underlying services?
The basic idea (at least in KMS) is, that the KMS key is not a single key, but it is a set of keys, which the last one is the current one. You can imagine that as "key versioning". After each key rotation the current key is saved so you can still decrypt the previously encrypted ciphertext (data key - as mentioned in other answers). I believe in the KMS this whole set is hidden, but Azure KeyValt shows the whole set as key version.
The whole encryption-decryption would take a lot of time and compute resources
No, you don't need to do anything. AWS manages the "key versions" for you. Even if you'd re-encrypt the envelope keys as suggested in another answer, then you would actually fail to fulfill the purpose of the key rotation.
The ciphertext generated by the KSM must contain some identification of the key version too, so the KMS is able to decrypt the ciphertext even after the key is rotated.
Here is the encryption flow of Server-side encryption with S3 managed keys (SSE-S3)
(this picture is from Oreilly)
The client selects their object(s) to upload to S3 and indicates the encryption mechanism of SSE-S3 during this process.
S3 then takes control of the object and encrypts it with a plaintext data key that's generated by S3. The result is an encrypted version of the object, which is then stored within your chosen S3 bucket.
The plaintext data key that used to encrypt the object is then encrypted with an S3 master key, resulting in an encrypted version of the key. This now encrypted key is also stored on S3 and has an association to the encrypted data object. Finally, the plaintext data key is removed from memory in S3.
As you can see, SSE-S3 use a unique data key to encrypt the object, rather than the master key.
I heard a lot that SSE-KMS is envelope encryption, my question is:
Is SSE-S3 envelop encryption too?
Reference
Stack Overflow: Does AWS KMS use envelope encryption?
AWS KMS Envelope Encryption
AWS Encryption-At-Rest(server-side encryption) uses Envelope Encryption irrespective of what key is used. Not just for S3, for every service at AWS. Here is a nice blog about it.
Only difference is who manages data key and encryption key.
SSE-S3 Both keys are managed by AWS
SSE-KMS We manage CMK, where as AWS manages data key. Gives us more control on rotation, access, etc.
SSE-C We manage both encryption key and data key(we can choose to not use data key but use same key), we provide data key and algorithm, AWS encrypts for us and we need to keep track of which key is used for which object.
If the answer is no, how to deal with the data encryption when migrating your data from aws cloud to another cloud someday?
e.g. S3 object that has been encrypted by SSE-S3
Its not possible. From docs:
By default, AWS KMS creates the key material for a CMK. You cannot extract, export, view, or manage this key material.
The exception is when you import your own keys into KMS. Since you import the key material, you can use the same one in the other provider if it supports importing keys.
When you copy your objects to other storage provider, AWS will transparently decrypt them. The new provider will have to encrypt your data using their own keys.
So basically, the migration involves, decryption of your data, transfer of the data to a new provider, and encryption using a new key.
The only way to transport encrypted data from s3 is if you use SSE-C in S3, which stands for customer-provided encryption. In this case you are fully responsible for encryption and decryption of your files. AWS and the new provider only store the encrypted files:
Using server-side encryption with customer-provided encryption keys (SSE-C) allows you to set your own encryption keys.
Typically, data is not encrypted using the keys stored in a Key Management Service (KMS).
Instead, when a file needs to be encrypted:
A random encryption key is generated that is specific to that file only
The file is encrypted using that key
The key is then encrypted using the keys stored in the KMS and the encrypted key is stored with the encrypted data
Later, when the file needs to be decrypted:
The encrypted key is decrypted using the KMS
The file is decrypted using the decrypted key
Thus, if you wish to move encrypted data to a different system, you merely need to decrypt the file-specific encryption keys using the KMS and re-encrypt them using the new KMS. The encrypted files can then be copied to the new system without needing to be decrypted.
Here's a picture from Server-side encryption with KMS managed keys (SSE-KMS) - AWS Certified Solutions Architect - Associate Guide [Book]:
I found that AWS RDS allows encrypting DB resources with AWS KMS. Because it is done inside the AWS infrastructure the encryption key can be easily rotated automatically. It is cool, but it is only encryption-at-rest.
I would additionally like to have encrypted some particular columns in the database. For example SSN. I would like to store them encrypted and decrypt them to display inside my application. Moreover, I would like to have an individual key for every user.
The main problem which I observed will be the rotation of the key. As I'm thinking to rotate the key for one user I would like to do this inside my application:
get a current encryption key from KMS
decrypt all the data from RDS encrypted with the current key
generate a new encryption key
encrypt everything again and store data in RDS
store the new key in the KMS
The main problem here would be to keep everything in a "transaction" - to "commit" if everything was fine and to "rollback" everything if anything went wrong.
I wonder if such keys rotation for the encryption at the columns level could be done inside the AWS infrastructure automatically. Do you have any ideas about that? Maybe you know any other, better approach for such a situation?
What problem are you solving by having individual keys per user? The KMS paradigm is to use policy to grant access to a Customer Master Key (CMK). As Mark pointed out above, there is a limit on the number of keys.
Have a look at this walkthrough
There is a section at the bottom about Key rotation strategies that might help:
"A recommended approach to manual key rotation is to use key aliases within AWS KMS. This allows users to always select the same key alias when configuring databases, while the key administrator rotates the underlying CMK. By keeping the old CMK, you allow any applications that currently use this key to still decrypt any data that was encrypted by it, as long as the CMK key policy still gives the AWSServiceRoleForRDS role permission as a Key User. It also allows for any new data to be encrypted with the new CMK."
I would additionally like to have encrypted some particular columns in the database.
Then I assume you will use a form of key wrapping ( data keys )
The main problem which I observed will be the rotation of the key
..
encrypt everything again and store data in RDS
store the new key in the KMS
The purpose of the key rotation is limit amount of data encrypted by a single key, not to re-encrypt the whole encrypted content.
Suggestion:
as already linked - encrypt your data using a random (per row?) data key.
encrypt the data key using the user-specific key.
encrypt the user-key with a KMS-key
Key Rotation (KMS) should be transparent for you with no action to do.
If you wish to manually rotate the user keys, you may, IMHO it is not so critical - the user keys are used to encrypt the data keys - relatively short data with high entropy.
IMHO the action by rotation taken should be creating a new key and preserving the old one for decryption purposes, not to re-encrypt all the database records
Are you using something like AWS Cognito to give each user temporary IAM permissions when they log in? Otherwise, I don't see the point of giving each user a separate KMS key, since you would be giving a single entity (your server) access to all the keys. Also note that there is a limit of 10,000 KMS keys in an AWS account. That's quite a bit, but if you have a website where anybody can sign up you might run up against that limit if you are assigning each user a key.
As for handling key rotation automatically, since you have to write the custom code to encrypt individual column values in your database, you will also have to write the code to perform all the steps of the key rotation process. You could create that as an AWS Lambda function and configure it to run "automatically", but it isn't something Amazon gives you out of the box without any custom code.