Rockchip 嵌入式安全系列设计实战

---

📺 B站视频讲解（Bilibili）：https://www.bilibili.com/video/BV1k1C9BYEAB/

📘 《Yocto项目实战教程》京东购买链接：Yocto项目实战教程

---

Rockchip 嵌入式安全系列设计实战

从 SoC 安全根到系统级防护的工程化落地方案

本文以 Rockchip SoC（以 RK3588 / RK3568 为代表） 为核心实例，系统性讲解一套 可量产、可复用、可维护 的嵌入式安全设计方案。全文坚持工程视角，避免抽象安全概念堆砌，围绕 真实攻击模型、芯片能力、软件架构与代码设计 展开，目标是回答一个问题：

在真实产品中，如何构建一条“攻击成本显著高于产品价值”的安全防护链？

---

一、为什么嵌入式安全是“系统工程”，而不是算法问题

在嵌入式产品中，安全失败往往并非源于 AES、RSA、ECC 算法本身，而是源于以下工程性错误：

• 密钥暴露在 Linux 文件系统
• Bootloader 未验证或可被替换
• 调试接口在量产阶段未关闭
• Secure World 与 Normal World 边界模糊
• 安全功能堆叠但缺乏整体策略

嵌入式安全的本质不是“绝对不可破”，而是：

通过硬件与软件协同设计，使攻击路径复杂化、成本化、不可规模化。

这正是 Rockchip SoC 在硬件层面提供安全能力的价值所在。

---

二、Rockchip SoC 的硬件安全根（Root of Trust）

2.1 BootROM：不可修改的起点

Rockchip SoC 在芯片内部固化 BootROM，其特点是：

• 存储在 Mask ROM 中，无法被软件修改
• 上电后执行的第一段代码
• 具备基础的镜像校验与加载能力

BootROM 的安全意义在于：

为整个系统提供一个不可伪造的起点

一切后续安全设计，必须以 BootROM 为信任源。

2.2 OTP / eFuse：不可逆安全配置

Rockchip 芯片提供 OTP / eFuse，用于存储：

• Secure Boot 使能位
• 公钥 Hash（Root Key Hash）
• 设备唯一性信息
• 调试接口关闭标志

OTP 的工程原则是：

• 只写一次，永不修改
• 写入前必须完成完整验证

任何未经过充分验证就写入 eFuse 的行为，都是不可逆的工程风险。

2.3 硬件唯一性（HW UID）

Rockchip SoC 内部通常具备：

• Chip ID
• Unique ID（由硅片制造过程决定）

这些 ID 不应直接作为密钥使用，而应作为：

密钥派生（Key Derivation）的根输入材料

---

三、Secure Boot：可信启动链的工程化设计

3.1 启动链的信任传递

典型 Rockchip Secure Boot 启动链如下：

BootROM
  ↓ 验证
SPL / Miniloader
  ↓ 验证
BL31 (ATF)
  ↓ 加载
BL32 (OP-TEE)
  ↓ 启动
BL33 (U-Boot / Kernel)

其核心原则是：

每一阶段只信任上一阶段验证通过的内容

3.2 签名 vs 加密：工程取舍

在 Secure Boot 中：

• 签名（Signature） 用于验证完整性与来源
• 加密（Encryption） 用于保护内容机密性

工程上常见误区是：

• 对所有镜像做加密

实际建议：

• Bootloader / Kernel：签名即可
• 包含密钥或算法的镜像：签名 + 加密

理由是：

• 加密增加维护复杂度
• 签名已能阻止恶意替换

3.3 防回滚（Anti-Rollback）

防回滚用于防止攻击者刷入历史漏洞版本。

常见做法：

• OTP 中存储版本计数器
• 启动时比较镜像版本
• 低于已烧录版本则拒绝启动

这是 金融 / 付费 / 安全敏感设备 的必选项。

---

四、TrustZone 与 OP-TEE 的正确定位

4.1 TrustZone 是“隔离机制”，不是 OS

ARM TrustZone 提供的是：

• CPU 执行状态隔离
• Secure / Normal World

而不是功能。

4.2 OP-TEE 的真实职责

OP-TEE 在 Rockchip 平台上的合理职责包括：

• 密钥管理
• 加解密运算
• 安全计数器
• 安全存储封装

不应承担：

• 业务逻辑
• 复杂协议栈
• 高并发任务

4.3 Secure World 的设计原则

• 代码最小化
• 接口数量最少化
• 永不暴露明文密钥

---

五、密钥体系设计（核心章节）

5.1 密钥分层模型

推荐的密钥分层如下：

层级	作用	存储位置
Root Key	芯片信任根	OTP / eFuse
Device Key	设备唯一身份	OP-TEE 内派生
Session Key	通信/会话	RAM / 临时

5.2 Key Derivation（关键设计）

绝对禁止：

• 在 Flash 中存储 Device Key

推荐做法：

DeviceKey = KDF(RootKey, HW_UID || Context)

特点：

• RootKey 永不出芯片
• DeviceKey 每次可重新派生
• Flash 被复制也无法复用

5.3 密钥生命周期管理

• 不长期存储会话密钥
• 使用后立即清除
• Secure World 内部使用 secure memory

---

六、实战案例一：设备身份与授权系统

6.1 设计目标

• 每台设备具备不可克隆身份
• 不依赖 MAC / SN
• Linux 无法获取私钥

6.2 架构

Server
  ↑ 签名验证
OP-TEE TA
  ↑ SMC
Linux CA

6.3 OP-TEE TA 核心逻辑（示意）

TEE_Result sign_challenge(uint8_t *in, size_t len,
                          uint8_t *out, size_t *out_len)
{
    key = derive_device_key();
    return tee_sign(key, in, len, out, out_len);
}

Linux 侧永远只能看到签名结果。

---

七、实战案例二：防克隆安全存储

7.1 威胁模型

• eMMC 被整体复制
• 固件被批量刷写

7.2 解决方案

• Secure Storage + Device Key
• 数据加密绑定芯片

即使 Flash 被复制，也无法解密。

---

八、Linux 系统完整性保护

8.1 dm-verity 的工程价值

• 防止 RootFS 被篡改
• 配合 Secure Boot

适用于：

• 付费设备
• 法规要求设备

8.2 与 Secure Boot 的协同

• Secure Boot：保护启动链
• dm-verity：保护运行时文件系统

---

九、产品阶段安全策略建议

阶段	必做	可选
EVT	Secure Boot	OP-TEE
DVT	Device Key	Secure Storage
MP	全链路	Anti-Rollback

---

十、常见错误设计总结

• 把密钥写进配置文件
• OP-TEE 中跑业务逻辑
• Secure Boot 但 UART 可刷机
• 所有镜像强制加密

---

结语：什么是成熟的嵌入式安全设计

成熟的嵌入式安全不是“功能最多”，而是：

• 信任边界清晰
• 攻击路径可控
• 成本与收益匹配

---

📺 B站视频讲解（Bilibili）：https://www.bilibili.com/video/BV1k1C9BYEAB/

📘 《Yocto项目实战教程》京东购买链接：Yocto项目实战教程

---