摘要

CRA Article 13(2) 要求"安全隔离"，PSA Certified Level 2+ 强制硬件隔离。本文用 TrustZone-M 两个世界 + 三类硬件单元 + DEN0063 三级隔离 + SPM 调度与 IPC 全链路，讲清楚 TF-M 如何满足 CRA 与 PSA 双重要求。

开篇：一个 400 万美元的教训

2015 年，一颗 Cortex-M4 的智能门锁固件被攻破。

攻击者通过 BLE 协议栈的一个缓冲区溢出，直接读到了同一内存空间里的设备私钥——因为加密代码、协议栈、应用逻辑全跑在同一个特权级，没有任何硬件隔离。

厂商召回 8 万台门锁，损失 400 万美元。

2018 年，Arm 发布 PSA 架构，给出了解法：把 CPU 拆成两个世界。安全世界跑 TF-M 固件掌管密钥，非安全世界跑应用。两个世界通过 TrustZone-M 硬件隔离，哪怕应用全盘被黑，攻击者也读不到安全世界的密钥。

2024 年，TF-M 已成为 PSA Certified Level 2+ 的事实标准——Nordic、ST、NXP、Silicon Labs、TI 全部采用。自研隔离方案的厂商在 PSA 评估中要额外证明隔离有效性，成本反而更高。

没有硬件隔离的系统，"安全"只是侥幸。

---

一、为什么需要固件隔离？CRA 与 PSA 的双重强制

CRA Article 13(2) 要求

CRA 要求"安全隔离"——敏感安全功能（密钥、认证、加密）必须与普通功能（应用、协议栈、驱动）隔离。这是 CRA 的 13 项核心要求之一，Class I Important 及以上需第三方评定。

PSA Certified 强制要求

标准	隔离要求	等级
CRA Article 13(2)	安全功能与普通功能隔离	Class I+
EN 18031-2 要求 4.2	安全隔离机制	全部
PSA Certified L1	软件隔离即可	L1
PSA Certified L2	硬件隔离（TZ-M）	L2+
PSA Certified L3	分区间硬件隔离（SAU/MPU）	L3+

没有隔离的代价

💡 真实案例：某厂商的 BLE SoC 没有 TrustZone-M，BLE 协议栈与应用代码同地址空间。攻击者通过 BLE L2CAP 的一个溢出漏洞，读取了 2KB 外的设备私钥。修复方案：升级到 Cortex-M33 + TZ-M，密钥移入安全世界。

---

二、TrustZone-M 硬件隔离机制

两个世界

TrustZone-M（Armv8-M 架构，Cortex-M23/M33/M55/M85）把 CPU 拆成两个执行域：

执行域	简称	运行内容	访问权限
Secure Processing Environment	SPE	TF-M 固件、密钥、安全服务	可访问安全 + 非安全区域
Non-Secure Processing Environment	NSPE	应用、RTOS、协议栈、驱动	只能访问非安全区域

📌 配图提示：双世界隔离示意图

三类硬件单元

单元	全称	作用	配置者
IDAU	Implementation-Defined Attribution Unit	定义物理地址的安全属性	芯片厂商（硬件固化）
SAU	Security Attribution Unit	软件可配置的安全属性	TF-M（运行时）
AU	Attribution Unit	总线层面的访问控制	SoC 总线（硬件）

💡 关键点：IDAU 是硬件固化的——芯片设计阶段就定死了哪些地址是安全的。这保证了即使 SAU 被篡改，安全区域也不会被非安全侧访问。

NSC 区域与 SG 指令（最小入口原则）

非安全世界不能直接跳转到安全世界的任意地址——直接跳转会触发 HardFault。唯一的入口是 NSC（Non-Secure Callable）区域：

应用代码 → NSC 跳板 → SG 指令 → SPM 调度 → 安全分区 → 返回结果 → NSC → 应用代码

1. 应用调用 PSA API（如 psa_hash_compute()）
2. 函数指针指向 NSC 区域的 stub 代码
3. NSC 区域位于安全 Flash 最前面，只含 SG（Secure Gateway）指令
4. 执行 SG 指令后 CPU 自动切到安全模式
5. 进入 TF-M 的 SPM 调度到对应安全分区

⚠️ 工程教训：某厂商的 NSC stub 写了 50+ 个函数，其中 3 个参数校验不完整，攻击者通过缓冲区溢出在安全侧执行了任意代码。SG 接口应控制在 20 个函数以内，每个函数参数白名单校验。

内存映射示例

0x1000_0000 - 0x1FFF_FFFF: Secure Flash      ← TF-M 固件 + 密钥
0x2000_0000 - 0x2FFF_FFFF: Non-Secure Flash  ← 应用固件
0x3000_0000 - 0x3000_FFFF: NSC Region        ← 安全入口跳板

0x4000_0000 - 0x40FF_FFFF: Secure SRAM       ← TF-M 运行时数据
0x4100_0000 - 0x41FF_FFFF: Non-Secure SRAM   ← 应用运行时数据

链接阶段就把 Flash/SRAM 物理地址分配到安全/非安全区域。CPU 上电默认在安全模式运行 TF-M，初始化完成后跳转到非安全世界执行应用。

---

三、PSA 固件框架 DEN0063

规范与实现的关系

项目	DEN0063	TF-M
性质	Arm 规范（文档）	参考实现（代码）
内容	定义隔离模型、SPM、RoT Service、IPC	C 代码，可直接编译运行
关系	PSA Certified 认证依据	满足 DEN0063 的开源实现
类比	POSIX 标准	Linux/glibc

