3、安全启动概述：安全启动的目标、威胁模型（篡改、重放、恶意注入）、安全启动与可信启动的区别、信任根（RoT）概念

在嵌入式系统与智能设备大规模普及的今天，Bootloader 作为系统上电后执行的第一段软件，其安全性直接决定了整个设备的安全边界。攻击者一旦篡改或替换 Bootloader，即可绕过所有上层安全机制，实现持久化控制、数据窃取或功能破坏。因此，理解安全启动（Secure Boot）的目标、威胁模型、信任根（Root of Trust, RoT）概念，以及与可信启动（Trusted Boot）的边界，是构建可信设备的基础。本章将从工程实践视角出发，系统拆解安全启动的核心原理与落地要点。

3.1 安全启动的核心目标

安全启动并非单一技术，而是一套从硬件信任根出发、逐级验证的完整机制。其根本目标可以归纳为三个层面：确保代码完整性（Integrity）、验证代码真实性（Authenticity）以及建立可传递的信任链（Chain of Trust）。完整性保证 Bootloader 镜像在存储或传输过程中未被篡改；真实性则通过数字签名确认镜像确实来自合法的设备厂商或开发者；信任链则确保从 BootROM 到操作系统内核的每一级加载都经过验证，不存在"跳过验证"的旁路。

从工程角度看，安全启动还需要满足几个关键属性：不可绕过性——攻击者无法通过修改启动配置或短路调试接口来跳过验证；最小可信计算基（TCB）——信任根应尽可能小，便于形式化验证和审计；失败安全（Fail-Safe）——验签失败时系统必须进入安全恢复模式，而不是继续执行。此外，安全启动还应支持安全更新机制，允许在设备生命周期内安全地升级 Bootloader 和固件，同时防止降级攻击。

3.2 威胁模型：篡改、重放与恶意注入

要设计有效的安全启动方案，必须首先明确对抗的威胁。嵌入式设备的攻击面广泛，从物理接触到远程利用，从供应链到调试接口，攻击者可能在任何环节发起攻击。以下三类威胁是安全启动需要重点防御的。

3.2.1 篡改（Tampering）

篡改是指攻击者直接修改 Bootloader 的二进制内容，植入恶意代码或后门。常见的篡改手段包括：拆解芯片通过 SPI/I2C 接口读取并改写 Flash 内容；利用调试接口（JTAG/SWD）在运行时修改内存；或者通过固件更新机制上传伪造的镜像。篡改攻击的隐蔽性很强，因为攻击者可以保持镜像的原始功能不变，仅添加恶意逻辑。防御篡改的核心是数字签名验证——BootROM 使用公钥验证 Bootloader 的签名，任何字节的修改都会导致验签失败。

3.2.2 重放（Replay）

重放攻击，又称回滚攻击，是指攻击者将设备固件回退到存在已知漏洞的旧版本。例如，某厂商在 v1.2 版本中修复了一个 Bootloader 缓冲区溢出漏洞，但攻击者将设备回滚到 v1.1，利用该漏洞获取控制权。重放攻击的防御不能仅靠签名验证，因为旧版本同样具有合法签名。必须引入防回滚计数器（Anti-Rollback Counter）或版本号单调递增机制。具体实现上，可以在 eFuse 或 TPM 中维护一个单调递增的计数器，每次更新固件时计数器加一，BootROM 在验签时同时检查镜像中的版本号是否大于等于当前计数器值。

3.2.3 恶意注入（Malicious Injection）

恶意注入是指攻击者通过设备的外部接口（USB、UART、CAN、以太网等）向 Bootloader 的解析逻辑发送精心构造的数据，利用解析漏洞（如缓冲区溢出、整数溢出）执行任意代码。这类攻击不直接修改 Flash 内容，而是利用 Bootloader 自身的缺陷。例如，Bootloader 在解析网络启动（PXE）或 USB 启动镜像时，如果对数据长度校验不严，攻击者可以构造超长字段触发溢出。防御恶意注入需要严格的输入验证、内存保护机制（如 SMEP/SMAP、W^X）以及最小化攻击面——在生产环境中禁用不必要的启动介质和调试接口。

