📚 课程目录第3章启动链验证机制

3、启动链验证机制：BootROM设计、一级引导加载程序验证、多级链式信任传递

安全启动的核心，说白了就是一条信任链。从芯片上电的第一条指令开始，到最终操作系统内核加载完毕，每一步都要确保：谁启动的，谁签名的，谁授权的。我做了这么多年嵌入式安全，见过太多设备因为启动链上某个环节被攻破，整个安全体系瞬间崩塌。今天咱们就聊聊这条链上的三个关键节点：BootROM、一级引导加载程序，以及多级信任传递。

3.1 BootROM：信任的根

BootROM是芯片上电后执行的第一段代码。它固化在芯片内部，不可修改。你想想看，如果连BootROM都能被篡改，那整个安全体系就无从谈起了。所以，BootROM的设计原则就一条：最小化、不可变、可验证。

核心要点：BootROM是信任链的锚点。它必须足够小，小到可以被形式化验证；它必须足够简单，简单到不可能有后门；它必须被物理保护，防止被探测或篡改。

我在一个IoT网关项目里遇到过一个问题：芯片厂商的BootROM里居然有一段未使用的调试代码，可以通过特定GPIO电平触发。嗯，这要是被攻击者发现，整个安全启动就形同虚设了。所以，我建议你在选型时，一定要确认BootROM是否经过安全审计，有没有残留的调试接口。

3.1.1 BootROM的核心职责

硬件初始化：设置时钟、内存控制器、安全引擎等基础外设
根密钥校验：验证一级引导加载程序的签名
安全启动策略：决定是否允许降级、是否允许未签名镜像
故障处理：校验失败时进入安全恢复模式或直接锁死

BootROM里通常会内置一个公钥哈希，或者直接存储公钥。我个人习惯用公钥哈希，因为公钥本身可以放在外部Flash里，BootROM只需要校验这个哈希是否匹配。这样既保证了灵活性，又没降低安全性。

3.1.2 BootROM的验证流程

上电后，BootROM会做以下几件事：

读取一级引导加载程序（通常叫SPL或BL1）
计算其哈希值
用内置公钥验证数字签名
如果验证通过，跳转到一级引导加载程序执行
如果验证失败，进入错误处理流程

避坑指南：我曾经在一个项目里发现，BootROM在验证签名时没有检查签名算法标识符。攻击者把RSA签名换成了ECDSA签名，而BootROM居然照单全收。所以，一定要确认BootROM对签名算法的校验是严格的，不能有“兼容性”妥协。

3.2 一级引导加载程序验证

一级引导加载程序（BL1/SPL）是信任链的第二环。它由BootROM加载并验证，然后负责加载二级引导加载程序（BL2/UBoot）。这一级的关键在于：它必须足够小，小到可以被BootROM完整加载到内部SRAM中。

为什么？因为外部DDR内存还没有初始化，你没法用。所以BL1通常只有几十KB，甚至更小。我见过一些设计把BL1压缩到16KB以内，用LZSS算法解压后执行。嗯，这确实是个好办法，但要注意解压代码本身也要在BootROM里，否则就成了鸡生蛋蛋生鸡的问题。

3.2.1 BL1的验证方式

验证方式	描述	安全性	我推荐吗？
哈希校验	只检查哈希值，不验证签名	低	不推荐
RSA签名验证	使用RSA公钥验证签名	高	推荐
ECDSA签名验证	使用椭圆曲线签名	高	推荐（密钥更短）
对称MAC	使用HMAC验证完整性	中	不推荐（密钥管理困难）

我个人强烈建议使用非对称签名验证。RSA-2048或ECDSA-P256都够用。别用对称MAC，因为密钥怎么安全地存到BootROM里是个大问题。你想想看，如果密钥泄露了，攻击者就能自己签名恶意BL1了。

3.2.2 BL1的典型代码结构

// 伪代码：BL1验证流程
void bl1_main(void) {
    // 1. 初始化基础硬件
    init_clock();
    init_sram();
    init_watchdog();
    
    // 2. 从存储设备读取BL2头部
    bl2_header_t header;
    read_from_flash(BL2_OFFSET, &header, sizeof(header));
    
    // 3. 验证BL2签名
    if (!verify_signature(header.hash, header.signature, ROOT_PUB_KEY)) {
        // 签名验证失败
        enter_error_handler(ERR_SIG_FAIL);
        return; // 不会执行到这里
    }
    
    // 4. 验证通过，跳转到BL2
    jump_to(header.load_address);
}

