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

2、密码学基础：哈希算法（SHA-256等）、非对称加密（RSA、ECC）、数字签名、证书链、信任根（Root of Trust）的概念与作用

Secure Boot 的安全根基并非来自某一种单一的密码学技术，而是由哈希算法、非对称加密、数字签名、证书链与信任根共同构成的一条完整信任传递链路。如果把 Secure Boot 比作一道坚固的城门，那么哈希算法是校验货物完整性的“称重器”，非对称加密是分发钥匙的“锁匠体系”，数字签名是封条上的“防伪印章”，证书链是逐级核验印章真伪的“行政流程”，而信任根则是这一切的“最高立法机构”。本章将逐一拆解这些基础组件的数学原理、工程实现方式及其在 Secure Boot 中的具体作用，帮助读者建立从底层算法到顶层信任模型的完整认知框架。

上图展示了 Secure Boot 中密码学组件的完整信任传递链路。信任根作为最高权威锚点，通过证书链将信任逐级传递给平台证书，平台证书对应的私钥对启动镜像进行数字签名，而哈希算法则用于度量镜像的完整性。整个验证过程从 BootROM 开始，逐级向上，任何一环断裂都会导致启动流程终止。

2.1 哈希算法：数据完整性的度量工具

核心原理

哈希算法（Hash Algorithm）是一种将任意长度输入数据映射为固定长度输出的数学函数。以 SHA-256 为例，无论输入是 1 字节还是 1GB 数据，输出始终是 256 位（32 字节）的摘要值。其核心特性包括：单向性（由摘要无法反推原文）、抗碰撞性（极难找到两个不同输入产生相同摘要）、雪崩效应（输入微变，输出剧变）。在 Secure Boot 中，哈希算法主要用于度量启动镜像的完整性——计算镜像的哈希值，与签名中携带的哈希值比对，若一致则说明镜像未被篡改。

判断方法与操作流程

在实际工程中，选择哈希算法需考虑以下维度：

算法	输出长度	安全性	性能（软件实现）	适用场景
SHA-1	160 bit	已破解（碰撞攻击）	快	不推荐用于 Secure Boot
SHA-256	256 bit	安全（截至2025年）	中等	主流选择，UEFI Secure Boot 默认
SHA-384	384 bit	安全	较慢	高安全等级场景
SHA-512	512 bit	安全	较慢	需要更大摘要的场景

操作流程上，BootROM 或固件会按以下步骤执行哈希度量：

读取启动镜像的前 N 个块（通常为 4KB 对齐）；
使用 SHA-256 硬件加速引擎或软件库计算摘要；
将摘要与镜像签名中嵌入的期望值进行常量时间比较（防止时序攻击）；
若匹配则继续加载，否则触发安全策略（阻止启动或进入恢复模式）。

案例拆解：U-Boot 中的哈希验证

以嵌入式 Linux 设备常用的 U-Boot 引导程序为例，其 CONFIG_FIT_SIGNATURE 配置启用镜像签名验证。实际启动日志中可以看到：

## Loading kernel from FIT Image at 0x80000000 ...
   Verifying Hash Integrity ... sha256,rsa2048: OK
   Loading kernel from FIT Image ... OK

这里的 sha256 表示使用 SHA-256 计算镜像哈希，rsa2048 表示使用 RSA-2048 进行签名验证。如果镜像被篡改，日志会显示 Bad Hash Value 并终止启动。该案例中，哈希算法承担了“度量”职责，而非“认证”职责——它只保证数据未被修改，但不保证数据来源可信。

常见误区：哈希算法本身不提供身份认证。攻击者可以同时替换镜像和哈希值。因此哈希必须与数字签名配合使用——签名保证哈希值本身未被篡改，哈希保证镜像内容未被篡改。

2.2 非对称加密：RSA 与 ECC 的工程选型

核心原理

