📚 课程目录第3章升级包制作与签名

3、升级包制作与签名：差分升级包生成、全量升级包制作、数字签名与验签机制

升级包制作，是整个OTA流程里最核心的环节之一。说白了，你前面网络传得再快、设备端协议再稳，要是升级包本身有问题，那一切都白搭。我这些年见过太多“升级失败”的案例，追根溯源，十有八九是包没做对。

这一章，咱们就聚焦在三个关键动作上：差分包怎么生成、全量包怎么做、签名验签怎么落地。嗯，顺序很重要——先搞清楚包的结构，再给它上锁。

3.1 全量升级包制作

全量升级包，顾名思义，就是把整个固件镜像打包成一个完整的升级文件。设备拿到它，直接擦除旧分区，写入新数据。简单粗暴，但可靠。

我在项目里常用的打包流程是这样的：

编译固件：生成目标平台的二进制镜像，比如 firmware.bin。
添加元信息：在包头部写入版本号、硬件平台、校验和、包大小等字段。
压缩（可选）：对镜像进行gzip或lzma压缩，减少传输体积。
计算校验值：对整个包做SHA-256哈希，写入包头或单独字段。
签名：用私钥对哈希值签名，生成签名块。
封装：将包头、镜像数据、签名块拼接成最终文件。

全量包结构示意

+-------------------+------------------+------------------+
|   包头 (Header)   |   镜像数据 (Data) |   签名块 (Sig)   |
+-------------------+------------------+------------------+
| 魔数 | 版本 | 长度 | 压缩后的固件内容  | 签名算法 | 签名值 |
| 校验和 | 硬件ID |   |                  |          |        |
+-------------------+------------------+------------------+

你可能会问：“全量包这么大，每次都传整个镜像，不浪费流量吗？” 没错，所以差分升级才登场。

3.2 差分升级包生成

差分升级的核心思想是：只传输新旧版本之间的差异部分。设备端拿到差分包后，结合本地旧版本，还原出新版本。

常用的差分算法有 bsdiff、hdiffpatch、xdelta 等。我个人习惯用 bsdiff，它在二进制差异处理上表现很稳。

生成差分包的基本步骤：

准备新旧镜像：旧版本 v1.0.bin，新版本 v2.0.bin。
运行差分工具：bsdiff v1.0.bin v2.0.bin patch.bin。
验证差分包：用 bspatch 在本地还原，确认结果与 v2.0.bin 一致。
封装差分包：在差分包头部加入源版本号、目标版本号、校验信息。

经验之谈：差分包的体积通常只有全量包的 10%~30%。但要注意，如果新旧版本差异过大（比如换了文件系统），差分包可能比全量包还大。这时候，我建议直接走全量升级，别硬差分。

我曾经在一个IoT项目里遇到过坑：差分包在实验室测试一切正常，但到了现场，部分设备死活还原失败。查了两天，最后发现是设备端的旧版本镜像有细微的坏块，导致差分算法计算偏移出错。从那以后，我在差分包生成前，一定会先对旧镜像做一次完整性校验。

3.3 数字签名与验签机制

升级包做好了，怎么保证它没被篡改？怎么确认它确实来自官方？答案就是数字签名。

签名验签的流程，我习惯用一张图讲清楚：

流程其实不复杂：

签名：对升级包做哈希，然后用私钥加密哈希值，得到签名。
验签：设备用公钥解密签名，得到原始哈希；再对收到的包做同样的哈希运算，对比两个哈希值。一致则通过。

重要提醒：私钥必须保存在安全的服务器上，绝对不能随升级包下发。公钥可以预埋在设备固件中，但建议做防篡改保护，比如放在安全存储区或使用硬件安全模块（HSM）。

3.4 签名算法选型对比

选什么签名算法？我整理了一张对比表，方便你决策：

算法	签名长度	计算开销	安全性	适用场景
RSA-2048	256 字节	中等	高	通用场景，兼容性好
ECDSA P-256	64 字节	低	高	资源受限设备，签名短
Ed25519	64 字节	极低	极高	高性能需求，现代设备
SM2	64 字节	低	高（国密）	国内合规场景

我个人偏好 ECDSA 或 Ed25519。为什么？签名短、计算快，对MCU友好。RSA虽然成熟，但签名太长，在窄带物联网场景下传输压力大。

3.5 验签的工程落地细节

理论讲完了，咱们聊聊实际代码怎么写。下面是一个简化的验签流程伪代码：

// 设备端验签函数
int verify_ota_package(uint8_t *package, uint32_t pkg_len, uint8_t *signature) {
    // 1. 从安全存储区读取公钥
    uint8_t public_key[64];
    read_public_key_from_secure_storage(public_key);

    // 2. 对升级包数据做哈希
    uint8_t hash[32];
    sha256(package, pkg_len, hash);

    // 3. 用公钥解密签名，得到原始哈希
    uint8_t decrypted_hash[32];
    ecdsa_verify(public_key, signature, decrypted_hash);

    // 4. 对比两个哈希
    if (memcmp(hash, decrypted_hash, 32) == 0) {
        return VERIFY_SUCCESS;  // 验签通过
    } else {
        return VERIFY_FAILED;   // 验签失败，拒绝升级
    }
}

避坑指南：我曾经在一个项目里，验签函数跑在中断上下文里，结果哈希计算耗时太长，导致系统看门狗超时复位。后来我把验签放到任务级线程中，并加了进度反馈，问题就解决了。记住：验签操作要放在非关键路径上，别阻塞主流程。

3.6 升级包制作的完整流程总结

最后，我把整个升级包制作到验签的流程串起来，方便你对照落地：

编译：生成新固件镜像。
选择包类型：全量包 or 差分包？根据网络带宽和设备存储决定。
打包：生成升级包文件，包含包头、数据、校验信息。
签名：用私钥对包做数字签名。
发布：将签名后的升级包上传到OTA服务器。
下载：设备下载升级包。
验签：设备用公钥验证签名，失败则丢弃。
升级：验签通过后，执行升级流程。

嗯，这一套流程走下来，升级包的安全性和可靠性就有了基本保障。你想想看，如果少了签名这一步，攻击者随便伪造一个恶意包就能刷进设备，那后果不堪设想。