RK3588 安全体系全解析：Secure Boot 与 OP-TEE 深度解析（对比 Jetson 平台）

最新推荐文章于 2025-11-25 11:29:48 发布

原创最新推荐文章于 2025-11-25 11:29:48 发布 · 1.1k 阅读

18 ·

CC 4.0 BY-SA版权

文章标签：

#安全 #边缘计算 #人工智能 #linux #运维 #缓存

NVIDIA 专栏收录该内容

28 篇文章

订阅专栏

作者书籍推荐：
⚡ 内地版本：电子工业出版社已出版，并在大陆热销。Yocto项目实战教程:高效定制嵌入式Linux系统
⚡ 海外版本：繁体中文版支持全球华人购买，让更多开发者轻松掌握嵌入式系统核心技能。金石堂购买链接
🎥 更多学习视频请关注 B 站：嵌入式Jerry

🔒 RK3588 安全体系全解析：Secure Boot 与 OP-TEE 深度解析（对比 Jetson 平台）

在当下的高性能 SoC 生态中，安全启动（Secure Boot） 与 可信执行环境（OP-TEE / TrustZone） 已经成为嵌入式产品走向量产、合规与安全的重要门槛。尤其是对于 Rockchip RK3588 这样面向 AI、视觉与工业领域的旗舰级芯片，它的安全体系结构不仅完整，而且在工程实现上与 NVIDIA Jetson 平台 有诸多相似之处，同时又有明显的差异与开发重点。

本文将以 RK3588 为核心，系统讲解其安全架构、Secure Boot 启动链、TrustZone/OP-TEE 实现逻辑，重点分析与 Jetson 的对比差异，帮助你在实际 BSP 开发中更好地构建一个可验证、可量产的安全系统。

在这里插入图片描述

🧠 一、RK3588 的安全架构概览

RK3588 内部集成了 ARMv8-A 架构的多核 Cortex-A76/A55 处理器，其中每个核心都支持 ARM TrustZone。整个安全体系可以分为四个层次：

层级	模块	作用
硬件层	eFuse / OTP / Crypto Engine	存储密钥、执行加密、提供签名验证能力
启动层	BootROM / Loader / U-Boot	完成 Secure Boot 链式验证
安全世界层	OP-TEE / ARM Trusted Firmware (ATF)	提供安全执行环境（Secure World）
操作系统层	Linux + optee.ko + tee-supplicant	通过 TEE 框架与 Secure World 通信

与 Jetson 类似，RK3588 的 Secure Boot 同样从硬件的 eFuse 公钥哈希开始，通过 BootROM 启动链完成系统完整性验证。但在实现细节上，Rockchip 采用了更灵活的可配置机制（包括 Loader、Trust、U-Boot 的独立签名验证），为开发者提供了更高的可定制性。

⚙️ 二、RK3588 Secure Boot 启动链详解

RK3588 的 Secure Boot 由硬件 BootROM 触发，整个启动链如下：

┌──────────────────────────────────────────┐
│ eFuse / OTP (Root Key Hash)              │
│   ↓                                      │
│ BootROM                                 │
│   ↓ Verify Signature → Trust.img (BL31) │
│   ↓ Verify Signature → U-Boot (BL33)    │
│   ↓ Verify Signature → Kernel / DTB     │
└──────────────────────────────────────────┘

🧩 各阶段说明

阶段	镜像	主要功能
BootROM	固化在芯片中	从 eFuse 读取公钥哈希，验证 Trust 镜像签名
Trust.img (BL31)	Trusted Firmware-A	初始化 TrustZone，加载 OP-TEE
U-Boot (BL33)	普通世界引导器	启动 Linux 内核
Kernel / DTB	操作系统	最终启动系统，加载 optee.ko

📘 核心逻辑：RK3588 的 BootROM 会读取 OTP 或 eFuse 中的公钥哈希，并使用该公钥验证下一级镜像的签名。这条链条的每一环都由前一环验证签名，形成完整的 Root of Trust。

🔐 三、eFuse 与 Root of Trust

在 RK3588 中，eFuse 是安全启动的基础。它用于：

存储公钥哈希（PK Hash）
启用 Secure Boot 模式
存储调试锁（JTAG、UART Boot）

写入命令示例

Rockchip 官方工具支持通过 upgrade_tool 或 rkdeveloptool 烧写 eFuse：

./rkdeveloptool efuse_write 0x50 <hash.bin>

一旦写入 Secure Boot 相关位，BootROM 将永久进入验证模式：

🔒 即使攻击者通过外部方式修改存储中的镜像，也无法通过签名验证。

🧱 四、TrustZone 与 OP-TEE 架构

RK3588 同样基于 ARM TrustZone 实现安全世界的隔离。

在硬件层面：

Secure World (EL1S)：运行 OP-TEE（BL32）
Normal World (EL1N)：运行 Linux 内核与用户应用

在软件架构上，RK3588 的安全世界主要由以下部分组成：

模块	描述
BL31	Trusted Firmware-A，负责初始化 TrustZone 并加载 OP-TEE
BL32 (OP-TEE)	运行在 Secure World 的微型安全操作系统
optee.ko	Linux 内核模块，用于与 Secure World 通信
tee-supplicant	用户态守护进程，管理存储与服务请求

启动逻辑

BootROM → BL31 (Trust.img) → BL32 (OP-TEE) → BL33 (U-Boot)
                                      ↓
                             Linux Kernel (Normal World)
                                      ↓
                            optee.ko ↔ tee-supplicant ↔ OP-TEE

