摘要

  • RFC 9019 把固件更新称为“经授权的远程代码执行”。签名认证作者并保护清单，但设备仍须单独判断这位作者是否有权执行所请求的动作。
  • 作者、设备运营者、网络运营者、用户与信任配置机构可以拥有不同权利。RFC 9124 支持多重签名，正是为了让不同角色的授权共同构成安装许可。
  • 本文建议保存最小化的“固件变更授权回执”，把清单证据连接到政策、上线窗口、启动观测与恢复。它是 Daniel Kade 的编辑性建议，不是 SUIT 字段或 IETF 要求。

验签通过是一项强证据。它说明受信任密钥保护了清单，受保护的字节没有变化；清单里的载荷摘要又把收到的镜像与这些指令绑定起来。没有这些能力，更新通道会直接变成攻击者的远程执行通道。

问题不在证据太弱，而在系统让一项精确证据承担了过多结论。RFC 9019 于 2021 年 4 月作为 IETF Informational RFC 发布。它明确说，经过认证的作者身份只是授权过程的输入，不是所有作者都拥有相同权限，设备必须检查请求动作是否落在签署者的权限之内。

因此，“可信密钥”不能自动翻译成“万能更新者”。一把密钥可以只获准修改某类设备、某个组件或某种紧急动作。它在边界内完全合法，在边界外仍没有权力。算法只能证明是谁签了；政策决定签署者可以做什么。

五个角色不能被一个绿灯抹平

RFC 9019 区分固件作者、设备运营者、网络运营者、用户和信任配置机构（TPA）。作者制作镜像；设备运营者承担日常运行；网络运营者控制连接环境；用户可能拥有或使用设备；TPA 分发信任锚与授权政策，并且可以委派权利。

在简单产品里，这些角色可以由同一组织承担。若本地政策明确赋予它完整权限，一份签名可以足够。标准并没有要求所有更新都必须人工点击，或者机械地凑够两份签名。

复杂供应链则不同。无线模块供应商可以签自己的组件，却不应决定工厂何时停机。设备厂商可以发布内核修复，却未必有权更改现场安全参数。网络侧服务可以负责配送，却不因此取得创作和批准权。支持期结束后，设备所有者还可能需要另一个合法的维护者。

TPA 的授权政策因而是更新系统隐藏的“宪法”。它把密钥映射到角色，再把角色映射到组件、设备类别、动作和委派范围。若映射过期、过宽或无法检查，密码学可以全程正确，权力关系却已经错误。

信任锚回答“哪把钥匙可以提交证据”，并不自然回答“能不能改启动程序”“能不能作用于这一批设备”“是否必须与运营者共同批准”“权限是否已经到期”。安装前仍需回答这些问题。

预授权不是又验一次签名

固件消费者接收清单、检查保护、决定是否获取和处理镜像。RFC 9019 明确设置预授权步骤：先判断签署清单的实体是否有权进行该更新。对于电池、带宽和闪存都有限的设备，尽早拒绝越权请求还有实际资源价值。

授权对象必须具体。一位作者可能有权更新应用，却无权替换 bootloader；有权修改传感器家族，却无权触碰工业控制器；有权发安全修复，却无权永久增加商业功能。载荷摘要能确保字节没换，不能替政策定义这些范围。

RFC 9019 的关键基础设施例子最清楚：作者提供的镜像可以完全真实，但仍要设备运营者同意。设备可以要求作者和运营者同时签署。第二份批准不是怀疑作者身份，而是表达另一位责任主体愿意在这个环境里执行改变。

RFC 9124 把这一点写进信息模型：清单格式必须能够携带多重签名，以便拥有不同权限的多方共同授权安装。它还把运营者明确写成需要保障产品族互操作性、并要求对变更作出明示批准的主体。

但不能只数签名。两把都映射为“作者”的钥匙，不能满足“作者加运营者”的政策；三份普通签名也不能代替缺失的安全责任人。验证器必须知道每把钥匙的角色、政策版本、范围和它所覆盖的动作。

触发、运输和批准是三件事

状态跟踪器可以宣布有新版本、接收设备特征，并远程触发更新。它可以由作者、设备运营者、网络运营者或其他合适主体运行。这种灵活性避免了固定拓扑，但也要求系统不要把“能触发”偷换成“有权批准”。

服务器可以只负责保存，网关可以只负责转发，网络运营者可以只负责安排低负载时段。它们都不应修改受保护的清单，也不因接近设备而继承作者或运营者的权力。

反过来，作者也未必掌握现场时机。真实而紧急的补丁可能在物理过程无法中断时到达；正确签名的新功能可能碰上尚未完成的依赖升级、缺失的恢复镜像或不允许变化的认证配置。

