4、Secure Boot概念：Secure Boot的定义、信任根（Root of Trust）、信任链（Chain of Trust）与安全启动流程

在TinyML设备中，固件通常运行在资源极度受限的MCU（如Cortex-M系列）或MPU上，且往往部署在物理不可控的边端环境中。攻击者一旦通过UART、JTAG、SPI Flash编程器或OTA漏洞篡改固件，就能植入后门、窃取模型参数或使设备沦为僵尸网络节点。Secure Boot（安全启动）正是抵御此类攻击的第一道硬件防线。它的核心思想并不复杂：确保设备每次上电或复位后，只执行经过数字签名验证的、完整且未被篡改的固件镜像。本章将深入剖析Secure Boot的定义、信任根（Root of Trust, RoT）、信任链（Chain of Trust）的构建方式，并详细拆解从复位向量到应用运行的完整安全启动流程。

上图展示了Secure Boot的三大核心组件与启动流程的映射关系。信任根（RoT）是设备上电后第一个被信任的代码和数据，它通常固化在芯片内部的Boot ROM中，不可修改。信任链则是由Boot ROM逐级验证后续固件的过程，每一级验证通过后才将执行权交给下一级。信任边界则划定了哪些代码和数据是受保护的，哪些是外部不可信的。下面我们将逐一深入展开。

4.1 Secure Boot的定义与核心目标

Secure Boot并非一个单一的技术，而是一套端到端的固件完整性验证机制。从广义上讲，它涵盖了从硬件复位到操作系统或应用加载的整个过程中的所有安全校验步骤。其核心目标可以归纳为以下三点：

• 完整性（Integrity）：确保固件镜像在传输或存储过程中未被篡改。通常通过SHA-256等哈希算法实现，任何比特位的改变都会导致哈希值不匹配。
• 真实性（Authenticity）：确保固件镜像确实来自合法的发布者（通常是设备制造商或开发者）。这通过非对称加密算法（如RSA-2048、ECDSA P-256）的数字签名来实现。
• 抗回滚（Anti-Rollback）：防止攻击者将设备固件降级到存在已知漏洞的旧版本。这通常依赖于OTP（一次性可编程）存储器中的版本计数器或eFuse。

在TinyML场景下，Secure Boot还有一层特殊意义：保护模型知识产权（IP）。如果攻击者能够直接读取Flash中的模型文件，经过训练的神经网络权重和结构就会被窃取。Secure Boot通过验证固件合法性，间接阻止了通过替换固件来dump内存或Flash的物理攻击手段。

4.2 信任根（Root of Trust）：一切安全的基石

信任根是安全启动链的起点，它必须满足两个条件：不可篡改性和不可绕过性。在MCU中，信任根通常由两部分组成：

1. Boot ROM（掩膜ROM）：芯片出厂时固化的只读代码，是CPU复位后执行的第一段指令。它负责初始化最小硬件环境（如时钟、SRAM控制器），并包含验证下一级固件所需的公钥或公钥哈希。
2. OTP/eFuse（一次性可编程存储器）：用于存储根公钥的哈希值（而非公钥本身，以节省空间）以及安全配置位（如“强制安全启动使能”位）。这些位一旦烧写就无法修改。

为什么Boot ROM中不直接存储完整的公钥？因为公钥本身可能长达几百字节（RSA-2048为256字节），而Boot ROM的空间极其宝贵。更安全的做法是：在Boot ROM中存储一个固定的、不可变的公钥哈希（如SHA-256摘要，32字节），然后在外部Flash中存储完整的公钥。Boot ROM启动时，先计算外部公钥的SHA-256值，与OTP中的哈希比对，一致则采用该公钥验证后续固件。这样既节省了ROM空间，又防止了攻击者替换公钥。

信任根组件	存储介质	内容	防篡改能力
Boot ROM	芯片掩膜	启动代码、公钥哈希比较逻辑	物理不可变（需光罩攻击）
OTP/eFuse	硅片内	根公钥SHA-256、版本号、安全使能位	一次性烧写，不可逆向
SRAM (临时)	片内易失	启动过程中的临时变量、栈	掉电即失，需防冷启动攻击

4.3 信任链（Chain of Trust）：逐级验证的传递模型

信任链的核心思想是“以信任传递信任”。由于Boot ROM无法容纳整个操作系统或TinyML运行时，它只能验证第一级引导程序（通常称为BL1或Secondary Bootloader）。然后，BL1负责验证BL2（可能是主引导程序或RTOS内核），BL2再验证应用固件。每一级都承担着验证下一级的责任。

这种设计的关键在于最小化信任根的攻击面。Boot ROM中的代码越少，被攻击的可能性就越低。同时，每一级验证都使用相同的密码学原语（签名验证），但密钥可以不同。例如：

• Boot ROM 持有 根公钥 A（哈希存储在OTP）。
• BL1 使用 私钥 A 签名，Boot ROM用公钥A验证BL1。
• BL2 使用 私钥 B 签名，BL1中嵌入了公钥B的哈希，BL1验证BL2。
• App固件 使用 私钥 C 签名，BL2中嵌入了公钥C的哈希，BL2验证App。

这种分层密钥管理的好处是：即使应用固件的私钥C泄露，攻击者也只能伪造应用固件，无法影响Bootloader的完整性。如果要更换密钥，只需更新BL1或BL2中的公钥哈希，而无需修改Boot ROM。

