设备 OTA 升级怎么设计才安全：签名、灰度与回滚
OTA 升级让设备可以远程修复问题、增加功能，但一次失败的升级也可能让大批设备无法使用。本文从固件签名、分区设计、灰度发布、断点续传与回滚几个方面，讲清安全可靠的 OTA 方案要点。
对于联网设备来说，OTA（空中升级）几乎是必备能力：出厂后发现的问题可以远程修复，新功能可以持续推送，安全漏洞可以及时修补。但 OTA 也是风险最高的操作之一。如果升级包被篡改，设备可能被恶意控制；如果升级过程中断电，设备可能无法启动；如果新固件有问题且推送给了所有设备，售后压力会在短时间内集中爆发。
一个可靠的 OTA 方案，要在设备端、云端和发布流程三个层面同时设计。
一、先明确升级对象与范围
设备上可能需要升级的部分不止一个，方案设计前先列清楚：
- 主控芯片固件；
- 通信模组固件，如 Wi-Fi、蜂窝、蓝牙模组，有时由模组厂商提供升级方式；
- 应用层程序或脚本，对于运行 Linux 的设备较常见；
- 配置文件、证书、资源文件；
- 外设或子设备的固件，例如网关下挂的传感器。
每个部分的升级方式、存储空间、失败影响都不同。存储空间是硬件选型阶段就要考虑的问题：如果想支持双分区升级，Flash 容量至少要能放下两份固件。这一点在设计后期很难补救。
二、签名与校验：确保固件来自你
OTA 安全的第一道防线是确保设备只接受官方发布的固件：
- 固件发布时用私钥签名，设备内置对应公钥，升级前验证签名，不通过则拒绝安装；
- 私钥妥善保管，最好放在硬件安全模块或专门的签名服务中，不要放在构建服务器或代码仓库里；
- 除签名外还要校验完整性，如 SHA-256 摘要，防止下载过程中数据损坏；
- 下载通道使用 TLS 加密，并校验服务端证书；
- 如果芯片支持安全启动，启用它，确保每次启动时也验证固件签名，而不只是升级时验证。
只做 MD5 校验而不做签名，只能发现传输错误，防不住篡改。
三、分区设计：保证升级失败还能启动
升级过程中最常见的故障是断电和网络中断。常见的设计方案有：
- A/B 双分区：设备有两个固件分区，当前运行 A 时把新固件写入 B，写入并校验成功后再切换启动分区；新固件启动失败则自动切回 A。可靠性最高，但需要双倍空间；
- 单分区加恢复分区：保留一个最小的恢复系统，主分区升级失败时进入恢复模式重新下载；
- 差分升级：只传输新旧版本之间的差异，节省流量和时间，适合蜂窝网络设备，但对版本管理要求更高，必须确认设备当前版本与差分包的基础版本一致。
无论采用哪种方案，都要保证在升级流程的任意时刻断电，设备重新上电后都能进入可用状态。
四、启动确认与自动回滚
新固件能启动不代表能正常工作。可靠的做法是新固件启动后进入「试运行」状态，完成自检后再确认：
- 自检内容包括：关键外设初始化成功、能连上网络、能与云平台通信；
- 在规定时间内未完成确认，或者连续多次重启，自动回滚到旧版本；
- 回滚后向云端上报失败原因，便于排查；
- 设备端配合看门狗，防止新固件卡死后无法恢复。
五、防降级与版本管理
攻击者可能尝试把设备刷回一个存在已知漏洞的旧版本，这称为降级攻击。防护措施包括：
- 固件中带版本号，且版本号包含在签名范围内；
- 设备记录已安装的最低安全版本，拒绝安装低于该版本的固件，有条件时使用芯片的防回滚计数器；
- 需要主动降级时，由云端签发专门的降级授权，而不是放开限制。
云端也要建立清晰的版本管理：每个版本对应哪些硬件型号、兼容哪些模组版本、是否强制升级、修复了哪些问题。
六、灰度发布：不要一次推给所有设备
即使经过了充分测试，新固件在真实环境中仍可能遇到意想不到的问题。灰度发布是控制风险的关键：
- 内部测试设备先升级，覆盖不同硬件批次和网络环境；
- 小比例外部设备升级，观察一段时间内的升级成功率、在线率、异常重启、业务指标；
- 指标正常后逐步扩大比例；
- 任何阶段发现异常，立即暂停推送；
- 支持按型号、硬件版本、地区、客户、固件版本等维度圈选升级对象。
此外还要考虑升级时机。例如在设备空闲时段升级，正在工作的设备延后升级，电量低于阈值的电池设备不升级；大批量升级时分批下发，避免同时下载压垮服务器或 CDN。
七、OTA 方案检查清单
- 硬件存储空间满足所选分区方案；
- 固件签名、设备端验签、安全启动已实现；
- 签名私钥有专门保管方案和使用审批流程；
- 任意时刻断电都能恢复，已做过断电测试；
- 启动确认与自动回滚已实现；
- 防降级机制已实现；
- 云端支持分组、灰度、暂停和升级状态统计；
- 升级失败原因能上报，有对应的排查手册；
- 设备端有升级进度和状态提示，用户知道设备正在升级。
OTA 的设计目标不是「能升级」，而是「升级失败也不会出事」。每一个环节都要假设它可能失败，再设计失败后的出路。
大乐网络在物联网平台项目中，会把 OTA 管理作为平台的基础模块，与设备端团队一起确定签名、分区和灰度策略。如果你的设备还在硬件选型阶段，建议现在就把 OTA 方案纳入评估。