2. 安全启动基础
UEFI 安全启动（UEFI Secure Boot）是平台固件在操作系统加载之前建立的一道密码学验证关卡。它的核心目标不是“加密磁盘”，而是确保从固件到引导加载程序、再到内核模块的每一段可执行代码都经过授权签名，从而阻断 bootkit、恶意引导程序以及未授权内核驱动的加载。理解安全启动，必须同时理解它的信任链结构、四类关键密钥数据库，以及“签名”与“撤销”这对相反操作如何共同决定一段代码能否运行。
一、信任链：从不可变根到可执行代码
安全启动的信任不是凭空产生的，而是从平台固件中一段不可修改的根开始逐级传递。平台密钥（Platform Key，PK）位于信任链顶端，它代表平台所有者对固件的控制权。PK 通常用于签名密钥交换密钥（Key Exchange Key，KEK），KEK 再用于更新签名数据库（db）和撤销数据库（dbx）。真正参与镜像验证的是 db 中的证书或哈希，而 dbx 则记录被明确禁止的证书、哈希或镜像。
信任链的传递过程可以概括为：固件验证引导加载程序，引导加载程序验证内核与 initramfs，内核再通过模块签名验证可加载模块。每一级都使用上一级信任的密钥来验证下一级对象的签名。只要其中任何一级验证失败，启动就会中止或进入受限状态。这个链条的强度取决于最弱一环，因此 PK、KEK、db、dbx 的配置必须整体考虑，而不能只关注某一个数据库。
二、四类密钥数据库的职责与关系
安全启动的密钥管理围绕四个数据库展开，它们各自承担不同职责，且存在明确的授权关系。PK 是平台密钥，通常只有一把或一组，用于签名 KEK 更新。KEK 是密钥交换密钥，可以由多个证书组成，用于授权 db 和 dbx 的更新。db 是签名数据库，包含允许加载的证书、公钥或镜像哈希。dbx 是撤销数据库，包含被禁止的证书、公钥或镜像哈希。四者关系可以概括为：PK 管 KEK，KEK 管 db 和 dbx，db 决定“谁能进”，dbx 决定“谁不能进”。
| 数据库 | 全称 | 作用 | 典型更新者 | 更新影响 |
|---|---|---|---|---|
| PK | Platform Key | 平台所有者控制权，签名 KEK | OEM 或平台所有者 | 更换 PK 会重置信任根 |
| KEK | Key Exchange Key | 授权更新 db 与 dbx | 平台所有者、OS 厂商 | 影响后续密钥更新权限 |
| db | Signature Database | 允许加载的证书、公钥、哈希 | OS 厂商、企业管理员 | 新增可引导镜像或驱动 |
| dbx | Forbidden Signature Database | 禁止加载的证书、公钥、哈希 | OS 厂商、安全响应团队 | 撤销泄露或恶意签名 |
三、密钥轮换与撤销的工程流程
在真实工程中，密钥轮换与撤销不是简单替换文件，而是一套需要审计、验证和回滚准备的流程。以企业环境为例，当某个用于签名内核模块的密钥疑似泄露时，管理员需要先确认该密钥对应的证书是否在 db 中，然后将其证书或哈希写入 dbx，最后再生成新密钥并加入 db。整个过程必须保证已有合法系统仍能启动，否则会导致大面积无法引导。
# 查看当前安全启动状态与数据库
mokutil --sb-state
efi-readvar -v PK
efi-readvar -v KEK
efi-readvar -v db
efi-readvar -v dbx
# 将撤销证书写入 dbx（示意）
efi-updatevar -e -f revoked.crt dbx
# 将新签名证书加入 db（示意）
efi-updatevar -e -f new_signing.crt db
# 验证更新结果
efi-readvar -v dbx | grep -i "revoked"
efi-readvar -v db | grep -i "new_signing"
上述命令中，efi-readvar 用于读取变量，efi-updatevar 用于更新变量。实际生产环境通常通过固件管理界面、厂商工具或自动化配置管理平台完成，而不是手工逐条执行。无论采用哪种方式，都必须遵循“先撤销、后新增、再验证”的顺序，避免出现旧密钥仍被信任而新密钥尚未生效的窗口期。
四、典型场景与常见误区
场景一：操作系统厂商发布内核更新，但旧内核签名证书被泄露。此时厂商会发布 dbx 更新，将泄露证书加入撤销列表，同时发布新证书到 db。企业终端在下次启动时，固件会拒绝加载使用泄露证书签名的旧内核，从而阻断潜在攻击。
场景二：企业自签名内核模块。管理员将企业 CA 证书加入 db 后，所有由该 CA 签发的模块都能加载。但如果 CA 私钥泄露，必须立即将 CA 证书写入 dbx，并重新签发所有模块。此时若只更新 db 而不更新 dbx，旧证书仍然有效，撤销就没有意义。
常见误区：把 db 当成“白名单”就以为足够安全。实际上，如果 dbx 没有及时更新，已泄露的证书仍然可以签名恶意代码并通过验证。另一个误区是认为 PK 可以随意更换。更换 PK 会改变信任根，可能导致原有 KEK、db、dbx 全部失效，必须重新配置整个信任链。
工程建议：在生产环境中，建议将 PK 离线保存，KEK 由平台所有者和 OS 厂商共同管理，db 和 dbx 的更新走变更审批流程。每次更新前备份当前变量，更新后使用 efi-readvar 和启动测试验证。对于大规模终端，应先在少量设备上灰度验证，再逐步推广。
安全启动的信任链、PK、KEK、db 与 dbx 共同构成一个动态的授权与撤销体系。理解它们之间的签名关系和更新顺序，是后续进行密钥轮换、撤销响应和故障排查的基础。只有把“谁信任谁、谁撤销谁”梳理清楚，才能在安全与可用性之间取得平衡。