📺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 CA6.3 OP-TEE TA 核心逻辑（示意）
TEE_Resultsign_challenge(uint8_t*in,size_tlen,uint8_t*out,size_t*out_len){key=derive_device_key();returntee_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项目实战教程
)