注意：BL1本身也要考虑安全。它运行在SRAM里，如果SRAM没有保护，攻击者可以通过DMA或调试接口读取或篡改BL1代码。我建议在BL1启动后立即锁定SRAM的调试访问权限。

3.3 多级链式信任传递

信任链不止两级。从BootROM到BL1，再到BL2，再到OS内核，再到文件系统，每一级都要验证下一级。这就是多级链式信任传递。你想想看，如果BL2被攻破了，它就能加载任意内核，那前面的BootROM和BL1再安全也没用。

我参与过一个车载信息娱乐系统的安全设计，信任链足足有5级：BootROM → BL1 → BL2 → 内核 → 文件系统。每一级都用自己的密钥对下一级签名。这样做的好处是：即使某一级被攻破，攻击者也只能控制后续的加载过程，无法逆向篡改前面的环节。

3.3.1 信任链的层级设计

3.3.2 信任传递的关键点

单向性：信任只能从根向叶传递，不能逆向。BootROM信任BL1，但BL1不能反过来影响BootROM
密钥隔离：每一级使用不同的密钥对。即使BL2密钥泄露，攻击者也只能签名恶意BL2，无法影响BL1或BootROM
最小权限：每一级只做自己该做的事。BL1只负责加载BL2，不负责加载内核
回滚保护：每一级都要检查版本号，防止攻击者用旧版本的镜像替换新版本

经验之谈：我曾经在一个项目里发现，BL2在加载内核时没有检查内核的版本号。攻击者把旧版本内核（有已知漏洞）替换了新版本，成功绕过了安全启动。从那以后，我每个项目都会强制要求版本号检查，而且版本号要单调递增，不能回退。

3.3.3 信任链的终止条件

信任链不能无限延伸。它必须在某个点终止。通常，终止点就是操作系统内核。内核加载完成后，安全启动的职责就结束了，剩下的安全由内核自己负责（比如SELinux、AppArmor等）。

但有些设计会把信任链延伸到文件系统。比如，内核在挂载根文件系统前，先验证文件系统的签名。这样做的好处是：即使攻击者篡改了文件系统，内核也不会加载。坏处是：启动时间变长了，而且文件系统更新时需要重新签名。

我个人建议：信任链延伸到内核就够了。文件系统的完整性可以用dm-verity或IMA来保证，没必要在启动链里做。你想想看，如果内核本身是安全的，它完全有能力在运行时验证文件系统。

3.4 常见问题与避坑

坑1：BootROM没有防回滚机制

有些芯片的BootROM允许通过外部引脚选择启动模式。攻击者可以把启动模式切换到“下载模式”，绕过BootROM直接加载代码。我建议你在硬件设计时，把启动模式引脚在量产时熔断或拉死，不让攻击者有切换的机会。

坑2：BL1没有锁定调试接口

BL1运行在SRAM里，如果JTAG/SWD接口没有锁定，攻击者可以直接读取SRAM内容，拿到BL1的代码和数据。更严重的是，他们可以修改BL1的执行流程。我建议BL1启动后立即锁定调试接口，只允许安全厂商通过专用密钥解锁。

坑3：信任链中间环节没有签名

我见过一个设计：BootROM验证了BL1，BL1验证了BL2，但BL2加载内核时只做了哈希校验，没有签名验证。攻击者只要替换了内核镜像，哈希值自然就变了，但BL2没有检查签名，直接加载了。嗯，这等于信任链在BL2这里断了。记住：每一级都必须做签名验证，不能只做哈希。

3.5 小结

启动链验证机制，说白了就是一条从硬件到软件的信任链。BootROM是根，必须不可变；BL1是承上启下的关键环节，必须小而精；多级信任传递要保证单向性、密钥隔离和回滚保护。我做了这么多年，最大的体会就是：安全启动不是某个环节的事，而是整条链的事。任何一个环节的疏忽，都会让前面的努力白费。