4、密码学基础：对称加密（AES）、非对称加密（RSA/ECC）、哈希函数（SHA-2/SHA-3）、数字签名（RSA-PSS/ECDSA）、消息认证码（HMAC）在安全启动中的应用

安全启动（Secure Boot）的信任根建立与链式验证，本质上是一套精心编排的密码学协议。BootROM作为第一段不可篡改的代码，必须依赖硬件加速的密码引擎完成对下一级Bootloader的完整性校验与来源认证。本章将系统梳理AES、RSA/ECC、SHA-2/SHA-3、RSA-PSS/ECDSA及HMAC在启动流程中的具体分工、实现原理与工程选型要点，帮助开发者构建从复位向量到操作系统内核的完整信任链。

上图展示了安全启动过程中各类密码学原语的协同关系。BootROM作为信任根，仅内置公钥的哈希值（PKH），通过比对实际加载的公钥哈希来防止公钥替换攻击。后续每个阶段的Bootloader都采用“验签-解密-校验-跳转”的固定流程，其中签名验证使用非对称算法，镜像解密使用对称算法，完整性校验则依赖哈希函数或HMAC。这种分层设计确保了即使某个阶段的Bootloader被攻破，攻击者也无法向上追溯修改更早阶段的代码。

4.1 对称加密AES在启动镜像保护中的核心原理

核心原理：AES（高级加密标准）是一种分组密码算法，分组长度为128位，支持128/192/256位密钥。在安全启动场景中，AES主要用于两个目的：一是加密Bootloader和内核镜像，防止静态逆向分析；二是配合GCM等认证加密模式，同时提供机密性和完整性保护。AES的硬件实现通常包含S盒替换、行移位、列混合和轮密钥加四个步骤，在嵌入式平台上通过硬件加速器可在几个微秒内完成整个镜像的解密。

判断方法：选择AES工作模式时需考虑以下因素：

• ECB模式：不推荐用于镜像加密，相同明文块产生相同密文块，易泄露代码结构信息。
• CBC模式：需要初始化向量（IV），每个密文块依赖前一个块，适合块设备加密，但无法提供完整性保护。
• CTR模式：将分组密码转为流密码，支持并行解密，适合高性能场景，但同样缺乏认证能力。
• GCM模式：结合CTR加密和GHASH认证，一次操作同时完成加密和完整性校验，是安全启动的首选模式。

常见误区：部分开发者误以为AES加密即可保证镜像安全，忽略了密钥管理。如果AES密钥以明文形式存储在Flash中，攻击者通过调试接口读取Flash即可获得密钥，加密形同虚设。正确的做法是将密钥存储在eFuse或HSM内部，并设置访问权限，仅允许加密引擎在特定安全状态下访问。

4.2 非对称加密RSA/ECC在签名验证中的工程实践

核心原理：非对称加密使用公钥-私钥对，私钥用于签名，公钥用于验签。RSA基于大整数分解难题，密钥长度通常为2048或4096位；ECC基于椭圆曲线离散对数难题，P-256曲线提供与RSA-3072相当的安全强度，但密钥更短、计算更快。在安全启动中，BootROM内置公钥哈希（PKH），实际公钥随镜像一起发布，BootROM先计算公钥的SHA-256哈希并与PKH比对，再用该公钥验证镜像签名。

操作流程：签名验证的完整流程如下：

1. BootROM从OTP/efuse读取PKH（32字节SHA-256值）。
2. 从镜像头部加载公钥证书（包含公钥、证书签名等）。
3. 计算公钥的SHA-256哈希，与PKH进行常量时间比较。
4. 若哈希匹配，使用公钥对镜像签名进行验签（RSA-PSS或ECDSA）。
5. 验签通过后，解析镜像元数据（版本号、加载地址、大小等）。
6. 将镜像加载到RAM并跳转执行。

对比维度	RSA-2048	ECC P-256	工程考量
密钥长度	2048位	256位	ECC存储占用更小
验签速度	约1-2ms（硬件加速）	约0.3-0.5ms（硬件加速）	ECC更适合启动时间敏感场景
签名长度	256字节	64字节	ECC节省Flash空间
安全强度	112位	128位	ECC提供更高安全边际
硬件资源	需要大数乘法器	需要椭圆曲线点乘	现代SoC通常同时支持

案例拆解：某Linux网关设备采用i.MX8M Plus处理器，其BootROM支持RSA-2048和ECC P-256。初始设计使用RSA-2048，但发现启动时间中验签占用了约40%的预算。切换到ECC P-256后，验签时间从1.8ms降至0.4ms，同时公钥存储空间从256字节降至64字节。需要注意的是，ECC实现必须验证点是否在曲线上，防止无效曲线攻击，硬件加速器通常自动处理此检查。

4.3 哈希函数SHA-2/SHA-3与消息认证码HMAC的完整性保障

核心原理：SHA-2（包括SHA-256、SHA-384等）和SHA-3（Keccak算法）是密码学哈希函数，将任意长度输入映射为固定长度输出。SHA-2基于Merkle-Damgård结构，SHA-3基于海绵结构，两者在安全启动中用于计算镜像摘要、生成HMAC以及派生密钥。HMAC（基于哈希的消息认证码）使用密钥对消息进行认证，公式为HMAC(K,m)=H((K'⊕opad)||H((K'⊕ipad)||m))，其中K'是密钥K的填充版本。

判断方法：在安全启动中选择哈希算法时，需考虑以下因素：

