3. 密钥与签名机制：PK、KEK、db、dbx 数据库的作用

安全启动这套体系，说白了就是一套「谁可以给系统发号施令」的信任链。我刚开始接触 UEFI 时，觉得这些缩写 PK、KEK 什么的特别绕。后来在项目里亲手配了一次，才明白它们其实就是几个不同权限等级的「钥匙串」。

咱们今天就把这几个数据库拆开来看。你想想看，一台电脑从按下电源键到加载操作系统，中间要经过很多步。每一步都得确认：「这个代码是谁签的？我该不该信它？」

3.1 四个核心数据库

安全启动里一共有四个关键的数据库，它们都存储在主板上的 NVRAM 里。我习惯把它们比作一个公司的门禁系统：

数据库	全称	我的理解
PK	Platform Key	公司最高权限的「董事长钥匙」
KEK	Key Exchange Key	「行政部钥匙」—— 负责管理其他钥匙
db	Signature Database	「白名单」—— 允许执行的签名
dbx	Forbidden Signature Database	「黑名单」—— 禁止执行的签名

3.2 PK —— 平台的最高权限

PK 是整个安全启动的根。它由平台制造商（比如主板厂商）在出厂时写入。PK 的私钥通常被厂商牢牢锁在硬件安全模块里。

PK 只有一个职责：验证谁可以修改 KEK。嗯，就这么简单。但它权限最大——有了 PK，你就能换掉整个 KEK 列表。

3.3 KEK —— 钥匙管理员

KEK 的作用是验证谁可以修改 db 和 dbx。你可以有多个 KEK，比如主板厂商一个、操作系统厂商一个。

我个人习惯把 KEK 比作「门禁卡管理员」。它不能直接开门，但它可以决定谁有资格拿到门禁卡。

举个例子：微软的 KEK 签名了 Windows 的 bootloader，所以 Windows 能启动。如果你装 Linux，有些发行版也会把自己的 KEK 签进去。

3.4 db —— 白名单

db 里存的是「允许执行」的签名或哈希值。这是实际干活的地方。

每次 UEFI 要加载一个驱动或 bootloader 时，它会做两件事：

1. 检查这个文件的签名是否在 db 里
2. 检查这个签名是否在 dbx 里（黑名单优先）

只有「在 db 里且不在 dbx 里」的代码才能执行。这个逻辑其实挺朴素的，对吧？

3.5 dbx —— 黑名单

dbx 是安全启动的「后悔药」。当发现某个签名有问题（比如私钥泄露、发现漏洞），就把它的哈希或证书加进 dbx。

我记得有一次，某个知名厂商的 bootloader 被发现了一个严重漏洞。微软紧急推送了一个 dbx 更新，通过 Windows Update 写进 NVRAM。从那以后，那个有漏洞的版本就再也启动不了了。

3.6 签名验证流程

咱们把整个流程串起来看看。从按下电源键开始：

1. 阶段一：验证启动管理器
   • UEFI 固件加载 bootloader（比如 bootmgfw.efi）
   • 用 db 里的证书验证它的数字签名
   • 检查 dbx 里有没有这个签名
2. 阶段二：验证操作系统内核
   • bootloader 加载操作系统内核
   • 同样走一遍签名验证
3. 阶段三：验证驱动和扩展
   • 任何 UEFI 驱动、Option ROM 都要过一遍

任何一个环节验证失败，系统就会停止启动。这就是为什么恢复镜像必须处理好签名问题——否则你连恢复环境都进不去。

3.7 证书链的层级结构

安全启动的证书链其实就是一个树形结构。我画了一张图，你看一眼就明白了：

这个层级结构保证了：即使某个下游证书被攻破，只要及时更新 dbx，就能阻断攻击链。而 PK 作为根，只要它安全，整个链条就还有救。

3.8 实际项目中的注意事项

最后分享几个我在项目里总结的经验：

• 备份 PK 私钥要像备份命一样重要——我见过有人把 PK 私钥存在一个 U 盘里，结果 U 盘坏了，整批设备都得返厂。
• KEK 最好留一个厂商的、一个自己的——这样既能保证兼容性，又能保留控制权。
• dbx 更新前一定要在测试机上跑一遍——我曾经差点把一个正常驱动的签名加进 dbx，还好测试阶段发现了。
• 恢复镜像必须带有效的签名——否则在安全启动开启的机器上，你的恢复工具连加载的机会都没有。