4.4 安全启动流程详解：从复位到TinyML推理

下面以一个典型的基于ARM Cortex-M33 + TrustZone的TinyML设备为例，展示完整的安全启动流程。该流程分为五个阶段，每个阶段都有明确的输入、操作和输出。

阶段0: 硬件复位
  - CPU从0x00000000取出初始SP（栈指针）
  - CPU从0x00000004取出初始PC（程序计数器）
  - 该地址映射到芯片内部的Boot ROM

阶段1: Boot ROM执行 (信任根)
  - 初始化时钟、SRAM、关闭所有DMA
  - 读取OTP中的安全配置位（是否强制Secure Boot）
  - 从外部Flash固定偏移（如0x08000000）读取BL1头部
  - 计算BL1头部中公钥的SHA-256，与OTP中的哈希比对
  - 使用公钥验证BL1的签名（RSA或ECDSA）
  - 验证通过 → 跳转到BL1；失败 → 进入错误处理（如LED闪烁）

阶段2: BL1 (二级引导)
  - 初始化外部DDR（如果存在）
  - 验证BL2（主Bootloader）的签名和哈希
  - 验证BL2的版本号 >= OTP中的最低版本号（防回滚）
  - 跳转到BL2

阶段3: BL2 (主Bootloader)
  - 初始化外设（Flash控制器、加密引擎）
  - 验证TinyML应用固件（App.bin）的签名
  - 可选：解密固件（如果固件是加密存储的）
  - 将App加载到SRAM或DDR的特定区域
  - 设置MPU（内存保护单元），将Boot ROM和Bootloader区域设为只读
  - 跳转到App的入口地址

阶段4: TinyML应用运行
  - 应用初始化NPU/GPU/DSP
  - 加载模型权重（已验证的固件的一部分）
  - 开始推理任务

在整个流程中，任何一步验证失败都会导致设备停止启动。这是Secure Boot与普通启动最大的区别——普通启动遇到错误可能会尝试跳过或继续，而Secure Boot采取“Fail-Stop”策略。

4.5 案例拆解：某款NB-IoT智能传感器固件被篡改后的启动失败分析

为了更直观地理解Secure Boot的价值，我们来看一个实际案例。某公司生产了一款基于Cortex-M4的NB-IoT环境监测传感器，用于采集温湿度数据并上传云端。该设备支持OTA升级，但早期版本未启用Secure Boot。

攻击场景：攻击者通过监听无线信道获取了OTA升级包，发现固件未加密且无签名校验。攻击者修改了固件中的传感器校准参数，使设备上报虚假数据，同时植入了一个挖矿木马（虽然算力极低，但会消耗电池）。由于设备部署在偏远地区，维护人员无法及时现场更新，导致大量设备被“僵尸化”。

解决方案实施：公司决定在新版本固件中启用Secure Boot，并进行了以下改造：

1. 硬件层面：选用带有Boot ROM和OTP的MCU（如STM32L4系列），在产线上烧写OTP，写入根公钥哈希和版本号计数器。
2. 密钥管理：生成三对密钥——根密钥（存于HSM中）、Bootloader密钥、应用密钥。根密钥私钥离线保存在安全环境，仅用于签名Bootloader。
3. 签名流程：每次构建固件时，CI/CD流水线自动调用签名工具，使用应用私钥对固件进行ECDSA P-256签名，并将签名附加在固件头部。
4. OTA升级适配：OTA下载包中包含新固件+签名+版本号。BL2在升级前先验证签名和版本号，确认无误后才写入Flash。

结果对比：启用Secure Boot后，攻击者再次尝试篡改固件时，设备在启动阶段即检测到签名不匹配，拒绝启动并进入安全恢复模式（仅支持通过UART接收官方固件）。攻击者的恶意固件完全无法运行，且由于版本号计数器存在，也无法回滚到旧版本。

代价与复盘：该方案的代价是启动时间增加了约200ms（主要是RSA/ECDSA验签计算），以及Flash占用增加了约4KB（用于存储签名和公钥）。但相对于安全收益，这些代价完全可接受。复盘经验是：密钥管理流程比技术实现更重要——必须确保私钥不落入开发者个人电脑，而是存储在HSM或密钥管理服务中。

4.6 常见误区与总结

在实施Secure Boot时，开发者常陷入以下误区：

• 误区一：Secure Boot = 固件加密。Secure Boot主要解决“谁写的固件”和“固件是否被改过”，而固件加密解决“固件内容是否泄露”。两者可以独立使用，也可以结合。如果模型参数是核心资产，建议在Secure Boot基础上增加固件加密。
• 误区二：只要MCU支持Secure Boot就万事大吉。如果调试接口（JTAG/SWD）未锁定，攻击者可以直接通过调试器读写内存，绕过所有安全启动逻辑。必须同时烧写调试锁定位。
• 误区三：签名验证一次就够了。在复杂的TinyML系统中，如果应用固件支持动态加载模型（从文件系统读取），那么模型文件本身也需要签名或MAC校验，否则攻击者可以替换模型文件。
• 误区四：忽略防回滚。如果没有版本号检查，攻击者可以将设备回滚到旧版本，而旧版本可能没有修复某些漏洞。