4. 安全通信与传输：TLS/DTLS协议配置、断点续传机制、升级包完整性校验

各位做OTA的同行，咱们今天聊点硬核的。安全通信这块，说白了就是解决三个问题：传输过程不被偷看、断了能接着传、拿到手的包没被人动过。我最早做智能电表OTA时，就因为没处理好这些，差点让整批设备变砖。嗯，咱们一个一个拆开讲。

4.1 TLS/DTLS协议配置：给数据通道加把锁

先问个问题：你的升级包在网络上裸奔过吗？如果答案是肯定的，那赶紧打住。TLS（TCP场景）和DTLS（UDP场景）就是给数据通道加密的标配。我个人习惯，物联网设备优先用DTLS，原因很简单——很多设备走CoAP/UDP，DTLS比TLS省一个握手往返，对低功耗设备更友好。

4.1.1 协议选型对比

我在项目中遇到过最坑的事：某款Wi-Fi模组只支持TLS 1.0，结果服务器升级后强制TLS 1.2，整批设备升级失败。所以我的建议是——协议版本要写在产品需求里，别等上线再改。

4.1.2 证书与密钥配置要点

• 证书链完整性：设备端只存根CA证书，服务器发完整链。我曾经见过有人把私钥也塞进固件……嗯，那画面太美不敢看。
• 预共享密钥（PSK）：资源受限设备（比如Cortex-M0+）用PSK模式，省掉证书解析开销。但PSK要定期轮换，别写死在代码里。
• 会话复用：TLS握手很费电。我建议开启会话ID或会话Ticket，让设备重连时跳过完整握手。

// 最小化配置示例
#define MBEDTLS_SSL_PROTO_DTLS
#define MBEDTLS_SSL_DTLS_HELLO_VERIFY   // 防DoS攻击
#define MBEDTLS_SSL_MAX_CONTENT_LEN 2048 // 升级包分片大小
// 证书验证
mbedtls_ssl_conf_authmode(&conf, MBEDTLS_SSL_VERIFY_REQUIRED);
mbedtls_ssl_conf_ca_chain(&conf, &cacert, NULL);
// 设置超时（重要！）
mbedtls_ssl_conf_handshake_timeout(&conf, 1000, 60000);

4.2 断点续传机制：大包不怕断

升级包动辄几十MB，网络一抖就重头传？用户会骂娘的。断点续传的核心就一句话：记录已传位置，下次从断点续传。但实现起来有几个坑，我踩过，你们别踩。

4.2.1 分片与状态记录

我个人习惯把升级包切成固定大小的块（比如1KB或4KB），每块算一个分片。设备端维护一个位图（Bitmap），记录哪些分片已收到。流程如下：

1. 发起请求：设备告诉服务器“我要升级包A，已收到分片0-100，缺101-500”。
2. 服务器响应：只发送缺失的分片，不重复传。
3. 校验合并：设备收到分片后更新位图，写入Flash。
4. 断点恢复：如果连接断开，设备重启后读取Flash中的位图，继续请求缺失分片。

4.2.2 分片大小与并发策略

另外，并发下载能提速，但别贪多。我建议并发数不超过3，否则设备内存和Flash写入带宽会打架。你想想看，一边收数据一边写Flash，CPU还得算校验，并发太高容易死机。

4.3 升级包完整性校验：别让坏包刷进去

传输过程中可能被篡改、损坏，甚至被植入恶意代码。完整性校验就是最后一道防线。我见过最惨的案例：某厂商没做校验，升级包在CDN上被中间人替换，结果设备全部变砖。嗯，从那以后我再也不敢省略这步。

4.3.1 哈希算法选型

• SHA-256：目前最推荐。安全强度够，计算速度在Cortex-M4上约50-100MB/s（硬件加速）。
• SHA-1：别用了。虽然快，但已经被证明可碰撞。我2017年就淘汰它了。
• MD5：绝对不要用。128位哈希，碰撞攻击成本极低。
• SHA-512：安全但慢，适合对安全性有变态要求的场景（比如金融设备）。

// 伪代码示例
uint8_t expected_hash[32]; // 从服务器获取的预期哈希
uint8_t computed_hash[32];

// 1. 逐块计算哈希（避免一次性加载整个包）
SHA256_CTX ctx;
sha256_init(&ctx);
while (有数据) {
    sha256_update(&ctx, chunk, chunk_len);
}
sha256_final(&ctx, computed_hash);

// 2. 比较哈希
if (memcmp(expected_hash, computed_hash, 32) == 0) {
    // 校验通过，开始刷写
} else {
    // 校验失败，丢弃包并上报错误
}

4.3.2 哈希的获取与验证

哈希本身也要安全传输。我建议两种方式：

1. 带外传输：哈希通过另一个通道（比如管理平台API）下发，不和升级包走同一条路。
2. 数字签名：用私钥对哈希签名，设备用公钥验签。这样即使哈希被截获，也无法伪造。

4.4 整体流程框架

下面这张图把三个环节串起来了。你仔细看，每一步都有校验点，环环相扣。

4.5 避坑总结

做了这么多年OTA，我总结了几条血泪教训，你们记一下：

• 证书过期：设备证书有有效期，提前半年就要考虑OTA更新证书本身。我见过设备因为证书过期，整批无法升级。
• Flash磨损：断点续传的位图频繁写入会磨损Flash。我建议用磨损均衡，或者把位图放在RAM里，只在关键节点（比如收到完整包）写一次。
• 哈希计算性能：低端MCU算SHA-256可能耗时几秒。我建议在空闲任务里算，别阻塞主循环。
• 回滚机制：万一刷进去的包校验通过但运行有问题呢？所以升级前要备份旧固件，或者留一个恢复分区。