🧩 五、`optee.ko` 与内核通信机制

optee.ko 是 Normal World 与 Secure World 之间的桥梁。

注册 /dev/tee0 设备节点；
将来自用户态的 IOCTL 调用转换为 SMC 调用；
通过共享内存区（Shared Memory）实现数据传输；
管理安全上下文（Session、Context）。

通信流程图

User App → libteec.so → tee-supplicant → /dev/tee0 → optee.ko
                                         │
                                         ▼
                                   OP-TEE Secure World

与 Jetson 平台相比，RK3588 的 optee.ko 同样基于主线 Linux 的 TEE 框架 (CONFIG_TEE, CONFIG_OPTEE)，因此内核通信层机制几乎一致。

⚙️ 六、编译与配置：从 BSP 到 Secure OS

在 Rockchip SDK 中，涉及安全相关的核心源码通常位于：

rkbin/
├── tools/                   ← 生成签名工具与 fuse 工具
├── bin/rk35/                ← 各阶段启动镜像 (trust.img, uboot.img, etc.)
├── optee_os/                ← OP-TEE 源码
└── atf/                     ← ARM Trusted Firmware

编译命令

cd rkbin/optee_os
make CROSS_COMPILE=aarch64-linux-gnu- PLATFORM=rockchip_rk3588 CFG_ARM64_core=y

生成 tee.bin，并在构建 Trust 镜像时自动打包：

cd rkbin
./mktrust.sh

输出：

trust.img  (包含 BL31 + BL32)

该文件即被 BootROM 作为 Secure Boot 验证对象。

🔧 七、内核配置依赖项

RK3588 的内核驱动层与 Jetson 一致，需要启用以下配置项：

CONFIG_TEE=y
CONFIG_OPTEE=y
CONFIG_ARM_SMCCC=y
CONFIG_ARM_PSCI=y

这些选项位于：

arch/arm64/configs/rockchip_defconfig

若未启用，optee.ko 将无法生成或加载，/dev/tee0 不会出现。

🧰 八、用户空间验证

验证系统是否成功启动 OP-TEE：

dmesg | grep optee

输出：

[    1.352] optee: probing for conduit method.
[    1.354] optee: initialized driver

查看设备：

ls /dev/tee*

输出：

/dev/tee0 /dev/teepriv0

运行测试：

xtest

若所有测试通过，表示 Normal ↔ Secure 通信完全正常。

🔍 九、RK3588 与 Jetson 安全体系对比

特性	Rockchip RK3588	NVIDIA Jetson
BootROM 验证机制	eFuse + RSA 签名验证	eFuse + Secure Boot Chain
Secure Boot 启动链	BootROM → Trust → U-Boot → Kernel	BootROM → MB1 → MB2 → BL31 → Kernel
TrustZone 支持	ARMv8-A TrustZone	ARMv8-A TrustZone
Secure OS	OP-TEE（BL32）	OP-TEE（BL32）
签名工具链	`rk_sign_tool` / `upgrade_tool`	`odmfuse.sh` / `tegraflash.py`
内核通信机制	optee.ko + tee-supplicant	optee.ko + tee-supplicant
BSP 开发灵活度	可自由修改 Trust 及签名规则	固定结构，安全限制更严格
安全风险点	签名链配置错误、eFuse 写入错误	签名密钥丢失、eFuse 烧录不可逆

Jetson 平台的安全链更“闭环”，而 Rockchip 的安全系统则更开放灵活，更适合 OEM 二次开发，但也要求开发者有更强的安全意识与密钥管理机制。

⚠️ 十、安全风险与工程建议

🔴 1. 未启用 Secure Boot

风险：系统可被替换、加载非授权 U-Boot / Kernel。
对策：启用 eFuse，锁定 Root Key Hash。

🟠 2. 未使用签名镜像

风险：攻击者可注入恶意模块。
对策：启用签名机制并定期更新密钥对。

🟢 3. 未启用 OP-TEE 驱动

风险：应用无法使用安全服务，安全世界闲置。
对策：确认内核中 CONFIG_OPTEE 启用，并验证 /dev/tee0。

🔵 4. eFuse 错误烧录

风险：设备永久失效或无法调试。
对策：测试环境使用临时 RSA Key，正式生产后再锁定。

🧩 十一、RK3588 安全开发最佳实践

分阶段启用安全机制：
- 开发阶段禁用 Secure Boot（调试方便）。
- 量产阶段烧录 eFuse 并启用 Secure Boot。
区分开发与量产密钥：
- 开发：临时 RSA 密钥。
- 生产：硬件 HSM 管理私钥，防止泄露。
定期更新信任链：
- 新固件签名需重新生成 Trust 镜像。
- 建议在 CI/CD 系统中自动化签名。
集成 Yocto / Buildroot 支持：
- 使用 meta-optee 层集成 OP-TEE。
- 在 RootFS 安装 tee-supplicant 与测试工具。
验证工具链完整性：
- Rockchip 的 rk_sign_tool 与 rkdeveloptool 必须版本匹配。

🧭 十二、总结：两种安全哲学

维度	Jetson	RK3588
安全策略	封闭、自动验证、出厂固化	开放、灵活、可自定义
使用难度	配置较少，风险低	配置较多，灵活但易出错
适用场景	工业自动化、机器人、高安全边缘设备	定制产品、AI 工控、智能摄像头