3. 升级包制作与管理：差分升级算法、全量升级包、升级包签名与加密

好，咱们进入第三章。这一章聊的是升级包的“生产”和“管理”。说白了，就是你要把新版本的软件，做成一个能让车机安全、高效吃下去的“药丸”。

我个人习惯把升级包分为两类：全量包和差分包。全量包好理解，就是把整个系统镜像打包。差分包呢？只包含新旧版本之间的差异部分。你想想看，一个车载系统动辄几个GB，每次升级都下载全量包，流量和时间都受不了。所以差分升级在OTA里是绝对的主流。

3.1 差分升级算法：bsdiff 与 xdelta

差分算法的核心任务，就是找出两个二进制文件之间的差异，生成一个尽可能小的补丁文件。业界最常用的两个算法是 bsdiff 和 xdelta。

• bsdiff：基于后缀排序的算法，压缩率极高。特别适合二进制文件，比如固件镜像、库文件。我在项目中遇到过，一个 500MB 的镜像，用 bsdiff 生成的差分包只有 20MB 左右。
• xdelta：基于 VCDIFF 标准，速度更快，但压缩率略逊于 bsdiff。适合对实时性要求高的场景，比如车内局域网的快速升级。

嗯，这里要注意：差分算法对内存和CPU的消耗都不小。尤其是在车端做差分还原时，如果ECU的算力有限，可能会卡死。我曾经在一个老款T-Box上做测试，bsdiff还原时内存直接爆了。后来我换成了xdelta，虽然包大了点，但至少跑得稳。

下面是一个简单的差分包生成命令示例（bsdiff）：

# 生成差分补丁
bsdiff old_firmware.bin new_firmware.bin patch.bin

# 在车端还原
bspatch old_firmware.bin updated_firmware.bin patch.bin

为什么推荐 bsdiff？因为它对二进制文件的相似性利用得特别好。你想想看，两个版本的固件，大部分代码其实没变，只是改了几个函数。bsdiff 能精准地只记录这些变化。

3.2 全量升级包：什么时候用？

全量包虽然大，但并非一无是处。我建议在以下场景使用全量包：

• 首次升级：车辆出厂后第一次OTA，或者从极老的版本直接跳到最新版。这时候差分链太长，不如直接全量。
• 系统恢复：当车机系统崩溃，需要刷写完整镜像时。差分包依赖旧版本，如果旧版本已经损坏，差分还原会失败。
• 安全关键升级：比如刹车系统、转向系统的固件升级。全量包可以确保每个字节都是正确的，避免差分还原出错。

全量包的制作相对简单，就是把整个文件系统或分区镜像打包。但要注意，全量包通常需要压缩。我习惯用 gzip 或 lz4，前者压缩率高，后者解压速度快。

# 制作全量升级包
tar czf full_update.tar.gz rootfs/

3.3 升级包签名：防篡改的第一道防线

升级包在传输过程中，可能会被中间人攻击。你想想看，如果黑客篡改了升级包，把恶意代码刷进车机，后果不堪设想。所以，签名是必须的。

签名流程很简单：

1. 用哈希算法（如 SHA-256）计算升级包的摘要。
2. 用私钥对摘要进行加密，生成签名。
3. 将签名和升级包一起下发。
4. 车端用公钥解密签名，比对摘要是否一致。

这里有个坑：私钥一定要保管好。我曾经见过一个团队，把私钥直接放在代码仓库里，结果被泄露了。整个OTA系统都得重做。嗯，私钥应该放在硬件安全模块（HSM）里，或者至少用密码保护。

# 生成签名
openssl dgst -sha256 -sign private_key.pem -out signature.bin update_package.bin

# 验证签名
openssl dgst -sha256 -verify public_key.pem -signature signature.bin update_package.bin

3.4 升级包加密：保护数据隐私

签名只能防篡改，不能防窃听。如果升级包里包含敏感数据，比如地图数据、用户配置，那就需要加密。

加密通常使用对称加密算法，比如 AES-256。密钥可以通过非对称加密的方式安全分发。具体流程：

• 云端生成一个随机的对称密钥（Session Key）。
• 用这个密钥加密升级包。
• 再用车端的公钥加密这个对称密钥。
• 车端先用私钥解密得到对称密钥，再用它解密升级包。

这种混合加密方式，既保证了效率，又保证了安全。我建议使用 AES-256-GCM 模式，因为它同时提供了加密和完整性校验。

# 加密升级包
openssl enc -aes-256-gcm -salt -in update_package.bin -out encrypted_package.bin -pass file:session_key.bin

# 解密升级包
openssl enc -d -aes-256-gcm -in encrypted_package.bin -out decrypted_package.bin -pass file:session_key.bin

3.5 升级包管理：版本控制与分发策略

升级包做好了，怎么管理？我建议建立一个升级包仓库，包含以下信息：

字段	说明	示例
包名	唯一标识	IVI_v2.1.0
版本号	语义化版本	2.1.0
目标ECU	升级对象	IVI, T-Box
包类型	全量/差分	差分
依赖版本	差分包的基准版本	2.0.0
签名	签名值	0xAB12...
校验和	SHA-256	0xCD34...

分发策略上，我建议采用灰度发布。先让一小批车辆升级，观察没问题了，再全量推送。我曾经因为没做灰度，一个bug导致上千辆车升级失败，最后只能紧急回滚。嗯，从那以后，我再也不敢跳过灰度测试了。

好了，这一章就到这里。下一章我们聊聊升级任务的调度和执行，那才是真正考验系统设计的地方。