4、启动链（Boot Chain）：从ROM到Bootloader到OS的链式验证机制
嵌入式设备的安全启动并非由单一组件独立完成，而是通过一条环环相扣的信任链（Chain of Trust）逐级传递。每一级引导代码在获得执行权之前，必须先验证下一级镜像的完整性与真实性。这种“先验证、后执行”的机制，确保了即使攻击者篡改了存储介质中的某个环节，也无法在设备上运行恶意代码。本章将深入拆解从芯片内部ROM到Bootloader再到操作系统内核的完整验证链路，帮助读者建立对启动链的整体认知。
4.1 核心原理：信任根与逐级哈希验证
启动链的根基在于芯片内部固化的只读存储器（ROM），这段代码在芯片出厂时写入，无法通过软件手段修改。ROM中存储着根公钥的哈希值（SRK Hash）或直接固化根公钥，这是整个信任链的锚点。当设备上电或复位后，CPU首先执行ROM代码，ROM从外部存储介质（如eMMC、SPI NOR Flash、SD卡）读取第一级引导程序（FSBL），并使用根公钥验证FSBL的数字签名。只有签名验证通过，ROM才会将FSBL加载到内部SRAM并跳转执行。
FSBL执行后，其首要任务并非直接引导操作系统，而是重复同样的验证流程：使用FSBL中携带的公钥（或公钥哈希）验证第二级引导程序（SSBL）的签名。SSBL通常是功能完整的Bootloader（如U-Boot），它负责初始化DDR内存、外设驱动、文件系统驱动等。SSBL验证通过后，才被加载到DDR中执行。最后，SSBL验证操作系统内核镜像（如Linux的zImage/Image）、设备树（DTB）以及initramfs的签名，验证通过后跳转到内核入口。
这一机制的核心价值在于：攻击者无法绕过验证。即使攻击者完全替换了Flash中的FSBL、SSBL或内核镜像，由于没有合法的私钥签名，每一级验证都会失败，设备将拒绝启动。信任链的强度取决于最薄弱的环节——如果ROM中的根公钥哈希被泄露或替换，整个链条将崩溃；反之，只要ROM不可篡改，链条就是安全的。
4.2 判断方法与操作流程：验证链路的实施步骤
在实际嵌入式项目中，实现安全启动链需要遵循一套标准化的流程。以下以典型的ARM SoC平台（如NXP i.MX8、TI AM64x）为例，说明验证链路的实施步骤：
- 生成密钥对：使用RSA-2048或ECC-256生成多级密钥对。根密钥对（SRK）私钥保存在离线安全环境中，公钥哈希烧录到芯片eFuse中。FSBL密钥对、SSBL密钥对分别生成，私钥用于签名对应镜像。
- 签名镜像：对FSBL二进制文件计算SHA-256哈希，使用根私钥对哈希进行RSA签名，将签名附加到镜像末尾或存入单独签名块。SSBL和内核镜像同理，使用各自对应的私钥签名。
- 烧录与配置：将签名后的FSBL、SSBL、内核镜像写入存储介质。配置芯片的启动模式（如从eMMC启动），确保ROM能够正确读取FSBL。
- 验证流程测试：上电后观察串口日志，确认ROM打印“Verifying FSBL... OK”，FSBL打印“Verifying SSBL... OK”，SSBL打印“Verifying Kernel... OK”。任何一步失败，设备应停止启动并进入安全状态（如反复重启或进入下载模式）。
- 异常注入测试：使用二进制编辑器修改FSBL或内核的任意一个字节，重新烧录后确认设备拒绝启动。这是验证签名机制是否生效的必要手段。
| 验证阶段 | 验证者 | 被验证对象 | 使用的密钥 | 失败行为 |
|---|---|---|---|---|
| 第一阶段 | ROM | FSBL | 根公钥（eFuse中的哈希） | 停机，进入串行下载模式 |
| 第二阶段 | FSBL | SSBL | FSBL内置的公钥 | 停机，LED闪烁指示错误 |
| 第三阶段 | SSBL | OS内核 + DTB + initramfs | SSBL内置的公钥 | 停机，进入U-Boot命令行 |
| 第四阶段（可选） | 内核 | 内核模块、根文件系统 | 内核内置的模块公钥 | 拒绝加载模块，文件系统挂载失败 |
4.3 案例拆解：i.MX8M Plus 安全启动链实战
以NXP i.MX8M Plus评估板为例，该平台使用HABv4（High Assurance Boot）技术实现安全启动。项目背景：某工业网关产品需要防止固件被逆向或篡改，要求启动链覆盖从ROM到内核的完整链路。
初始现象与目标：开发阶段使用未签名的镜像可以正常启动，但生产环境要求启用HAB安全启动。目标是在不改变硬件设计的前提下，通过软件配置实现签名验证。
关键输入参数：
- SoC：i.MX8M Plus，支持HABv4，eFuse中可烧录SRK Hash（4个或8个哈希值）。
- Bootloader：U-Boot 2022.04，支持HAB验证。
- 镜像格式：FSBL为SPL（U-Boot SPL），SSBL为U-Boot proper，内核为Linux 5.15。
分析判断过程：首先确认ROM代码是否启用HAB。i.MX8M Plus的ROM默认不强制验证，需要通过烧录eFuse的SRK Hash并设置SEC_CONFIG[1]位来启用。然后使用NXP提供的Code Signing Tool（CST）生成密钥对和签名。关键决策点：SRK Hash烧录后不可逆，一旦烧错，设备将变砖，因此必须在量产前充分测试。
实际操作步骤：
- 在Linux主机上安装CST工具，生成4个RSA-2048密钥对（SRK1~SRK4），并生成SRK Table和SRK Hash。
- 编译U-Boot SPL和U-Boot proper，使用CST对SPL进行签名：
./cst -i csf_spl.txt -o csf_spl.bin # 将csf_spl.bin附加到SPL镜像末尾，生成spl-signed.bin - 对U-Boot proper签名，并将签名块写入Flash的特定偏移位置。
- 使用uuu工具将签名后的SPL烧录到eMMC的boot分区。
- 首次启动时，ROM检测到eFuse未烧录SRK Hash，会跳过验证。此时通过U-Boot命令烧录SRK Hash：
hab_status # 确认HAB状态正常后，烧录fuse fuse prog -y 6 0 0x12345678 0x9abcdef0 ... - 烧录完成后复位，观察串口输出：
HAB: Event 0xdb, ICB: 0x01, 验证SPL成功 HAB: Event 0xdb, ICB: 0x02, 验证U-Boot成功 ## Loading kernel from FIT Image ... Verifying Hash ... OK
结果对比与风险：启用HAB后，启动时间增加了约200ms（主要是RSA验签开销），但安全性显著提升。风险在于eFuse烧录不可逆，一旦SRK Hash错误，设备无法启动且无法通过软件恢复，只能返厂更换芯片。因此建议在量产前使用至少10台样机进行完整的签名验证和异常注入测试。
复盘经验：安全启动链的实施必须提前规划密钥管理流程。私钥应存储在硬件安全模块（HSM）中，并由专人保管。同时，建议在U-Boot中实现“恢复模式”：当验证失败时，允许进入USB下载模式，以便在开发阶段或售后维修时重新烧录合法固件。
4.4 常见误区与总结复盘
在实施启动链验证时，工程师常陷入以下误区：
- 误区一：只验证Bootloader，不验证内核。如果SSBL验证通过但内核未验证，攻击者可以替换内核镜像，加载恶意驱动或篡改系统。必须将验证延伸到内核及关键系统文件。
- 误区二：签名算法强度不足。使用SHA-1或RSA-1024在当今安全环境下已不够安全，建议使用SHA-256及以上、RSA-2048或ECC-256。
- 误区三：忽略回滚攻击。攻击者可能将设备回滚到旧版本固件，利用已知漏洞。应在镜像中嵌入版本号，并在Bootloader中实现版本回滚检测（Anti-Rollback）。
- 误区四：验证失败后处理不当。有些实现验证失败后仍继续启动，仅打印警告。这完全违背了安全启动的初衷，验证失败必须立即停止执行。
总结而言，启动链验证机制是嵌入式设备安全的第一道防线。它通过硬件信任根、逐级签名验证和严格失败处理，构建了一个从芯片上电到操作系统运行的完整信任边界。在实际工程中，需要根据SoC特性、产品威胁模型和量产成本，合理选择密钥算法、验证粒度和恢复策略。一个设计良好的启动链，不仅能够防御固件篡改，还能为后续的安全功能（如安全OTA升级、可信执行环境）奠定基础。