4. Secure Boot 核心组件
UEFI Secure Boot 的安全模型建立在四个核心数据库之上：平台密钥（PK）、密钥交换密钥（KEK）、签名数据库（db） 和 禁止签名数据库（dbx）。这四个组件构成了一个从平台所有者到最终可执行文件的信任链，任何一环的缺失或配置错误都会导致安全启动失败。
4.1 组件概述与层级关系
四个组件按照权限从高到低形成严格的层级结构。PK 位于最顶层，拥有最高权限；KEK 负责管理签名数据库的更新；db 和 dbx 直接决定哪些二进制文件可以执行。下表总结了每个组件的核心属性：
| 组件 | 全称 | 存储位置 | 主要功能 | 更新权限 |
|---|---|---|---|---|
| PK | Platform Key | UEFI 非易失性变量（PK） | 建立平台所有者对固件的控制权 | 仅 PK 自身（物理存在） |
| KEK | Key Exchange Key | UEFI 非易失性变量（KEK） | 授权对 db/dbx 的更新操作 | PK |
| db | Signature Database | UEFI 非易失性变量（db） | 存储受信任的签名/证书/哈希 | KEK |
| dbx | Forbidden Signature Database | UEFI 非易失性变量（dbx） | 存储被撤销的签名/证书/哈希 | KEK |
关键概念： PK 是信任的根，通常由平台制造商（OEM）在出厂时写入。KEK 是信任的桥梁，操作系统厂商（如 Microsoft）的证书通常作为 KEK 被预置。db 和 dbx 是执行策略的最终裁决者。
4.2 平台密钥（PK）
PK 是 Secure Boot 信任链的根锚点。它唯一标识平台的所有者。在固件层面，PK 是一个 UEFI 变量，存储一个或多个公钥证书（X.509）。
- 角色： 平台所有者（OEM 或最终用户）的数字身份。
- 权限： 只有使用与 PK 对应的私钥签名的更新请求，才能修改 PK 本身或 KEK 变量。
- 状态： PK 可以处于“已注册”或“未注册”状态。未注册时，Secure Boot 处于“设置模式”（Setup Mode），允许任何实体更新 KEK 和 db/dbx。一旦 PK 被注册，系统进入“用户模式”（User Mode），所有更新必须经过签名验证。
- 更新流程： 更新 PK 需要物理存在验证（通常通过 BIOS 设置界面）或使用当前 PK 私钥签名的更新请求。
安全警告： 丢失 PK 私钥意味着永久失去对平台 Secure Boot 策略的控制权。OEM 必须安全保管 PK 私钥，通常存储在硬件安全模块（HSM）中。
4.3 密钥交换密钥（KEK）
KEK 是 PK 与 db/dbx 之间的授权代理。它定义了哪些实体有权更新签名数据库。KEK 变量可以包含多个公钥证书。
- 角色： 授权签名数据库更新的中间信任节点。
- 权限： 使用 KEK 私钥签名的更新请求可以添加、删除或替换 db 和 dbx 中的条目。
- 典型配置： 大多数 x86 平台预置 Microsoft 的 KEK 证书，允许 Windows 操作系统通过安全更新机制（如 Windows Update）更新 db/dbx。
- 与 PK 的关系： KEK 的更新必须由 PK 签名。这确保了只有平台所有者才能决定谁有权管理签名数据库。
4.4 签名数据库（db）
db 是 Secure Boot 的白名单。它包含受信任的签名者证书、具体二进制文件的哈希值或经过签名的允许列表。当固件加载一个 EFI 可执行文件（如 bootloader、Option ROM、UEFI 驱动）时，会将其签名与 db 中的条目进行匹配。
- 匹配规则：
- 如果文件的数字签名链中的任何证书在 db 中，则允许执行。
- 如果文件的哈希值在 db 中，则允许执行。
- 如果文件未签名且 db 中允许未签名执行（通常不推荐），则允许执行。
- 内容类型： X.509 证书、RSA-2048 密钥、SHA-256 哈希、EFI_CERT_TYPE 等。
- 管理： 通过 KEK 签名的更新请求进行管理。操作系统厂商会定期发布包含新受信任证书的 db 更新。
4.5 禁止签名数据库（dbx）
dbx 是 Secure Boot 的黑名单。它包含已知不安全、已撤销或已过期的签名证书、哈希值。dbx 的优先级高于 db：如果一个文件同时匹配 db 和 dbx，则禁止执行。
- 角色： 撤销受信任实体的信任，应对安全漏洞和证书泄露。
- 更新机制： 通过 KEK 签名的更新请求进行更新。Microsoft 通过 Windows Update 定期推送 dbx 更新，以撤销被攻破的 bootloader 或证书。
- 典型用例： 当发现某个版本的 GRUB2 存在 BootHole 漏洞时，其签名哈希会被加入 dbx，阻止所有使用该版本 GRUB2 的系统启动。
- 大小限制： dbx 变量有大小限制（通常为 64KB 或 128KB），因此需要谨慎管理条目数量。
4.6 核心组件交互流程
下图展示了 Secure Boot 启动过程中四个核心组件的交互关系：
4.7 组件关系与信任链
四个组件共同构建了 Secure Boot 的信任链模型。下图展示了从平台所有者到最终可执行文件的完整信任传递路径：
4.8 实际开发中的注意事项
开发实践要点：
- PK 管理： 在固件开发阶段，建议使用测试 PK 证书，并确保在量产前替换为生产证书。测试 PK 私钥必须严格隔离。
- KEK 配置： 对于支持多操作系统的平台，KEK 应包含所有目标 OS 厂商的证书。例如，同时支持 Windows 和 Linux 的机器需要包含 Microsoft 和特定 Linux 发行版的 KEK。
- db 更新策略： 避免在 db 中存储过多哈希值，优先使用证书链。哈希值更新需要重新签名整个 db 变量，效率较低。
- dbx 容量规划： 由于 dbx 变量大小有限，建议仅存储关键安全更新（如已知漏洞的 bootloader 哈希）。定期清理过期条目。
- 测试方法： 使用
KeyTool.efi或EfiShell中的dbxupdate命令在开发板上手动测试 PK/KEK/db/dbx 的更新流程。
4.9 常见配置错误与排查
| 错误场景 | 现象 | 根因 | 解决方案 |
|---|---|---|---|
| PK 未注册 | Secure Boot 处于 Setup Mode，任何实体可修改策略 | 出厂时未写入 PK 或 PK 被清除 | 通过 BIOS 设置或工具注册 PK 证书 |
| KEK 缺失 | 无法通过操作系统更新 db/dbx | KEK 变量为空或不包含 OS 厂商证书 | 使用 PK 签名添加正确的 KEK 证书 |
| db 中缺少 bootloader 签名 | 系统无法启动，显示 Secure Boot 违规 | bootloader 的签名证书不在 db 中 | 将 bootloader 证书或哈希添加到 db |
| dbx 误添加 | 合法的 bootloader 被阻止启动 | 错误的哈希或证书被加入 dbx | 使用 KEK 签名从 dbx 中移除错误条目 |
| 变量空间不足 | 更新 db/dbx 时返回 EFI_OUT_OF_RESOURCES | UEFI 变量存储空间耗尽 | 清理无效条目或扩大 NVRAM 分区 |
调试技巧： 在 UEFI Shell 中使用
dmpstore -d PK、dmpstore -d KEK、dmpstore -d db、dmpstore -d dbx 命令查看当前变量内容。使用 var-check PK 验证变量属性。