升级包完整性校验：哈希校验与签名校验

各位工程师，咱们接着聊OTA升级。上一章我们讲了升级包的版本管理，今天要聊的，是升级包完整性校验。说白了，就是怎么保证你下载到设备上的那个包，是原厂出的、没被人动过手脚的。

我见过不少团队，前期觉得校验这步可有可无，结果产品上市后出了大问题。嗯，今天咱们就把这块彻底讲透。

为什么需要完整性校验？

先问个问题：升级包在传输过程中，可能发生什么？

• 传输错误：网络丢包、存储介质坏块，导致数据损坏
• 恶意篡改：中间人攻击，替换成带后门的固件
• 版本混淆：下载了错误版本，导致设备变砖

我当年做智能电表项目时，就遇到过升级包在CDN节点上被缓存损坏的情况。设备升级后直接死机，最后派了20个人去现场刷机。从那以后，我再也不敢跳过校验环节。

哈希校验：快速检测数据完整性

哈希校验，是最基础的完整性检查。它把任意长度的数据，映射成固定长度的摘要。只要原始数据改了一个bit，摘要就会完全不一样。

MD5 vs SHA256：怎么选？

哈希校验的典型流程是这样的：

1. 服务端计算升级包的哈希值，写入升级包元数据
2. 设备下载完成后，用同样的算法计算本地哈希
3. 比对两个哈希值，一致则通过，不一致则拒绝

代码实现其实很简单，我贴一段C语言的示例：

#include <openssl/sha.h>

int verify_sha256(const uint8_t *package, size_t len, 
                  const uint8_t *expected_hash) {
    uint8_t computed_hash[SHA256_DIGEST_LENGTH];
    SHA256_CTX ctx;
    
    SHA256_Init(&ctx);
    SHA256_Update(&ctx, package, len);
    SHA256_Final(computed_hash, &ctx);
    
    return memcmp(computed_hash, expected_hash, 
                  SHA256_DIGEST_LENGTH) == 0;
}

签名校验：防篡改的核心手段

哈希校验有个致命问题：如果攻击者同时替换了升级包和哈希值，你根本发现不了。所以，我们需要签名校验。

签名校验的原理是：用私钥对升级包的哈希值进行加密签名，设备端用公钥验证。私钥只有厂商持有，攻击者拿不到私钥，就无法伪造合法签名。

RSA vs ECDSA：两种主流方案

签名校验的完整流程：

1. 服务端：计算升级包SHA256 → 用私钥签名 → 将签名附加到升级包
2. 设备端：计算升级包SHA256 → 用公钥验签 → 通过则继续，失败则回滚

校验失败的典型处理流程

校验失败怎么办？很多新手工程师直接让设备重试，这是不对的。我总结了一套标准处理流程：

第一步：记录失败信息

• 记录失败类型（哈希不匹配 / 签名无效 / 证书过期）
• 记录失败时的上下文（下载进度、网络状态、时间戳）
• 保存原始升级包（用于后续分析）

第二步：触发回滚机制

• 切换到备份分区（A/B分区方案）
• 或者恢复出厂固件（单分区方案）
• 标记当前升级尝试为失败

第三步：上报失败事件

• 通过MQTT/CoAP上报到云端
• 包含失败码和诊断信息
• 触发告警通知运维人员

第四步：限制重试次数

• 最多重试3次，每次间隔递增（1min → 5min → 30min）
• 超过次数后，进入静默期（24小时内不再尝试）
• 防止设备陷入无限重试的死循环

我曾经遇到过一个案例：某智能门锁因为服务器证书更新，导致签名校验失败。设备不断重试，每次重试都消耗大量电量，结果电池在两天内耗尽。后来我们加了重试次数限制和静默期，才解决这个问题。

整体校验流程

下面这张图，把哈希校验和签名校验的完整流程串起来了：

实际项目中的避坑指南

做了这么多年OTA，我踩过不少坑。分享几个关键点：