3、密码学基础：对称加密、非对称加密、哈希函数、数字签名（RSA、ECDSA）、密钥管理基础概念
ARM 架构的安全启动（Secure Boot）与固件签名机制，其底层安全性完全建立在密码学原语之上。无论是校验固件镜像的完整性、验证其来源的真实性，还是保护密钥在存储与传输过程中的机密性，都离不开对称加密、非对称加密、哈希函数与数字签名这四大支柱。本章将深入剖析这些核心概念在 ARM 固件安全场景中的具体角色、工程实现路径以及常见的设计陷阱，帮助读者建立从数学原理到芯片级应用的安全认知闭环。
3.1 对称加密：固件保密性的基石
核心原理
对称加密使用同一个密钥完成加密与解密操作。在 ARM 固件安全场景中，AES（Advanced Encryption Standard）是的主流选择，常见配置为 AES-128 与 AES-256。其核心优势在于计算效率极高，适合在资源受限的嵌入式环境中对大量固件数据进行加解密。AES 的分组长度为 128 位，支持 ECB、CBC、CTR、GCM 等多种工作模式。其中 GCM（Galois/Counter Mode）模式同时提供加密与完整性校验，在固件加密传输场景中尤为实用。
判断方法与操作流程
在实际工程中，选择对称加密算法时需考虑以下决策路径：
- 数据量评估：固件镜像通常为数百 KB 至数十 MB，必须选择硬件加速的 AES 引擎，避免 CPU 软件计算成为性能瓶颈。
- 模式选择：若仅需机密性，CBC 模式足够；若同时需要完整性保护，优先选择 GCM 或 CCM 模式。
- 密钥来源：加密密钥不应直接存储在 Flash 中，而应通过芯片内部硬件唯一密钥（HUK）派生或由安全处理器管理。
// 典型 AES-GCM 固件加密流程（伪代码）
uint8_t key[32] = derive_from_huk(); // 从硬件唯一密钥派生
aes_gcm_ctx ctx;
aes_gcm_init(&ctx, key, 32);
aes_gcm_encrypt(&ctx, fw_data, fw_len, nonce, tag, output);案例拆解：固件镜像的在线加密升级
某 IoT 设备厂商需要对其 ARM Cortex-M7 平台的固件进行加密传输，防止固件被逆向提取。初始方案采用 AES-128-CBC，但发现攻击者可通过修改密文块实施比特翻转攻击，导致固件校验失败或执行异常。分析后改用 AES-256-GCM，利用其附加认证标签（Tag）机制，在解密前先验证完整性。实际操作中，将 16 字节随机 Nonce 与密文一同打包传输，接收端使用同一派生密钥完成解密与验证。结果固件提取难度显著提升，且解密性能仅下降约 8%，在可接受范围内。该案例的代价是需要额外管理 Nonce 的唯一性，避免重复使用导致密钥流重用。
3.2 非对称加密与哈希函数：信任链的数学根基
核心原理
非对称加密使用公钥-私钥对，公钥用于加密或验签，私钥用于解密或签名。RSA 基于大整数分解难题，而 ECDSA（椭圆曲线数字签名算法）基于椭圆曲线离散对数难题。在 ARM 安全启动中，非对称加密主要用于签名验证，而非数据加密。哈希函数（如 SHA-256）则将任意长度的固件数据映射为固定长度的摘要，具有单向性、抗碰撞性和雪崩效应，是数字签名的基础组件。
判断方法与操作流程
选择 RSA 还是 ECDSA 需要综合评估：
| 对比维度 | RSA-2048 | ECDSA P-256 |
|---|---|---|
| 密钥长度 | 2048 位 | 256 位 |
| 签名验证速度 | 较慢（模幂运算） | 较快（标量乘法） |
| 签名大小 | 256 字节 | 64 字节 |
| 硬件资源占用 | 高（需要大数运算单元） | 低（适合资源受限设备） |
| 适用场景 | 性能要求不高的启动阶段 | 高性能、低功耗场景 |
哈希函数在安全启动中的典型操作流程为：
- BootROM 读取固件头部，获取签名值与公钥索引。
- 对固件主体计算 SHA-256 摘要。
- 使用公钥对签名值进行解密/验签，得到原始摘要。
- 比对两个摘要，一致则通过验证。
案例拆解：ECDSA 在 ARM Trusted Firmware-A 中的应用
在 ARM Trusted Firmware-A（TF-A）中，BL2 镜像的签名验证采用 ECDSA P-256 曲线。某开发板在移植过程中，发现 BL2 验签失败，日志显示 "hash mismatch"。排查过程如下：首先确认公钥是否已正确烧录到 OTP 中，使用 fiptool 工具导出公钥并与源码比对；其次检查签名生成工具链，发现构建服务器上 OpenSSL 版本与目标板验证库版本不一致，导致 ECDSA 签名中的 DER 编码格式存在细微差异。最终统一使用相同版本的 OpenSSL 重新生成签名，问题解决。该案例表明，ECDSA 的工程实现必须严格遵循 DER 编码规范，且签名工具链与验证库需保持版本兼容。
3.3 数字签名：RSA 与 ECDSA 的工程实践
核心原理
数字签名结合了哈希函数与非对称加密：发送方对消息摘要用私钥签名，接收方用公钥验签。RSA 签名通常采用 PKCS#1 v1.5 或 PSS 填充方案，而 ECDSA 则基于椭圆曲线运算生成 (r, s) 签名对。在 ARM 安全启动中，签名验证是每一级引导程序的核心动作，BootROM 中固化公钥哈希，后续各级公钥由上一级验证后加载。
判断方法与操作流程
签名验证的工程实现需关注以下关键点：
- 填充方案：RSA-PKCS#1 v1.5 实现简单但存在 Bleichenbacher 攻击风险，推荐使用 RSA-PSS。
- 随机数质量：ECDSA 签名对随机数 k 的要求极高，若 k 值泄露或重用，私钥可被恢复。必须使用硬件 TRNG（真随机数发生器）。
- 公钥存储：根公钥的哈希应烧录在一次性可编程（OTP）存储器中，防止被篡改。
// ECDSA 签名验证核心逻辑（基于 Mbed TLS）
mbedtls_ecdsa_context ctx;
mbedtls_ecdsa_init(&ctx);
mbedtls_ecp_group_load(&ctx.grp, MBEDTLS_ECP_DP_SECP256R1);
mbedtls_mpi_read_binary(&ctx.Q.X, pubkey_x, 32);
mbedtls_mpi_read_binary(&ctx.Q.Y, pubkey_y, 32);
mbedtls_mpi_lset(&ctx.Q.Z, 1);
int ret = mbedtls_ecdsa_read_signature(&ctx, hash, 32, sig, sig_len);案例拆解：安全启动链的签名验证性能优化
某汽车电子控制单元（ECU）采用 i.MX8 平台，安全启动链包含四级镜像验证。初始实现中，每级验证均使用 RSA-2048 软件验签，总启动时间增加 1.2 秒，超出系统要求。通过性能分析发现，RSA 模幂运算占用了 78% 的验证时间。优化方案：将第一级 BootROM 验证保留 RSA（因为 BootROM 有专用硬件加速），后续级别切换为 ECDSA P-256，并启用芯片的加密加速引擎（CAAM）。优化后，总验证时间降至 320 毫秒，满足 500 毫秒的启动预算。该案例的代价是需要额外维护两套密钥体系，增加了密钥管理的复杂度。
3.4 密钥管理：安全启动的信任锚
核心原理
密钥管理是安全启动体系中最薄弱的环节。ARM 平台通常采用分层密钥结构：芯片出厂时烧录硬件唯一密钥（HUK）到 eFuse 中，HUK 用于加密其他密钥或派生会话密钥。固件签名密钥分为根密钥（Root Key）与次级密钥（Sub Key），根密钥公钥哈希固化在 OTP 中，次级密钥由根密钥签名。这种分层设计允许密钥轮换，同时保证信任根不变。
判断方法与操作流程
密钥管理的核心流程包括：
- 密钥生成：在离线安全环境中生成 RSA/ECDSA 密钥对，私钥存储在 HSM（硬件安全模块）中。
- 密钥烧录：将根公钥哈希写入 OTP，此操作不可逆，需严格校验。
- 密钥轮换：通过签名次级密钥的方式更新固件签名密钥，无需修改 OTP。
- 密钥销毁：设备报废时，需清除所有敏感密钥材料。
| 密钥层级 | 存储位置 | 用途 | 生命周期 |
|---|---|---|---|
| HUK | eFuse/OTP | 派生加密密钥 | 芯片生命周期 |
| 根密钥公钥 | OTP（哈希） | 验证次级密钥 | 产品生命周期 |
| 固件签名私钥 | HSM/离线存储 | 签名固件镜像 | 可轮换 |
| 固件加密密钥 | 安全存储区 | 加解密固件 | 随固件版本更新 |
案例拆解：密钥轮换策略的落地实施
某网络设备厂商需要对其已部署的 10 万台设备进行固件签名密钥轮换。初始方案是直接更换根密钥，但发现 OTP 已烧录无法修改。重新设计后采用次级密钥轮换方案：保留根密钥不变，使用根密钥私钥签发新的次级密钥公钥，并生成新的固件签名密钥对。设备端在启动时，BootROM 验证根密钥，BL1 验证次级密钥，BL2 使用新的次级密钥验证固件。整个轮换过程通过固件升级包完成，无需硬件改动。该方案的风险在于，如果根密钥私钥泄露，整个信任链将崩溃，因此根密钥私钥必须存放在银行级 HSM 中，并实施多人分持管理。
3.5 常见误区与总结复盘
误区一：混淆加密与签名
加密保护机密性，签名保护完整性与真实性。在安全启动中，固件通常需要签名而非加密，因为启动过程需要公开验证固件来源。若错误地对固件进行加密，会导致 BootROM 无法直接读取固件内容，需要先解密再验签，增加启动复杂度且密钥管理更为困难。
误区二：忽视哈希截断风险
某些实现为了节省存储空间，仅截取 SHA-256 的前 128 位作为摘要。虽然碰撞概率仍然很低，但在安全启动场景中，攻击者可能利用碰撞构造恶意固件。建议使用完整 SHA-256 或 SHA-384，并确保签名算法与哈希长度匹配。
误区三：密钥存储依赖外部 Flash
将私钥或对称密钥存储在 SPI Flash 中，即使加密存储，攻击者仍可通过物理攻击（如探针、电压故障注入）提取。正确的做法是使用芯片内置的 eFuse、安全 NVRAM 或 TrustZone 保护的 RPMB 分区。
总结复盘
本章系统梳理了密码学基础在 ARM 安全启动中的工程应用。对称加密（AES-GCM）保障固件传输与存储的机密性；哈希函数（SHA-256）提供完整性度量；非对称加密（RSA/ECDSA）与数字签名构建信任链验证机制；分层密钥管理确保信任根的安全。在实际项目中，应根据芯片的硬件加速能力、启动时间预算、安全等级要求综合选择算法组合。建议读者在开发板上实际实践：使用 OpenSSL 生成密钥、编写签名工具、在 U-Boot 或 TF-A 中实现验签流程，以加深对密码学原语与硬件交互的理解。