📚 课程目录第3章密码学基础

3、密码学基础：公钥基础设施（PKI）、非对称加密、数字签名、哈希算法在Secure Boot中的应用

Secure Boot 的信任链本质上是一条“密码学证据链”。从平台固件（Boot ROM）到操作系统加载器，每一级引导组件都必须向下一级证明自己的合法身份与内容完整性。这种证明机制并非凭空设计，而是建立在公钥基础设施（PKI）、非对称加密、数字签名和哈希算法四大密码学支柱之上。理解这些基础概念在 Secure Boot 中的具体映射关系，是配置密钥、管理证书链以及排查启动失败问题的前提。本章将逐一拆解这四大支柱在 Secure Boot 流程中的角色、交互方式及工程实践要点。

3.1 哈希算法：内容完整性的“数字指纹”

核心原理

哈希算法（如 SHA-256、SHA-384）将任意长度的二进制数据映射为固定长度的摘要值。在 Secure Boot 中，哈希算法承担两个关键职责：一是生成引导镜像的“数字指纹”，用于检测内容是否被篡改；二是作为证书签名和数据库条目的基础数据结构。SHA-256 输出 256 位摘要，碰撞概率极低，是目前 UEFI Secure Boot 的主流选择。

判断方法与操作流程

在验证引导镜像时，固件执行以下步骤：

读取镜像文件（如 bootloader.efi）到内存；
使用 SHA-256 算法计算整个文件的哈希值 H_calc；
从签名数据库中提取该镜像对应的预期哈希值 H_expected（或从签名中恢复）；
比较 H_calc 与 H_expected，若一致则完整性校验通过。

工程中常用 openssl dgst -sha256 -binary bootloader.efi | xxd -p 计算镜像哈希，用于与固件日志中的预期值比对。

实战场景：某设备升级固件后无法启动，日志显示 Hash mismatch for shim.efi。排查时先计算当前 shim.efi 的 SHA-256，再与 db 中登记的哈希比对。若不一致，说明镜像在传输或存储过程中被修改，或 db 条目指向了旧版本镜像。此时需重新签名并更新 db，而非简单替换文件。

风险提示：哈希算法只保证完整性，不提供身份认证。攻击者可以同时替换镜像和哈希值。因此哈希必须与数字签名结合使用，由签名保证哈希值的真实性。

3.2 非对称加密：公钥与私钥的分工协作

核心原理

非对称加密使用一对数学关联的密钥：公钥（Public Key）和私钥（Private Key）。私钥由密钥所有者严格保管，用于签名或解密；公钥公开发布，用于验签或加密。在 Secure Boot 中，平台固件只存储公钥，私钥则保存在离线环境（如 HSM 或安全机房）中。RSA-2048 和 ECC P-256 是两种常见算法，前者兼容性广，后者计算开销小。

判断方法与操作流程

密钥生成与分发流程如下：

使用 openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out PK.key 生成平台密钥私钥；
从私钥导出公钥：openssl pkey -in PK.key -pubout -out PK.pub；
将公钥以 X.509 证书格式写入固件变量（如 PK、KEK、db）；
私钥离线存储，用于后续签名操作。

验证时，固件使用存储的公钥解密签名数据，得到原始哈希值，再与计算出的镜像哈希比对。

经验提醒：私钥丢失意味着无法签发新证书或更新数据库，可能导致设备永久无法通过 Secure Boot 验证。建议采用 Shamir 秘密共享方案拆分私钥，由多人分别保管分片，降低单点风险。

3.3 数字签名：身份与完整性的双重保证

核心原理

数字签名是对镜像哈希值进行私钥加密的结果。签名过程为：发送方计算镜像哈希 H，使用私钥对 H 进行加密（或签名算法如 RSA-PSS），生成签名 S；接收方使用公钥解密 S 得到 H_sig，再计算镜像哈希 H_calc，若 H_sig == H_calc，则确认镜像来源可信且未被篡改。Secure Boot 要求所有可执行引导组件（如 UEFI 驱动、引导加载器）必须携带有效签名。

判断方法与操作流程

签名验证的完整链路：

固件从镜像的 WIN_CERTIFICATE 结构中提取签名数据；
使用 db 中匹配的公钥对签名进行解密/验签；
同时计算镜像的哈希值；
比对解密得到的哈希与计算哈希，一致则通过。

签名工具常用 sbsign --key db.key --cert db.crt --output bootloader.signed bootloader.efi。

案例拆解：某厂商发布新版本内核，但用户升级后系统提示 Verification failed: 0x800000000000000D。分析发现：新内核使用了新的签名密钥，但该公钥未加入 db 数据库。解决路径：① 使用 KEK 私钥对包含新公钥的 db 更新文件签名；② 通过固件设置或操作系统工具（如 efi-updatevar）更新 db 变量；③ 重启验证。此案例说明签名验证不仅依赖算法，还依赖证书库的同步管理。

3.4 公钥基础设施（PKI）：构建信任链的层级体系

核心原理

PKI 定义了证书的签发、分发、撤销和信任层级。在 Secure Boot 中，典型的信任链为：平台密钥（PK）→ 密钥交换密钥（KEK）→ 签名数据库（db/dbx）。PK 是信任根，其私钥用于签署 KEK 证书；KEK 私钥用于更新 db 和 dbx（撤销列表）；db 包含受信任的签名公钥或镜像哈希；dbx 包含被撤销的证书或哈希。这种层级设计实现了权限分离：PK 所有者控制 KEK 的变更，KEK 所有者控制具体签名策略。

判断方法与操作流程

证书链验证遵循“自下而上”的信任回溯：

固件读取 db 中的证书，验证其签名是否由某个 KEK 证书签发；
再验证该 KEK 证书是否由 PK 签发；
若整条链有效，则信任 db 中的公钥可用于验签引导镜像。

证书生成示例：

# 生成自签名 PK
openssl req -new -x509 -key PK.key -out PK.crt -days 3650
# 生成 KEK 证书请求并用 PK 签名
openssl req -new -key KEK.key -out KEK.csr
openssl x509 -req -in KEK.csr -CA PK.crt -CAkey PK.key -out KEK.crt -days 3650

常见误区与总结复盘

误区	后果	正确做法
所有密钥使用同一对 RSA 密钥	权限不分，PK 泄露则全盘崩溃	严格分离 PK、KEK、db 密钥
忽略 dbx 撤销列表	已泄露的私钥仍可签名恶意镜像	定期更新 dbx，加入被撤销的证书指纹
证书有效期设置过长	密钥泄露风险随时间累积	设置 1-2 年有效期，建立轮换机制
私钥存储在构建服务器	攻击者获取私钥即可签名任意镜像	使用离线 HSM 或气隙环境保管私钥

风险说明：PK 私钥一旦丢失，整个信任链无法更新，设备将永久锁定在当前状态。务必在安全位置备份 PK 私钥，并测试恢复流程。

总结而言，哈希算法保证“内容未被改”，非对称加密提供“密钥对唯一性”，数字签名实现“来源可信且内容完整”，PKI 则将这些能力组织成可管理的信任层级。在 Secure Boot 配置中，四者缺一不可：没有哈希，签名无法绑定到具体内容；没有非对称加密，签名密钥无法安全分发；没有 PKI，信任关系无法扩展和撤销。理解这四者的协同关系，是后续配置密钥、管理证书链和排查启动故障的基石。