非对称加密使用一对密钥：公钥（Public Key）和私钥（Private Key）。私钥由签名方秘密保存，公钥公开分发。RSA 基于大整数分解难题，ECC（椭圆曲线密码学）基于椭圆曲线离散对数难题。在 Secure Boot 场景中，非对称加密主要用于数字签名而非数据加密——私钥对镜像哈希进行签名，公钥用于验证签名。RSA-2048 是目前最广泛使用的选择，而 ECC（如 P-256）以更短的密钥长度提供相当的安全性，适合资源受限的嵌入式环境。

对比分析

特性	RSA-2048	ECC P-256
密钥长度	2048 bit	256 bit
签名长度	256 字节	64 字节
签名速度	较慢（模幂运算）	较快
验签速度	较快（公钥指数小）	中等
硬件支持	广泛	逐渐普及
安全强度	112 bit 等效	128 bit 等效

实战场景：密钥生成与签名流程

在构建 Secure Boot 镜像签名系统时，典型的操作流程如下：

使用 OpenSSL 生成 RSA 密钥对：openssl genrsa -out private.pem 2048；
提取公钥并嵌入 BootROM 或固件：openssl rsa -in private.pem -pubout -out public.pem；
对镜像计算 SHA-256 哈希，然后使用私钥签名：openssl dgst -sha256 -sign private.pem -out sig.bin image.bin；
将签名附加到镜像中，或存储在独立分区。

验证端（BootROM）使用公钥解密签名，得到哈希值 H1；同时计算镜像哈希 H2；若 H1 == H2，则验证通过。

经验提醒：ECC 的私钥生成必须使用安全的随机数源。在嵌入式设备中，如果硬件随机数生成器（TRNG）不可用，应使用内核熵池或专用安全芯片，避免使用可预测的伪随机数导致私钥泄露。

2.3 数字签名：防伪与防篡改的统一

核心原理

数字签名 = 哈希 + 非对称加密。签名过程：发送方对消息 M 计算哈希 H(M)，用私钥加密 H(M) 得到签名 S。验证过程：接收方用公钥解密 S 得到 H1，计算 H(M) 得到 H2，比较 H1 与 H2。数字签名同时提供了完整性（消息未被篡改）和真实性（消息确实来自私钥持有者）。在 Secure Boot 中，每个启动镜像（如 UEFI 驱动、内核、initramfs）都必须携带有效签名才能被加载。

操作流程与验证逻辑

UEFI Secure Boot 的签名验证流程如下：

固件读取镜像的签名数据库（db）中的证书；
使用证书公钥验证镜像签名；
若签名有效，检查镜像是否在禁止数据库（dbx）中；
若不在 dbx 中，则允许加载执行。

这一流程确保了只有经过签名的合法镜像才能运行，同时允许通过更新 db/dbx 来管理信任策略。

案例拆解：Shim 引导链中的签名验证

在 Linux 系统的 UEFI Secure Boot 实现中，shim 是一个小型的预引导程序，它包含 Microsoft 签名的公钥。实际验证过程：

shim: Verifying grubx64.efi with MOK (Machine Owner Key)
shim: grubx64.efi is signed with MOK key
shim: Loading grubx64.efi ... OK

shim 首先验证自身（由 Microsoft 签名），然后使用 MOK 验证 GRUB，GRUB 再验证内核。每一级签名验证都依赖上一级的信任，形成链式信任模型。如果攻击者替换了 grubx64.efi，签名验证会失败，系统拒绝启动。

  深度复盘：2023 年发现的 CVE-2023-40547 漏洞表明，即使有签名验证，如果验证逻辑存在边界条件错误（如未检查文件大小），攻击者仍可能通过精心构造的镜像绕过验证。这提醒我们：签名验证不仅要检查“签名是否正确”，还要检查“验证过程本身是否完整”。

2.4 证书链与信任根：构建信任的锚点

核心原理

