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

3、密码学基础：非对称加密、数字签名、哈希函数、证书链在Secure Boot中的应用原理

Secure Boot 的信任根机制，本质上是一套“密码学证据链”的验证协议。要理解设备如何从一段固件代码逐步建立起可信的执行环境，必须掌握四个核心密码学工具：哈希函数、非对称加密、数字签名和证书链。这四者并非孤立存在，而是层层嵌套、互为支撑：哈希函数负责为数据生成“指纹”，非对称加密负责保护密钥分发的安全性，数字签名负责证明代码的完整性与来源真实性，证书链则负责将信任从一颗物理烧录的根密钥传递到每一个启动组件。本章将逐一拆解这些工具在 Secure Boot 各阶段的具体应用原理，并结合实际固件启动流程进行案例拆解。

上图展示了 Secure Boot 中密码学组件的协作关系。信任根（通常烧录在芯片 eFuse 或一次性可编程存储器中）存储的是根公钥的哈希值，而非公钥本身。启动 ROM 首先使用该哈希值验证根证书的合法性，然后通过根证书的公钥验证中间证书，再使用中间证书的公钥验证 Bootloader 的数字签名。整个链条中，每一级验证都依赖上一级提供的公钥，而最终信任锚点始终是那颗物理不可篡改的根密钥。

3.1 哈希函数：数据完整性的“指纹”

哈希函数是 Secure Boot 中最基础、也是计算开销最小的密码学原语。它将任意长度的二进制数据映射为固定长度的摘要值（如 SHA-256 输出 32 字节）。在 Secure Boot 场景中，哈希函数承担两个关键职责：一是为固件镜像生成唯一的“指纹”，用于检测任何比特位的篡改；二是对公钥本身进行哈希，以便将公钥的摘要值安全地存储在芯片内部，避免直接存储大体积公钥带来的空间浪费。

判断一个哈希函数是否适合 Secure Boot 场景，需要关注以下核心指标：抗碰撞性（无法找到两个不同输入产生相同输出）、抗原像性（由输出无法反推输入）、雪崩效应（输入微小变化导致输出剧烈变化）。目前业界普遍采用 SHA-256 或 SHA-384，SHA-1 已被证明存在碰撞攻击风险，不应再用于新设计。

  实际应用场景：在 UEFI Secure Boot 中，固件卷（Firmware Volume）的每个文件都附带一个 EFI_FV_FILE_ATTRIBUTES 属性，其中包含该文件的哈希值。当平台固件加载驱动或应用时，会重新计算文件的 SHA-256 哈希，并与存储的哈希值比对。如果两者不一致，说明文件在存储或传输过程中被篡改，系统将拒绝加载该文件。

哈希函数在 Secure Boot 中的另一个重要应用是密钥哈希存储。由于 RSA-4096 公钥长度可达 512 字节，而芯片内部的一次性可编程（OTP）存储区域通常只有几 KB 容量，直接存储多个公钥不现实。因此，设计者通常只存储公钥的 SHA-256 哈希值（32 字节）。当需要验证证书时，先计算证书中公钥的哈希，与 OTP 中存储的哈希比对，一致则确认该公钥可信。

# 计算固件镜像哈希（以 U-Boot 环境为例）
$ sha256sum u-boot.bin
# 输出示例：a3f5c8d1e9b2...（64位十六进制字符串）
# 该值将被写入固件签名结构体，供启动 ROM 验证

需要注意的是，哈希函数本身不提供“来源真实性”验证。攻击者可以同时替换固件和哈希值。因此，哈希必须与数字签名结合使用，才能构成完整的 Secure Boot 验证链。

3.2 非对称加密：公钥与私钥的分权设计

非对称加密是 Secure Boot 的信任基础。它使用一对数学关联的密钥：公钥（Public Key）和私钥（Private Key）。公钥可以公开分发，用于验证签名或加密数据；私钥必须严格保密，用于生成签名或解密数据。在 Secure Boot 场景中，非对称加密主要用于数字签名验证，而非数据加密——因为固件镜像本身通常是明文存储的，安全性依赖于签名而非加密。