📌 规范引用：做 PSA Certified 认证必须遵守 DEN0063，可以直接用 TF-M，也可以自研——但自研方案在评估时要额外证明符合 DEN0063，成本极高。

三级隔离

隔离级别	机制	硬件要求	PSA Level
Level 1	软件隔离（同一特权级）	无 TrustZone	L1
Level 2	世界隔离（TZ-M 两世界）	TrustZone-M	L2+
Level 3	分区间硬件隔离（SAU/MPU）	TZ-M + MPU	L3+

📌 配图提示：三级隔离演进图

• Level 1：所有安全服务在同一个安全世界，靠软件边界隔离。一个服务的 bug 可能影响其他服务
• Level 2：安全世界 vs 非安全世界硬件隔离。应用被黑不影响安全服务，但安全服务之间仍同地址空间
• Level 3：每个安全分区有独立 MPU 区域，分区间硬件隔离。一个分区的漏洞不会泄露另一个分区的密钥

💡 工程视角：Level 2 是性价比拐点——Cortex-M33 + TZ-M 的 IP 成本约 10-30 万美元，满足 PSA Level 2。Level 3 需要 MPU 精细化配置 + 分区独立栈，内存开销增加 20-40%，但安全性显著提升。Nordic nRF5340 用 Level 2，ST STM32WBA6x 用 Level 3。

Secure Partition——最小隔离单元

每个 Secure Partition 是 SPE 内部的最小隔离单元：

• 有独立的内存区域（代码 + 数据 + 栈）
• 有唯一的 Partition ID
• 单线程模型，不能直接访问其他分区内存
• 通过 SPM 中转的 IPC 通信

📌 配图提示：SPM 管理多分区架构图

PSA-RoT vs App-RoT

层	提供者	内容	认证方式
PSA-RoT	芯片厂商	SPM、生命周期、不可变 RoT、Crypto、启动更新	平台级认证
App-RoT	设备厂商	厂商自定义认证协议、特定安全存储、第三方组件	产品级认证

分开之后，芯片厂商可以独立认证 PSA-RoT，设备厂商只需认证自己的 App-RoT，不用重新认证整个安全栈——这是 PSA Certified 分级认证的基础。

---

四、SPM 调度与 IPC 通信

SPM 是什么

SPM（Secure Partition Manager）是 TF-M 的核心，负责：

1. 分区管理：创建、销毁、调度安全分区
2. IPC 中转：分区间通信必须经过 SPM
3. 访问控制：校验分区对资源的访问权限
4. 中断路由：安全中断分发到对应分区

事件驱动 + 协作式调度

SPM 是事件驱动 + 协作式调度器——分区不能被抢占，必须主动调用 psa_wait() 让出 CPU：

// 安全分区的主循环（伪代码）
void partition_main(void) {
    psa_signal_t signals;
    while (1) {
        signals = psa_wait(PSA_WAIT_ANY, PSA_BLOCK);  // 等待消息
        if (signals & MAILBOX_SIGNAL) {
            handle_request();  // 处理 IPC 请求
            psa_reply(handle, PSA_SUCCESS);  // 回复
        }
    }
}

⚠️ 重要提醒：协作式调度意味着分区不能有死循环——一个分区如果一直不调用 psa_wait()，整个安全世界会卡死。某厂商的加密分区在 RSA-3072 签名时阻塞了 200ms，导致其他分区的看门狗超时。修复方案：RSA 改用 ECDSA P-256（10ms），或拆分为异步操作。

IPC 通信全链路

📌 配图提示：IPC 通信时序图

IPC 开销（不是免费的）

操作	耗时	说明
NS→S 切换（SG 指令）	~100 cycles	硬件自动
SPM 调度	~500 cycles	查找分区、投递消息
分区切换（Level 3）	~200 cycles	MPU 重配置
单次 IPC 总开销	~800 cycles	约 5-10μs @ 64MHz

💡 工程教训：某厂商的应用每次加密 16 字节都要一次 IPC，加密 1KB 数据要 64 次 IPC，IPC 开销占 70%。修复方案：用 psa_hash_compute() 一次性接口替代 psa_hash_setup/update/finish 多次调用，IPC 次数从 64 降到 1。

---

本期小结

1. CRA Article 13(2) 要求安全隔离，PSA Level 2+ 强制硬件隔离
2. TrustZone-M 把 CPU 拆成两个世界，IDAU 硬件固化安全属性
3. NSC + SG 指令是最小入口原则，SG 函数应 ≤20 个
4. DEN0063 定义三级隔离，Level 2 是性价比拐点
5. SPM 是事件驱动 + 协作式调度，分区不能有死循环
6. IPC 不是免费的，用一次性 API 替代多步调用

---

下期预告

第 4 期：PSA Crypto API 实战

下一期进入工程实战——TF-M 的四大核心服务如何使用？

• Crypto 分区：密钥不离开安全世界
• ITS/PS 存储分区：片上 vs 外部
• Attestation 分区：设备证明
• TF-M + Zephyr/FreeRTOS 集成
• 自研隔离 vs TF-M 成本对比

关注本系列，从架构走向代码。

---

📣 互动话题：
你的项目用 TrustZone-M 了吗？选 Level 2 还是 Level 3？

• 留言区分享你的选型经验
• 转发给固件/安全团队，对照三级隔离评估
• 收藏本文，随时查阅 TF-M 架构

关注本账号，每周更新 CRA × PSA 合规实战内容。

---

话题标签

#TF-M #TrustZone #PSA #固件隔离 #Cortex-M33 #IoT安全 #芯片安全 #CRA

---