4. 升级包制作与签名

OTA 升级能否安全、稳定地落地，很大程度上取决于升级包本身。升级包不只是把新固件“压缩一下”，它需要经过打包、差分、签名、加密校验和版本管理五个关键环节。任何一个环节设计不当，都可能导致升级失败、设备变砖，甚至被恶意固件劫持。本节围绕升级包从生成到可被设备安全接收的完整链路展开。

一、核心原理：升级包是一份“可验证的契约”

升级包的本质，是设备与云端之间的一份契约：云端声明“这是版本 V2.3.1 的合法固件”，设备则通过密码学手段验证这份声明是否可信。因此升级包通常由三部分组成：

• 载荷（Payload）：完整固件或差分补丁，是真正要写入 Flash 的数据。
• 元数据（Metadata）：版本号、目标硬件型号、分区布局、大小、哈希值、时间戳等。
• 签名（Signature）：对元数据与载荷摘要的私钥签名，供设备用公钥验签。

设备端升级流程可概括为：接收升级包 → 校验签名 → 校验哈希 → 解密（如启用）→ 写入备份分区 → 重启切换 → 回滚保护。只有签名和哈希都通过，才允许写入，这是防止恶意固件的第一道防线。

二、方法流程：从固件到可发布升级包

一个可发布的升级包，通常按以下步骤生成：

1. 确定目标版本与兼容范围：明确目标硬件型号、当前基线版本、分区表版本，避免跨硬件刷入。
2. 生成差分补丁：若设备已有旧版本，优先使用差分升级，减少下载体积。常用工具为 bsdiff、hdiffpatch 或自研块级差分。
3. 封装元数据：写入版本号、目标型号、分区偏移、载荷长度、哈希算法等字段。
4. 计算摘要并签名：对元数据与载荷计算 SHA-256，再用私钥签名，生成签名块。
5. 可选加密：对载荷使用 AES 加密，密钥可由设备唯一密钥或云端下发密钥派生。
6. 生成发布包并入库：输出 .ota 文件，记录版本、哈希、签名、发布时间，进入版本管理库。

下面是一个典型的打包命令示例，展示差分、签名与元数据写入过程：

# 1. 生成差分补丁
hdiffpatch -s old_fw.bin new_fw.bin patch.bin

# 2. 计算载荷哈希
sha256sum patch.bin > patch.sha256

# 3. 生成元数据
cat > meta.json <<EOF
{
  "version": "2.3.1",
  "target": "OTA-BOARD-A",
  "base_version": "2.2.0",
  "payload": "patch.bin",
  "hash": "sha256:9f2c...",
  "partition": "app",
  "timestamp": 1735689600
}
EOF

# 4. 私钥签名
openssl dgst -sha256 -sign private.pem -out meta.sig meta.json

# 5. 打包
tar -czf firmware_v2.3.1.ota meta.json meta.sig patch.bin

三、案例/场景：差分升级与签名校验的配合

某车载 OTA 项目需要将 2.2.0 升级到 2.3.1，完整固件为 48 MB，差分补丁仅 3.2 MB。若直接下发完整包，在弱网环境下下载耗时约 6 分钟；使用差分后，下载时间缩短到 25 秒左右。但差分包必须与基线版本严格匹配，否则补丁无法应用。

因此设备端在应用差分前，会先校验当前运行版本的哈希是否与元数据中的 base_version 一致。若不一致，则拒绝差分，回退到完整包升级。签名校验则保证补丁来源可信，防止中间人替换补丁内容。实际日志如下：

[OTA] recv pkg: firmware_v2.3.1.ota
[OTA] verify signature: OK
[OTA] base version check: 2.2.0 == 2.2.0, OK
[OTA] apply patch: 3.2MB -> 48MB
[OTA] hash check: OK
[OTA] write backup slot: OK
[OTA] set boot flag: try
[OTA] reboot to apply

四、误区与复盘：升级包制作中的常见坑

复盘时建议建立升级包检查清单，确保每个包在发布前都经过以下验证：