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

升级包制作与签名：差分升级包原理、全量包与差分包、签名算法(RSA/ECDSA)、哈希校验(SHA256)

各位好，我是老赵。今天咱们聊聊升级包制作和签名这块硬骨头。说实话，很多团队在OTA上栽跟头，十有八九是升级包没做好，或者签名校验漏了。我见过不止一次，因为差分包打错了补丁，导致设备变砖，最后只能返厂。

嗯，咱们一步步来。先搞清楚全量包和差分包到底有什么区别，再深入差分原理，最后把签名和哈希校验讲透。

全量包 vs 差分包：什么时候用哪个？

先看一张对比表，心里有个底：

对比维度	全量包	差分包
包体大小	大（完整固件）	小（仅差异部分）
升级耗时	长（全量写入）	短（局部修补）
网络消耗	高	低
适用场景	首次升级、跨大版本、设备存储充裕	小版本迭代、带宽受限、频繁升级
制作复杂度	低（直接打包）	高（需差分算法）
失败风险	低（完整覆盖）	中（依赖旧版本基线）

我个人习惯是：大版本用全量，小补丁用差分。你想想看，如果每次改个配置文件都要下载几十兆的全量包，用户流量扛不住，服务器带宽也吃不消。

差分升级包原理：bsdiff 和它的兄弟们

差分升级的核心思想很简单——只传变化的部分。但实现起来，学问可大了。

目前业界最常用的差分算法是 bsdiff，它基于 后缀排序 和 最长公共子串 匹配。说白了，就是把新旧两个固件二进制对齐，找出哪些字节没变、哪些变了、哪些新增了。

我给大家画个流程图，一看就明白：

你看，服务端用 bsdiff 生成差分包，设备端用 bspatch 还原。整个过程，旧固件必须完整且未被篡改，否则还原出来的新固件就是坏的。

⚠️ 避坑指南： 我曾经遇到过一个项目，设备端 flash 有坏块，旧固件读出来已经损坏了，但校验没做。结果 bspatch 还原出来的新固件直接跑不起来。从那以后，我要求所有差分升级前，必须先对旧固件做一次 SHA256 校验，确认基线正确再打补丁。

差分算法的选择：不只是 bsdiff

除了 bsdiff，还有几个常用的差分算法，我列个表对比一下：

算法	压缩率	内存消耗	适用场景
bsdiff	高（通常 5%-15%）	高（需加载新旧固件）	通用固件差分
hdiffpatch	中（10%-20%）	中	大文件差分
courgette	极高（3%-8%）	极高	二进制可执行文件（Chrome 在用）
xdelta3	低（20%-30%）	低	嵌入式资源文件

我个人习惯在嵌入式项目里用 bsdiff，虽然内存消耗大一点，但压缩率最好。如果设备 RAM 只有几十 KB，那就只能退而求其次用 xdelta3 了。

哈希校验：SHA256 是底线

哈希校验是升级包完整性的第一道防线。说白了，就是给升级包算一个「指纹」，设备端收到后重新算一遍，对比指纹是否一致。

为什么用 SHA256 而不是 MD5 或 SHA1？

MD5：已经被证明可以碰撞，不安全。
SHA1：Google 已经演示过碰撞攻击，不推荐。
SHA256：目前没有实际可行的碰撞攻击，是业界最低安全标准。

我给大家看一段生成 SHA256 校验的代码示例：

# 服务端：生成升级包的 SHA256 哈希
import hashlib

def generate_sha256(file_path):
    sha256_hash = hashlib.sha256()
    with open(file_path, "rb") as f:
        # 分块读取，避免大文件内存溢出
        for byte_block in iter(lambda: f.read(4096), b""):
            sha256_hash.update(byte_block)
    return sha256_hash.hexdigest()

# 设备端：校验升级包完整性
def verify_sha256(file_path, expected_hash):
    actual_hash = generate_sha256(file_path)
    if actual_hash != expected_hash:
        raise Exception("哈希校验失败！升级包可能被篡改或损坏。")
    print("哈希校验通过 ✅")

💡 小技巧： 我建议在升级包的元数据中同时存放 全量包哈希 和 差分包哈希。设备端先校验差分包完整性，再校验还原后的全量包完整性。双重校验，双重保险。

签名算法：RSA vs ECDSA

哈希校验只能保证数据没损坏，但不能保证数据来源可信。签名算法就是用来解决这个问题的——确认升级包确实是官方发布的，而不是黑客伪造的。

目前主流的选择有两个：RSA 和 ECDSA。我直接对比一下：

对比维度	RSA (2048位)	ECDSA (P-256)
密钥长度	2048 位	256 位
签名长度	256 字节	64 字节
签名速度	慢	快
验签速度	快	慢
安全强度	高	高（同等安全强度下密钥更短）
嵌入式资源消耗	高（大数运算）	低（椭圆曲线运算）

你想想看，设备端验签是每次升级都要做的，如果设备 CPU 很弱，RSA 验签可能耗时几百毫秒，而 ECDSA 可能只需要几十毫秒。我个人习惯是：服务端签名用 RSA（签名慢但安全），设备端验签用 ECDSA（验签快省资源）。当然，如果设备性能足够，直接用 RSA 也没问题。

签名与校验的完整流程

我把整个流程串起来，大家看看：

服务端：生成升级包 → 计算 SHA256 哈希 → 用私钥对哈希签名 → 打包（升级包 + 哈希 + 签名）→ 分发
设备端：下载升级包 → 计算 SHA256 哈希 → 对比哈希（完整性校验）→ 用公钥验签（来源校验）→ 校验通过后执行升级

这里有个关键点：先校验哈希，再验签。为什么？因为验签的计算量比哈希大得多。如果哈希都过不了，说明数据已经损坏了，没必要再浪费 CPU 去验签。

    🔑 核心原则： 升级包安全 = 哈希校验（完整性）+ 数字签名（真实性）。缺一不可。

避坑指南：我踩过的三个坑

最后，分享几个我亲身经历过的教训：

坑一：签名密钥硬编码在代码里。我曾经接手过一个项目，私钥直接写在源码里，还上传到了 Git 仓库。嗯，后果可想而知。正确的做法是：私钥放在硬件安全模块（HSM）或密钥管理服务中，设备端公钥放在安全存储区（如 eFuse 或 TEE）。
坑二：签名算法不指定哈希算法。有些工程师直接用 RSA 签名原始数据，而不是签名哈希。这会导致签名长度和原始数据一样长，而且安全性降低。正确的做法是：先哈希，再签名。
坑三：差分升级不校验基线版本。我遇到过设备端旧固件版本和服务端预期的不一致，结果 bspatch 还原出来的固件直接崩溃。从那以后，我要求差分包元数据里必须包含 源版本哈希，设备端先确认自己跑的确实是那个版本，再打补丁。

好了，升级包制作与签名这块，核心内容就这些。记住：全量包保底，差分包提效，SHA256 保完整，RSA/ECDSA 保真实。把这四样用好，你的 OTA 升级就稳了一大半。