📚 课程目录第4章 BootROM设计

4、BootROM设计：BootROM架构、不可篡改性保证、BootROM代码签名验证

BootROM，说白了就是芯片上电后执行的第一段代码。它固化在芯片内部的只读存储器里，出厂后谁都没法改。我经常跟团队说，BootROM是整个信任链的「物理锚点」——如果它不可信，后面所有安全措施都是白搭。

这一章，咱们就聊聊BootROM到底该怎么设计。我会从架构讲起，再谈不可篡改性的实现手段，最后落到代码签名验证这个核心机制上。

4.1 BootROM架构：小而精的信任起点

BootROM的架构设计，核心原则就四个字：小而精。为什么？因为BootROM的容量极其有限——通常只有几十KB到几百KB。你想想看，要在这么小的空间里塞下安全启动、外设初始化、签名验证等全套逻辑，每一行代码都得精打细算。

我个人习惯把BootROM架构分成三个层次：

硬件抽象层（HAL）：直接操作寄存器的底层驱动，比如初始化时钟、配置内存控制器、设置看门狗。这部分代码量最小，但最关键。
核心服务层：提供哈希计算、RSA/ECC验签、安全存储访问等基础能力。我建议这部分用查表法替代复杂的条件分支，能省不少空间。
启动控制层：负责启动介质检测、镜像加载、签名验证流程编排。这是BootROM的「大脑」。

来看一个典型的BootROM启动流程图：

嗯，这里要注意一点：BootROM里的代码几乎都是用汇编和C混编的。汇编负责最底层的CPU初始化，C语言负责上层逻辑。我见过一些团队为了省事，全部用汇编写BootROM，结果后期维护成本高得吓人。

4.2 不可篡改性保证：从物理到逻辑的层层防护

BootROM的不可篡改性，不是靠一句「只读」就能保证的。它需要从物理、电气、逻辑三个维度共同构建。

4.2.1 物理层面的防护

芯片制造时，BootROM区域会使用一次性可编程（OTP）存储器，或者掩膜ROM。这两种方式出厂后都无法通过任何电气手段改写。

我曾经遇到过一颗芯片，客户说BootROM被篡改了。查到最后发现，是芯片的测试模式（Test Mode）没锁死，攻击者通过JTAG接口直接读写了ROM区域。从那以后，我要求所有项目必须在芯片tape-out前：

熔断所有测试接口的使能位
物理移除调试探针的访问路径
在金属层做防护栅格，防止FIB（聚焦离子束）攻击

⚠️ 重要提醒： 不要以为OTP就绝对安全。有些攻击者会通过电压毛刺（Voltage Glitch）或激光注入，让OTP读取电路返回错误值。BootROM代码本身必须能检测到这种异常——比如在关键跳转前做CRC校验。

4.2.2 逻辑层面的防护

物理防护防的是「改」，逻辑防护防的是「绕过」。BootROM必须确保：

执行流不可跳过：签名验证代码必须在跳转到外部镜像之前执行，且不能被中断或异常打断。
关键寄存器写保护：控制BootROM映射地址的寄存器，一旦锁定就不能再解锁。
安全状态机：芯片内部维护一个安全状态寄存器，BootROM执行过程中状态值不断变化，任何异常跳转都会导致状态不匹配，触发硬件复位。

我个人的经验是，逻辑防护里最容易出问题的是「条件竞争」。比如BootROM在读取外部存储器的签名时，如果攻击者通过DMA快速修改内存内容，就可能绕过验证。解决办法很简单：验签期间禁止所有DMA传输。

4.3 BootROM代码签名验证：信任链的第一道锁

签名验证是BootROM最核心的功能。说白了，就是BootROM拿着出厂时烧录的公钥，去验下一级镜像的签名。验过了，才放行。

4.3.1 公钥的存储与保护

公钥存在哪？这是个大学问。常见方案有三种：

存储位置	优点	缺点
OTP（一次性可编程存储器）	出厂后不可改，安全性最高	容量小，一旦写错无法恢复
eFuse（电子熔丝）	可逐比特编程，灵活性好	需要高压编程，工艺复杂
BootROM代码内部硬编码	零额外成本	公钥泄露后无法更换

我个人推荐用eFuse + 哈希锁定的方案。具体做法是：把公钥的哈希值烧进eFuse，公钥本体放在BootROM的常量区。每次验签前，先算一遍公钥的哈希，跟eFuse里的值比对。这样既保证了公钥的完整性，又保留了更换公钥的灵活性——只要重新烧eFuse就行。

4.3.2 签名验证流程

标准的签名验证流程是这样的：

加载镜像头：BootROM从启动介质读取Bootloader的前N个字节，里面包含签名和元数据。
解析签名算法：根据镜像头里的算法ID，选择RSA-2048、ECDSA-P256等对应验签函数。
计算镜像哈希：对Bootloader的代码段做SHA-256哈希。
验签：用公钥解密签名，跟计算出的哈希比对。
判定结果：一致则跳转执行，不一致则进入恢复模式或死循环。

来看一段简化的验签伪代码：

// BootROM 签名验证核心逻辑
int bootrom_verify_signature(uint8_t *image, uint32_t image_len) {
    // 1. 读取镜像头
    image_header_t *hdr = (image_header_t *)image;
    
    // 2. 检查魔数，防止加载错误数据
    if (hdr->magic != BOOT_MAGIC) {
        return ERR_INVALID_MAGIC;
    }
    
    // 3. 从OTP读取公钥哈希，验证公钥完整性
    uint8_t pubkey_hash[32];
    otp_read(OTP_PUBKEY_HASH_OFFSET, pubkey_hash, 32);
    if (sha256(g_pubkey, sizeof(g_pubkey)) != pubkey_hash) {
        return ERR_PUBKEY_TAMPERED;
    }
    
    // 4. 计算镜像哈希
    uint8_t image_hash[32];
    sha256(image + sizeof(image_header_t), 
           image_len - sizeof(image_header_t), 
           image_hash);
    
    // 5. RSA验签
    if (rsa_verify(g_pubkey, hdr->signature, image_hash) != 0) {
        return ERR_SIGNATURE_MISMATCH;
    }
    
    return ERR_OK;
}

💡 实战技巧： 验签时一定要做「恒定时间比较」，不能用memcmp。因为memcmp在遇到第一个不匹配的字节就会返回，攻击者可以通过测量返回时间来推断签名内容。我习惯自己写一个恒定时间的比较函数，循环次数固定为签名长度。

4.3.3 回滚保护

签名验证只能保证镜像「是谁签的」，不能保证镜像「是不是最新版」。攻击者可以拿一个旧版本的、有漏洞的合法镜像来降级攻击。

解决办法是版本号检查。BootROM里维护一个最小允许版本号（存在OTP或eFuse里），每次验签时比较镜像头里的版本号。如果低于最小值，直接拒绝启动。

我记得有一次，客户的产品在OTA升级后变砖了。查了半天，发现是BootROM里的版本号检查逻辑写反了——把「大于」写成了「小于」。从那以后，我要求所有版本号比较代码必须经过形式化验证。

4.4 小结

BootROM的设计，本质上是在「有限资源」和「绝对安全」之间找平衡。架构上要精简到极致，防护上要覆盖物理和逻辑两个层面，签名验证要兼顾正确性和抗攻击能力。