3、升级包制作与管理：升级包的组成结构、差分升级算法原理、升级包的签名与加密
好，咱们进入第三章。这一章聊的是升级包本身——说白了，就是那个要往车机里塞的“包裹”到底长什么样，怎么让它变小，怎么保证它没被人动过手脚。
我在做第一个车载项目时，对升级包的理解就是“把固件打个包扔进去”。结果呢？升级包太大，下载到一半网络断了，车机变砖。嗯，从那以后，我再也不敢小看这个“包裹”的设计了。
3.1 升级包的组成结构
一个标准的车载OTA升级包，不是简单的二进制文件。它更像一个“集装箱”，里面分门别类装好了各种东西。我个人习惯把它拆成三层来看：
- 元数据层：描述这个包是谁的、给哪个ECU、版本号多少、依赖什么前置版本。
- 载荷层：真正的升级数据。可能是完整镜像，也可能是差分补丁。
- 安全层：签名、哈希值、加密信息。用来验证包的真伪和完整性。
你想想看，如果元数据里写错了ECU ID，那升级包就可能刷到隔壁的模块上去了。我在项目中就遇到过这种事——一个同事把网关和座舱域的ID搞反了，结果升级完，空调控制界面跑到了仪表盘上。嗯，那场面挺尴尬的。
一个典型的升级包结构，用JSON描述大概是这样：
{
"package_id": "OTA-2024-0315-001",
"target_ecu": "IVI_MAIN",
"hw_version": "HW-2.1",
"sw_version_from": "2.0.3",
"sw_version_to": "2.1.0",
"payload_type": "delta", // 或 "full"
"payload": {
"size": 245760,
"hash": "sha256:abc123...",
"data": [二进制数据]
},
"signature": {
"algorithm": "ECDSA-P256",
"value": "30450221..."
}
}
核心要点：元数据里的版本依赖关系一定要写清楚。我曾经见过一个升级包，从2.0.3升到2.1.0，但用户当前是2.0.2，结果差分补丁打不上，车机直接卡在恢复模式。所以，前置版本校验是升级包的第一道防线。
3.2 差分升级算法原理
为什么要做差分？说白了，就是省流量。一个完整的车机固件动辄几百MB，甚至上GB。如果每次升级都全量下载，用户的流量套餐怕是扛不住。差分升级只传输“变化的部分”，通常能压缩到原大小的5%-20%。
目前主流的差分算法，我接触过的有三种：
| 算法 | 原理 | 适用场景 | 压缩率 |
|---|---|---|---|
| bsdiff | 基于后缀排序，找最长公共子串 | 二进制文件差异大时效果好 | 高 |
| hdiffpatch | 基于哈希匹配，速度快 | 嵌入式设备，内存受限 | 中 |
| xdelta | 基于VCDIFF标准，通用性强 | 文件系统级别的差分 | 中高 |
我个人在车载项目里用得最多的是 bsdiff。为什么？因为车机固件每次改动其实不大，但二进制布局变化可能很大。bsdiff对这种场景的压缩率最好。不过它有个缺点——内存占用高。我记得有一次在低端MCU上跑bsdiff的合并过程，直接OOM了。后来换成了hdiffpatch，虽然压缩率差一点，但至少跑得稳。
差分升级的核心流程，其实就三步：
- 生成差分：在云端服务器，拿旧版本和新版本做对比，生成一个补丁文件。
- 传输补丁：把补丁文件下发到车机，而不是整个新固件。
- 合并还原：车机端用旧固件 + 补丁，合并出完整的新固件。
这里有个坑——合并过程不能断电。我曾经在测试时故意在合并到一半时断电，结果旧固件和新固件都坏了，车机彻底变砖。后来我们加了一个“双备份”机制：合并时先把补丁写到临时分区，合并完成并校验通过后，再替换主分区。
小技巧：差分算法对内存敏感。如果你的车机只有64MB RAM，建议把补丁分块处理，每块256KB，逐块合并。这样峰值内存可以控制在1MB以内。
3.3 升级包的签名与加密
升级包在传输过程中，最怕什么？怕被人篡改。你想啊，如果有人截获了升级包，往里面塞了一段恶意代码，然后刷到车机上……那后果不堪设想。所以，签名和加密是OTA安全的基石。
签名和加密是两回事，别搞混了：
- 签名：保证包是谁发的，有没有被篡改。用的是非对称密钥（私钥签名，公钥验签）。
- 加密：保证包的内容不被偷看。用的是对称密钥（AES等）加密载荷，非对称密钥加密对称密钥。
我建议的流程是这样的：
- 在云端，用私钥对升级包的哈希值进行签名。
- 用AES-256-GCM加密升级包的载荷部分。
- 把签名、加密后的载荷、加密用的对称密钥（用公钥加密后）一起打包。
- 车机端收到后，先用私钥解密对称密钥，再用对称密钥解密载荷，最后用公钥验签。
代码示例（伪代码，展示核心逻辑）：
// 云端签名
hash = SHA256(payload)
signature = ECDSA_Sign(private_key, hash)
// 云端加密
aes_key = random(32)
encrypted_payload = AES256_GCM_Encrypt(aes_key, payload)
encrypted_aes_key = RSA_Encrypt(public_key, aes_key)
// 打包
package = {
encrypted_payload,
encrypted_aes_key,
signature
}
// 车机端验签
aes_key = RSA_Decrypt(private_key, encrypted_aes_key)
payload = AES256_GCM_Decrypt(aes_key, encrypted_payload)
hash = SHA256(payload)
is_valid = ECDSA_Verify(public_key, hash, signature)
警告：千万不要把私钥放在车机端！我见过一个项目，为了“方便调试”，把签名私钥硬编码在了车机代码里。结果呢？攻击者反编译后，直接用这个私钥签了一个恶意升级包，刷遍了整个车队。嗯，那个项目后来被召回整改了。
还有一个容易被忽略的点——密钥轮换。车机出厂时烧录的公钥，不能一成不变用十年。万一私钥泄露了呢？所以，OTA协议里要支持密钥更新。我习惯的做法是：在升级包里附带一个新的公钥，用旧私钥签名后下发。车机验签通过后，更新本地存储的公钥。这样就能实现密钥的平滑轮换。
最后说一句，签名算法我推荐用 ECDSA（椭圆曲线数字签名算法），而不是RSA。为什么？因为ECDSA的签名更短，对车机这种存储和带宽都受限的场景更友好。256位的ECDSA，安全等级相当于3072位的RSA，但签名长度只有64字节。你想想看，省下来的空间能多放多少升级数据？
好，这一章就到这里。升级包的结构、差分算法、安全机制，这三块是OTA的核心。下一章我们聊聊升级策略——什么时候升、怎么升、失败了怎么办。