4、固件包管理：版本号、差分升级与安全签名
好，咱们进入第四章。这一章聊的是固件包管理，说白了就是怎么管好你的升级包。我做了这么多年嵌入式，见过太多因为版本号混乱导致设备变砖的案例。嗯，咱们一个一个来拆解。
4.1 固件版本号管理策略
版本号这东西，看着简单，坑却不少。我个人习惯用三段式：主版本号.次版本号.修订号。举个例子：V2.1.3。
- 主版本号：大功能变更，不兼容旧版时递增。比如从V1.x升级到V2.x，意味着API或协议变了。
- 次版本号：新增功能，但向后兼容。比如V2.1加了新指令，旧设备还能用。
- 修订号：Bug修复或小优化。比如V2.1.3修复了内存泄漏。
我在项目中遇到过一个问题：某次OTA升级，设备端版本号是V2.1.3，服务器端却写成了V2.1.30。你猜怎么着？设备认为V2.1.3比V2.1.30大，因为字符串比较时3大于30？不对，是3小于30，所以设备拒绝升级。后来我强制要求版本号必须用整数比较，不能直接比字符串。
核心建议：版本号在固件中存储为三个独立整数（uint16_t），比较时逐段比较数值大小。别偷懒用字符串。
小技巧：我习惯在固件头部放一个结构体，包含版本号、编译时间、Git Commit ID。这样出问题时能快速定位。
// 版本号结构体示例
typedef struct {
uint16_t major;
uint16_t minor;
uint16_t patch;
uint32_t build_time; // Unix时间戳
char commit_id[8]; // Git短哈希
} firmware_version_t;4.2 差分升级 vs 全量升级
全量升级，就是把整个固件包发过去。差分升级，只发变化的部分。你想想看，一个1MB的固件，每次只改了几行代码，全量发是不是很浪费？
| 对比项 | 全量升级 | 差分升级 |
|---|---|---|
| 传输数据量 | 大（整个固件） | 小（仅差异部分） |
| 实现复杂度 | 低 | 高（需要差分算法） |
| 设备端资源 | 需要足够Flash存新固件 | 需要额外RAM做差分还原 |
| 适用场景 | 首次升级、版本跨度大 | 频繁小版本更新 |
| 失败风险 | 低 | 中（依赖旧固件完整性） |
我曾经在一个NB-IoT项目里用过差分升级。设备每次只上报几十KB的数据，省流量效果很明显。但有一次，设备端的旧固件被意外擦除了部分区域，差分还原时直接崩溃。嗯，这里要注意：差分升级必须保证旧固件完整且未被篡改。
避坑指南：我曾经在差分升级中犯过一个错——没有做版本兼容性检查。设备从V1.0直接跳到V2.0，差分算法根本算不出来。后来我加了一条规则：差分升级只允许相邻版本之间进行，跨版本必须全量升级。
4.3 固件包的签名与加密
安全这块，我把它分成三层：完整性校验、来源认证、内容保密。咱们一个一个说。
4.3.1 哈希校验（完整性）
最简单的做法：计算固件的SHA256哈希值，和设备端算出来的对比。如果一致，说明固件没被篡改。
# 服务器端生成固件包时
sha256sum firmware.bin > firmware.bin.sha256
# 设备端校验
uint8_t expected_hash[32];
uint8_t actual_hash[32];
sha256_calculate(firmware_data, firmware_size, actual_hash);
if (memcmp(expected_hash, actual_hash, 32) == 0) {
// 校验通过
} else {
// 固件被篡改，拒绝升级
}但哈希校验有个问题：它只能保证数据没变，不能保证数据是谁发的。黑客可以替换固件包和哈希值，设备照样能通过校验。所以需要签名。
4.3.2 RSA/ECDSA签名（来源认证）
签名的作用是：证明这个固件包确实来自你信任的服务器。我个人更推荐ECDSA，因为它密钥更短、计算更快。在资源受限的MCU上，ECDSA比RSA快一个数量级。
签名流程：服务器用私钥对固件的哈希值签名 → 设备用公钥验证签名。公钥提前烧录在设备中，不可更改。
// 服务器端签名（伪代码）
uint8_t hash[32];
sha256_calculate(firmware, size, hash);
ecdsa_sign(private_key, hash, signature);
// 设备端验签
uint8_t hash[32];
sha256_calculate(firmware, size, hash);
if (ecdsa_verify(public_key, hash, signature) == 0) {
// 签名有效，固件来源可信
} else {
// 签名无效，可能被篡改或伪造
}我在一个智能门锁项目里用过ECDSA。当时选的是secp256r1曲线，签名长度64字节，验签时间在STM32F4上大约30ms。嗯，这个性能完全可以接受。
我的习惯：公钥在产线烧录时写入OTP区域（一次性可编程），防止被替换。私钥保存在HSM（硬件安全模块）或离线服务器上，绝不出现在任何网络可达的机器上。
4.3.3 加密（内容保密）
签名解决的是「谁发的」，加密解决的是「谁能看」。如果固件里包含算法或敏感配置，建议用AES-128-GCM加密。GCM模式自带认证，能同时保证机密性和完整性。
// 加密流程
aes_gcm_encrypt(key, iv, firmware, ciphertext, tag);
// 解密流程
aes_gcm_decrypt(key, iv, ciphertext, tag, plaintext);但说实话，大部分IoT场景不需要加密固件。你想想看，攻击者拿到固件又能怎样？他得先破解签名才能刷进去。我一般只在金融支付类设备上启用加密。
重要提醒：加密和签名是两回事。别以为加密了就不需要签名。我曾经见过一个方案，只加密不签名，结果攻击者虽然解不了密，但可以重放旧版本固件（回滚攻击）。所以我的建议是：先签名，再加密，或者直接用GCM这种同时提供认证和加密的模式。
4.4 综合方案建议
说了这么多，给一个我常用的方案组合：
- 版本号：三段式整数，存储在固件头部结构体。
- 升级方式：首次或跨版本用全量，小版本迭代用差分（需做版本兼容检查）。
- 安全校验：SHA256哈希 + ECDSA签名（推荐secp256r1）。
- 可选加密：AES-128-GCM，仅用于敏感设备。
这套方案我在三个量产项目里验证过，累计超过50万台设备，没出过安全问题。当然，安全是动态的，算法会过时，密钥会泄露。定期审视你的安全策略，别一套方案用十年。
好，这一章就到这里。下一章咱们聊聊升级过程中的异常处理和回滚机制——嗯，那才是真正考验系统健壮性的地方。