RSA 和 ECC（椭圆曲线密码）是两种主流算法。RSA 基于大整数分解难题，密钥长度通常为 2048 或 4096 位；ECC 基于椭圆曲线离散对数难题，在相同安全强度下密钥更短（如 P-256 曲线提供与 RSA-3072 相当的安全性）。选择哪种算法取决于硬件加速能力、启动时间预算和安全合规要求。

对比维度	RSA-2048	RSA-4096	ECC P-256
公钥长度	256 字节	512 字节	64 字节
签名长度	256 字节	512 字节	64 字节
验证速度（软件）	较快	慢	快
硬件加速支持	广泛	部分支持	逐渐普及
安全强度	112 位等效	128 位等效	128 位等效
典型应用	旧版 Secure Boot	高安全要求设备	新型 SoC 平台

在 Secure Boot 的密钥权限设计中，根私钥通常由设备制造商离线保管，存储在硬件安全模块（HSM）中，仅在签署新固件版本时使用。中间证书的私钥可能由不同团队持有，用于日常代码签名。这种分权设计确保即使中间密钥泄露，攻击者也无法伪造根证书，从而保护了整个信任链的根基。

风险提示：如果根私钥被泄露，攻击者可以签发任意证书，从而完全绕过 Secure Boot。因此，根私钥必须存储在物理隔离的 HSM 中，并遵循严格的密钥管理流程（如多人分持、双人控制）。此外，建议定期轮换中间密钥，并在固件中内置密钥撤销列表（Revocation List）。

3.3 数字签名：完整性与真实性的双重保障

数字签名是 Secure Boot 验证的核心操作。它结合了哈希函数和非对称加密：签名者使用私钥对固件镜像的哈希值进行加密运算，生成签名值；验证者使用公钥解密签名，得到原始哈希值，再与自行计算的固件哈希比对。如果两者一致，则证明：①固件未被篡改（完整性）；②固件确实由持有对应私钥的实体签发（真实性）。

在 Secure Boot 中，数字签名通常遵循 PKCS#1 v1.5 或 PSS（Probabilistic Signature Scheme）填充方案。PKCS#1 v1.5 实现简单、兼容性好，但存在一些理论上的弱点；PSS 提供了更强的安全证明，但需要更复杂的填充逻辑。UEFI Secure Boot 规范默认支持 PKCS#1 v1.5，而部分新平台开始支持 PSS。

签名生成阶段（离线操作）：开发者在构建固件时，计算固件镜像的 SHA-256 哈希值，使用私钥对哈希值进行 RSA 加密，生成签名块。签名块与固件镜像一起打包发布。
签名验证阶段（设备启动时）：启动 ROM 读取固件镜像，计算其 SHA-256 哈希值；使用存储在证书中的公钥解密签名块，得到签名者计算的哈希值；比对两个哈希值，一致则通过验证。
失败处理：如果哈希比对失败，启动 ROM 将停止执行并进入恢复模式（Recovery Mode），拒绝加载任何后续代码。

经验提醒：签名验证必须覆盖整个固件镜像，包括头部、代码段、数据段和尾部填充。如果只验证部分区域，攻击者可以在未验证区域注入恶意代码。建议在固件构建脚本中明确指定签名覆盖范围，并使用工具（如 sbsign、sign-file）自动生成签名。

数字签名的安全性依赖于私钥的保密性和算法的强度。如果攻击者能够获取私钥，或者找到算法漏洞（如 RSA 的小指数攻击），则签名可以被伪造。因此，除了算法选择外，还需要关注密钥长度、填充方案和随机数生成质量。

3.4 证书链：从信任根到启动组件的逐级验证

证书链（Certificate Chain）解决了“如何信任一个公钥”的问题。在 Secure Boot 中，设备出厂时只烧录一个根公钥哈希。但实际固件签名可能由多个不同实体完成（如 Bootloader 由 A 团队签名，内核由 B 团队签名）。证书链允许通过层级结构，将根信任扩展到多个签名实体，而无需在芯片中存储所有公钥。

一个典型的 Secure Boot 证书链包含三个层级：根证书（Root Certificate）、中间证书（Intermediate Certificate）和终端实体证书（End-Entity Certificate）。根证书是自签名的，其公钥哈希存储在芯片 OTP 中；中间证书由根证书的私钥签发，用于授权特定签名权限；终端实体证书由中间证书签发，直接用于验证固件签名。