3.3 安全启动与可信启动的区别

安全启动（Secure Boot）与可信启动（Trusted Boot）经常被混用，但它们在目标、机制和结果上存在本质区别。理解这一区别对于正确设计系统安全架构至关重要。

安全启动的核心是阻止未授权代码的执行。它通过逐级签名验证，在加载每个启动组件之前检查其完整性和真实性。如果验证失败，启动过程立即终止。安全启动是一种强制策略，它确保设备只能运行经过签名的代码。典型实现包括 UEFI Secure Boot、ARM Trusted Firmware (TF-A) 中的认证启动。

可信启动的核心是度量与报告。它并不阻止代码执行，而是记录启动过程中每个组件的哈希值（度量值），并将这些值扩展到 TPM 的 PCR（Platform Configuration Register）中。系统启动后，远程验证方或本地策略引擎可以比对 PCR 值，判断系统是否处于可信状态。可信启动是一种感知与证明机制，它允许系统运行，但会记录"运行了什么"。

在实际系统中，两者常常结合使用：安全启动负责建立信任链，可信启动负责将信任状态扩展到操作系统和应用程序。例如，U-Boot 在验证内核镜像签名后（安全启动），将内核镜像的哈希值扩展到 TPM PCR[4]（可信启动），供后续的远程证明使用。

3.4 信任根（RoT）概念与工程实现

信任根是整个安全启动体系中最基础、最关键的组件。它是一组不可被篡改的、硬件强制的信任锚点，所有安全验证都从这里开始。信任根必须满足三个条件：不可变性——攻击者无法修改信任根的代码或数据；可信性——信任根的行为可以被验证和审计；最小性——信任根的代码量应尽可能小，以减少漏洞面。

在典型的 SoC 中，信任根由以下组件构成：

• BootROM（只读存储器）：芯片出厂时烧录的不可变代码，是信任链的第一环。BootROM 负责初始化最小硬件环境（时钟、SRAM），并验证下一级 Bootloader 的签名。
• OTP / eFuse：一次性可编程存储，用于存放根公钥的哈希、安全启动使能位、防回滚计数器等关键安全参数。eFuse 一旦烧写不可逆转，确保攻击者无法修改公钥。
• 硬件密码引擎：专用的 RSA/ECC/SHA 加速器，确保签名验证在安全环境中执行，避免软件实现中的侧信道泄露。
• 安全存储：用于保存设备私钥、证书链等敏感数据，通常与主存储隔离，防止物理攻击读取。

信任根的建立过程通常如下：芯片厂商在出厂时将 BootROM 和根公钥哈希烧入芯片；设备制造商在开发阶段生成自己的密钥对，将公钥哈希烧入 eFuse；BootROM 在每次启动时，使用 eFuse 中的公钥哈希验证 Bootloader 的签名。整个信任链从 BootROM 开始，逐级传递，每一级都验证下一级的签名，直到操作系统内核。

3.4.1 信任根的工程实现案例

以 NXP i.MX8M 系列处理器为例，其安全启动实现如下：

1. BootROM 阶段：芯片上电后，BootROM 从 eFuse 中读取 SRK（Super Root Key）哈希，并初始化 HAB（High Assurance Boot）引擎。
2. 签名验证：BootROM 加载 Bootloader 镜像及其签名块（包含签名、证书链、元数据），使用 SRK 公钥验证证书链，再使用证书中的公钥验证镜像签名。
3. 防回滚：BootROM 检查镜像中的版本号是否大于等于 eFuse 中的安全版本号（Security Configuration）。
4. 启动控制：验证通过后，BootROM 将控制权交给 Bootloader；验证失败则进入串行下载模式或安全失败模式。

3.5 实战场景：从开发到量产的安全启动落地

下面通过一个完整的实战案例，展示安全启动从开发到量产的落地过程。假设我们基于 i.MX8M Mini 平台开发一款工业边缘网关，需要实现安全启动。

背景与约束：产品面向工业现场，要求防止固件被篡改和回滚；开发团队需要保留调试能力，但生产设备必须关闭调试接口；产品生命周期 5 年以上，需要支持安全的远程固件升级。

