3、升级包制作与签名：升级包格式选择、增量包制作、数字签名与验签流程
各位同学，欢迎来到第三章。这一章我们聊聊升级包本身。说白了，升级包就是OTA的灵魂。你想想看，车端ECU能不能安全、稳定地完成升级，很大程度上取决于这个包做得怎么样。
我个人习惯把升级包制作分成三个核心问题：用什么格式装？怎么做得小？怎么保证安全？ 咱们一个一个来拆解。
3.1 升级包格式选择：.zip、.tar 还是 .swu？
很多刚入行的朋友会问我：“老师，到底用哪种格式好？” 我的回答是：没有最好的，只有最合适的。
先看最常见的 .zip。它最大的优点是通用性强，几乎所有的操作系统都原生支持。我在早期做后装市场产品时，就用的zip。但zip有个问题——它没有内建的完整性校验机制。你解压完了，文件对不对，得自己算一遍哈希。这在车规级场景下，是个隐患。
再看 .tar。tar本身不压缩，只是打包。所以它通常和gzip、xz等压缩算法配合使用，变成.tar.gz或.tar.xz。它的好处是结构简单，流式处理方便。我记得有一次做全量包升级，ECU的内存只有64MB，用tar流式解压，边下载边写入，体验很好。
最后是 .swu。这是SWUpdate工具的原生格式，也是目前车载OTA领域的事实标准。它本质上是一个CPIO归档文件，前面带一个描述头。swu格式最大的优势是自描述——包里面包含了元数据、签名、校验和，甚至还可以嵌入安装脚本。
我的建议：
- 如果你在做后装或原型验证，.zip 够用，但记得自己加签名和校验。
- 如果你在做前装量产项目，直接用 .swu。它和SWUpdate、OSTree等工具链配合得天衣无缝。
- .tar 适合做中间格式，比如在服务器端打包，最后再转成.swu。
这里有个小对比表格，方便你选型时参考：
| 格式 | 压缩支持 | 内建校验 | 流式处理 | 车规适用性 |
|---|---|---|---|---|
| .zip | 是（Deflate） | 否 | 部分支持 | 低 |
| .tar(.gz/.xz) | 是（外部算法） | 否 | 是 | 中 |
| .swu | 是（CPIO + zlib） | 是（SHA256 + 签名） | 是 | 高 |
3.2 增量包制作：bsdiff 与 xdelta
全量包简单粗暴，但体积大。你想想看，一个IVI系统的镜像动辄2-3GB，每次升级都下载全量包，流量费都够呛。所以，增量更新就派上用场了。
增量包的核心思想是：只传输新旧版本之间的差异。目前业界最主流的两个工具是 bsdiff 和 xdelta。
bsdiff 是基于二进制差分算法。它逐字节比较新旧文件，找出差异。它的压缩率很高，但有个缺点——内存消耗大。我曾经在一个只有256MB RAM的ECU上跑bsdiff的补丁应用，结果直接OOM了。所以，如果你的目标硬件资源紧张，用bsdiff要小心。
xdelta 则基于VCDIFF标准。它的内存占用比bsdiff小得多，而且支持流式处理。我个人的经验是：对于资源受限的MCU，优先选xdelta。虽然它的压缩率略低于bsdiff，但稳定性更重要。
避坑指南：
我曾经在一个项目中，用bsdiff给一个Bootloader做增量包。本地测试一切正常，但量产后发现部分车辆升级失败。排查了三天，最后发现是ECU的Flash磨损导致某些扇区读取速度变慢，bsdiff的差分算法对时序敏感，超时了。后来换成xdelta，问题解决。
所以，增量算法不是越强越好，而是要匹配你的硬件特性。
来看一个实际的增量包制作命令示例：
# 使用 bsdiff 制作增量包
bsdiff old_firmware.bin new_firmware.bin delta.patch
# 使用 xdelta 制作增量包
xdelta3 -e -s old_firmware.bin new_firmware.bin delta.vcdiff
# 应用增量包（以 xdelta 为例）
xdelta3 -d -s old_firmware.bin delta.vcdiff new_firmware.bin
嗯，这里要注意：增量包依赖旧版本。如果车辆的当前版本和制作增量包时的基准版本不一致，补丁就打不上。所以，你的OTA服务器必须记录每台车的当前版本号，然后精准下发对应的增量包。
3.3 数字签名与验签流程：RSA vs ECDSA
升级包做好了，也压缩了。但你能保证它没被篡改过吗？
你想想看，如果攻击者在下载过程中替换了你的升级包，把恶意固件刷进了ECU……后果不堪设想。所以，数字签名是OTA安全的最后一道防线。
目前主流的签名算法有两种：RSA 和 ECDSA。
RSA 是老牌选手，应用广泛。它的安全性基于大整数分解的难度。RSA的优点是理解门槛低，很多硬件加密模块（HSM）都原生支持。但它的缺点是密钥长度长（2048位起步），签名体积大，计算速度慢。
ECDSA 是基于椭圆曲线密码学。它用更短的密钥（256位）就能达到和RSA 3072位相当的安全等级。签名体积小，计算速度快。我最近几年做的项目，全部转向了ECDSA。为什么？因为车端ECU的资源太宝贵了，能省一点是一点。
我的建议：
- 如果你们的HSM只支持RSA，或者有合规要求（比如某些国密场景），用RSA 2048位以上。
- 如果是新项目，没有历史包袱，直接上ECDSA with P-256或P-384曲线。
- 密钥长度不是越长越好。RSA 4096位虽然安全，但签名验签慢得让人抓狂。
来看一个完整的签名与验签流程：
# 1. 生成密钥对（以 ECDSA P-256 为例）
openssl ecparam -genkey -name prime256v1 -out private.pem
openssl ec -in private.pem -pubout -out public.pem
# 2. 计算升级包的哈希值
sha256sum upgrade.swu > upgrade.swu.sha256
# 3. 对哈希值进行签名
openssl dgst -sha256 -sign private.pem -out upgrade.swu.sig upgrade.swu
# 4. 打包：将升级包、签名、公钥（或证书）打包成最终的分发包
# 这一步通常由OTA服务器完成
# 5. 车端验签（伪代码）
# 读取公钥 -> 读取签名 -> 计算本地哈希 -> 验签
# openssl dgst -sha256 -verify public.pem -signature upgrade.swu.sig upgrade.swu
警告：
私钥是命根子。我曾经见过一个团队，把签名私钥直接硬编码在CI/CD脚本里，结果代码仓库被拖库，私钥泄露。所有已售车辆的OTA安全瞬间归零。
正确的做法：
- 私钥存储在离线HSM或密钥管理服务（KMS）中。
- 签名过程在隔离的构建环境中执行。
- 车端只存储公钥，且公钥必须烧写在只读区域（如OTP或eFuse）。
最后，总结一下验签的完整流程：
- 车端下载升级包和签名文件。
- 车端从安全存储区读取公钥。
- 车端计算升级包的SHA256哈希值。
- 车端使用公钥对签名进行解密，得到原始的哈希值。
- 比较两个哈希值。如果一致，验签通过；否则，拒绝安装。
嗯，这一章的内容就到这里。升级包制作看似简单，但里面的坑不少。格式选错了，后面改起来很痛苦；增量算法没选对，车端跑不起来；签名流程没设计好，安全形同虚设。希望我的这些经验能帮你少走弯路。
下一章，我们聊聊升级包的存储与分发策略。到时候见。