1

我们目前正在研究 gcp 云 kms 以及如何应对灾难恢复。这是我们当前的测试设置：

Java 使用 Spring boot + Google Tink 使用 KMSEnvelopeAead + AesGcmJce（即由 tink 生成的 DEK，将通过 kms (KEK) 加密并与密文一起存储），对称

  1. 项目“A”（灾难恢复前的初始项目）

    -> KMS -> 密钥环“keyringABC” -> 密钥“keyABC” -> 通过导入作业导入的自定义密钥。我可以成功地加密/解密一些文本 - 一切都好，一切都好

resource: projects/A/locations/eur3/keyRings/keyringABC/cryptoKeys/keyABC/cryptoKeyVersions/1

  1. 项目“B”（灾难恢复项目）或具有新密钥 + 密钥环的相同项目“A”（名称可能不同）

    -> KMS -> 密钥环“keyringABC” -> 密钥“keyABC” -> 通过导入作业导入自定义密钥

    我重新导入了之前已导入项目“A”的自定义密钥材料，用于加密项目“A”中的数据。新创建的密钥模仿了与项目“A”中相同的结构。唯一的区别是，它位于项目“B”中

resource: projects/B/locations/eur3/keyRings/keyringABC/cryptoKeys/keyABC/cryptoKeyVersions/1

现在，当我尝试使用在项目“A”中加密的项目“B”中新创建的密钥解密数据时，我不起作用。查看云日志记录我可以看到以下错误消息

Decryption failed: verify that 'name' refers to the correct CryptoKey.

我的假设是（在阅读文档时）密文，在这种情况下，由 tink 通过云 kms 生成的 DEK，还包含指向项目“A”的密钥的确切资源标识符，因此加密的 DEK 不能被解密在项目“B”中使用新创建的密钥时不再使用。这意味着即使底层（导入的）自定义密钥材料相同，也无法恢复另一个项目中的数据。

任何人都可以对此有所了解吗？任何帮助表示赞赏。

干杯马塞尔

PS：来自 google kms 文档

当使用对称 Cloud KMS 或 Cloud HSM 密钥加密数据时，有关加密密钥版本的额外元数据将与加密数据一起保存、加密。在 Cloud KMS 之外加密的数据中不存在此元数据。

和

对称密钥总是有一个主版本。此版本默认用于加密。当 Cloud KMS 使用对称密钥执行解密时，它会自动识别执行解密所需的密钥版本。

4

1 回答 1

0

是的，它必须是完全相同的密钥，具有完全相同的资源 id，包括项目 id。解密的密文应该与 encrypt 调用返回的完全相同。因此，您需要确保它与您在其中创建 KMS 密钥的项目相匹配。当您尝试使用在project-A中加密的project-B中新创建的密钥解密数据时，它会失败。

在您的用例中，您尝试解密的密文是使用不同的密钥加密的。您应该对加密和解密使用相同的密钥，否则 KMS 会告诉您它无法找到密钥，而实际上已找到密钥。

于 2021-11-29T10:39:24.333 回答