3. 升级包制作与签名：从原始镜像到安全交付
升级包，说白了就是车载 ECU 的「新灵魂」。你想想看，一个几十兆甚至上百兆的固件，要通过 OTA 通道安全地刷进控制器，中间不能出错、不能被篡改、不能被窃取。这背后靠的就是一套严谨的打包与签名机制。
我个人习惯把升级包拆成三个核心部分：元数据、镜像本体、以及校验签名信息。今天我们就一步步把它说透。
3.1 升级包的组成：三层结构
一个标准的 OTA 升级包，内部其实是一个结构化的容器。我见过不少新手工程师，上来就把整个固件扔进去，结果版本号、硬件兼容性这些关键信息全丢了。嗯，这里要注意，元数据才是升级包的「身份证」。
| 层级 | 内容 | 作用 |
|---|---|---|
| 元数据层 | 版本号、ECU ID、硬件兼容列表、包大小、哈希值、签名 | 描述包是谁的、给谁用、是否完整、是否可信 |
| 镜像层 | 完整固件镜像（.bin/.hex）或差分包（.diff） | 实际要刷入 Flash 的二进制数据 |
| 校验层 | SHA256 哈希值 + RSA/ECDSA 数字签名 | 保证数据完整性 + 来源真实性 |
关键原则：元数据必须独立于镜像进行签名。我曾经遇到过一个项目，把哈希值放在镜像内部一起签名，结果验签时成了「自己证明自己」，逻辑上就闭环了——这是典型的先有鸡还是先有蛋的问题。
3.2 哈希校验：SHA256 是怎么工作的？
哈希校验，说白了就是给数据算一个「指纹」。你改一个 bit，指纹就完全变了。SHA256 是目前汽车行业最常用的哈希算法，输出固定 256 bit（32 字节）的摘要。
为什么不用 MD5 或 SHA1？我直接说结论：MD5 和 SHA1 已经被证明存在碰撞攻击，在汽车安全领域已经不被推荐。Tier-1 的审核现在基本只认 SHA256 或更高。
// 伪代码：计算固件镜像的 SHA256 哈希
uint8_t firmware_image[IMAGE_SIZE];
uint8_t hash_output[32]; // SHA256 输出 32 字节
SHA256_CTX ctx;
sha256_init(&ctx);
sha256_update(&ctx, firmware_image, IMAGE_SIZE);
sha256_final(&ctx, hash_output);
// 将 hash_output 写入元数据，准备签名
实战建议：计算哈希时，一定要把整个镜像文件按二进制流读入，不要做任何格式转换。我见过有人把 hex 文件当成文本去算哈希，结果车端和云端永远对不上——因为换行符被改了。
3.3 数字签名：RSA vs ECDSA
哈希只能保证数据没被改过，但保证不了数据是谁发的。这时候就需要数字签名了。简单说，签名就是用私钥加密哈希，验签就是用公钥解密哈希并比对。
汽车行业目前主流是 RSA-2048 和 ECDSA（椭圆曲线）。我个人更倾向于 ECDSA，原因很简单：同样的安全强度下，ECDSA 的密钥更短、签名更快、占用空间更小。对于资源受限的 MCU，这很关键。
| 特性 | RSA-2048 | ECDSA (P-256) |
|---|---|---|
| 密钥长度 | 2048 bit | 256 bit |
| 签名长度 | 256 字节 | 64 字节 |
| 签名速度 | 较慢 | 较快 |
| 验签速度 | 较快 | 较慢（但可接受） |
| MCU 资源占用 | 高（大数运算） | 低（椭圆曲线运算） |
避坑指南：我曾经在一个项目中，ECU 的 Bootloader 只支持 RSA 验签，但云端升级服务默认生成 ECDSA 签名。结果车端验签一直失败，排查了两天才发现是签名算法不匹配。所以，签名算法必须在项目早期就与 Bootloader 团队对齐，不要等到集成阶段才发现。
3.4 差分包：只传变化的部分
全量镜像升级，说白了就是每次把整个固件刷一遍。但车载 ECU 的镜像动辄几十 MB，如果每次升级都全量下载，流量和时间成本都扛不住。差分包就是只传输新旧版本之间的差异部分。
常用的差分算法有 bsdiff、hdiffpatch 等。我习惯用 bsdiff，它在二进制级别上表现稳定，尤其适合固件这种结构化的数据。
# 生成差分包（云端）
bsdiff old_firmware.bin new_firmware.bin delta.patch
# 应用差分包（车端）
bspatch old_firmware.bin updated_firmware.bin delta.patch
差分包的大小通常只有全量包的 5%~30%，具体取决于新旧版本的差异程度。嗯，这里要注意：差分算法对内存有要求，车端 MCU 需要足够的 RAM 来缓存新旧数据块。
经验之谈：差分升级不是万能的。如果新旧版本差异太大（比如换了编译器或底层驱动），差分包可能比全量包还大。我一般会在云端加一个策略：如果差分包超过全量包的 80%，就直接走全量升级。
3.5 完整升级包制作流程
下面这张图是我在实际项目中一直沿用的升级包制作流程，你可以把它当作一个 checklist 来用。
3.6 代码实战：用 OpenSSL 完成签名
下面是一个完整的签名流程示例，使用 OpenSSL 命令行工具。我建议你在 CI/CD 流水线中集成类似的脚本。
# 1. 生成 RSA 私钥（2048 bit）
openssl genrsa -out private.pem 2048
# 2. 提取公钥
openssl rsa -in private.pem -pubout -out public.pem
# 3. 计算固件哈希
openssl dgst -sha256 -binary firmware.bin > firmware.hash
# 4. 用私钥签名哈希
openssl pkeyutl -sign -inkey private.pem \
-in firmware.hash -out firmware.sig
# 5. 打包（元数据 + 镜像 + 签名）
# 这一步通常用脚本组装成自定义格式
小技巧：生产环境中，私钥绝对不能出现在构建服务器上。我习惯的做法是：在离线 HSM（硬件安全模块）中完成签名，构建服务器只拿到签名后的 .sig 文件。这样即使 CI 被攻破，私钥也不会泄露。
3.7 车端验签流程
车端收到升级包后，Bootloader 会执行以下验签流程。注意，验签必须在安全环境中进行，防止被跳过。
- 解析元数据：提取版本号、ECU ID、哈希值、签名数据
- 校验硬件兼容性：确认升级包目标 ECU 与当前 ECU 匹配
- 计算镜像哈希：对接收到的镜像重新计算 SHA256
- 比对哈希：与元数据中的哈希值比对，不一致则丢弃
- 验签：用预置公钥解密签名，与哈希比对
- 通过后：将镜像写入 Flash，更新版本号
我曾经踩过的坑：有一个项目，Bootloader 验签通过了，但刷写后 ECU 变砖。后来发现是公钥在产线烧录时被写错了位置，导致验签用的是一把「假钥匙」。从那以后，我要求所有项目在产线增加一个「自签自验」的测试环节——用已知的测试镜像和签名，验证 Bootloader 的验签逻辑是否正常。
3.8 本章小结
升级包制作与签名，是 OTA 安全的第一道防线。记住三个核心点：哈希保完整、签名保来源、差分省流量。实际项目中，把这套流程固化到自动化工具链里，比什么都重要。手动打包迟早会出问题——我见过太多次了。