This Topic is a continuation of previous topic that i created. I browsed through the materials that was recommended in the previous topic and those were very helpful and i have few questions on the same.
Here is my understanding
The keys that will be used to encrypt/decrypt the fields in collection will be stored in Mongodb keystore (collection). These keys will be encrypted/decrypted using CMK and CMK can be maintained/stored in any of the external KMS service for example (AWS-KMS).
Here are my questions
Question1
Lets assume that
- The CMK that is stored in AWS-KMS is rotated after 6months(but the keys present in mongodb keystore are not rotated) then this means there will be a newCMK key. But the keys present in mongodb keystore is encrypted using the oldCMK key.
- In this case, will there be any issue if this newCMK key is used to decrypt the keys from mongodb keystore as the keys present in mongodb keystore were encrypted using the oldCMK key?
Question2
Lets assume that
- The keys present in mongodb keystore are rotated
- After rotation of keys in mongodb keystore, the CMK fetched from AWS-KMS is used to encrypt the rotatedKeys and these newKeys are stored into mongodb keystore.
- In this case, will the mongodb driver still be able to decrypt the fields that were encrypted by oldKeys?
As i don’t have clarity on crypto related topics, i would like to have some clarity on below question as well
Question3
"if a particular data is encrypted using a key and if this key is rotated (this will give rise to newKey), then will this newKey would still be able to decrypt the data which was encrypted using the oldKey?
I feel like all the above questions are similar, but i’m not sure about it. I’m looking forward for the response.
I think I can help. Taking your questions in order:
Master key rotation using a purpose-generated Amazon KMS master key (“CMK”) rotation: In Amazon (and GCP & Azure) parlance, key service “rotations” are really just versioning techniques. Because many use cases (such as FLE data in MongoDB) are for long term storage with potentially massive numbers of records and previously encrypted data must still continue to be accessible, a CMK rotation will create a new wrapping envelope on any newly created data (field) keys, but all previous “old” encrypted payloads carry enough meta information so they can still be decrypted as well. In this sense, rotation is meant to signifiy that a given key is only used for encryption for a specific period of time. You can read more details here: Rotating AWS KMS keys - AWS Key Management Service, but the take-away is, no, automatic rotation with AWS KMS CMKs do not pose any issue for FLE. They are essentially an opaque implementation detail and from the view of our drivers, old and new field keys can still be decrypted through API calls using the same IAM account privileges as always.
Not sure I entirely follow what you’re asking, but the actual (raw/plaintext) data encryption keys (field keys) themselves are not rotated, only the encryption key that protects them on initial generation. You can think of this as similar to what happens on a laptop with disk encryption - when you change your password, a key derivation algorithm is used to create a new wrapping for the disk encryption key, but the disk data encryption key itself does not change; if it did, your whole drive would have to be re-encrypted block by block, and with a sizable volume that could take a considerable amount of time.
As mentioned, the field encryption keys themselves are not rotated, but their encrypted versions can be, if desired. One of the advantages of a hardened, mature key service like AWS KMS is that the master key material used to perform the envelope encrypt/decrypt operations never leaves the confines of the service, and depending on the provider may not even leave the backing Hardware Security Module. This is not the case with the local key service (which could be supplied with either an actual local key file or results of a REST call to a remote key/secrets manager like Hashicorp Vault).
What may be helpful is to consider real world threat modeling: how likely is it that an attacker would compromise your application server, capturing database credentials and privileged network access and plaintext FLE encryption keys (or the latter and a full snapshot of the production database)? And if that were to occur, it may make sense to rotate your keys, but in many (most?) cases this would be a distant priority from dealing with the fact that your application server were compromised in the first place; responding to a catastrophic breach would take precendent.
From a compliance perspective, rotating master keys typically meets the intention of most major regulatory frameworks and industry guidelines.
@Kenneth_White Not only you have answered my questions but you have constructed the answer in such a way that i would try to respond. Thanks a lot. Have a nice day
