📚 课程目录第2章安全启动链

2、安全启动链：从BootROM到应用层的信任根建立

安全启动链，说白了就是给设备装上一套「出生证明+基因检测」系统。从芯片上电的第一条指令开始，每一级代码都要验明正身，才能继续往下走。我在好几个项目里都见过那种「BootROM随便跳，后面全靠爱」的设计——嗯，结果就是被攻击者按在地上摩擦。

2.1 信任根：一切安全的起点

信任根（Root of Trust, RoT）是安全启动链的基石。它通常固化在芯片的BootROM里，物理上不可更改。为什么非要放在ROM里？因为ROM在流片时就固定了，攻击者改不了。

核心原则：信任根必须是不可变的（Immutable），且是芯片上第一个执行的代码。它只做两件事：验证下一级Bootloader的签名，然后跳转执行。

我个人习惯把信任根分成三类，你在选型时可以参考：

类型	存储位置	可更新性	典型场景
硬件信任根	BootROM	不可更新	高端MCU、SoC
一次性可编程信任根	eFuse / OTP	仅可熔断	安全芯片、TPM
软件信任根	Flash保护区	可更新（需签名）	低端IoT设备

注意：软件信任根虽然灵活，但风险也最大。我曾经见过一个客户把信任根放在Flash里，结果攻击者通过电压故障注入跳过了校验——嗯，那批设备后来全部召回了。

2.2 签名验证机制：每一级都要「刷脸」

安全启动链的每一级跳转，都伴随着一次签名验证。你想想看，如果BootROM不验证Bootloader，那攻击者直接替换成恶意Bootloader，后面全是白搭。

典型的验证流程是这样的：

BootROM：读取Bootloader的头部信息，提取签名和公钥索引。
公钥获取：从eFuse或OTP中读取预置的公钥哈希，比对Bootloader头部的公钥是否匹配。
签名验证：使用匹配的公钥，对Bootloader的镜像进行ECDSA或RSA-PSS签名验证。
哈希校验：验证通过后，再计算Bootloader镜像的哈希值，确保完整性。
跳转执行：全部通过，才跳转到Bootloader的入口地址。

下面这张图展示了完整的信任链传递过程：

经验之谈：签名算法选型上，我个人更倾向ECDSA。同样的安全强度下，ECDSA的签名长度更短，对IoT设备的Flash和RAM压力更小。但要注意，ECDSA的随机数生成必须用硬件TRNG，否则私钥会泄露——我在一个项目里就踩过这个坑。

2.3 回滚保护与防降级攻击

降级攻击（Rollback Attack）是安全启动链里最容易忽略的漏洞。攻击者不篡改固件，而是把设备「退回」到有漏洞的旧版本。你想想看，如果设备能随便刷回旧固件，那前面做的签名验证还有什么意义？

我见过最典型的案例：某智能门锁厂商只做了签名验证，没做版本检查。攻击者拿到一个旧版本固件（里面有个已知的后门），直接OTA降级——嗯，门锁就成摆设了。

回滚保护的实现方式主要有三种：

方案	实现方式	安全性	缺点
版本号比较	固件头部包含版本号，Bootloader检查版本号是否大于等于当前版本	低	版本号可被篡改（如果Flash可写）
防降级计数器	在eFuse或OTP中维护一个单调递增计数器	中	计数器空间有限，用完后无法升级
安全版本号（SVN）	将版本号哈希后存储在eFuse中，每次升级熔断新位	高	硬件成本高，需要足够多的eFuse位

避坑指南：我曾经在一个项目里用了「版本号比较」方案，结果发现攻击者可以直接修改Flash里的版本号字段。后来改成了eFuse计数器，但eFuse位不够用，又得重新流片——嗯，那叫一个酸爽。

2.4 实践：实现一个最小安全启动链

光说不练假把式。下面我用伪代码展示一个典型的安全启动链实现，你可以在自己的项目里参考：

// BootROM 伪代码
void bootrom_main() {
    // 1. 从固定地址读取Bootloader头部
    boot_header_t *hdr = (boot_header_t *)BOOTLOADER_BASE;
    
    // 2. 从eFuse读取公钥哈希
    uint8_t expected_pubkey_hash[32];
    efuse_read(EFUSE_PUBKEY_HASH, expected_pubkey_hash, 32);
    
    // 3. 验证公钥
    if (sha256(hdr->pubkey, 64) != expected_pubkey_hash) {
        panic("Public key mismatch!");
    }
    
    // 4. 验证签名
    if (!ecdsa_verify(hdr->pubkey, hdr->signature, 
                      BOOTLOADER_BASE + sizeof(boot_header_t),
                      hdr->image_size)) {
        panic("Signature verification failed!");
    }
    
    // 5. 检查版本号（防降级）
    uint32_t min_version = efuse_read_counter(EFUSE_MIN_VERSION);
    if (hdr->version < min_version) {
        panic("Rollback detected!");
    }
    
    // 6. 跳转到Bootloader
    jump_to(BOOTLOADER_BASE + sizeof(boot_header_t));
}

建议：实际项目中，记得在Bootloader里也实现同样的验证逻辑，用来校验固件镜像。另外，eFuse的读写操作要加错误处理——我见过因为eFuse读取失败导致设备变砖的案例，那叫一个惨。

2.5 常见攻击手法与防御

安全启动链不是万能的。攻击者有的是办法绕过它。我整理了几种常见攻击手法：

故障注入攻击：通过电压毛刺、电磁干扰让CPU跳过验证指令。防御措施：使用冗余校验、插入随机延迟、硬件故障检测。
公钥替换攻击：如果eFuse没锁死，攻击者可以写入自己的公钥。防御措施：熔断eFuse的写使能位，一次性编程。
中间人攻击：在OTA过程中替换固件包。防御措施：端到端签名，传输层用TLS。
侧信道攻击：通过功耗分析提取签名私钥。防御措施：使用恒定时间算法、加噪处理。

核心观点：安全启动链不是银弹。它只是整个安全体系的第一道防线。你还需要配合安全存储、安全OTA、运行时保护等措施，才能打造真正「不可攻破」的IoT设备。

嗯，这一章的内容就到这里。安全启动链的设计，说白了就是「信任传递」四个字。从BootROM到应用层，每一级都要对下一级负责。你把这个链条守住了，攻击者就很难从启动阶段下手了。