Encrypter requires Cloud KMS Decrypt while wrapping a Data Manager DEK

Upstream report - encrypt-only Data Manager keyset wrapping

Target: googleads/data-manager-python

Title: Encrypter requires Cloud KMS Decrypt while wrapping a Data Manager DEK

Report

The official google-ads-datamanager-util Encrypter cannot be constructed with a least-privilege
Cloud KMS identity that has cloudkms.cryptoKeyVersions.useToEncrypt but not
cloudkms.cryptoKeyVersions.useToDecrypt.

Environment:

• googleads/data-manager-python commit
  4c8e3ee94854e9fc34c63f9468dcaee20ad02c89 (google-ads-datamanager-util==0.4.0rc1)
• tink[gcpkms]==1.16.0
• a Cloud KMS service account restricted to encrypting under one exact KEK

Encrypter._create(...) calls tink.proto_keyset_format.serialize_encrypted(...). Tink encrypts
the serialized keyset with the supplied KMS AEAD and then immediately calls that AEAD's decrypt
method to compare the recovered keyset. Cloud KMS Encrypt succeeds, but the expected Decrypt denial
causes Encrypter construction to fail before any Data Manager request is made.

Relevant source:

• official utility call
• Tink 1.16.0 serialization entry point
• Tink 1.16.0 Encrypt-then-Decrypt check

Could the utility expose a supported path that produces the same Data Manager encrypted_dek
bytes while requiring only KMS Encrypt from the local identity? If Tink intentionally requires the
round-trip check, guidance on the supported least-privilege permission model would also resolve the
ambiguity.

Tink's public KmsEnvelopeAead.encrypt(...) is not a drop-in replacement: it encrypts raw
KeyData.value, generates a fresh key per payload, and returns a length-prefixed combined envelope
ciphertext rather than the serialized process-lifetime EncryptedKeyset emitted by the utility.

We deliberately did not grant temporary Decrypt, fabricate a Decrypt result, patch Tink, or assemble
the secret-keyset envelope manually. No Data Manager RPC was attempted and no customer data is
involved in this report.

Commencez par google/ads/datamanager_util/encrypt.py autour de l'appel à l'utilitaire cité, puis examinez _proto_keyset_format.py et _keyset_handle.py de Tink dans les vérifications de sérialisation et de round-trip référencées. Déterminez si un chemin encrypt-only pris en charge peut préserver les octets encrypted_dek de l'utilitaire, ou documentez le modèle d'autorisations requis. Le travail est terminé lorsque le comportement pris en charge ou les indications sont dépourvus d'ambiguïté.