3、密码学基础：哈希算法（SHA-256等）、非对称加密（RSA/ECC）、数字签名与验签原理

Secure Boot 的信任根建立与镜像验签流程，本质上是一套精心设计的密码学协议。要深入理解固件在启动过程中如何被逐级校验，必须先掌握三个核心密码学构件：哈希算法、非对称加密和数字签名。哈希算法负责为固件生成唯一的“数字指纹”，非对称加密提供了公私钥对的安全基础，而数字签名则将两者结合，确保固件的完整性（未被篡改）与真实性（来自可信发布者）。本章将系统梳理这三者的数学原理、工程实现以及在 Secure Boot 场景下的具体应用逻辑。

3.1 哈希算法：固件完整性的基石

核心原理：单向散列的数学保证

哈希算法（Hash Algorithm）是一种将任意长度的二进制数据映射为固定长度摘要（Digest）的数学函数。在 Secure Boot 场景中，最常用的哈希算法是 SHA-256（Secure Hash Algorithm 256-bit），它输出 32 字节的摘要值。其核心安全属性包括：抗原像性（给定摘要无法反推原文）、抗第二原像性（给定原文和摘要，无法找到另一原文产生相同摘要）以及抗碰撞性（难以找到任意两个不同输入产生相同输出）。SHA-256 采用 Merkle-Damgård 结构，将输入数据分块（512-bit）后通过压缩函数迭代处理，每一轮的位运算（异或、移位、加法）确保了雪崩效应——输入数据的任何 1 bit 变化，都会导致约 50% 的输出位发生变化。

工程实现与性能考量

在固件验签流程中，哈希计算通常由硬件加速器（如 ARM TrustZone 中的 CryptoCell、Intel 的 SHA Extensions）或软件库（如 OpenSSL、mbedTLS）完成。硬件加速的优势在于：固定时间计算（避免时序侧信道攻击）、零拷贝 DMA（直接从 Flash 读取数据计算）以及低功耗。以一块 16MB 的固件镜像为例，软件 SHA-256 在 1GHz 主频的 Cortex-A53 上大约需要 80ms，而硬件加速器可将时间压缩至 10ms 以内。工程上还需注意哈希算法的上下文管理：对于流式校验（边读取边计算），需要维护 SHA256_CTX 结构体，依次调用 Init、Update、Final 三个接口。

常见误区与复盘

• 误区一：MD5 仍可用于固件校验。MD5 已被证明存在碰撞攻击，攻击者可构造两个不同固件产生相同 MD5 值。Secure Boot 场景必须使用 SHA-256 或更高级别算法。
• 误区二：哈希值本身需要加密传输。哈希值不包含原始数据信息，即使被窃听也不会泄露固件内容。但若攻击者篡改哈希值，则完整性校验失效，因此哈希值必须通过安全通道或签名保护。
• 误区三：忽略长度扩展攻击。SHA-256 对 Merkle-Damgård 结构存在长度扩展攻击风险，在构造 MAC 时应使用 HMAC-SHA256 而非简单拼接密钥与数据。

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

核心原理：公私钥对的数学基础

非对称加密使用一对数学关联的密钥：公钥（Public Key）和私钥（Private Key）。RSA 算法基于大整数分解难题，其安全性依赖于：给定两个大素数 p 和 q 的乘积 n（通常 2048-bit），在不知道 p、q 的情况下分解 n 是计算上不可行的。ECC（椭圆曲线密码学）则基于椭圆曲线离散对数问题，在 256-bit 密钥长度下即可提供与 RSA-3072 相当的安全强度。Secure Boot 场景中，私钥存储在签名服务器（离线环境），公钥烧录在设备的一次性可编程存储器（OTP）或 eFuse 中，作为信任根。

算法对比与选型决策

选型建议：对于消费类电子产品，ECC-P256 在签名速度和存储占用上优势明显；对于需要满足国内合规要求的设备（如金融终端、政务设备），必须选用 SM2；对于已有 RSA 基础设施的老旧系统，可继续使用 RSA-2048，但需关注密钥长度升级趋势。

密钥管理与生命周期

Secure Boot 的密钥管理遵循层级化信任模型：根密钥（Root Key）→ 中间密钥（Intermediate Key）→ 固件签名密钥（Firmware Signing Key）。根密钥对中间密钥进行签名，中间密钥对固件签名密钥进行签名，固件签名密钥最终对固件镜像签名。这种分层设计允许在不更换硬件信任根的情况下轮换中间密钥和固件签名密钥。密钥生成必须在离线、物理隔离的环境中进行，私钥使用硬件安全模块（HSM）存储，并设置严格的访问控制策略。

3.3 数字签名与验签：Secure Boot 的核心协议

签名生成与验签流程

数字签名结合了哈希算法和非对称加密，为固件提供完整性和真实性保证。签名生成过程如下：