证书层级	签发者	持有者	密钥权限	存储位置
根证书	自签名	设备制造商	签发中间证书、撤销权限	芯片 OTP（仅存哈希）
中间证书	根证书	固件开发团队	签发终端实体证书	固件镜像中
终端实体证书	中间证书	具体固件模块	验证 Bootloader/内核签名	固件镜像中

验证流程如下：启动 ROM 首先计算固件中根证书公钥的哈希，与 OTP 中存储的哈希比对，确认根证书可信；然后使用根证书公钥验证中间证书的签名，确认中间证书合法；最后使用中间证书公钥验证终端实体证书的签名，并使用终端实体证书的公钥验证固件签名。整个过程形成一条完整的信任链，任何一环断裂都会导致启动失败。

  案例拆解：某 ARM 服务器平台采用三段式证书链。根证书由公司安全委员会持有，私钥存储在离线 HSM 中；中间证书由 Bootloader 团队持有，用于签发 U-Boot 的签名证书；终端实体证书由内核团队持有，用于签发 Linux 内核镜像。当平台启动时，BootROM 验证根证书（哈希比对），然后验证 U-Boot 的签名证书，最后验证 U-Boot 镜像本身。U-Boot 启动后，再使用同样的机制验证内核镜像。这种设计实现了“分级授权、最小权限”的密钥管理原则。

证书链设计的关键在于密钥权限的粒度控制。根证书权限最大，但使用频率最低；中间证书权限适中，用于日常签发；终端实体证书权限最小，仅用于验证特定固件。如果某个中间证书被泄露，安全团队可以签发新的中间证书，并通过固件更新撤销旧证书，而无需更换芯片中的根密钥。

3.5 常见误区与设计复盘

在实际的 Secure Boot 方案设计中，工程师常犯以下几类错误，值得重点警惕：

误区一：只验证签名，不验证证书链。有些实现直接使用固件中携带的公钥验证签名，而不验证该公钥是否由可信根签发。这相当于信任了攻击者提供的公钥，Secure Boot 形同虚设。正确做法是：必须从根证书开始逐级验证，确保证书链完整。
误区二：哈希函数选择不当。部分旧平台仍使用 SHA-1 或 MD5，这些算法已被证明存在碰撞攻击。攻击者可以构造两个不同固件具有相同哈希值，从而绕过验证。建议至少使用 SHA-256，高安全场景使用 SHA-384。
误区三：签名覆盖范围不完整。如果签名只覆盖固件头部或部分代码段，攻击者可以在未签名区域注入恶意代码。必须确保签名覆盖整个固件镜像，包括所有填充字节。
误区四：密钥存储不安全。将私钥存储在开发者的普通电脑或 CI 服务器上，一旦被入侵，攻击者即可签发恶意固件。私钥必须存储在 HSM 或专用安全芯片中，并启用访问审计。
误区五：忽略密钥撤销机制。当密钥泄露或证书过期时，如果没有撤销机制，旧证书仍然有效。应在固件中内置证书撤销列表（CRL）或在线证书状态协议（OCSP）支持。

设计复盘：某 IoT 设备厂商在 Secure Boot 实现中，将根公钥直接存储在 SPI Flash 中，而非芯片 OTP。攻击者通过物理攻击读取 Flash 内容，替换为攻击者自己的公钥，从而完全绕过 Secure Boot。正确的做法是将根公钥哈希存储在一次性可编程（OTP）区域，该区域在芯片制造时烧录，之后无法修改。即使攻击者读取了 Flash 中的证书，也无法替换 OTP 中的哈希值。

总结而言，Secure Boot 的密码学设计是一个系统工程，需要综合考虑算法选择、密钥管理、证书链设计和硬件存储。哈希函数提供完整性保障，非对称加密提供真实性保障，数字签名将两者结合，证书链则解决了密钥分发的信任问题。在实际项目中，建议遵循“最小权限、分层管理、物理隔离”的原则，并定期进行安全审计和密钥轮换。