Client-side encryption DEK rewrapping with rewrapManyDataKey
Parent: MongoDB Security Architecture · Published reference · snapshot 2026-10-29
↓ Facts as markdownall context files
Source-anchored research for Client-side encryption DEK rewrapping with rewrapManyDataKey. Run status: COMPLETED.
These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.
Definitions
- The operation is not atomic, and MongoDB warns against running it in parallel with other key-management operations. (low confidence) [source]
How it works
- The historical MONGOCRYPT-464 bug affected rewrapping with libmongocrypt 1.5.0/1.5.1: when Azure- or GCP-backed DEK decryption required fetching an access token, rewrapping could replace original key material with random material. The documented fix was libmongocrypt 1.5.2. (medium confidence) [source]
- The driver API returns RewrapManyDataKeyResult with an optional bulkWriteResult; it can be absent when no keys match or when the bulk write is unacknowledged. (low confidence) [source]
- The options identify the target KMS provider and provider-specific masterKey. When masterKey is omitted, each DEK uses the CMK referenced in its existing metadata. (medium confidence) [source]
- AWS KMS key-material rotation preserves the logical KMS key and selects the original key material when decrypting existing ciphertext. It does not rotate data keys or mitigate a compromised data key; MongoDB likewise leaves DEK material unchanged when rewrapping. (medium confidence) [source]
Comparisons and alternatives
- rewrapManyDataKey decrypts existing DEKs and re-encrypts their unchanged plaintext key material under the selected CMK. Rewrapping changes key protection rather than replacing the DEKs that encrypt application fields. (medium confidence) [source]
Facts and statements
- The key vault stores CMK-encrypted DEKs. A client needs both key-vault access and access to the protecting KMS key to use a DEK; the key vault can reside on a separate MongoDB cluster. (medium confidence) [source]
- Rotating the KMS key does not itself rewrap existing stored DEKs. AWS additionally documents that key rotation does not replace data keys, re-encrypt protected data, or mitigate a compromised data key. (medium confidence) [source]
- The filter selects key-vault documents to rewrap. If no key matches, the driver performs no bulk write; without a new masterKey, DEKs are rewrapped using their current master keys. (medium confidence) [source]
- Back up the key-vault collection before rewrapping: losing DEK material can make the corresponding encrypted data unrecoverable. (medium confidence) [source]
- The client-side encryption specification requires applicable drivers to reject rewrapManyDataKey with libmongocrypt 1.5.0 or 1.5.1 and document dependency upgrades for MONGOCRYPT-464. (low confidence) [source]
- Fortanix documents a concrete KMIP integration sequence: rotate the CMK in DSM, then call ClientEncryption.rewrapManyDataKey with the returned CMK identifier as masterKey.keyId and the chosen provider. (low confidence) [source]
- rewrapManyDataKey decrypts matching wrapped DEKs, re-encrypts them under a specified CMK, and updates their documents in the Key Vault collection. (medium confidence) [source]
- Rotating a CMK at the KMS does not automatically rewrap existing MongoDB DEKs; an explicit rewrapManyDataKey operation performs that separate step. (medium confidence) [source]
- The query filter selects Key Vault documents to rewrap; an empty filter selects all keys. If no keys match, the driver specification requires no bulk write and leaves bulkWriteResult unset. (medium confidence) [source]
- Back up the Key Vault before rewrapping and confirm that keys no longer protect any required data or keys before deleting them. Losing a required DEK or CMK can make encrypted fields permanently unreadable. (medium confidence) [source]
- MongoDB's mongosh v1.5.4 release notes, dated July 31, 2022, describe a destructive historical bug: rewrapping an Azure- or GCP-backed DEK that required fetching an access token for decryption could replace all rewrapped DEKs with random material. The release notes identify v1.5.4 as the shell fix. (low confidence) [source]
Children
- Key-vault backup and recovery during DEK rewrapping (frontier)
- KMS key-version rotation versus DEK replacement (frontier)
- MONGOCRYPT-464 dependency safeguards (frontier)
Frontier under this node: KMS key-version rotation versus DEK replacement, Key-vault backup and recovery during DEK rewrapping, MONGOCRYPT-464 dependency safeguards