📚 课程目录第2章量子密钥分发与密钥管理基础

2. 量子密钥分发与密钥管理基础

在讨论量子密钥如何与业务系统对接之前，需要先把三个层次分清楚：QKD 负责在两端之间产生并协商出对称密钥，密钥管理系统（KMS）负责这些密钥的存储、调度、更新与销毁，密钥即服务（KaaS）负责把密钥以标准接口交付给业务系统。三者是"产生—治理—消费"的关系，任何一层缺失，量子密钥都无法真正进入业务加密流程。

一、QKD 原理简述：密钥不是"传"过去的，而是"协商"出来的

QKD 的典型代表是 BB84 协议。它利用单光子量子态不可克隆的特性：发送端（Alice）随机选择两组基（直角基 + 与对角基 ×）之一，把随机比特编码到单光子偏振态上；接收端（Bob）也随机选基测量。测量后双方通过公开信道比对"用了哪组基"，只保留基一致的比特，这一步叫基比对（sifting），通常能保留约 50% 的原始比特。

随后双方公开部分密钥比特做误码率估计（QBER）。若信道被窃听者（Eve）截获重发，会引入额外误码。工程上常以约 11% 作为安全阈值参考：低于阈值则继续，高于阈值则丢弃本轮密钥并告警。通过阈值后，还要经过纠错消除双方不一致比特，再经过隐私放大压缩掉窃听者可能掌握的信息，最终得到一段双方一致、且对第三方保密的对称密钥。

关键认知：QKD 输出的是"密钥材料"，不是业务数据。它解决的是密钥分发的安全性，不解决身份认证——身份认证仍需依赖预共享密钥或数字证书，这是工程部署中必须补齐的一环。

二、密钥管理生命周期：从生成到销毁的闭环

QKD 链路持续产出密钥，但业务系统不能直接"抓"原始密钥使用，必须由 KMS 按生命周期管理。一个完整的生命周期通常包含以下阶段：

生成与注入：QKD 设备产出密钥后写入 KMS 的密钥池，按密钥 ID、生成时间、长度、来源链路打标签。
存储与隔离：密钥在 KMS 内部加密存储，按租户/业务域隔离，禁止跨域明文导出。
分发与取用：业务系统按需申请，KMS 以密钥 ID 引用方式下发，密钥本身不落地到业务明文配置中。
轮换：按时间或用量阈值触发更新，例如每 10 分钟或每加密 1 GB 数据轮换一次。
归档与销毁：过期密钥进入归档区保留审计期，到期后执行不可恢复销毁并记录销毁凭证。

生命周期管理的核心指标是密钥池水位。若 QKD 链路因环境扰动（如光纤振动、温度漂移）导致成码率下降，而业务侧取用速率不变，密钥池会被抽干，此时 KMS 必须能降级到备用密钥源或限制发放速率，否则业务加密会中断。这是运维中最常见的故障模式之一。

三、KaaS 模型：密钥作为服务交付给业务系统

KaaS 的本质是把密钥从"设备私有资产"变成"可被业务系统按标准方式调用的服务"。业务系统不再关心密钥来自哪台 QKD 设备、经过什么协议，只通过统一接口完成三件事：申请密钥、使用密钥、归还/释放引用。

一个典型的 KaaS 交互流程如下（示例参数，非实测）：业务系统启动加密任务时，向 KMS 发起申请，请求体包含业务标识、所需密钥长度（如 256 bit）、用途标签（如 db-encrypt）和期望有效期（如 600 秒）。KMS 校验租户权限与密钥池水位后，返回密钥 ID 与一次性取用令牌，业务系统凭令牌在有效期内获取密钥明文用于本地加密运算，运算完成后立即释放内存中的密钥明文，仅保留密钥 ID 用于审计追溯。

POST /kms/v1/keys/request
{
  "tenant": "biz-payment",
  "purpose": "db-encrypt",
  "key_length": 256,
  "ttl_seconds": 600
}

响应示例：
{
  "key_id": "qkd-key-20240612-000871",
  "token": "tk-9f3a...c21",
  "expires_at": "2024-06-12T10:30:00Z",
  "source_link": "qkd-link-shanghai-01"
}

这种"引用式"设计有两个工程好处：一是密钥明文不进入业务配置文件，降低泄露面；二是 KMS 可以精确统计每个业务系统的密钥消耗速率，为容量规划提供依据。例如某业务每秒申请 1 把 256 bit 密钥，则日消耗约 8.6 万把，若 QKD 链路成码率折算后每小时仅能补充 2 万把，密钥池必然入不敷出，需要提前扩容链路或调整轮换策略。

四、与业务系统的关系：三种典型对接模式

实际落地中，业务系统与 KaaS 的对接通常有三种模式。旁路代理模式：在业务与 KMS 之间部署密钥代理，业务无改造，由代理完成申请与注入，适合存量系统快速接入。SDK 嵌入模式：业务代码集成 KMS 客户端 SDK，按需调用，控制粒度最细，适合新建系统。网关托管模式：由加密网关统一向 KMS 取密钥并完成加解密，业务只与网关交互，适合多业务共享同一套密钥基础设施的场景。

无论哪种模式，都必须明确一条边界：QKD 只保证密钥分发环节的物理安全，业务数据的加密强度还取决于算法选择、密钥使用规范和访问控制。把 QKD 接入业务系统，不是"接上就安全"，而是要把密钥生命周期、接口权限、审计日志和降级预案一起设计进去，才能形成可运维、可审计的密钥服务闭环。