• SHA-256：当前最广泛使用的哈希算法，所有主流BootROM均支持，硬件加速器成熟。
• SHA-384/512：提供更高安全强度，适用于需要FIPS 140-2 Level 4合规的场景。
• SHA-3-256：与SHA-2算法结构完全不同，可防御某些针对SHA-2的潜在攻击，但硬件支持较少。
• HMAC-SHA-256：用于镜像加载后的运行时完整性校验，防止DMA攻击或内存篡改。

实战场景：在U-Boot的Verified Boot机制中，镜像的哈希值被签名保护。启动时，U-Boot计算镜像的SHA-256哈希，与签名中携带的哈希值比对。若镜像被修改，哈希不匹配，验签失败。对于需要防回滚的场景，镜像版本号也纳入哈希计算，确保旧版本镜像无法通过验证。

常见误区：部分开发者将哈希函数等同于加密，认为对镜像做SHA-256即可防止篡改。实际上，哈希函数不提供机密性，且无密钥保护时攻击者可同时修改镜像和哈希值。正确的做法是：使用签名保护哈希值（签名哈希），或使用HMAC（密钥保护哈希）。此外，SHA-1已被证明存在碰撞攻击，严禁在安全启动中使用。

4.4 数字签名RSA-PSS/ECDSA的选型与实现要点

核心原理：数字签名提供来源认证、完整性和不可否认性。RSA-PSS（概率签名方案）是RSA签名的一种安全填充方式，包含盐值（salt），提供比传统PKCS#1 v1.5更高的安全性。ECDSA（椭圆曲线数字签名算法）基于ECC，签名由(r,s)两个整数组成，验证时需计算椭圆曲线点乘。在安全启动中，签名算法必须与BootROM支持的算法匹配，且需考虑硬件加速器的具体实现。

操作流程：ECDSA签名验证的数学过程如下：

1. 计算消息哈希e = SHA-256(message)。
2. 从签名中提取(r,s)，检查r,s ∈ [1,n-1]（n为曲线阶）。
3. 计算w = s⁻¹ mod n。
4. 计算u1 = e·w mod n，u2 = r·w mod n。
5. 计算点(x,y) = u1·G + u2·Q（G为基点，Q为公钥）。
6. 若x mod n == r，则签名有效。

案例拆解：某安全MCU平台支持RSA-PSS和ECDSA两种签名方案。在开发阶段，使用RSA-PSS-2048便于与现有PKI基础设施集成；量产阶段切换到ECDSA P-256以降低启动延迟。切换过程中发现，ECDSA验签需要额外的曲线参数配置，且必须验证公钥是否在有效曲线上。通过硬件加速器的寄存器配置，最终实现了两种算法的无缝切换。

签名方案	填充方式	签名长度	验证复杂度	适用场景
RSA-PSS	MGF1 + 盐值	256字节 (2048位)	模幂运算	兼容性要求高的场景
RSA-PKCS#1 v1.5	固定填充	256字节 (2048位)	模幂运算	遗留系统兼容
ECDSA P-256	无填充	64字节	点乘运算	资源受限的嵌入式设备
Ed25519	无填充	64字节	点乘运算	新兴高性能场景

常见误区：RSA-PSS的盐值长度选择不当会影响安全性。盐值过短（如8字节）会降低安全性，推荐使用与哈希输出等长的盐值（如SHA-256对应32字节）。ECDSA实现中，随机数k的生成至关重要——如果k值重复，攻击者可通过两个签名恢复私钥。因此，必须使用硬件真随机数发生器（TRNG）生成k值，且不能使用可预测的伪随机数。

4.5 密码学算法在安全启动中的综合应用与工程复盘

核心原理：一个完整的安全启动方案需要将上述密码学原语有机组合。典型的信任链如下：BootROM（包含PKH）→ 验证SBL签名 → SBL验证ABL签名 → ABL验证内核签名。每一级验证都包含“公钥验证+签名验证+哈希校验”三个步骤。同时，AES密钥的传递通常采用密钥包装（Key Wrapping）机制：使用非对称加密传输AES密钥，或使用硬件唯一密钥（HUK）派生。

判断方法：评估安全启动方案的强度时，需考虑以下维度：

• 信任根保护：PKH是否存储在OTP中？是否支持多级回滚保护？
• 密钥隔离：私钥是否存储在HSM中？AES密钥是否与CPU隔离？
• 算法强度：是否使用至少SHA-256、RSA-2048或ECC P-256？
• 防侧信道：硬件加速器是否具备抗功耗分析能力？
• 故障注入防护：是否检测到电压/时钟毛刺攻击？

案例复盘：某工业物联网设备在量产阶段发现，部分设备的BootROM验签失败。排查过程如下：

1. 初步怀疑是Flash读取错误，但重读多次结果一致。
2. 检查公钥哈希比对，发现PKH读取正常，但公钥加载后哈希不匹配。
3. 进一步分析发现，公钥存储在外部SPI Flash中，而SPI控制器在BootROM阶段未初始化DMA，导致读取时序不稳定。
4. 解决方案：在BootROM中增加SPI Flash读取重试机制，并添加CRC校验。
5. 复盘结论：硬件初始化顺序和时序容错是安全启动稳定性的关键因素。

总结：密码学算法是安全启动的基石，但算法本身并不足以保证安全。工程实践中，需要关注密钥管理、硬件加速、错误处理、防侧信道等多个层面。建议开发者在项目初期就建立安全启动的威胁模型，明确信任边界，并针对每个信任转换点设计相应的密码学保护措施。同时，定期更新BootROM和密钥管理策略，以应对不断演进的攻击手段。