4、镜像签名与验证：RSA/ECDSA算法选择、镜像哈希计算、签名链验证机制

好，咱们接着聊镜像签名与验证。这部分内容，说白了就是给车机里的软件镜像上一把「数字锁」。你想想看，如果谁都能往座舱里刷个镜像，那系统安全就形同虚设了。我在MTK8676的项目里，就亲眼见过一台测试车因为刷了未签名的镜像，导致整个IVI系统变砖，最后只能拆下来用烧录器救活。

所以，签名验证不是可选项，而是必选项。今天我就把算法选择、哈希计算、签名链验证这三个核心环节，掰开了讲清楚。

4.1 RSA vs ECDSA：算法选择的实战考量

先聊算法选择。RSA和ECDSA，这是目前车规级安全启动里最主流的两种签名算法。我个人的习惯是，先看硬件加速器支持什么，再谈算法优劣。

RSA 的优势在于成熟、稳定。车规级芯片里，RSA协处理器几乎是标配。MTK8676的硬件安全模块（HSM）就内置了RSA-2048/4096的加速引擎。签名验证速度非常快，大概在毫秒级就能完成。

ECDSA 的优势在于密钥更短、性能更高。同样是128位的安全强度，RSA需要3072位密钥，而ECDSA只需要256位。这意味着签名体积更小，验证速度更快。但有个坑——ECDSA的实现复杂度更高，对随机数生成器的要求极其苛刻。我在一个项目里就遇到过，因为硬件随机数发生器（TRNG）的熵源不足，导致ECDSA签名偶尔会失败，排查了整整两天。

下面这张表，是我在实际项目中总结的对比数据：

4.2 镜像哈希计算：从文件到摘要的完整流程

签名之前，必须先算哈希。为什么？因为签名算法不能直接处理大文件，只能对固定长度的摘要进行签名。这个道理，就像你不能把一整头牛塞进烤箱，得先切成牛排。

在MTK8676上，我通常使用SHA-256作为哈希算法。具体流程是这样的：

1. 读取镜像文件：按块读取，每块大小建议4KB，兼顾内存和性能。
2. 逐块计算：调用HSM的SHA-256硬件引擎，更新哈希上下文。
3. 获取摘要：所有块处理完后，调用Finalize接口，得到32字节的哈希值。
4. 填充与签名：将哈希值按照PKCS#1 v1.5或PSS格式填充，然后送入RSA/ECDSA签名引擎。

这里有个细节，我踩过坑——哈希计算的顺序必须和验证方完全一致。比如，镜像文件末尾可能有填充字节，签名方和验证方必须约定好是否包含这些填充。我曾经因为一个字节的差异，导致签名验证失败，查了三天才发现是工具链版本不同导致的填充策略不一致。

下面是一段伪代码，展示在MTK8676上如何调用HSM进行哈希计算：

// 伪代码：MTK8676 HSM SHA-256 计算示例
hsm_handle_t hsm = hsm_open(HSM_DEVICE_0);
sha256_context_t ctx;
uint8_t hash[32];

hsm_sha256_init(&ctx);
while (bytes_remaining > 0) {
    size_t chunk_size = min(4096, bytes_remaining);
    hsm_sha256_update(&ctx, chunk_buffer, chunk_size);
    bytes_remaining -= chunk_size;
}
hsm_sha256_final(&ctx, hash);
// 此时 hash 数组里就是镜像的 SHA-256 摘要

4.3 签名链验证机制：从BootROM到应用镜像的信任传递

单签一个镜像不难，难的是如何构建一条完整的信任链。MTK8676的启动流程，就是一条典型的签名链验证过程。

我把它拆解成四个层级：

• 第0级：BootROM —— 芯片出厂固化的只读代码，不可更改。它内部硬编码了根公钥的哈希值。
• 第1级：Preloader —— 第一段可执行代码，由BootROM验证其签名。验证通过后，加载到SRAM执行。
• 第2级：U-Boot / ATF —— 引导加载程序，由Preloader验证签名。负责初始化DDR、加载内核。
• 第3级：Linux Kernel + Android / Linux Userspace —— 操作系统和应用程序，由U-Boot验证签名。

每一级只信任上一级，上一级只验证下一级的签名。这就是所谓的「信任链」。一旦某个环节的签名验证失败，系统立即停止启动，进入安全模式或直接断电。

验证流程的伪代码大致如下：

// 伪代码：签名链验证流程
bool verify_image(uint8_t *image, uint32_t image_size, 
                  uint8_t *signature, public_key_t *pub_key) {
    uint8_t hash[32];
    // 1. 计算镜像哈希
    compute_sha256(image, image_size, hash);
    // 2. 使用公钥验证签名
    return rsa_verify(pub_key, hash, signature);
}

// 启动流程中的调用
if (!verify_image(preloader, preloader_size, preloader_sig, root_pub_key)) {
    panic("Preloader signature verification failed!");
    // 系统死锁，无法继续
}

4.4 避坑指南：我踩过的三个大坑

最后，分享几个我在实际项目中遇到的坑，希望能帮你少走弯路。

• 坑一：哈希算法不统一 —— 签名方用SHA-256，验证方用SHA-384。结果可想而知。建议在项目初期就统一哈希算法，并在设计文档中明确标注。
• 坑二：公钥存储位置不当 —— 有人把公钥放在文件系统里，结果被篡改。记住，公钥必须存储在安全存储区域（如OTP、eFuse），或者由上一级安全组件传递。
• 坑三：签名验证超时 —— 在MTK8676上，如果镜像体积过大（比如超过100MB），哈希计算和签名验证可能耗时超过看门狗定时器阈值，导致系统复位。解决方案是分块验证，或者在看门狗喂狗期间完成验证。

好了，镜像签名与验证这部分，核心就是算法选型、哈希计算、信任链构建。你只要把这三点吃透，MTK8676的安全启动就掌握了八成。下一章，咱们聊聊OTA升级中的镜像加密与解密，那又是另一番天地了。