2、信任根基础：信任根（Root of Trust）的概念、类型（硬件、固件、软件）、信任链传递模型
在Secure Boot安全启动链的构建中，信任根（Root of Trust，RoT）是整个安全体系的锚点。如果信任根被攻破，那么基于它构建的所有安全校验都将失去意义。本章将深入剖析信任根的核心概念、三种主要类型（硬件、固件、软件）以及信任链的传递模型，帮助您理解为什么“信任必须从一个不可信的起点开始建立”，以及如何在工程实践中选择和应用合适的信任根。
2.1 核心原理：为什么需要信任根
信任根的本质是一个“无条件可信”的实体。在密码学和安全工程中，信任链必须有一个起点，这个起点本身无法通过链式验证来证明其可信性，而是通过物理保护、制造过程保证或逻辑隔离来确立其可信性。信任根的核心价值在于：它为整个安全启动链提供了一个不可伪造、不可篡改、不可绕过的基准点。
从工程角度看，信任根需要满足三个基本属性：
- 不可变性（Immutability）：信任根自身不能被运行时软件修改，通常通过硬件只读存储或一次性可编程（OTP）区域实现。
- 不可绕过性（Non-bypassability）：系统启动路径必须强制经过信任根的校验逻辑，不能存在旁路或跳转指令。
- 可度量性（Measurability）：信任根能够对下一级代码进行度量（计算哈希）或验证签名，并给出明确的通过/失败结果。
在实际的SoC（片上系统）设计中，信任根通常固化在芯片内部的Boot ROM中。这段代码在芯片制造时写入，之后任何软件都无法修改它。Boot ROM作为第一级信任锚点，负责验证后续加载的Bootloader代码。
2.2 信任根的类型与工程选型
根据实现载体和安全属性的不同，信任根可分为硬件信任根、固件信任根和软件信任根三种类型。在实际产品中，往往是多种信任根组合使用，形成纵深防御体系。
| 类型 | 典型载体 | 安全强度 | 更新能力 | 适用场景 |
|---|---|---|---|---|
| 硬件信任根 | eFuse、OTP、TPM芯片、PUF | 最高（物理隔离） | 不可更新或需特殊授权 | 高安全要求设备、金融终端、军工 |
| 固件信任根 | Boot ROM、安全引导块、微码 | 高（只读存储） | 通常不可更新，部分可补丁 | 通用SoC、嵌入式Linux设备 |
| 软件信任根 | OS内核校验、安全策略配置、证书库 | 中（依赖系统完整性） | 可灵活更新 | 普通消费电子、IoT设备 |
2.2.1 硬件信任根
硬件信任根是最强的信任锚点，它将密钥或信任凭证存储在专用硬件中，与主处理器隔离。常见的实现包括：
- eFuse/OTP：芯片内部的一次性可编程存储，用于存放根密钥哈希或设备唯一密钥。一旦写入，无法通过软件读取或修改。
- TPM（可信平台模块）：独立的密码协处理器，提供受保护的密钥存储、平台配置寄存器（PCR）和远程证明功能。
- PUF（物理不可克隆函数）：利用芯片制造过程中的物理差异生成唯一指纹，无需显式存储密钥，抗物理攻击能力强。
硬件信任根的选型需要权衡成本与安全等级。例如，消费级路由器可能仅使用eFuse存储公钥哈希，而金融POS终端则要求独立TPM芯片。
2.2.2 固件信任根
固件信任根通常指芯片出厂时烧录的Boot ROM代码。它位于CPU的复位向量地址，上电后第一条指令就从这里执行。Boot ROM的主要职责包括：初始化最小硬件环境（时钟、内存控制器）、从固定存储介质（如eMMC、SPI Flash）读取Bootloader、验证其签名或哈希、然后跳转执行。
固件信任根的一个关键设计是“不可变代码”。即使发现Boot ROM存在漏洞，也只能通过芯片改版修复，无法在线更新。因此，Boot ROM的代码量必须精简，逻辑必须经过严格的形式化验证。
2.2.3 软件信任根
软件信任根是信任链的末端，它依赖于操作系统或应用层的安全机制。例如，Linux内核在启动时验证驱动模块的签名，Android系统验证APK的签名。软件信任根的优势是灵活性高，可以随时更新证书和策略；劣势是它本身运行在复杂的软件环境中，攻击面较大。
2.3 信任链传递模型：从RoT到应用层
信任链传递模型描述了信任如何从信任根逐级扩展到整个系统。其核心思想是：每一级组件在加载下一级组件之前，必须验证后者的完整性和真实性。只有验证通过，信任才得以传递；一旦验证失败，启动过程立即终止。
标准的信任链传递过程如下：
- 步骤1：上电复位，CPU从Boot ROM开始执行，此时信任根已确立。
- 步骤2：Boot ROM验证Bootloader，使用内置公钥验证Bootloader的签名，同时计算其哈希值并与OTP中存储的期望值比对。
- 步骤3：Bootloader验证OS内核，Bootloader加载内核映像到内存，验证其签名和完整性度量值。
- 步骤4：OS内核验证驱动和服务，内核在加载模块时逐一对模块进行签名校验。
- 步骤5：应用层验证，应用程序或容器镜像在启动时通过证书链验证其来源。
这个模型的关键在于“度量-验证-执行”的循环。每一步的验证结果都会影响后续的执行路径，任何一步失败都会导致启动中止或进入恢复模式。
2.4 实战场景：基于ARM TrustZone的信任链构建
为了更直观地理解信任根和信任链的工程实现，我们以一款基于ARM Cortex-A72的工业网关设备为例，展示其安全启动链的构建过程。
背景与约束：该设备部署在电力监控系统中，要求支持远程升级，但必须防止固件被逆向或篡改。硬件平台选用NXP i.MX8M Plus处理器，该芯片内置Boot ROM和eFuse。安全需求等级为“高”，要求即使攻击者获得物理访问权限，也无法植入恶意固件。
初始现象与目标：设备在开发阶段发现，通过串口可以进入Uboot命令行，并手动加载未签名的内核镜像。目标是通过配置信任根和信任链，彻底关闭这一后门。
关键输入参数：
- eFuse区域大小：4KB，用于存储RSA公钥哈希（SHA-256）和启动配置。
- Boot ROM版本：i.MX8M Plus的ROM版本支持HAB（High Assurance Boot）v4.2。
- 签名工具：NXP提供的CST（Code Signing Tool）工具集。
分析判断过程：我们首先确认Boot ROM的HAB功能默认启用，但eFuse中的公钥哈希未烧录，导致HAB处于“开放模式”，任何镜像都能通过验证。攻击者正是利用这一点，在Uboot阶段加载了自定义内核。
实际操作步骤：
- 生成RSA-2048密钥对，私钥保存在离线HSM中，公钥导出为二进制格式。
- 使用CST工具计算公钥的SHA-256哈希，并通过JTAG接口烧录到eFuse的SRK_HASH区域。
- 将eFuse的HAB模式从“开放”切换为“封闭”，使Boot ROM强制验证所有后续镜像。
- 为Uboot和内核镜像添加签名，签名数据附加在镜像尾部，并更新镜像头部的签名信息。
- 重新烧录带签名的Uboot和内核，重启设备验证启动流程。
结果对比：配置完成后，尝试加载未签名镜像时，Boot ROM直接拒绝启动，串口输出“HAB Event: Authentication failed”。设备只能启动经过签名的镜像，攻击路径被有效阻断。
风险与代价：eFuse烧录是不可逆操作，一旦封闭HAB模式，后续所有固件更新都必须使用正确的私钥签名。如果私钥丢失，设备将变砖。因此，密钥管理流程必须严格规范，建议使用HSM存储私钥并建立密钥备份机制。
复盘经验：信任根的配置必须在产品定义阶段就纳入设计，而不是在开发后期补救。同时，建议在eFuse烧录前进行完整的测试，包括签名验证失败场景、密钥轮换场景等。
2.5 常见误区与总结复盘
在信任根和信任链的工程实践中，以下误区需要特别警惕：
- 误区1：信任根越多越好。实际上，过多的信任根会增加密钥管理的复杂度，并扩大攻击面。应选择最少且最强的信任根组合。
- 误区2：信任链只覆盖启动阶段。信任链需要延伸到运行时更新、外设固件加载等场景，否则攻击者可以在启动完成后通过动态加载恶意模块绕过。
- 误区3：忽略物理攻击防护。如果攻击者能够通过探针读取eFuse内容或干扰总线信号，信任根的安全性将大打折扣。需要结合主动屏蔽层、总线加密等措施。
- 误区4：信任根与密钥管理脱节。信任根存储的只是公钥哈希，真正的私钥管理才是安全的核心。私钥泄露意味着整个信任链崩塌。
总结而言，信任根是Secure Boot安全启动链的基石，其类型选择取决于产品的安全等级、成本预算和更新策略。信任链传递模型则提供了一套系统化的验证框架，确保从芯片上电到应用运行的每一个环节都经过完整性校验。在实际工程中，需要将信任根配置、密钥管理、镜像签名和启动策略作为一个整体来设计，才能构建出真正可信的安全启动环境。