所以“可用”“已触发”“已下载”“已存储”“获准安装”“安装完成”“正在运行”必须各有状态。一个绿灯把它们合并，最大的损失不是界面细节，而是没人知道最后一次被证明的转移发生在哪里。

清单序列号不是软件进步刻度

RFC 9124 要求清单序列号单调增加，以阻止攻击者重放更早但仍有效的清单。同时它特别说明，这不是固件版本字段。一个更高序列号的清单可以有意授权安装较低版本固件。

这为受控恢复留下通道。若新版本在现场失败，责任主体可以作出新的授权决定，把设备带回已知镜像。授权对象是新的，所以清单序列增加；载荷版本回退，并不等于旧授权被重放。

把所有低版本都标成 rollback attack 会阻断正当恢复。正确检查应包括清单序列、签署者角色、回退权限、当前前置状态和决策原因。相反，版本号升高也不能证明权限：越权密钥完全可以签出“更新”的代码。

清单历史记录授权决定，固件历史记录执行状态。两条线通常同向，但不能被强迫为同一条线。事故发生时，正是它们之间的差异解释了系统为什么选择某个镜像。

真实镜像也可能不适用于当前设备

很多 IoT 产品包含多个微控制器。一项完整更新可能要求多份镜像、组件依赖、特定前置版本、存储位置和协调启动。RFC 9124 定义厂商、类别、设备、组件、前置摘要、依赖、格式与处理步骤，原因就在于真实镜像仍可能用错地方。

差分更新若面对错误前置镜像就会失败。两份各自合法的组件更新可能彼此不兼容。相邻硬件型号可以正确验证同一算法，却应拒绝不属于自己的载荷。签名验证没有失败，适用性判断仍可失败。

现场还有政策无法完全塞进通用清单的事实：受控设备是否停机、备用电源是否可用、技术人员是否在场、canary 是否健康、依赖服务是否已迁移。公共格式负责表达共同条件，本地运营者负责证明现场条件。

这不是拒绝自动化。相反，只有把条件结构化，设备才能在无人值守时依据预先批准的政策自动作出决定。无人点击并不等于无人负责；责任已提前编码在角色、范围、窗口和恢复规则中。

“更新完成”可能发生在重启之前

RFC 9019 区分固件消费者与固件验证器。前者处理清单并存储镜像，后者通常位于更高信任级别，在启动前再次验证并调用新镜像。若新镜像无效，设备需要选择另一份有效镜像，或获得新的有效镜像。

它的示例流程在随后重启、安全启动验证和激活之前，就发送“Firmware Update Completed”。这条消息没有造假，它完成的是当前协议阶段。它不能证明尚未发生的重启结果。

重启后，bootloader 可能拒绝镜像；系统可能启动但核心服务不恢复；多控制器产品可能只激活一部分；设备也可能在回报前失去网络，或者自动回到旧版本。收到前一条完成消息的服务器，还不知道哪种状态最终稳定下来。

因此需要范围明确的启动后证据：选中了哪份镜像、组件集合如何、启动结果、是否进入恢复路径、关键功能是否在预定时间内回归。远程证明可以帮助说明运行了什么，却不能独自说明为什么获准安装，更不能代替物理过程的结果。

建立固件变更授权回执

本文建议保存一份本地、最小化的固件变更授权回执，让一个真实提案从证据走到结果。它不取代清单，也不公开设备库存。

第一部分绑定清单哈希、载荷摘要、清单序列、声明版本、设备类别、组件和前置／依赖状态；同时记录授权政策版本、每个签署者的角色以及满足了哪组批准。审计者应能回答：这些签名为什么足以授权这个具体动作？

第二部分记录上线准入：目标批次、维护窗口、现场条件、canary 结果、恢复镜像或替代路径、责任人以及接受、延后或拒绝决定。密钥、详细设备标识、内部拓扑和漏洞暴露不应被复制到宽泛可见的记录中，受控引用与哈希通常足够。

第三部分把下载、存储、安装、验证器接受、重启后激活、健康检查和恢复分别记录。若决定回到旧版本，它应指向批准该动作的更高序列清单，并说明最终留在运行中的版本。

最后要关闭临时权力：短期批准是否到期，委派是否撤除，哪些设备仍未完成，哪个批次已隔离，后续证据由谁负责。总体成功率不能替代异常项的责任归属。

这份回执是 Daniel Kade 的编辑性治理建议，不是 SUIT 字段、IETF 新要求、TPA 产品、远程命令或公共设备清单。它只要求组织不要用准确的签名结果回答签名没有回答的问题。

Heng Lu 的方法把最低共同规范、本地决定、自愿采用、运行执行和观察结果分开。RFC 9019 与 RFC 9124 提供共同语法；本地政策分配权力；运行代码执行；观测证据决定是否关闭或重新打开这项改变。

验签绿灯应该保留。安装授权必须另有一盏灯。

来源