📚 课程目录第4章 Secure Boot核心组件

4、Secure Boot核心组件：平台密钥（PK）、密钥交换密钥（KEK）、签名数据库（db）和禁止签名数据库（dbx）的作用与关系

Secure Boot 的信任链并非由单一密钥维系，而是由一组职责明确、层级分明的密钥与数据库组件共同构建。理解平台密钥（PK）、密钥交换密钥（KEK）、签名数据库（db）和禁止签名数据库（dbx）的作用与相互关系，是掌握安全启动机制、进行固件签名策略设计以及排查启动失败问题的核心基础。这四类组件共同构成了 UEFI 固件与操作系统加载器之间的“信任锚点”，任何一环配置失误都可能导致系统无法启动或安全策略失效。

上图清晰地展示了 Secure Boot 信任链的层级结构：平台密钥位于最顶层，向下授权密钥交换密钥，再由 KEK 授权签名数据库与禁止签名数据库的更新。在启动验证阶段，固件会依据 db 和 dbx 中的条目对启动组件进行签名校验。下面我们将逐一深入剖析每个组件的具体职责与它们之间的协作关系。

4.1 平台密钥（PK）：信任链的根

核心原理：平台密钥是整个 Secure Boot 体系的信任根，它由平台所有者（通常是硬件制造商或最终用户）持有。PK 的私钥用于对 KEK 的更新操作进行签名，从而控制谁有权修改 KEK。在出厂状态下，固件中会预置一个由 OEM 生成的 PK 公钥。当用户接管平台后，可以通过固件设置界面或操作系统工具更换为自己的 PK，实现平台所有权的转移。

判断方法与操作流程：要确认当前平台的 PK 状态，可以在 Linux 下使用 efi-readvar 工具，或在 Windows 下使用 Manage-SecureBootUEFI PowerShell 命令。操作流程通常包括：

进入固件设置界面（通常按 Del 或 F2 键）。
找到 Secure Boot 或密钥管理选项。
选择“恢复出厂密钥”或“自定义密钥”模式。
若选择自定义，系统会提示导入新的 PK 证书文件（.cer 或 .auth 格式）。

实战场景：某企业采购了一批工作站，希望将 Secure Boot 的信任根从 OEM 默认 PK 切换为企业自有的 PK，以便统一管理。IT 管理员使用 KeyTool.efi 在 UEFI Shell 环境下导出原 PK，生成企业自签名 PK 证书，并通过 SignTool 对新 PK 进行签名后导入。整个过程需要确保固件处于 Setup 模式（即没有 PK 的状态），否则导入操作会被拒绝。

常见误区：许多用户误以为 PK 是用来直接签名操作系统内核的。实际上，PK 只负责签名 KEK，不直接参与启动组件的验证。如果 PK 丢失或损坏，平台将无法更新 KEK，但已配置好的 db/dbx 仍然可以正常工作，系统依然能够启动。

4.2 密钥交换密钥（KEK）：策略更新的授权者

核心原理：KEK 是连接 PK 与签名数据库之间的桥梁。它由操作系统厂商（如 Microsoft）或固件厂商持有，用于对 db 和 dbx 的更新条目进行签名。当需要添加新的可信启动组件或撤销已泄露的签名时，必须使用 KEK 私钥对更新请求进行签名。固件在接收到更新请求后，会先验证签名是否由当前有效的 KEK 生成，验证通过后才允许修改 db 或 dbx。

判断方法与操作流程：查看 KEK 列表同样可以使用 efi-readvar -l KEK 命令。更新 KEK 的流程如下：

准备新的 KEK 证书（通常由 OS 厂商提供）。
使用当前 PK 私钥对新 KEK 证书进行签名，生成 .auth 文件。
在固件设置中导入该 .auth 文件，或使用 Update-UEFISignature PowerShell 命令。