信任根（Root of Trust）是 Secure Boot 信任模型的最高锚点，通常存储在硬件中（如 CPU 的一次性可编程熔丝、TPM 的 EK 证书、或 SoC 的 BootROM 中）。信任根的公钥不可更改，因此攻击者无法通过替换公钥来伪造签名。证书链则是从信任根到最终平台证书的信任传递路径：根证书 → 中间 CA 证书 → 平台证书。每一级证书都由上一级私钥签名，验证时从信任根开始逐级验证。

信任链的构建与验证

层级	证书类型	存储位置	验证方式
L0	根证书（信任根）	硬件熔丝 / BootROM	不可修改，硬件固化
L1	中间 CA 证书	固件分区	由根证书公钥验证
L2	平台证书	固件分区 / 镜像头部	由中间 CA 公钥验证
L3	镜像签名	镜像附加数据	由平台证书公钥验证

实战场景：自定义 Secure Boot 证书体系

以嵌入式设备厂商为例，假设需要为 10 万台设备部署 Secure Boot：

在安全环境中生成根密钥对，私钥离线保存（不联网），公钥烧录到 SoC 熔丝；
生成中间 CA 密钥对，由根私钥签发证书；
为每个产品线生成平台密钥对，由中间 CA 签发；
使用平台私钥对每个版本的固件镜像签名；
设备启动时，BootROM 使用熔丝中的根公钥验证中间 CA，再验证平台证书，最后验证镜像签名。

该体系的好处是：即使某个产品线的平台私钥泄露，只需吊销该证书并更新中间 CA 的吊销列表，不影响其他产品线。

风险提示：信任根一旦烧录，无法更改（或更改成本极高）。如果根私钥泄露，整个产品线的安全体系崩溃，必须召回设备更换硬件。因此根私钥的生成和存储必须遵循最高安全标准，建议使用硬件安全模块（HSM）并在隔离环境中操作。

2.5 综合案例：从信任根到内核加载的完整验证

以一台基于 ARM64 架构的服务器为例，其 Secure Boot 验证流程如下：

BootROM:
  1. 读取 eFuse 中的根公钥哈希 (SHA-256)
  2. 加载 BL1 (Boot Loader Stage 1) 镜像
  3. 计算 BL1 的 SHA-256 哈希
  4. 使用根公钥验证 BL1 的 RSA 签名
  5. 哈希匹配且签名有效 → 跳转执行 BL1

BL1:
  1. 加载 BL2 (U-Boot SPL)
  2. 使用 BL1 中的平台公钥验证 BL2 签名
  3. 验证通过 → 跳转执行 BL2

BL2 (U-Boot):
  1. 加载 FIT 镜像 (包含内核、设备树、initramfs)
  2. 对每个组件计算 SHA-256 哈希
  3. 使用 FIT 签名中的 RSA 公钥验证签名
  4. 全部验证通过 → 加载内核并跳转

该流程中，每一级引导程序都验证下一级的完整性和真实性，形成从硬件信任根到操作系统内核的完整信任链。任何一级验证失败，系统都会停止启动并进入安全恢复模式。

  复盘与经验：在实际部署中，我们曾遇到一个问题：某批次设备的 eFuse 烧录时使用了错误的根公钥哈希，导致所有设备无法启动。排查过程耗时 3 天，最终通过 JTAG 调试接口读取 eFuse 内容才发现问题。教训是：信任根的烧录必须增加双重校验机制，例如烧录后回读比对，并在生产流程中增加独立的验证步骤。

密码学基础是 Secure Boot 的基石。哈希算法保证数据完整性，非对称加密提供身份认证能力，数字签名将两者结合形成不可抵赖的验证机制，证书链实现信任的逐级传递，而信任根则作为不可篡改的锚点。理解这些概念及其相互关系，是深入掌握 Secure Boot 原理与实现的前提。在实际工程中，还需要根据硬件能力、安全等级和性能要求，合理选择算法组合与密钥管理策略。