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

好，咱们进入第三章。升级包怎么造、怎么管，这是OTA系统里最实在的活儿。我见过不少团队，车都量产了，升级包管理还是一团乱麻——差分算法选错，包体签名漏掉，结果升级到一半被安全网关拦截。嗯，今天咱们就把这些坑一个个填上。

3.1 全量升级包 vs 差分升级包

先搞清楚两个基本概念。全量升级包，就是把整个系统镜像完整打包，不管新旧版本差多少。差分升级包，只记录新旧版本之间的差异部分。

我个人习惯：首次量产或跨大版本（比如从 Android 10 升到 12）用全量包，日常小版本迭代用差分包。你想想看，每次几百兆的流量走蜂窝网络，用户不投诉才怪。

3.2 差分升级算法：bsdiff、hdiffpatch 与 xdelta3

差分算法是升级包制作的核心。目前主流的有三种，我一个个说。

3.2.1 bsdiff

bsdiff 是 Colin Percival 在 2003 年提出的算法，基于后缀排序。它生成的差分包压缩率极高，但内存消耗也大。我在一个车机项目里用过，旧版本 512MB，新版本 530MB，差分包只有 18MB——压缩率 96.5%。

但代价是什么？制作时内存峰值接近 1.5GB，低端 MCU 根本跑不动。所以 bsdiff 适合服务器端制作，不适合在嵌入式设备上直接生成差分。

# 制作差分包
bsdiff old_firmware.bin new_firmware.bin patch.bin

# 应用差分包
bspatch old_firmware.bin updated_firmware.bin patch.bin

3.2.2 hdiffpatch

hdiffpatch 是腾讯开源的差分算法，专门针对嵌入式场景优化。它的内存占用比 bsdiff 低 40%~60%，而且支持大文件分块处理。

我记得有一次，客户要求差分包必须在 64MB RAM 的芯片上应用。bsdiff 直接跪了，hdiffpatch 跑得稳稳的。如果你做的是 IoT 设备或低端车机，我建议优先考虑 hdiffpatch。

3.2.3 xdelta3

xdelta3 基于 VCDIFF 标准，是三者中最轻量的。它适合文件级别的差分，而不是块设备级别的镜像差分。如果你只更新某个分区里的几个文件，xdelta3 是首选。

# 制作文件级差分
xdelta3 -e -s old_file.bin new_file.bin delta.xd3

# 应用文件级差分
xdelta3 -d -s old_file.bin delta.xd3 new_file.bin

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

升级包如果不签名，就等于把系统大门敞开。攻击者只要中间人攻击，替换掉升级包，就能植入恶意固件。我在 2019 年参与过一个安全审计项目，发现某厂商的 OTA 包连基本签名都没有——嗯，那是我见过最离谱的事。

3.3.1 签名流程

1. 计算哈希：对升级包内容计算 SHA-256 或 SHA-512 哈希值。
2. 私钥签名：用 OTA 签名私钥对哈希值进行 RSA 或 ECDSA 签名。
3. 打包签名信息：将签名值、证书链、签名算法标识写入升级包头部。

# 1. 计算升级包哈希
openssl dgst -sha256 -binary update_package.bin > package.hash

# 2. 使用私钥签名
openssl pkeyutl -sign -inkey ota_private.pem \
  -in package.hash -out signature.bin

# 3. 将签名附加到升级包尾部
cat update_package.bin signature.bin > signed_package.bin

3.3.2 验签流程（设备端）

1. 从升级包中提取签名值和证书链。
2. 用根证书公钥验证证书链有效性。
3. 用证书公钥验签，比对哈希值。
4. 验签通过才允许进入升级流程。

3.4 升级包加密：防泄密的第二道防线

签名防篡改，加密防泄密。有些固件包含核心算法或商业机密，明文传输风险太大。加密通常使用对称加密（AES-256-GCM），密钥由设备端的安全存储区提供。

3.4.1 加密流程

3.5 升级包管理：版本、元数据与回滚策略

包做好了，怎么管？我见过最乱的项目，升级包散落在 FTP 服务器上，文件名是 "final_v2.bin"、"final_v2_final.bin"——你懂的，版本管理灾难。

3.5.1 升级包元数据

每个升级包必须包含完整的元数据，我建议至少包括以下字段：

{
  "package_id": "OTA-2024-03-15-001",
  "product": "IVI_Gen3",
  "hw_version": "3.2.0",
  "sw_version_from": "2.1.0",
  "sw_version_to": "2.2.0",
  "package_type": "delta",
  "algorithm": "hdiffpatch",
  "hash_algorithm": "SHA-256",
  "hash_value": "a1b2c3d4...",
  "signature_algorithm": "ECDSA-P256",
  "signature_value": "e5f6g7h8...",
  "encryption_algorithm": "AES-256-GCM",
  "encrypted_key": "i9j0k1l2...",
  "release_date": "2024-03-15",
  "compatibility_list": ["IVI_Gen3_RevA", "IVI_Gen3_RevB"]
}

3.5.2 版本兼容性矩阵

升级不是随便升的。硬件版本、中间件版本、依赖组件版本都要匹配。我习惯用一张兼容性矩阵表来管理：

3.5.3 回滚策略

升级失败怎么办？必须能回滚。我建议保留最近两个可用版本的备份。回滚时，设备端从备份分区加载旧版本，同时云端标记该设备回滚事件。

3.6 本章知识结构图

下面这张图把升级包制作与管理的核心流程串起来了。你可以把它当作本章的思维导图。

这张图从左到右、从上到下，把升级包从类型选择到生命周期管理串了一遍。你写代码、做方案时，可以拿它当检查清单——看看自己卡在哪一层。