组件	持有者	签名对象	更新方式
PK	平台所有者	KEK	固件设置 / KeyTool
KEK	OS 厂商 / 固件厂商	db、dbx	需 PK 签名授权
db	固件存储	启动组件签名	需 KEK 签名授权
dbx	固件存储	吊销签名/哈希	需 KEK 签名授权

经验提醒：在大多数 PC 平台上，Microsoft 的 KEK 是预装的，用于支持 Windows 启动。如果用户安装了 Linux 并启用了 Shim 机制，通常还需要额外添加 Linux 发行版的 KEK 或直接将 Shim 的签名加入 db。切勿删除 Microsoft KEK，否则可能导致 Windows 无法启动。

4.3 签名数据库（db）与禁止签名数据库（dbx）：黑白名单机制

核心原理：db 存储了被信任的签名者证书、文件签名或哈希值，固件在启动每个 UEFI 应用（如引导加载程序、驱动、Option ROM）时，会计算其哈希或验证其数字签名，并与 db 中的条目进行比对。dbx 则存储了被明确禁止的签名或哈希，其优先级高于 db。即使某个文件的签名同时存在于 db 和 dbx 中，固件也会拒绝加载。

操作流程：添加或删除 db/dbx 条目需要生成签名更新文件：

# 生成新的 db 更新条目（以添加一个签名证书为例）
1. 准备证书文件 cert.cer
2. 使用 KEK 私钥签名：
   sign-efi-sig-list -k KEK.key -c KEK.crt db cert.cer db_update.auth
3. 在固件中导入 db_update.auth 文件

案例拆解：某安全团队发现一个第三方 UEFI 驱动存在严重漏洞，该驱动的签名证书已被攻破。团队需要立即阻止该驱动的加载。他们从漏洞报告中获取了该驱动的 SHA-256 哈希值，使用 KEK 私钥生成了一个 dbx 更新条目，并通过企业固件管理平台批量推送到所有终端。更新后，固件在启动时检测到该驱动的哈希与 dbx 中的条目匹配，直接拒绝加载，成功阻止了潜在攻击。整个过程从发现漏洞到完成阻断仅用了 4 小时，且未影响其他正常驱动的加载。

常见误区：dbx 并非只能存储哈希值，它同样可以存储证书和文件签名。但使用哈希值进行精确阻断更为常见，因为哈希值针对特定文件版本，不会误伤同一证书签名的其他合法文件。另外，dbx 的更新是单向的——一旦某个签名被加入 dbx，就无法通过正常手段移除（除非清除所有 Secure Boot 密钥并重新配置）。

4.4 四者协作关系与信任链验证

核心原理：Secure Boot 的信任链验证遵循“自顶向下”的授权逻辑：固件内置 PK 公钥，用 PK 验证 KEK 的签名；用 KEK 验证 db/dbx 的更新签名；最终用 db 中的公钥或哈希验证启动组件的签名。整个链条中，任何一级的签名验证失败都会导致后续操作被拒绝。

判断方法：当系统启动失败时，可以通过以下步骤定位信任链中的断裂点：

检查固件事件日志（Event Log）中是否有“Secure Boot failure”记录。
使用 sbverify --list 命令检查启动文件的签名信息。
对比当前 db 中的证书与启动文件签名者的证书是否匹配。
确认 dbx 中是否误加了相关哈希。

经验总结：在实际运维中，最常见的信任链断裂原因是 db 中缺少了启动文件的签名证书，其次是 dbx 误更新。建议在每次更新 db/dbx 前，先在测试机上验证更新文件的有效性，并备份当前密钥和数据库内容。对于关键生产系统，建议启用固件的“审计模式”（Audit Mode），该模式会记录所有被拒绝的启动尝试，但不会真正阻止启动，便于在正式启用前发现潜在问题。

理解 PK、KEK、db 和 dbx 的职责边界与协作关系，是进行 Secure Boot 策略设计、故障排查和安全加固的基础。在实际工作中，应当根据平台的所有权归属、操作系统需求和安全管理要求，合理规划密钥的生成、存储和轮换策略，确保信任链的完整性和可用性。