📚 课程目录第2章嵌入式安全基础

2. 嵌入式安全基础

在讨论 TF-M 安全固件升级与回滚保护之前，必须先建立一套完整的嵌入式安全心智模型。安全启动、信任根、可信执行环境、Arm TrustZone 与 TF-M 架构并不是彼此孤立的概念，而是从“芯片上电第一行代码”到“应用安全服务”逐层递进、相互支撑的技术栈。理解它们之间的依赖关系，才能明白为什么固件升级必须被签名、为什么回滚需要版本计数器、以及为什么安全固件通常运行在隔离的安全域中。

一、信任根：安全链条的起点

信任根（Root of Trust, RoT）是整个系统安全性的绝对起点。它通常由芯片内部不可修改的 ROM 代码、硬件密钥存储、一次性可编程熔丝（OTP/eFuse）以及受保护的调试接口组成。信任根的核心特征是：其行为在制造后无法被软件篡改，因此可以作为验证后续所有固件的“信任锚点”。

信任根一般提供三类基础能力：

不可变启动代码：芯片出厂即固化，负责上电后的第一段执行逻辑。
硬件唯一密钥：用于验证签名或派生会话密钥，私钥永不出芯片。
安全状态存储：保存安全启动使能位、生命周期状态、防回滚计数器等。

信任根不是“一个模块”，而是一组硬件与固件协同的最小可信集合。只要其中任一环节可被软件改写，整条信任链就会失效。

二、安全启动：逐级验证的信任链

安全启动（Secure Boot）利用信任根，在每次上电时逐级验证下一阶段固件的完整性与真实性。典型流程是：Boot ROM 验证一级引导程序 BL1，BL1 验证 BL2，BL2 验证安全固件与安全应用，最后再验证非安全侧镜像。每一级都使用上一级提供的公钥或哈希进行校验，形成一条不可中断的信任链。

验证内容通常包括：镜像哈希是否匹配、数字签名是否由可信私钥签发、镜像版本是否满足最低版本要求、以及防回滚计数器是否单调递增。若任一项失败，系统应进入安全失败状态，而不是继续启动。

BootROM (RoT)
  └─ 验证 BL1 签名与哈希
       └─ 验证 BL2 签名与哈希
            ├─ 验证 TF-M 安全固件
            │    └─ 验证安全服务与安全应用
            └─ 验证 Non-Secure 应用镜像
                 └─ 跳转到非安全世界运行

三、可信执行环境与 Arm TrustZone

可信执行环境（TEE）是在同一颗处理器上，通过硬件隔离机制划分出的安全执行区域。Arm TrustZone 是 Cortex-A 与 Cortex-M 上广泛采用的实现方式：它把系统划分为安全世界（Secure World）与非安全世界（Non-Secure World），并通过总线、内存、外设和中断的访问控制，阻止非安全代码读取安全资源。

在 Cortex-M 上，TrustZone 引入了安全属性单元（SAU）和实现定义属性单元（IDAU），用于定义各内存区域的 Secure/Non-Secure 属性。安全世界可以访问非安全资源，反之则被硬件阻止。这种单向隔离是 TF-M 能够把密钥、加密引擎和安全存储保护起来的基础。

四、TF-M 架构概览

TF-M（Trusted Firmware-M）是 Arm 为 Cortex-M 平台提供的开源安全固件参考实现。它运行在安全世界，向上提供标准化的安全服务接口，向下管理安全启动、安全存储、加密和 attestation 等能力。其核心组件包括：

组件	职责	与升级/回滚的关系
Bootloader（MCUboot）	镜像验证、槽位管理、跳转	决定是否接受新镜像、是否允许回滚
SPM（安全分区管理器）	安全分区隔离与 IPC 调度	保护升级服务不被非安全侧越权调用
Secure Storage	加密存储密钥与元数据	保存版本号、回滚计数器、镜像状态
Crypto	哈希、签名验证、密钥派生	验证固件签名与镜像完整性
Attestation	证明设备身份与固件状态	升级后可远程确认版本真实性

TF-M 的启动过程与安全启动紧密耦合：Boot ROM 验证 BL2，BL2 再验证 TF-M 安全镜像与非安全镜像。TF-M 启动后初始化 SPM 与各安全分区，最后通过 PSA API 向非安全应用暴露安全服务。固件升级通常由非安全侧发起请求，但真正的镜像写入、签名验证和槽位切换由安全侧完成。

五、典型场景：一次安全升级如何穿过这些层次

假设设备运行 TF-M，非安全应用收到云端下发的固件包。流程如下：

非安全应用通过 PSA Firmware Update API 向安全侧发起升级请求。
安全侧 Crypto 服务验证镜像签名与哈希，确认来源可信。
Secure Storage 检查新镜像版本号是否高于当前版本，并读取防回滚计数器。
镜像写入备用槽位，写入完成后标记为“待验证”。
重启后 BL2 验证备用槽位镜像，通过则切换启动槽位，失败则回退到原镜像。
Attestation 服务可生成新的固件状态证明，供云端确认升级结果。

安全升级的关键不在于“写入新固件”，而在于“安全侧独立验证并决定是否信任新固件”。非安全侧只能发起请求，不能绕过验证。

六、常见误区与复盘

误区一：有签名就等于安全启动。 若验证公钥存储在可写 Flash 中，攻击者可替换公钥后伪造签名。公钥必须锚定在信任根或由信任根验证的证书链中。
误区二：TrustZone 隔离可以替代安全启动。 TrustZone 保护运行时隔离，但若启动阶段未验证镜像，攻击者可直接替换安全固件，隔离边界形同虚设。
误区三：回滚保护只是版本号比较。 仅比较版本号可被重放攻击绕过，必须配合单调递增的硬件计数器或安全存储中的不可回退状态。
误区四：升级失败后自动回滚总是安全的。 若旧版本存在已知漏洞，回滚可能重新引入风险。策略应结合最低允许版本与安全策略综合判断。

复盘时可以用一张检查清单快速定位问题：信任根是否不可变？每一级镜像是否都被验证？验证公钥是否受保护？版本与回滚状态是否存储在安全侧？非安全侧是否只能通过标准 API 发起升级？只有这些条件同时满足，TF-M 的安全固件升级与回滚保护才具备完整的信任基础。