3. 安全启动技术原理：PK、KEK、db、dbx证书数据库的层级结构与信任链
UEFI 安全启动（Secure Boot）的核心是一个基于公钥基础设施（PKI）的分层证书数据库与静态信任链验证机制。该机制确保平台在启动过程中仅执行经过授权的、未被篡改的固件、引导加载程序（Boot Loader）及操作系统内核。理解 PK、KEK、db、dbx 四个数据库的层级关系与交互流程，是掌握安全启动配置与排错的基础。
3.1 证书数据库的层级结构
安全启动的信任模型由四个关键组件构成，它们以严格的层级关系存储在 UEFI 非易失性变量中：
| 数据库 | 全称 | 层级位置 | 核心作用 | 签名对象 |
|---|---|---|---|---|
| PK | Platform Key | 根信任（Root of Trust） | 建立平台所有者对固件的控制权；授权 KEK 更新 | KEK 证书 |
| KEK | Key Exchange Key | 第二层（密钥交换层） | 授权操作系统与第三方对 db/dbx 的更新操作 | db / dbx 证书 |
| db | Signature Database | 第三层（白名单） | 存储受信任的签名证书或哈希，允许执行对应镜像 | Boot Loader / OS Loader / 内核 |
| dbx | Forbidden Signature Database | 第三层（黑名单） | 存储已撤销或恶意的签名证书或哈希，阻止执行 | 被吊销的 Boot Loader / 内核 |
关键原则：PK 是信任的锚点，只有使用 PK 私钥签名的 KEK 更新请求才被接受；只有使用 KEK 私钥签名的 db/dbx 更新请求才被接受。这种单向授权机制防止了未经授权的恶意软件篡改信任数据库。
3.2 信任链验证流程
在平台启动过程中，UEFI 固件按以下顺序执行签名验证，形成一条从硬件到操作系统的信任链：
- 固件启动阶段：UEFI 固件（SEC/PEI 阶段）首先验证自身完整性，然后加载 DXE 阶段驱动。此阶段信任根固化在固件代码中。
- Boot Manager 阶段：固件读取
Boot####变量指向的引导加载程序（如 shim.efi、grubx64.efi）。 - 签名验证：固件计算镜像的哈希值，并与 db 数据库中的白名单条目进行匹配。同时检查 dbx 黑名单，确保镜像未被吊销。
- 授权执行：若镜像签名在 db 中且不在 dbx 中，则固件授权执行该引导加载程序。
- 链式传递：引导加载程序（如 shim）继续验证下一阶段镜像（如 GRUB 或 Linux 内核），通常使用内嵌的证书或 Machine Owner Key（MOK）。
- 内核加载：最终，经过签名的 Linux 内核（vmlinuz）被加载并执行，完成安全启动链。
实践提示：在配置自定义内核参数签名时，通常需要将自签名的证书添加到 MOK（Machine Owner Key）列表，而非直接修改 db。MOK 由 shim 引导加载程序管理，避免了修改固件数据库的风险。
3.3 证书数据库层级关系 SVG 架构图
下图展示了 PK、KEK、db、dbx 之间的层级授权关系与信任链流向：
3.4 数据库更新与签名验证机制
证书数据库的更新操作必须遵循严格的签名验证规则，以防止恶意篡改：
- PK 更新：必须由当前 PK 私钥签名。若 PK 为空（设置模式），则无需签名即可写入。
- KEK 更新：必须由当前 PK 私钥签名。KEK 本身不能自授权。
- db / dbx 更新：必须由当前 KEK 私钥签名。操作系统通过此机制添加或吊销证书。
- 镜像验证：固件计算镜像的 Authenticated Variable 格式签名，使用 db 中的公钥验证。若签名有效且哈希不在 dbx 中，则镜像通过验证。
安全警告：在生产环境中，PK 私钥必须离线存储于硬件安全模块（HSM）或物理保险柜中。一旦 PK 私钥泄露，攻击者可完全控制平台的信任数据库，绕过安全启动保护。
3.5 设置模式与用户模式
UEFI 安全启动有两种操作模式，决定了数据库的可写性：
| 模式 | PK 状态 | 数据库可写性 | 典型场景 |
|---|---|---|---|
| 设置模式（Setup Mode） | PK 为空 | PK、KEK、db、dbx 均可无签名写入 | OEM 出厂配置、首次部署 |
| 用户模式（User Mode） | PK 已设置 | 所有更新必须经对应私钥签名 | 生产环境、日常运行 |
部署建议：在完成 PK 注册后，系统自动从设置模式切换到用户模式。建议在部署前完成所有数据库的初始化配置，避免后期在用户模式下频繁更新带来的签名管理复杂性。
3.6 信任链验证流程图
以下 SVG 流程图展示了从固件启动到内核加载的完整签名验证路径：
3.7 常见问题与排错思路
- 启动失败，提示“Image not authorized”：镜像签名不在 db 中，或已被加入 dbx。检查镜像签名证书是否已注册到 db 或 MOK。
- 无法更新 db/dbx：更新请求未使用正确的 KEK 私钥签名。确认签名工具链与 KEK 证书匹配。
- PK 丢失或损坏：平台将无法退出设置模式，或无法进行任何授权更新。需通过物理访问清除安全启动状态（清除 CMOS 或进入固件设置重置）。
- MOK 与 db 混淆：MOK 是 shim 维护的软件级数据库，独立于固件 db。自定义内核签名通常添加到 MOK，而非 db。
排错工具：在 Linux 下可使用
mokutil --list-enrolled 查看 MOK 列表，使用 sbverify --list <镜像> 查看镜像签名信息，使用 efi-readvar 查看固件变量中的 PK/KEK/db/dbx 内容。