3、密钥体系与角色：PK（平台密钥）、KEK（密钥交换密钥）、db/dbx（签名数据库/黑名单数据库）的作用与关系

Secure Boot 的信任链并非凭空建立，而是由一组层次化、角色分明的密钥和数据库共同支撑。理解 PK、KEK、db、dbx 的定位与协作关系，是进行密钥烧录、轮换和安全管理的前提。本章将深入拆解这套密钥体系的架构原理、操作判断方法、实战场景以及常见误区，帮助您建立完整的 UEFI 安全启动信任模型。

3.1 核心原理：四层信任锚点的职责划分

Secure Boot 的密钥体系本质上是一个“倒树状”的信任模型。最顶层是平台密钥（PK），它代表平台所有者的权威；第二层是密钥交换密钥（KEK），负责管理签名数据库的更新；第三层是签名数据库（db）和黑名单数据库（dbx），它们直接决定哪些启动镜像可以被加载。每一层都通过数字签名机制向下授权，形成一条不可跳过的验证链。

PK（Platform Key）是整个 Secure Boot 机制的信任根。它通常由平台所有者（如企业 IT 部门或 OEM 厂商）生成并持有私钥，公钥被烧录到主板固件中。PK 的私钥极少被使用，仅在更换 KEK 或关闭 Secure Boot 时才会调用。一旦 PK 被清除或替换，整个信任链将重置，所有已注册的密钥都会失效。

KEK（Key Exchange Key）是连接 PK 与签名数据库的桥梁。KEK 的私钥用于对 db/dbx 的更新请求进行签名。例如，当微软发布新的 Windows 启动管理器时，会使用微软的 KEK 签名更新 db。KEK 的数量可以不止一个，但每个 KEK 都必须经过 PK 的签名授权才能生效。

db（Signature Database）存储被信任的签名者证书或镜像哈希值。当固件加载启动镜像时，会先检查镜像的签名是否匹配 db 中的条目。匹配则允许启动，不匹配则拒绝。db 中既可以存放 X.509 证书（用于验证签名），也可以存放具体的文件哈希（用于精确匹配）。

dbx（Forbidden Signature Database）是 db 的补充，存储已被撤销或不再信任的签名者证书、镜像哈希或时间戳。dbx 的优先级高于 db——即使镜像签名在 db 中有效，只要其哈希或证书出现在 dbx 中，固件同样会拒绝加载。这为应对密钥泄露或镜像漏洞提供了快速响应通道。

3.2 判断方法与操作流程：如何正确配置和验证密钥

在实际的密钥烧录与安全配置中，判断当前密钥状态、规划更新流程是首要任务。以下是一套标准化的操作判断流程，适用于大多数 UEFI 固件环境（如 AMI、Insyde、Phoenix）。

3.2.1 密钥状态检查

在 Linux 环境下，可以使用 efi-readvar 工具查看当前固件中的密钥变量；在 Windows 下，可使用 Manage-SecureBootUEFI PowerShell 命令。检查时需关注以下关键指标：

• SecureBoot 状态：Enabled（启用）或 Disabled（禁用）。
• SetupMode 状态：若为 1，表示处于设置模式，允许直接写入 PK；若为 0，表示处于用户模式，必须通过签名验证才能更新密钥。
• PK/KEK/db/dbx 条目数：确认是否存在默认密钥（如微软的 KEK 和 db 条目）。

# Linux 下查看 Secure Boot 变量
efi-readvar -f PK
efi-readvar -f KEK
efi-readvar -f db
efi-readvar -f dbx

3.2.2 密钥更新操作流程

以“替换 KEK 并新增 db 条目”为例，标准流程如下：

1. 生成新密钥对：使用 OpenSSL 生成新的 KEK 私钥和证书请求（CSR）。
2. 使用 PK 私钥签名 KEK 证书：将新 KEK 证书用 PK 私钥进行签名，生成 KEK.auth 文件。
3. 使用 KEK 私钥签名 db 更新：将新的 db 条目（证书或哈希）用 KEK 私钥签名，生成 db.auth 文件。
4. 写入固件：在 UEFI Shell 或操作系统下，使用 efi-updatevar 工具写入 KEK.auth 和 db.auth。
5. 验证：重启后再次检查变量，确认新条目已生效且 Secure Boot 仍为 Enabled。