1. 计算摘要：对固件镜像计算 SHA-256 摘要 H(Firmware)。
2. 私钥签名：使用签名私钥对摘要进行加密运算，生成签名值 Sig = Sign_PrivateKey(H(Firmware))。
3. 打包发布：将固件镜像、签名值、证书链（包含公钥）打包为发布文件。

设备端验签流程（以 U-Boot 或 ARM Trusted Firmware 为例）：

1. 提取公钥：从 OTP/eFuse 或证书链中获取验签公钥。
2. 解密签名：使用公钥对签名值进行解密运算，得到摘要1 = Verify_PublicKey(Sig)。
3. 计算摘要2：对当前固件镜像重新计算 SHA-256 摘要。
4. 比对摘要：若摘要1 == 摘要2，则验签通过，允许启动；否则拒绝启动并进入恢复模式。

案例拆解：基于 ECC-P256 的 U-Boot 验签实现

某工业控制设备采用 NXP i.MX8M Plus 处理器，Secure Boot 流程由 SPL（Secondary Program Loader）执行。其验签关键参数如下：

• 固件镜像大小：8MB（包含 U-Boot 和 OP-TEE）
• 签名算法：ECDSA-P256 + SHA-256
• 公钥存储：4KB eFuse 区域，分 8 次烧录
• 验签时间预算：≤ 50ms（从 Flash 读取到验签完成）

初始现象：设备在冷启动时频繁进入恢复模式，日志显示 "Authentication failed" 错误。分析过程：

1. 使用串口抓取完整启动日志，确认失败发生在 SPL 阶段。
2. 检查 eFuse 烧录记录，发现公钥的第 3 个字（32-bit）烧录值异常。
3. 对比原始公钥哈希，确认 eFuse 烧录过程中发生了位翻转（bit flip）。
4. 进一步检查烧录工具，发现电压波动导致 eFuse 编程时序不满足数据手册要求。

解决方案：重新烧录 eFuse（使用稳定电源），并在烧录后增加回读校验步骤。同时，在 U-Boot 源码中增加公钥有效性预检（检查公钥的曲线参数是否合法），避免无效公钥导致的验签失败。修复后，设备冷启动 1000 次无失败记录。

常见误区与最佳实践

• 误区一：验签时只比对签名，不检查证书链。攻击者可替换证书链中的公钥。正确做法是：从信任根（OTP 中的根公钥）开始，逐级验证证书链的签名，直到获得固件签名公钥。
• 误区二：忽略防回滚保护。攻击者可能将设备回滚到存在漏洞的旧版本固件。应在固件头中增加版本号字段，并在验签时检查版本号不低于当前最低允许版本。
• 误区三：验签失败后直接进入 shell。安全做法是：验签失败后进入安全恢复模式，仅允许签名固件升级，禁止任何调试接口。
• 最佳实践：采用"先验签后解压"的顺序，确保压缩固件在解压前已被验证；使用硬件 crypto 引擎进行验签，避免软件实现中的时序侧信道泄露。

3.4 密码学基础在 Secure Boot 中的综合应用

信任链的建立与传递

Secure Boot 的完整信任链从芯片内部的 Boot ROM 开始。Boot ROM 中固化的根公钥（Root Public Key）是信任锚点，它验证下一级引导加载程序（如 SPL）的签名。SPL 验证 U-Boot，U-Boot 验证内核或 OP-TEE，形成一条完整的信任传递链。每一级验证都遵循相同的密码学流程：读取镜像 → 计算哈希 → 公钥验签 → 比对摘要 → 跳转执行。这种分层设计将密码学操作分散到不同启动阶段，既保证了安全性，又控制了单级验签的时间开销。

性能优化与安全平衡

在实际工程中，验签性能与安全强度需要权衡。对于启动时间敏感的消费设备（如手机），可采用以下优化策略：

• 并行哈希计算：在 DMA 读取固件数据的同时，硬件哈希引擎并行计算摘要，减少串行等待时间。
• 缓存验签结果：对于频繁重启的设备，可在安全存储中缓存最近一次验签通过的固件哈希值，下次启动时仅比对哈希（需配合防回滚计数器）。
• 分级安全策略：对启动关键组件（如内核）使用强签名算法，对非关键组件（如设备树）使用较轻量级校验。

密码学基础是 Secure Boot 体系的数学根基。哈希算法保证了固件完整性，非对称加密提供了密钥分发与身份认证能力，数字签名则将两者融合为可工程实现的验签协议。理解这三者的原理与工程约束，是后续深入分析 Secure Boot 镜像格式、验签流程实现和攻击面防御的前提。在实际项目中，应根据设备的安全等级、性能预算和合规要求，选择合适的算法组合与密钥管理策略，构建既安全又高效的启动信任链。