KMS: add ability to decrypt data with all rotated keys #12482
Conversation
4ed53cd to
7910244
Compare
LocalStack Community integration with Pro 2 files 2 suites 4m 12s ⏱️ Results for commit cd6f742. ♻️ This comment has been updated with latest results. |
|
Nice work! It's great to see the GitHub issues being handled :) Could you please explain in the PR description or comments how you determine which key material, of possible 10 values, was used to encrypt the value? |
| keys_to_try = [self.crypto_key.key_material] + self.previous_keys | ||
|
|
||
| for key in keys_to_try: | ||
| try: | ||
| return decrypt(key, ciphertext.ciphertext, ciphertext.iv, ciphertext.tag, aad) | ||
| except (InvalidTag, InvalidSignature): | ||
| continue |
There was a problem hiding this comment.
Here the data can be decrypted only with the key which encrypted it.
During decryption, we first attempt with the current key material. If decryption fails, we try previous key versions until we find the one that correctly matches the ciphertext.
There was a problem hiding this comment.
During decryption, we first attempt with the current key material. If decryption fails, we try previous key versions until we find the one that correctly matches the ciphertext.
Ok, but why does decryption actually fail here? When doesInvalidSignature get thrown, and how does it know the key material’s wrong—what value in the code is it checking?
There was a problem hiding this comment.
What is the difference between InvalidTag and InvalidSignature being thrown in this case?
There was a problem hiding this comment.
When data is encrypted using a specific key, it can only be decrypted using that exact key. Attempting to decrypt the data with a different key will result in an error—commonly InvalidSignature or InvalidTag, depending on the algorithm being used.
To handle key rotation gracefully, especially when accessing older data, the decryption process must attempt to use not just the current key but also all previous key materials. This ensures backward compatibility and allows successful decryption of data encrypted before the most recent key rotation.
There was a problem hiding this comment.
why: now that localstack/localstack#12482 and localstack/localstack#10723 are done and we have upgrade to the latest localstack, we can remove the workaround code.
why: now that localstack/localstack#12482 and localstack/localstack#10723 are done and we have upgrade to the latest localstack, we can remove the workaround code. Signed-off-by: Keith Wall <kwall@apache.org>
why: now that localstack/localstack#12482 and localstack/localstack#10723 are done and we have upgrade to the latest localstack, we can remove the workaround code. Signed-off-by: Keith Wall <kwall@apache.org>
Motivation
Add ability to decrypt data that was encrypted before the rotation event by preserving the history of the key material on
RotateKeyOnDemand.Closes: #10723
Changes
Store all the previous crypto keys with a maximum of 10 times per KMS key (checkout the AWS Documentation) to ensure the decryption of the data that was encrypted before the rotation of the key.
Validate the implementation using AWS validated snapshot tests.