4. 安全启动与信任链

在固件回滚保护系统化训练工程中，安全启动是回滚保护的“地基”。如果设备在启动阶段无法确认固件来源可信、版本状态可信，那么回滚保护就失去了判断依据。安全启动解决的是“这段固件能不能被运行”，回滚保护解决的是“这段固件是否被允许降级运行”。两者共享同一套密码学信任基础，却在策略层面各司其职。

一、安全启动的核心原理：从信任根逐级验证

安全启动的本质是一条信任链。设备上电后，最先执行的代码无法由软件自身证明其可信，因此必须依赖一个不可篡改的硬件锚点，即信任根（Root of Trust, RoT）。信任根通常由固化在芯片 ROM 中的只读引导代码和硬件密钥存储区组成，它天然可信，是整个验证链条的起点。

信任链的传递过程可以概括为：ROM 引导代码验证第一级引导加载程序（BL1）的签名，验证通过后把控制权交给 BL1；BL1 再验证 BL2，BL2 验证操作系统或应用固件。每一级都只信任“上一级验证通过”的下一级，形成逐级背书的链条。任何一级签名验证失败，启动流程立即中止，设备进入恢复或锁定状态。

二、信任根、签名验证与回滚保护的关系

信任根提供的是身份可信，签名验证提供的是完整性可信，而回滚保护提供的是版本状态可信。三者缺一不可。仅有签名验证，攻击者仍可把设备刷回存在已知漏洞的旧版本固件，因为旧固件同样拥有合法签名；只有加入回滚保护，才能拒绝“签名合法但版本过旧”的镜像。

回滚保护依赖两个关键要素：一是单调计数器（Monotonic Counter）或安全版本号（Security Version Number, SVN），它只能递增、不可回退，通常存储在 OTP、eFuse 或受保护的安全存储中；二是版本策略，即当前设备允许运行的最低安全版本。启动时，安全启动流程除了验证签名，还要比较固件声明的 SVN 与设备记录的最低 SVN，只有前者不小于后者才允许启动。

三、方法流程：一次安全启动中的验证步骤

以典型的嵌入式安全启动为例，一次完整的启动验证通常包含以下步骤：

1. 上电复位，CPU 从 ROM 固定地址取指，执行信任根代码。
2. ROM 代码读取 BL1 镜像头部，提取镜像摘要、签名、SVN 和公钥证书链。
3. 用内置根公钥验证证书链，再用证书中的公钥验证 BL1 签名。
4. 读取设备安全存储中的最低允许 SVN，与 BL1 声明的 SVN 比较。
5. 两项均通过后，将 BL1 载入 RAM 并跳转执行；BL1 对 BL2 重复类似流程。
6. 若签名失败或 SVN 低于最低值，记录启动失败原因，进入恢复或锁定。

下面是一段简化的启动验证伪代码，用于说明签名验证与版本比较的先后关系：

bool secure_boot_verify(image_t *img) {
    // 1. 验证证书链与镜像签名
    if (!verify_signature(img->cert_chain, img->signature, img->digest)) {
        log_error("SIGNATURE_INVALID");
        return false;
    }
    // 2. 读取设备最低安全版本
    uint32_t min_svn = otp_read_min_svn();
    // 3. 版本回滚检查
    if (img->svn < min_svn) {
        log_error("ROLLBACK_DETECTED: img_svn=%u min_svn=%u",
                  img->svn, min_svn);
        return false;
    }
    return true;
}

四、案例与场景：签名合法但版本过旧的攻击

某工业网关设备使用安全启动，固件镜像均带厂商签名。攻击者获取了早期固件包，该固件存在已知的远程命令执行漏洞。攻击者通过调试接口把旧固件写入 Flash，重启设备。由于旧固件签名合法，单纯依赖签名验证的安全启动会放行，设备被降级到漏洞版本。

引入回滚保护后，设备在 OTP 中记录了最低安全版本 SVN=5。旧固件声明 SVN=3，启动时版本比较失败，设备拒绝启动该镜像并进入恢复模式。攻击者即使拥有合法签名的旧固件，也无法让设备运行它。这个案例说明：签名验证防篡改，回滚保护防降级，两者必须同时部署。

五、常见误区与复盘要点

总结来看，安全启动构建了从信任根到应用固件的完整信任链，签名验证保证镜像来源与完整性，回滚保护则在这条链上叠加版本状态判断。三者协同，才能让设备既不被篡改，也不被降级到已知风险版本。理解它们之间的联系，是后续实现固件回滚保护策略、设计升级与恢复流程的前提。