MCU固件验签通过，为何仍需防回滚？

签名正确的固件仍可能不适合启动：它可能属于错误硬件，也可能是已被淘汰的合法旧版本。MCU 安全启动既要证明镜像来自可信发布者，又要证明当前设备仍允许接受它，两种判断不能互相替代。

签名验证的可靠性首先受验证范围约束。引导程序需要对真正参与启动的镜像内容及关键元数据建立认证关系，包括决定装载位置、长度和兼容性的字段。若只认证代码区，而允许未认证的头部改变解释方式，攻击者便可能保留签名却影响后续行为。普通循环冗余校验能发现部分传输错误，但其计算规则公开，不能证明发布者身份；把校验和换成摘要，同样没有自动建立可信的签名关系。

验证所用公钥也必须有可信来源。若攻击者能够同时替换镜像和引导程序读取的公钥，数学上完全正确的验签仍会接受攻击者签发的软件。工程实现通常需要将信任锚或其摘要放在受保护位置，并限制引导代码自身的修改路径。具体保护能力取决于器件的启动结构、存储保护与生产配置，不能仅凭启用了某个密码库就认定信任链已经成立。升级公钥的流程也需要由既有信任关系授权。

镜像通过验证后，执行对象必须与被验证对象保持一致。例如把外部存储中的文件验完后再按未受保护的长度重读，或允许其他写入路径在启动前修改镜像，都会破坏先前结论。可采用受控复制、写保护或执行前再次核验等方式约束这段时间。硬件型号与映像用途同样应在可信元数据中表达，避免同一发布密钥签发的测试固件被误装到生产设备。签名证明授权来源，不会替工程配置做兼容性判断。

即便以上条件满足，旧镜像依旧可能拥有有效签名。设备修复过一个缺陷后，攻击者重新投递此前合法版本，验签本身不会失败。防回滚需要比较镜像中的安全版本与设备保存的最低允许值，而且镜像版本字段必须受认证保护，最低值必须存放在无法被普通更新随意降低的位置。应用界面显示的软件版本可以变化丰富，安全计数则应表达兼容的安全代际，不能依赖字符串排序决定新旧。

版本门槛的更新时机需要与试运行机制协调。若在新镜像尚未证明可用时就永久提高门槛，旧镜像可能立即失去资格，新程序一旦启动失败，设备便无法按计划恢复。反过来，长期保留旧门槛又会扩大重放窗口。采用支持试运行的引导方案时，应按其平台接口，在新镜像完成必要自检并被确认后，再以受保护流程推进最低安全版本，确保确认状态与计数更新在重启之后仍有一致解释。

MCU 产品应把这条策略落实为可测试的状态转换，而非一句“支持双分区”。测试至少覆盖合法旧镜像被拒绝、新镜像未确认时能够恢复，以及确认前后发生复位时的选择结果。具体更新顺序必须遵守所用引导器的实现约定，不能把不同交换模式的标志混用。若业务要求紧急恢复到较旧功能版本，应准备安全计数不降低的专用恢复镜像，通过重新发布保留恢复能力，而非开放任意降级通道。

可信启动需要把来源认证与版本许可并列设计。签名范围封闭、信任锚受保护之后，还要让安全计数与镜像确认协调推进，才能同时抵御篡改和合法旧版本重放。