随着企业把工作负载分布到多个云平台，BYOK（Bring Your Own Key）已经成为数据主权和关键业务保护的重要组成部分。但密钥在网络中传输时，传统导入方式通常依赖经典公钥加密算法。攻击者可以先截获并长期保存这些密文，等具备密码学意义的量子计算机出现后再尝试解密，这就是“先存储、后解密”（Store Now, Decrypt Later，SNDL）攻击。
Google Cloud KMS 现已预览支持面向软件加密密钥的量子安全密钥导入。它把后量子密码学能力接入现有的 Cloud KMS 导入流程，在密钥进入 KMS 边界之前，使用量子抗性的 HPKE 信封保护密钥材料。
量子安全导入解决什么问题
传统 BYOK 流程的核心目标是让客户控制密钥材料，但传输保护仍可能使用经典 RSA 或椭圆曲线算法。面对今天的攻击，这些算法仍然有效；问题在于，已经被截获并保存的密文可能在未来受到量子计算的影响。
量子安全密钥导入把风险窗口前移处理：密钥材料从客户端离开时，就被封装在量子抗性的传输信封中。这样，攻击者即使保存了传输中的密文，也更难在未来利用量子计算能力恢复原始密钥。
这项能力目前面向软件型加密密钥的导入，并且属于预览阶段。它并不意味着所有业务数据、现有密钥和通信链路都已经完成后量子迁移。企业仍然需要盘点算法、密钥用途、依赖服务和轮换策略。
一次导入任务如何完成
新的流程仍然围绕 Cloud KMS API 的 ImportJob 展开，主要步骤如下：
- 客户端通过 Cloud KMS API 创建导入任务，并请求后量子 HPKE 导入方法。
- Cloud KMS 生成后量子 KEM 私钥，并向客户端提供对应的公钥。
- 客户端使用 Tink、OpenSSL 或其他受支持的密码学库执行 HPKE
Seal()。 Seal()通过 KEM 封装建立共享密钥，再使用 HKDF-SHA-256 派生临时 AES 密钥。- 客户端使用 AES-256-GCM 加密目标密钥材料，并把 KEM 密文与加密后的密钥材料提交回 Cloud KMS。
- Cloud KMS 使用自身的 KEM 私钥执行 HPKE
Open()，在 KMS 边界内解开并保护密钥材料。
KEM 层可以选择 X-Wing、ML-KEM-768 或 ML-KEM-1024。密钥派生使用 HKDF-SHA-256，最终的对称封装使用 AES-256-GCM，并采用标准的 12 字节 nonce。
需要注意，HPKE 的具体封装格式、字段拼接方式、导入任务参数和密钥材料编码必须以 Cloud KMS 文档及所选密码学库的要求为准。不要自行发明一个“看起来像 HPKE”的协议。
一个可改造的客户端封装示例
下面的 Python 示例演示了导入流程中本地对称加密部分的结构。它可以直接运行，但 kem_encapsulate() 使用的是占位实现，因为真实的 X-Wing 或 ML-KEM 封装必须由受支持的 HPKE/PQC 库完成。接入生产环境时，应把该函数替换为 Cloud KMS 支持的 Tink、OpenSSL 或其他官方兼容实现。
运行前安装依赖：
python -m pip install cryptography
示例代码：
#!/usr/bin/env python3
import base64
import os
from cryptography.hazmat.primitives import hashes
from cryptography.hazmat.primitives.kdf.hkdf import HKDF
from cryptography.hazmat.primitives.ciphers.aead import AESGCM
def kem_encapsulate(import_public_key: bytes) -> tuple[bytes, bytes]:
"""Replace this with the supported X-Wing or ML-KEM implementation."""
if not import_public_key:
raise ValueError("import public key is required")
raise NotImplementedError(
"Call the supported HPKE/PQC library to perform KEM encapsulation"
)
def wrap_key_material(key_material: bytes, import_public_key: bytes) -> bytes:
encapsulated_key, shared_secret = kem_encapsulate(import_public_key)
aes_key = HKDF(
algorithm=hashes.SHA256(),
length=32,
salt=None,
info=b"Cloud-KMS-quantum-safe-key-import",
).derive(shared_secret)
nonce = os.urandom(12)
ciphertext = AESGCM(aes_key).encrypt(nonce, key_material, None)
# The exact envelope layout must match the Cloud KMS import contract.
envelope = encapsulated_key + nonce + ciphertext
return envelope
if __name__ == "__main__":
# Replace these values with the public key returned by the import job
# and the local software key material that must be imported.
kms_import_public_key = base64.b64decode("REPLACE_WITH_BASE64_PUBLIC_KEY")
software_key_material = base64.b64decode("REPLACE_WITH_BASE64_KEY_MATERIAL")
envelope = wrap_key_material(software_key_material, kms_import_public_key)
print(base64.b64encode(envelope).decode("ascii"))
这个例子强调了几个边界：KEM 私钥不应离开 Cloud KMS；客户端只应使用导入任务返回的公钥；AES-GCM nonce 必须对同一密钥绝不重复；最终提交的封装格式不能仅凭示例代码决定。生产实现还应加入密钥材料长度校验、审计日志、失败重试策略和敏感数据清理。
如果团队更习惯命令行，可以先把工作流拆成以下几个可审计步骤。命令中的参数名是示意，实际使用时请替换为当前 Cloud KMS 版本支持的参数：
PROJECT_ID="your-project-id"
LOCATION="global"
KEYRING="byok-keyring"
IMPORT_JOB="pqc-import-job"
# 1. 创建或选择目标密钥，并创建后量子导入任务
# 具体 --import-method 参数以当前 Cloud KMS CLI/API 文档为准
gcloud kms import-jobs create "$IMPORT_JOB" \
--location="$LOCATION" \
--keyring="$KEYRING" \
--project="$PROJECT_ID" \
--import-method="QUANTUM_SAFE_HPKE"
# 2. 获取导入任务返回的 HPKE/KEM 公钥
# 3. 使用受支持的 PQC/HPKE 工具在本地封装密钥材料
# 4. 将封装后的 ciphertext 提交给 Cloud KMS
# 不要把私钥、明文密钥材料或中间文件写入共享日志
把导入能力放进迁移计划
量子安全密钥导入只是后量子密码学迁移的一个里程碑。它主要保护密钥材料在导入过程中的传输，不会自动替换应用中的 TLS 算法、签名算法、数据库加密方案或外部供应商接口。
可以按下面的顺序推进：
- 盘点非对称密钥使用的算法、用途、生命周期和依赖服务。
- 区分需要防范长期保密风险的密钥，例如用于保护长期存档数据的密钥。
- 优先为新建的 BYOK 流程设计量子安全导入，而不是继续扩大传统导入方式的覆盖面。
- 评估 X-Wing、ML-KEM-768 和 ML-KEM-1024 在兼容性、性能、密钥大小和组织标准方面的取舍。
- 使用 Cloud KMS PQC insights 查看非对称密钥的算法分类，形成可跟踪的现代化清单。
- 在预览能力进入生产前，验证审计、恢复、轮换、灾备和供应商互操作性。
采用时的检查清单
量子安全导入适合纳入新密钥和高价值密钥的保护计划，但不应被当作一次性迁移按钮。落地前至少确认以下事项：
- 是否明确了需要导入的密钥材料类型和编码格式？
- 客户端是否使用了受支持的 HPKE、X-Wing 或 ML-KEM 实现？
- 是否验证了 nonce 不重复、密钥材料不落盘和日志脱敏？
- 是否记录了导入任务、封装算法、版本和操作人员？
- 是否为预览功能准备了回滚、轮换和故障处理方案？
- 是否结合 PQC insights 制定了整体后量子迁移优先级？
对 BYOK 用户来说，最现实的起点是保护“今天创建、需要长期保密”的新密钥，并同步建立算法盘点和迁移指标。这样可以在量子安全能力逐步演进的同时，减少未来集中改造带来的风险。