嵌入式安全启动：签名通过后仍要防回滚

合法签名只能证明指定内容获得受信密钥授权，无法证明它没有旧漏洞。嵌入式安全启动需要分别建立镜像认证边界与防回滚下限，再确认恢复路径也遵守同样的启动策略。

启动ROM或首级引导程序通常持有根公钥、密钥摘要或不可变信任材料，并验证下一阶段映像的签名。信任链必须逐段延伸：验证者先确认被验证代码的真实性，再由该代码验证应用及其资源。若签名只覆盖程序主体，却未覆盖影响执行的版本元数据、分区地址或加载配置，攻击者可能篡改这些未签名字段改变启动路径。签名算法本身正确，不会自动修复覆盖范围设计的缺口。

摘要的输入区间必须在格式中无歧义地定义，长度字段也应先经过边界校验，避免恶意镜像声明的长度超出分区后触发越界读取。若镜像有多个分段、压缩数据或可重定位段，每个将被执行或影响执行的字节都需要纳入认证，或者由受信加载器安全地产生。验签成功后才应把控制权交给映像；启动代码还需确保对内容的检查与实际执行的是同一份数据，不能在验证后继续允许外部修改存储内容。

验签密钥的替换同样要受信任链约束。若应用镜像可以随意提交一把新公钥并用其自签名，就等于把根信任交给了攻击者。密钥轮换需要由当前受信根签署授权、设置受控密钥版本或依赖芯片安全存储中的受保护状态。开发调试口、恢复模式和工厂测试路径也必须纳入威胁模型；生产配置若仍允许未认证路径启动，正常启动链的密码学强度便无法覆盖整台设备。

对多个镜像协同启动的设备，签名元数据还需明确组件依赖和兼容性约束。单独合法的引导程序与应用，组合后未必遵守相同接口；验证器不能把两个验签成功直接等同于整机可信。嵌入式项目可把镜像角色、硬件型号和依赖版本写入受认证元数据，测试交换不同型号或不同组件的映像时是否被拒绝。这里的匹配规则应是明确允许关系，不能用未经认证的文件名推断身份。验签结果还应绑定完整映像身份，避免校验的是一个分区，最终跳转却来自另一个分区。

新鲜度防护与签名验证解决的是不同问题。攻击者重放一份过去合法签名的映像，验签仍会通过；若旧版本含有后来修补的安全缺陷，就可能重新暴露已封堵入口。设备需要把映像安全版本与受保护的单调计数器或等效硬件状态比较，只接受不低于策略下限的版本。单纯在普通Flash配置区保存最高版本值，若该区域能被外部擦除或回滚，就不能提供可靠的防回滚证明。

更新计数器的提交顺序还与恢复策略相关。新映像尚未完成写入和验证时就提前提升最低版本，掉电可能让设备既拒绝旧映像，也无法启动新映像；等映像确认成功后再提升，又需阻止攻击者在确认间隙反复启动旧版本。安全更新方案需要明确试启动、确认和计数器更新的原子化边界，并依据硬件安全计数器、可信存储与启动状态机设计顺序。失败恢复通道也只能启动满足认证与版本策略的映像。

镜像认证保证内容获得授权，防回滚保证版本满足安全下限。覆盖边界、密钥授权和版本状态必须一起验证，更新失败时的恢复路径也需遵循同一策略。