IoT 固件更新：从下载完整性到安装授权与回滚防护
OTA 更新让厂商修复已经售出的设备，也赋予更新系统改变设备软件的能力。攻击者如果能影响这条链路，目标可能是安装未经批准的代码，也可能只是让设备接受一个签名合法但存在漏洞的旧版本，或者在更新中途失去恢复能力。
实操：核对真实升级包、兼容性检查和回退行为
准备被测产品正常发布的当前与旧版固件、型号与硬件修订、升级入口和恢复方法。OpenWrt 样本可以先用于学习实际升级检查；安全启动和防回退是否存在，需要回到对应平台验证。
从发布包核对到设备运行版本
先按官方固件下载流程核对包的哈希和发布来源。在自己的 OpenWrt 设备或QEMU 固件中执行：
ubus call system board
cat /etc/openwrt_release
sysupgrade -h
记录 board_name、target、运行版本与镜像种类。x86 镜像不能拿去刷 ARM 路由器，同品牌也不意味着硬件修订相容。
只运行安装前测试，核对实际检查了什么
把与当前设备匹配的官方升级文件传到 /tmp/firmware.img.gz。QEMU 样本在电脑可使用：
scp -O -P 2222 openwrt-24.10.5-x86-64-generic-squashfs-combined.img.gz root@127.0.0.1:/tmp/firmware.img.gz
ssh -p 2222 root@127.0.0.1 'sysupgrade -T /tmp/firmware.img.gz'
-T 执行镜像检查而不升级；记录输出与退出状态，并对照实际 target 的 platform_check_image、metadata 和签名验证路径。测试通过不证明设备有安全启动或最低安全版本策略。OpenWrt 的不同 target 与版本检查内容不同，以实际 sysupgrade 源码为准。
用厂商实际版本检查回退
在有恢复途径的专用样机上，通过原升级入口提交厂商仍可获取的旧版本，保留上传响应、验证日志、重启日志和实际运行版本。若产品声明防回退，再核对最低安全版本存在哪里、何时推进、恢复入口是否使用同一策略；普通功能版本号降低与安全版本降低应分开记录。
ESP32 产品可接着读取 espefuse.py --chip esp32 --port "$IOT_PORT" summary SECURE_VERSION，并核对固件构建的安全版本、启动日志及 OTA 状态。只有发布身份有效而安全版本不足的镜像被拒绝，才能证明该路径上的防回退；签名无效被拒绝证明的是另一项检查。
检查中断与恢复是否重新放宽权限
围绕实际下载、校验、分区写入、首次启动与版本确认阶段设置中断点，按厂商恢复方案准备串口或有线恢复。每次确认当前活动分区和版本，再继续下一轮；没有恢复路径时不要直接做断电写入测试。
被拒绝的包是否落盘、旧分区是否重新被选择、首次启动失败是否正确撤回，都通过升级日志、Bootloader 输出和实际运行版本核对。
成立前提与能力变化
攻击者需要影响更新包、清单、分发通道、发布身份或安装状态中的一项，并使设备接受与当前策略不符的软件或无法恢复的状态。内容被替换不等于能够安装，下载成功也不等于能够启动；应分别观察验证、写入、启动选择和运行确认。
下载通道与安装授权分开判断
HTTPS 保护设备与某个服务器之间的传输，普通哈希帮助判断文件是否与预期摘要一致。但如果攻击者同时替换文件与未受保护的摘要，两者仍然匹配；如果下载服务器失陷，合法 HTTPS 也可能运送恶意内容。
数字签名要把安装授权绑定到设备实际使用的内容与元数据。IETF RFC 9019 将 IoT 更新的授权策略与底层传输架构分开：镜像可以经不同渠道分发，设备仍需要独立判断是否允许安装。RFC 9019
因此，需要确认谁能签名、设备信任哪些密钥，以及签名保护是否覆盖了影响安装行为的目标型号、镜像摘要、组件依赖和处理指令。仅验证压缩包外层，而后续又从可变地址下载真正执行的内容，可能留下验证与使用之间的差异。
更新清单是授权对象，不是说明文字
RFC 9124 提出固件更新清单的信息模型，其中包括防止未授权旧清单回退的单调序列号与兼容性条件。一个容易混淆的细节是：清单序列号不等于固件版本。授权方可以为旧固件签发更高序列号的新清单，因此防清单重放并不自动等于禁止一切固件回退。RFC 9124，3.2 与 4.3
产品需要另行定义最低可接受安全版本和紧急回退政策。设备应在受保护状态中保存必要的进度，避免重启、恢复备份或修改普通配置后重新接受旧授权。
安装清单还应防止“给甲设备的合法包被乙设备接受”。兼容性不能只靠人类可读文件名判断，处理器相同也不证明分区、外设和安全配置相容。
清单中哪些信息必须一起受到保护
可以用下面的抽象对象检查实现，字段名仅用于说明，不是 SUIT 清单的编码格式：
目标：产品系列、硬件修订与组件标识
内容：实际镜像的摘要、大小与必要依赖
授权：发布主体、清单序列与安装条件
安全策略：最低安全版本与允许的恢复路径
设备应验证这些信息与实际安装对象一致。修改下载 URL 不一定破坏内容安全，前提是设备最终验证的摘要与签名仍绑定到正确镜像；反之，只签名 URL 而不约束收到的内容，可能无法覆盖服务器内容变化。
多组件更新还要考虑组合安全。单独签名正确的无线固件、主应用和 Bootloader，未必能任意组合。兼容性或依赖约束若不被认证保护，攻击者可能利用旧组件与新组件之间的协议差异影响检查。
安装程序还必须避免先执行再验证，例如在确认来源之前运行包内脚本或解析具有危险副作用的格式。验证器本身也是输入解析器，其复杂度和权限应受到约束。
区分清单序列、固件版本与安全版本
假设测试设备保存已接受清单序列 31，最低安全版本为 3。下面的条件组合只用于验证策略，不代表某个标准或芯片的实际字段编码：
| 待安装对象 | 预期判断 | 检查的机制 |
|---|---|---|
| 序列 30、合法签名、安全版本 3 | 拒绝旧授权 | 清单防回退 |
| 序列 32、合法签名、安全版本 2 | 拒绝危险版本 | 最低安全版本 |
| 序列 32、合法签名、安全版本 3、目标硬件不符 | 拒绝 | 兼容性 |
| 序列 32、合法签名、安全版本 3、镜像摘要不符 | 拒绝 | 实际内容绑定 |
| 序列 32、各项均获准 | 可以进入安装流程 | 仍需后续写入与启动检查 |
第三方能改写设备保存的序列或最低安全版本时，表中的拒绝逻辑可能被绕过；这些状态本身也需要保护。反过来，如果授权方确实允许回退到某个旧功能版本，可以签发新的清单，但仍应满足产品的安全版本与恢复政策。测试必须把这些不同含义的“版本”分开记录。
发布私钥失陷后，设备验签可能仍然正常
IOActive 2014 年的 WeMo 披露记录了设备固件中存在签名能力的问题。这类设计让攻击者能够制造验证通过的内容，因此“签名校验成功”并不能补救发布权限已经泄露的事实。WeMo 原始披露
发布侧需要把构建产物与签名授权绑定，记录签名对象、审批主体和目标范围。私钥放在 HSM 中能够减少直接导出风险，但如果任何被攻陷的构建任务都能请求为任意内容签名，攻击者仍然能借用这项服务。
还应预先设计密钥轮换与失陷响应：旧密钥如何失效，新密钥通过什么信任关系进入设备，长期离线设备重新上线时如何处理。只有单一不可替换信任根的设备，可能无法仅靠一次普通 OTA 完成可靠迁移。
对照 ESP-IDF 的实际试运行状态
ESP-IDF v5.3.4 在启用 CONFIG_BOOTLOADER_APP_ROLLBACK_ENABLE 时，将应用可用性确认写入 otadata 的状态；这些状态不等于签名验证结果：
| 时刻或动作 | 相关状态 | 核对的位置 |
|---|---|---|
| 通过 esp_ota_set_boot_partition 选择新候选 | ESP_OTA_IMG_NEW | OTA 选择记录与 otadata |
| Bootloader 首次选择该候选 | ESP_OTA_IMG_PENDING_VERIFY | 启动状态与当前运行分区 |
| 自检后调用 esp_ota_mark_app_valid_cancel_rollback | ESP_OTA_IMG_VALID | 应用确认条件与调用返回值 |
| 自检失败并调用 esp_ota_mark_app_invalid_rollback_and_reboot | ESP_OTA_IMG_INVALID | 错误处理与下次启动选择 |
| 仍待确认就发生复位，下一次启动处理 | ESP_OTA_IMG_ABORTED | 回退分区与先前未完成的确认 |
先检查项目配置，再从源码查确认函数由什么健康条件触发，最后把串口日志、运行分区与上述状态对照。关闭回退功能时，NEW/PENDING_VERIFY 不按这条流程使用；不能只看函数名推断设备已经启用回退。ESP-IDF OTA 文档
最低安全版本的推进也要与确认协调。过早推进可能使仍需回退的旧槽位不再获准启动；过晚推进会延长旧漏洞镜像的可用窗口。产品应明确由谁确认成功，以及回退镜像是否满足当时的安全版本限制。
掉电恢复决定安全更新能否持续使用
双槽位机制能减少更新中断对可用性的影响，但它不是独立的安全保证。候选镜像、启动选择、版本状态与成功确认需要一致；攻击者若能只改槽位元数据，就可能影响实际执行对象。
一种可评估流程是先把镜像写入非活动槽位，校验后进入试运行，达到明确健康条件再确认成功。失败时回到仍被策略允许的可信镜像。配置迁移也要可恢复，否则程序回退成功，旧程序却可能读不懂新格式数据。
NIST SP 800-193 的保护、检测和恢复原则提醒实施者：更新不仅要拒绝篡改，还要在固件受损时有可靠恢复能力。它不替代具体产品的断电与状态一致性测试。NIST SP 800-193
验证围绕设备实际安装与启动展开
准备有效新包、内容篡改、签名错误、型号不符、旧清单、旧固件新授权等样本，分别检查安装结果与实际启动版本。对失败路径，确认设备没有退入弱认证恢复服务。
随后在下载、写入、切换槽位、首次启动和成功确认等阶段中断供电，记录下一次启动选择与版本状态。网络重试、空间不足和长期离线重连也需要覆盖。
更新成功率与安全拒绝率应分别观察。所有恶意包都被拒绝，但正常设备大量无法恢复，不是可持续的更新方案；所有设备都能升级，但发布身份能被普通业务服务借用，也没有建立完整的安装授权边界。
将更新包写入设备与让其中代码执行是不同边界，可对照任意文件上传中的存储、解析与执行关系；固件安装还需要本文讨论的发布授权和版本策略。