Hi,
I would really appreciate some further explanations about the point of key rotation when using FLE. I’ve gone through this topic and few other sources to do my best to understand the whole FLE mechanism but I still have one main issue with it. With Mongodb storing the data encryption keys (DEK) in separate collection and without those keys being rotated what’s the benefit of using key rotation of the keys that protect DEKs?
So let’s assume that we encrypt every document within collection with one DEK (so for two collections - let’s call them Bob and Alice - there are 2 DEKs etc.) and we use one key that protects those DEKs. If there is ever a situation that this protecting key is compromised, an attacker will always be able to read all the documents from Bob and Alice collections even if the key is rotated as the compromised key will always be able to decrypt both those DEKs. But if we add another collection after the rotation - the third collection will be safe as the new DEK is encrypted with the new version of rotated key and the compromised key is not able to decrypt it. Of course we assume in such case the attacker has an access to the compromised key and to MongoDB cluster.
Sorry if the question sounds silly but appsec is not my area of expertise. Do I understand this behaviour correctly? Is there any important aspect missing there? Or maybe there is some obvious improvement of presented flow you can suggest?
Thanks,
Maciek
Hi,
is there anyone who could help and confirm or resolve my doubts?
Regards,
Maciek
Hello Maciej,
Perhaps I can help explain. If I understand correctly your concern is that a compromised key could still be used to decrypt/unwrap the DEKs used to protect data. In this example I will refer to the key used to protect the Data Encryption keys (DEKs) as a Key Encryption Key (KEK). Once you know a key has been compromised there are two steps that should be taken.
One is, in addition to creating a new KEK with the key provider, you would need to change the KEK used to protect the DEKs from the compromised KEK to a new KEK. In the case you mention, the DEKs that were protected by the compromised KEK should be re-wrapped so that they are now protected by a new KEK. This ensures that the DEKs can no longer be decrypted/unwrapped with the compromised KEK. This is also considered key rotation, since in MongoDB you are rotating the KEK used to protect the DEKs. Programmatic support for this type of key rotation in FLE is in an upcoming release.
The second is to change the state of the key to “compromised”, or an equivalent supported state with your key provider. A compromised key should no longer be able to be used for any cryptographic purpose. That way even if an attacker has that compromised key, it cannot be used. Please note that key providers may support different key states and operations in those key states so ensure that you understand the implications before changing a key state. For example, you wouldn’t want to mark a KEK as compromised before you have ensured that there are no DEKs encrypted by it - which would leave your data permanently unreadable.
Since we are on the topic of securing keys, it is critical to ensure that your IAM roles that allow access to keys follow the principles of least privilege and separation of duties. Following those best practices will greatly reduce the risk of inadvertent or intentional exposure or compromise of your keys.
I hope that helps answer your question.
Cynthia
1 Like
Hey Cynthia,
In regards to “Programmatic support for this type of key rotation in FLE is in an upcoming release”. Is there anywhere I can track this release so I have an idea of when the functionality will be available?
Thanks,
Mey