If No New DEKs are Created after CMK Rotation with MongoDB CSFLE, Does That Mean The New Key Will Not be Used?

MongoDB Atlas
,
1

Hi all,

I’m looking through some past responses on how CMK rotation works with the CSFLE library: CSFLE key rotation: how to update the CMK in the DEK that references an updated version

My question is, after key rotation, if we don’t ever create a new data encryption key, does that mean the library will never use the new rotated key (on let’s say AWS KMS) and always use the old key?

Is there a way to achieve either of the following?

  1. Re-encrypt the DEK with the rotated key
  2. Maintain multiple DEKs and associate each with the correct data to decrypt transparently? Without needing to create multiple mongodb clients with multiple schemas and figuring out which client to use for which piece of data?

Thank you!

2

Hi @Thomas_Zhang2!

I’m not entirely sure if this answers your questions, but just a few clarifications:

  • Rotating the CMK will generally have no impact on DEKs and encrypted data in collections. Unless you are using the local KMS provider, rotating the CMK will just create a new encryption key on the KMS side (e.g. in AWS), but the old CMK will generally be kept around and can still be used for decrypting older DEKs that were encrypted using the old CMK.
  • DEKs can be re-wrapped, which is referenced in the linked post as well – this will not change the actual DEK key material, though.

For the latter operation, you’d call the rewrapManyDataKey, which will:

  • Read the key vault collection and look for DEKs matching the specified filter (or all, if none was specified)
  • Reach out to the KMS which was used to encrypt the DEKs and ask it to decrypt the DEK
  • Reach out to the target KMS (which will often be the same one) and ask it to re-encrypt the DEK
  • Update the key vault collection to store the re-wrapped DEKs

Given the potentially destructive nature of these operations, it can make sense to create a backup of the key vault collection. Apart from that, yes, re-wrapping DEKs this way after performing a key rotation on the KMS side would be the easiest way to ensure that the DEKs are actually encrypted using the new CMK, and it’s probably the answer to your first question here.

For your second question – encrypted data in actual collections is self-describing, i.e. it contains the ID of the DEK that was used to encrypt it, and so MongoClient instances will generally know which DEK to fetch for decrypting it. In theory, this would allow you to use different DEKs for a single field in a single collection over time, but that only applies as far as direct decryption is concerned (i.e. queryability would still be broken in the case of Deterministic Encryption or when using Queryable Encryption instead of CSFLE).

I hope this helps!