📚 课程目录第4章密钥轮换核心概念

4. 密钥轮换核心概念

安全启动的密钥轮换并不是“把旧密钥删掉、换一把新密钥”这么简单。它同时牵动固件镜像签名、启动链验证、设备端信任根、恢复机制与产线烧录流程。真正可落地的轮换工程，核心在于把“何时换、怎么换、旧设备怎么办、如何识别密钥、元数据如何描述”这五件事设计成一套可审计、可回滚、可渐进推进的机制。

轮换的本质不是替换密钥本身，而是替换“信任关系的版本”。每一次轮换，都必须让设备、镜像、签名工具和策略服务器对“当前有效信任集合”达成一致。

一、轮换触发条件：从被动救火到主动治理

轮换触发条件决定了轮换是计划性动作还是应急响应。工程上通常分为四类：时间驱动、事件驱动、风险驱动和合规驱动。时间驱动适合按周期更新，例如每 12 或 24 个月轮换一次签名密钥；事件驱动发生在人员离职、供应商变更、签名服务迁移或 HSM 更换时；风险驱动则来自密钥泄露、侧信道攻击、算法弱化或异常签名行为；合规驱动来自标准或客户审计要求，例如要求密钥生命周期不超过规定期限。

需要特别注意的是，安全启动密钥一旦泄露，攻击者可以签名恶意固件并通过启动链验证，因此“泄露触发”必须预设应急路径：立即冻结旧密钥、发布撤销列表、启用备用密钥，并评估已出厂设备是否可通过恢复模式更新信任根。

二、轮换策略：渐进式、并行式与强制式

轮换策略决定新旧密钥如何共存与切换。常见策略有三种：

渐进式轮换：新固件使用新密钥签名，旧设备仍信任旧密钥，新设备只信任新密钥。适合大规模存量设备场景，但需要设备端支持多密钥信任。
并行式轮换：一段时间内新旧密钥同时有效，签名工具可任选其一，验证端同时接受两者。适合过渡期，但会扩大攻击面，必须设定明确的并行截止时间。
强制式轮换：一次性切换，旧密钥立即失效。适合小规模、可控设备或高风险应急场景，但回滚能力差，容易导致批量变砖。

策略选择应结合设备是否支持远程更新、是否有恢复模式、是否允许双签名，以及产线是否具备重新烧录能力。对于安全启动，推荐“渐进式为主、并行式为过渡、强制式仅用于应急”的组合策略。

三、向后兼容：让旧设备不被“一刀切”

向后兼容是轮换工程中最容易被低估的环节。安全启动的信任根通常固化在 OTP 或 ROM 中，无法像应用层密钥那样随意替换。因此，轮换设计必须回答：旧设备能否验证新固件？新设备能否拒绝旧固件？如果设备只信任一把密钥，轮换就意味着必须保留旧密钥用于旧设备，同时为新设备引入新密钥。

常见做法是采用“密钥槽”机制：设备端预留多个信任根槽位，每个槽位可独立启用或撤销。轮换时，新固件用新密钥签名，旧设备继续使用旧槽位验证；新设备出厂时只启用新槽位。这样既保证旧设备可继续接收安全更新，又避免新设备被旧密钥签名恶意固件降级攻击。

向后兼容不等于永久兼容。必须为旧密钥设定“最后支持版本”或“撤销日期”，否则旧密钥会成为长期攻击面。

四、版本管理与密钥标识：让每一把密钥可追踪

版本管理要求每次轮换都有明确的版本号、生效时间、失效时间和适用设备范围。密钥标识则用于在签名、验证和审计环节唯一识别密钥。推荐使用结构化标识，例如：

KeyID = <厂商ID>-<用途>-<算法>-<版本>-<状态>
示例：ACME-BOOT-RSA3072-v3-active
      ACME-BOOT-RSA3072-v2-deprecated
      ACME-RECOVERY-ECDSA-P256-v1-revoked

密钥标识应写入签名元数据、固件清单和撤销列表，使验证端能够根据 KeyID 快速判断该密钥是否在允许集合内。版本号建议单调递增，禁止复用；状态至少包含 active、deprecated、revoked 三种，便于策略服务器下发。

五、元数据设计：把信任策略写进数据里

元数据是轮换策略的载体。安全启动镜像的签名元数据通常应包含：KeyID、密钥版本、签名算法、签名时间、镜像版本、最低可接受安全版本、撤销列表版本、双签名标记等。元数据设计要遵循“验证端可独立判断”的原则，即设备不依赖网络也能根据本地策略和元数据决定是否接受镜像。

下面这张图展示了密钥轮换中“触发—策略—兼容—版本—元数据”之间的核心关系，以及新旧密钥在设备端与镜像端的信任映射。

六、案例与场景：一次典型的渐进式轮换

某工业网关厂商发现旧 RSA-2048 启动密钥即将到期，决定轮换到 RSA-3072。设备端 OTP 中预留了两个密钥槽：槽 0 为旧密钥，槽 1 为新密钥。轮换分三阶段：

准备阶段：生成新密钥对，KeyID 为 GW-BOOT-RSA3072-v2-active，旧密钥标记为 deprecated，但仍在设备端槽 0 中有效。
过渡阶段：新固件同时携带新旧两把密钥的签名，旧设备用槽 0 验证通过，新设备用槽 1 验证通过。撤销列表版本从 v5 升到 v6，明确旧密钥将在 6 个月后撤销。
收尾阶段：6 个月后，新固件只带新密钥签名，旧密钥进入 revoked 状态。未升级的旧设备通过恢复模式更新信任根，否则无法再接收新固件。

这个案例的关键在于：元数据中的“撤销列表版本”和“最低可接受安全版本”必须随固件一起下发，设备端才能判断是否接受某个镜像。

七、常见误区与复盘

误区	后果	正确做法
轮换时直接删除旧密钥	旧设备无法验证新固件，批量变砖	保留旧密钥槽，设定撤销日期
KeyID 不含版本和状态	无法区分新旧密钥，审计困难	使用结构化 KeyID，状态可查询
元数据不包含撤销列表版本	设备无法判断密钥是否已撤销	元数据携带撤销列表版本并校验
并行期无限延长	旧密钥长期有效，攻击面扩大	并行期设硬截止时间，到期强制撤销
忽略恢复模式	无法升级的旧设备彻底失联	设计恢复路径，允许安全更新信任根

轮换工程中最危险的不是新密钥不可用，而是旧密钥在撤销后仍被设备信任。必须确保撤销列表版本、设备端策略和签名元数据三者同步，否则会出现“已撤销但未生效”的信任空洞。

总结来看，密钥轮换的核心概念可以归纳为一条主线：触发条件决定何时换，轮换策略决定怎么换，向后兼容决定旧设备怎么办，版本管理决定如何追踪，密钥标识与元数据决定验证端如何判断。五者缺一不可，共同构成安全启动密钥轮换的可工程化基础。