安全启动基础：Secure Boot 的定义、作用、信任根与信任链概念
在嵌入式系统与固件安全领域，Secure Boot（安全启动）是构建设备可信运行环境的基石。它并非单一的技术点，而是一套从硬件根密钥到操作系统加载的完整验证机制。理解Secure Boot，首先需要厘清两个核心抽象概念：信任根（Root of Trust, RoT）与信任链（Chain of Trust, CoT）。信任根是系统内无条件被信任的硬件或固件实体，而信任链则是从该实体出发，逐级验证、逐级授权的一连串校验过程。本节将深入剖析Secure Boot的定义、作用，并重点拆解信任根与信任链的工程化实现逻辑。
上图展示了Secure Boot的核心架构：左侧为信任根（Boot ROM、eFuse/OTP、PUF），右侧为信任链的逐级验证过程。信任链的每一环都依赖上一环的验证结果，形成“由硬到软、由简到繁”的递进信任关系。下面我们将从定义、作用、信任根设计、信任链构建四个维度展开详细论述。
2.1 Secure Boot 的定义与核心作用
Secure Boot（安全启动）是指设备在上电启动过程中，通过密码学机制对固件镜像、引导加载程序、操作系统内核及关键系统文件进行完整性校验和来源认证，确保只有经过授权的、未被篡改的代码才能被执行。它解决的是“启动路径上的代码可信性”问题，而非数据加密问题。
Secure Boot 的核心作用可以归纳为以下四点：
| 作用维度 | 具体说明 | 典型威胁场景 |
|---|---|---|
| 完整性保护 | 检测固件镜像是否被篡改（如注入恶意代码、修改配置参数） | 攻击者通过UART或JTAG接口改写Flash中的Bootloader |
| 来源认证 | 验证镜像是否由设备厂商或授权方签名发布 | 使用伪造的第三方固件替换原厂固件 |
| 版本防回滚 | 通过版本计数器或Anti-Rollback机制阻止降级到有漏洞的旧版本 | 攻击者将已修复漏洞的固件降级为存在CVE的旧版本 |
| 信任边界隔离 | 确保低权限代码无法加载高权限代码，防止权限提升 | 利用引导阶段的缓冲区溢出获取内核态执行权限 |
从工程实践角度看，Secure Boot 并非一个单一功能模块，而是一个贯穿硬件启动、固件加载、内核初始化的安全状态机。它要求系统在“不可信环境”中建立“可信执行上下文”，这依赖于硬件提供的密码学原语（如SHA-256、RSA-2048/4096、ECC P-256）和密钥存储机制。
2.2 信任根（Root of Trust）的工程实现
信任根是安全启动的“锚点”，它本身不需要被验证，因为其可信性由物理硬件保证。在嵌入式系统中，信任根通常由以下三个硬件组件协同构成：
- Boot ROM（只读存储器）：固化在芯片内部的不可变代码，上电后CPU首先执行它。Boot ROM中包含了初始的验签逻辑和访问eFuse的驱动代码。由于Boot ROM在芯片制造时写入且无法修改，它天然具备不可篡改性。
- eFuse / OTP（一次性可编程存储器）：用于存储根密钥哈希（Root Key Hash, RKH）或根公钥本身。eFuse在出厂时烧录，之后无法改写。RKH通常是对根公钥的SHA-256摘要，长度为256位，占用8个32位eFuse字。
- PUF / TRNG（物理不可克隆函数 / 真随机数发生器）：PUF利用芯片制造过程中的工艺差异生成唯一且不可预测的硬件指纹，可用于派生密钥或作为熵源。TRNG则为签名验证提供随机数，防止重放攻击。
关键设计原则：信任根必须满足三个条件——不可绕过（CPU复位后强制从Boot ROM执行）、不可篡改（物理只读或一次性编程）、不可预测（密钥材料具有足够熵）。在实际项目中，若eFuse空间有限，通常只存储RKH而非完整公钥，以节省宝贵的OTP资源。
以NXP i.MX8M系列为例，其Boot ROM在复位后首先读取eFuse中的RKH，然后从Boot设备（SD/eMMC/SPI NOR）加载第一级引导镜像（SPL），并使用RKH对应的公钥验证SPL的签名。如果验证失败，Boot ROM会进入串行下载模式（USB/UART），等待主机重新烧录。
2.3 信任链（Chain of Trust）的构建与传递
信任链的构建遵循“逐级验证、逐级授权”的原则。每一级引导代码在获得执行权之前，必须通过上一级代码的签名验证。典型的信任链分为以下阶段：
- 阶段0（Boot ROM）：验证一级引导程序（SPL或FSBL）的签名。此阶段使用根公钥（从eFuse的RKH恢复）验证SPL的签名和版本号。
- 阶段1（SPL/FSBL）：SPL被验证通过后，获得执行权。SPL负责初始化DDR内存，并验证二级引导程序（如U-Boot或ATF）的签名。SPL中嵌入了二级公钥（由根私钥签发证书），用于验证下一级镜像。
- 阶段2（U-Boot/ATF）：U-Boot验证Linux内核镜像（Image/Image.gz）和设备树文件（DTB）的签名。同时，U-Boot还负责验证内核启动参数（bootargs）的完整性，防止攻击者篡改启动参数绕过安全机制。
- 阶段3（Linux Kernel）：内核在挂载根文件系统前，验证根文件系统的完整性（如使用dm-verity），并支持内核模块的签名验证（CONFIG_MODULE_SIG）。
信任链的传递过程中，密钥层级至关重要。通常采用“根密钥-中间密钥-代码签名密钥”的三级结构：
根密钥对 (RSA-4096)
├── 中间密钥对 (RSA-3072) — 由根私钥签发证书
│ ├── 代码签名密钥 A (RSA-2048) — 用于签名SPL
│ ├── 代码签名密钥 B (RSA-2048) — 用于签名U-Boot
│ └── 代码签名密钥 C (RSA-2048) — 用于签名Kernel
└── 吊销列表 (Revocation List) — 记录被废弃的密钥ID这种层级设计的好处是：当某一级代码签名密钥泄露时，只需吊销该密钥并更新上一级证书，而无需更换硬件中的根密钥。同时，根私钥可以离线保存在HSM（硬件安全模块）中，降低泄露风险。
2.4 实战场景：基于ARM Trusted Firmware (ATF) 的安全启动链路
为了更直观地理解信任链的运作，我们以一个基于ARM AArch64架构的典型设备为例，展示从Boot ROM到Kernel的完整验签流程。
场景背景：某工业网关设备使用NXP Layerscape LS1028A处理器，需要满足IEC 62443-4-2安全等级要求。设备采用ATF作为安全监控层，使用U-Boot作为主引导程序。
关键输入参数：
- eFuse中烧录RKH =
0x3A7F...9C2B（SHA-256摘要） - Boot ROM版本：LS1028A Rev2.0
- 镜像签名算法：RSA-3072 + SHA-256
- 镜像版本号：SPL v1.2，U-Boot v2023.04，Kernel v6.1.28
启动过程日志（串口输出）：
ROM: Boot from SD card
ROM: RKH[0] = 3A7F...9C2B
ROM: Loading SPL from offset 0x1000
ROM: Verifying SPL signature... OK
ROM: SPL version 1.2, anti-rollback check passed
SPL: Initializing DDR (4GB)
SPL: Loading U-Boot from FIT image
SPL: Verifying U-Boot signature... OK
U-Boot: Verifying Kernel Image + DTB signature... OK
U-Boot: Booting Linux 6.1.28 (verified boot)
Kernel: dm-verity enabled, rootfs verified分析判断过程：
在阶段0，Boot ROM从SD卡偏移0x1000处读取SPL头部，提取签名和版本号。首先使用eFuse中的RKH恢复根公钥，然后对SPL的镜像体（不含签名部分）计算SHA-256哈希，再用根公钥验证RSA签名。同时，SPL的头部包含一个32位的版本计数器，Boot ROM将其与eFuse中的最低防回滚版本号比较，若SPL版本低于阈值则拒绝启动。
在阶段1，SPL初始化DDR后，从FIT镜像（Flattened Image Tree）中提取U-Boot二进制。FIT镜像内部嵌入了签名节点，SPL使用自身携带的中间公钥验证U-Boot的签名。这里值得注意的是，SPL的公钥并非直接存储在SPL代码中，而是通过“公钥证书”的方式嵌入，证书由根私钥签发，SPL在验证U-Boot前先验证证书链。
实际操作步骤（开发环境）：
- 生成密钥对：
openssl genrsa -out root_key.pem 4096，并计算RKH：openssl rsa -in root_key.pem -pubout | sha256sum。 - 烧录RKH到eFuse：使用NXP提供的
efuse_program工具，将RKH写入fuse bank 0的字0-7。 - 签名SPL：使用
mkimage -T fsl_imx8m -s -r root_key.pem -v 1.2 spl.bin生成带签名的SPL。 - 构建FIT镜像：编写
fit.its文件，包含U-Boot和DTB，并使用mkimage -f fit.its fit.itb生成。 - 验证回滚保护：在eFuse中设置最低版本号
0x00010002，然后尝试烧录v1.1的SPL，观察启动是否被拒绝。
结果对比：
| 测试场景 | 预期结果 | 实际结果 | 耗时 |
|---|---|---|---|
| 正常签名镜像 | 启动成功 | 启动成功，日志显示所有验签通过 | 2.3s |
| 篡改SPL（修改1字节） | 启动失败 | Boot ROM报错“Signature verification failed”，进入USB下载模式 | 0.8s |
| 降级到v1.1 SPL | 拒绝启动 | Boot ROM报错“Anti-rollback check failed” | 0.5s |
风险与代价：该方案将启动时间增加了约0.5秒（主要是RSA验签计算），但换取了高等级的安全保障。需要注意的是，eFuse烧录是一次性操作，一旦RKH写入后无法修改，因此必须在量产前完成密钥规划。此外，若根私钥泄露，所有已部署设备都需要召回更新eFuse，代价极高。
常见误区提醒：很多开发者误以为“只要做了签名验证就是Secure Boot”。实际上，如果签名密钥存储在可读的Flash中（而非eFuse），攻击者可以通过读取Flash提取密钥，然后重新签名恶意固件。Secure Boot的强度取决于信任根的保护级别，而非签名算法本身。此外，版本回滚保护（Anti-Rollback）必须与签名验证配合使用，否则攻击者可以降级到存在已知漏洞的旧版本。
2.5 信任链的常见误区与设计复盘
在实施Secure Boot时，工程师常陷入以下认知或工程陷阱：
- 误区一：信任链越长越安全。实际上，每一级验证都会增加启动时间和攻击面。合理的信任链应控制在3-4级，过长的链反而增加了中间环节被攻击的风险。
- 误区二：只验证引导程序，不验证根文件系统。如果根文件系统未加密或未做完整性校验，攻击者可以在内核启动后替换系统二进制文件，实现持久化后门。应使用dm-verity或IMA（Integrity Measurement Architecture）补全信任链。
- 误区三：忽略调试接口的暴露。即使Secure Boot验证通过，如果JTAG或串口调试接口在量产固件中未禁用，攻击者仍可通过调试接口读取内存或修改寄存器，绕过安全启动。应在量产配置中永久关闭调试接口。
- 误区四：密钥管理流程混乱。开发环境、测试环境、生产环境应使用不同的密钥对。若开发密钥泄露，攻击者可签名开发版固件，虽然无法在生产设备上启动（因为RKH不同），但可能泄露安全机制细节。
设计复盘建议：在项目初期，应绘制一张“信任链流程图”，明确每一级的验证者、被验证者、密钥来源、失败处理策略。同时，建立密钥生命周期管理规范，包括密钥生成、分发、轮换、吊销和销毁流程。对于高安全等级设备，建议引入独立的Secure Element（安全芯片）作为信任根，将RKH存储在SE内部，而非SoC的eFuse中，以增强抗物理攻击能力。
经验之谈：在调试Secure Boot时，建议在Boot ROM和SPL中增加详细的日志输出（通过串口），记录验签的每一步状态（如“RKH loaded”、“Signature OK”、“Version check passed”）。这不仅能加速开发调试，还能在量产后的故障排查中提供关键线索。但注意，生产固件中应移除或禁用这些调试日志，避免信息泄露。
综上所述，Secure Boot的信任根与信任链设计是一个系统工程，需要硬件、固件、密钥管理三方面协同。理解“信任根提供锚点，信任链传递信任”的核心思想，是后续实现固件镜像验签流程的基础。在实际项目中，应根据设备的安全等级、启动时间约束、硬件成本等因素，合理选择信任根实现方式（eFuse vs. Secure Element）和信任链长度，在安全性与可用性之间取得平衡。