3.3 案例拆解：企业批量部署中的密钥轮换实战

某大型制造企业拥有 5000 台工业控制计算机，原厂预装的是 OEM 默认密钥。由于安全审计要求，企业需要将所有设备的 PK 替换为自有的企业 PK，并重新配置 KEK 和 db，以仅允许运行企业签名的定制操作系统镜像。

初始现象与目标：设备处于 SetupMode，Secure Boot 未启用。目标是将 Secure Boot 启用，并建立企业专属信任链。

关键输入数据：

• OEM 默认 PK 私钥不可用（仅存在于 OEM 手中）。
• 企业已生成自有的 PK、KEK 私钥及证书。
• 定制 OS 镜像已使用企业签名证书签名。

分析判断过程：由于设备处于 SetupMode，可以直接写入新的 PK，无需旧 PK 签名。但写入 PK 后，设备将自动退出 SetupMode 并进入用户模式，此时 KEK 和 db 的更新必须由新 PK 签名。因此，操作顺序必须为：先写入 PK，再写入 KEK，最后写入 db。

实际操作步骤：

1. 使用 efi-updatevar -f PK.auth 写入企业 PK。
2. 使用 efi-updatevar -f KEK.auth 写入企业 KEK（该文件已由企业 PK 签名）。
3. 使用 efi-updatevar -f db.auth 写入企业 db 条目（该文件已由企业 KEK 签名）。
4. 清除 dbx 中的 OEM 默认条目（如有），并添加企业已知的不安全签名。
5. 重启并验证 Secure Boot 状态为 Enabled，且能正常启动定制镜像。

结果对比：轮换后，设备仅能启动企业签名的镜像，任何未签名或 OEM 签名的镜像均被拒绝。安全审计通过，且后续更新只需使用 KEK 签名即可。

风险与代价：整个轮换过程耗时约 15 分钟/台，且需要物理接触或带外管理。若在写入 PK 后、写入 KEK 前断电，设备将变砖，需返厂恢复。因此，建议使用支持远程管理的设备，并确保操作过程中电源稳定。

复盘经验：批量部署时，应先在少量设备上验证流程，再推广。同时，务必离线备份 PK 私钥，并建立密钥管理库（HSM），防止私钥泄露。

3.4 常见误区与总结复盘

在实际的 Secure Boot 密钥管理中，以下误区最为常见，需要特别警惕：

误区	后果	正确做法
将 PK 私钥存储在服务器上	一旦服务器被攻破，攻击者可完全控制所有设备的信任链	PK 私钥离线存储于 HSM 或保险柜，仅在进行密钥轮换时临时接入
忽略 dbx 的更新	已泄露的签名证书仍可被信任，导致恶意软件加载	定期从微软或 OEM 获取最新 dbx 更新，并使用 KEK 签名后写入
在 SetupMode 下直接写入 db 而不写 PK	设备仍处于设置模式，任何人均可修改密钥，安全保护形同虚设	必须先写入 PK 并退出 SetupMode，再配置 KEK 和 db
混淆 KEK 与 db 的用途	使用 KEK 签名启动镜像，导致镜像无法通过 db 验证	KEK 仅用于签名 db/dbx 更新，启动镜像必须使用 db 中的证书签名

总结复盘：Secure Boot 的密钥体系是一个精密的授权链，PK 是根，KEK 是枝干，db/dbx 是树叶。在实际管理中，应遵循“最小权限、离线存储、定期轮换、及时响应”的原则。每次密钥变更前，务必进行完整备份；每次变更后，务必验证 Secure Boot 状态和启动能力。通过本章的学习，您应能清晰理解四者的角色关系，并能够独立完成密钥的检查、更新与故障排查。