we are currently getting our heads around gcp cloud kms and how to cater for disaster recovery. this is our current test setup:
Java using Spring boot + Google Tink using KMSEnvelopeAead + AesGcmJce (i.e. generated DEK by tink that will be encrypted via kms (KEK) and stored alongside the ciphertext), symmetric
project "A" (the initial project before disaster recovery)
-> KMS -> keyring "keyringABC" -> key "keyABC" -> imported custom key via import job. i can successfully encrypt/decrypt some text - all fine, all good
resource: projects/A/locations/eur3/keyRings/keyringABC/cryptoKeys/keyABC/cryptoKeyVersions/1
project "B" (the disaster recovery project) or same project "A" with a new key + keyring (names would be different)
-> KMS -> keyring "keyringABC" -> key "keyABC" -> imported custom key via import job
i reimport the custom key material that i already imported into project "A" before that was used to encrypt the data in project "A". the newly created key mimics the same structure as in project "A". the only difference is, that it resided in project "B"
resource: projects/B/locations/eur3/keyRings/keyringABC/cryptoKeys/keyABC/cryptoKeyVersions/1
Now, when i try to decrypt the data with the newly created key from project "B" that was encrypted in project "A" i does not work. looking into the cloud logging logs i can see the following error message
Decryption failed: verify that 'name' refers to the correct CryptoKey.
My assumption is (when reading the docs) that the ciphertext, in this case the DEK generated by tink via cloud kms, also contains the exact resource identifer pointing to the key of project "A" and hence the encrypted DEK can't be decrypted anymore when using the newly created key in project "B". This would mean that there is no way to recover data in another project even if the underlying (imported) custom key material is the same.
Can anybody shed some light on this? any help appreciated.
cheers marcel
PS: from the google kms docs
when data is encrypted using a symmetric Cloud KMS or Cloud HSM key, extra metadata about the encryption key version is saved, encrypted, along with the encrypted data. This metadata is not present in data encrypted outside of Cloud KMS.
and
Symmetric keys will always have a primary version. This version is used for encrypting by default. When Cloud KMS performs decryption using symmetric keys, it automatically identifies which key version is needed to perform the decryption.
Yes, it has to be the exact same key with the exact same resource id including project id.The ciphertext for decryption should be exactly as returned from the encrypt call. So, you need to make sure it matches the project in which you created the KMS key. When you try to decrypt the data with the newly created key from project-B that was encrypted in project-A, it fails.
In your use-case the ciphertext you're trying to decrypt was encrypted using a different key. You should use the same key for both encryption and decryption, else KMS tells you that it could not find the key while actually the key was found.