实施步骤：

1. 密钥生成与分级管理：使用 CST 工具生成四级密钥体系——SRK（根密钥）、CSF（命令序列文件密钥）、IMG（镜像密钥）、OEM（厂商自定义密钥）。SRK 私钥离线保存在硬件安全模块（HSM）中，仅用于签发 CSF 和 IMG 证书。
2. 开发阶段配置：在开发板上，通过 U-Boot 环境变量启用 HAB 的"开放模式"（Open Mode），此时 BootROM 仅记录验证结果但不阻断启动，便于调试。同时使用 hab_status 命令检查验证状态。
3. 签名 Bootloader：使用 CST 工具对 U-Boot 镜像进行签名，生成签名块并附加到镜像末尾。签名命令示例：

# 生成 CSF 命令序列文件
cst -i csf_uboot.txt -o csf_uboot.bin

# 将 CSF 附加到 U-Boot 镜像
cat u-boot.bin csf_uboot.bin > u-boot_signed.bin

# 烧写签名后的镜像到 Flash
dd if=u-boot_signed.bin of=/dev/mmcblk0 bs=1k seek=33 conv=fsync

4. 烧写 eFuse：在确认开发板验证通过后，烧写 SRK 哈希到 eFuse，并设置安全启动使能位。烧写命令（由 U-Boot 提供）：

# 烧写 SRK 哈希（fuse 命令）
fuse prog 0 0 0x12345678
fuse prog 0 1 0x9abcdef0
# ... 依次烧写 8 个 32 位字（共 256 位）

# 使能安全启动
fuse prog 0 6 0x00000002

5. 关闭调试接口：在生产固件中，通过 eFuse 或 GPIO 配置禁用 JTAG/SWD 端口，防止攻击者通过调试接口读取内存或修改寄存器。
6. 验证与测试：生产后执行以下验证流程：正常启动确认系统运行；尝试篡改 Bootloader 任意字节，确认设备进入安全失败模式；尝试烧写旧版本固件，确认防回滚机制生效。

结果与复盘：实施安全启动后，设备在以下场景中的表现：篡改 Bootloader 后设备无法启动，串口输出 HAB 验证失败错误码 0x1A；回滚到旧版本时，BootROM 检测到版本号低于 eFuse 中的安全版本号，拒绝加载；通过 USB 注入恶意数据时，由于 Bootloader 已禁用 USB 启动模式，攻击面被有效收敛。整个实施过程中，最大的风险点在于 eFuse 烧写不可逆——一旦烧错 SRK 哈希，芯片将变砖。因此建议在量产前使用至少 3 片样机进行完整的烧写与验证测试。

3.6 常见误区与总结复盘

在安全启动的工程实践中，以下误区值得特别注意：

• 误区一：只验证签名，不验证版本。这会导致重放攻击。必须结合防回滚计数器或版本号检查。
• 误区二：信任根代码量过大。BootROM 或安全监控器中包含过多功能会增加漏洞面。信任根应保持最小化，只做签名验证和基本硬件初始化。
• 误区三：开发模式直接用于生产。开发模式通常关闭了签名验证或允许跳过验证，必须通过 eFuse 切换为生产模式。
• 误区四：忽略调试接口。即使安全启动验证通过，如果 JTAG 端口未关闭，攻击者仍可通过调试接口读取内存、修改寄存器，绕过安全机制。
• 误区五：密钥管理不当。私钥泄露意味着整个安全体系崩溃。必须建立严格的密钥生命周期管理流程。

总结：安全启动是嵌入式设备安全的第一道防线，其核心在于建立从信任根开始的逐级验证链。理解威胁模型（篡改、重放、恶意注入）有助于针对性地设计防御措施；区分安全启动与可信启动有助于合理规划系统安全架构；而信任根的正确实现则是整个体系的基础。在实际项目中，安全启动的落地不仅是技术问题，更是流程和管理问题——密钥管理、生产烧写、版本控制、应急恢复等环节都需要严谨的工程规范。建议开发者在项目初期就引入安全启动设计，避免在产品成型后再进行安全加固带来的高成本和架构调整风险。