从“能解密”到“能守住”：实战阶段 3 —— 设计真正服务业务的 EKB 安全体系

原创已于 2025-12-13 18:54:08 修改 · 668 阅读

12 ·

CC 4.0 BY-SA版权

文章标签：

#安全 #YOLO #人工智能 #android #redis #java

于 2025-12-13 18:52:03 首次发布

NVIDIA 专栏收录该内容

60 篇文章

订阅专栏

编程达人挑战赛·第5期 10w+人浏览 403人参与

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

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

从“能解密”到“能守住”：实战阶段 3 —— 设计真正服务业务的 EKB 安全体系

关键词：EKB、OP-TEE、PTA、CA、Key_tag、安全边界、业务安全、Jetson

一、为什么一定要有“实战阶段 3”？

在前两个阶段，我们已经完成了两件极其关键但仍然不够“落地”的事情：

阶段 1：确认 OP-TEE 确实在 Secure World 中运行（xtest、tee-supplicant、随机数成功）。
阶段 2：确认 EKS/EKB 能被 OP-TEE 正确读取、解密，并且 PTA 可以对外提供安全服务（nvhwkey-app -r 成功）。

很多人会在这里停下，并误以为：

“既然 EKB 已经能解密，那安全问题就解决了。”

这是一个非常危险的误解。

阶段 3 的存在，就是为了纠正这个误解。

阶段 3 要解决的核心问题只有一个：

如何设计 EKB 的“内容”和“使用方式”，让它真正服务于业务安全，而不是沦为一个“形式正确但安全无效”的组件？

在这里插入图片描述

二、先统一认知：EKB 不是“钥匙文件”，而是“安全能力清单”

在进入具体设计之前，必须先完成一次概念升级。

1. 常见但错误的理解

很多初学者会天然地把 EKB 理解为：

“一个存着很多 key 的加密文件。”

于是设计思路会变成：

我需要 AES key → 放进 EKB
我需要 RSA key → 放进 EKB
业务想用 → 从 EKB 里拿出来

这是完全错误的方向。

2. 正确的理解方式

在 Jetson 的安全架构中：

EKB ≠ Key Store
EKB = Secure World 的“能力配置输入”

换句话说：

EKB 的内容，本质上是 PTA 在启动时读取的一份“安全策略 + 原始材料”；
EKB 中的 key，不应该也不需要被 Linux 世界直接理解其语义；
真正的“安全语义”，发生在 PTA 内部。

这也是为什么在阶段 2 中，你会看到：

随机数服务正常（不依赖 EKB 内容）；
加密失败，但错误是 ITEM_NOT_FOUND（PTA 在做正确的事情）。

三、阶段 3 的真实目标：建立“不可越权的安全边界”

在阶段 3，我们不再关心：

EKB 能不能解密（已经确认）；
PTA 能不能运行（已经确认）。

我们只关心三件事：

谁可以使用安全能力？
谁绝对不可能越权？
即便 Linux 被完全攻破，攻击者还能不能拿到核心资产？

这三件事，构成了阶段 3 的验收标准。

四、威胁模型（Threat Model）：你到底在防谁？

任何安全设计，如果没有明确的威胁模型，都是“自我感动”。

在 Jetson + OP-TEE + EKB 的体系中，一个现实且合理的威胁模型是：

攻击者可以：
- 获取 Linux root 权限；
- 注入用户态恶意程序；
- 读取文件系统；
- 抓取进程内存；
攻击者不能：
- 破坏芯片物理安全；
- 直接修改熔丝（Fuse）；
- 绕过 Secure World 的硬件隔离。

阶段 3 的设计目标就是：

在上述前提下，核心密钥、模型、身份、能力 依然安全。

五、EKB 内容设计的第一原则：Key_tag 才是“业务接口”

1. 什么是 Key_tag？

在 EKB 中，每一段内容都有一个 Key_tag。但它的意义绝不仅仅是“区分不同 key”。

正确的理解是：

Key_tag = 一类安全能力的唯一标识符

例如：

disk_enc_root
fw_decrypt_seed
model_protect_key
device_identity_seed

这些名字本身，就已经在描述：

用途（干什么用）
边界（谁能用）
生命周期（是否可派生、是否可更新）

六、EKB 内容的“分层设计”方法

一个成熟的 EKB 设计，一定是分层的。

1. 第一层：Root / Seed 类 Key

特点：

永远不直接用于业务；
永远不直接返回给 CA；
只存在于 PTA 内部；

典型示例：

设备身份 Seed
业务派生 Root Key

2. 第二层：业务派生 Key

特点：

由 PTA 使用 KDF 从 Seed 派生；
可能与设备唯一信息绑定；
可区分不同业务模块；

3. 第三层：能力接口（而不是 key 本身）

CA 永远不应该：

拿到明文 key；
看到 Root Key；

CA 只能：

请求“用某个能力完成一次操作”；
拿到结果，而不是秘密。

七、PTA 与 CA 的职责边界（阶段 3 的核心）

这是阶段 3 最重要的一条原则：

PTA = 安全决策者
CA = 业务请求者

1. PTA 应该做什么？

解析 EKB 内容；
管理 Key_tag 到内部 key 的映射；
决定某个 CA 请求是否被允许；
执行真正的加解密、派生、签名等操作。

2. CA 永远不应该做什么？

自己保存 key；
自己决定用哪个 key；
绕过 PTA 的接口限制。

你在阶段 2 看到的：

TEEC_ERROR_ITEM_NOT_FOUND

正是一个“健康的 PTA 行为”。

八、典型业务场景拆解：EKB 如何真正“服务业务”

示例 1：固件解密

EKB 中：
- fw_decrypt_seed
PTA：
- 启动时派生临时解密 key
CA：
- 只请求“解密固件块”

Linux 永远拿不到解密 key 本身。

示例 2：AI 模型保护

EKB 中：
- model_protect_key
PTA：
- 对模型文件进行解密或校验
CA：
- 只能请求加载结果

攻击者即使 dump 文件系统，也只能得到加密模型。

示例 3：设备唯一身份

EKB 中：
- device_identity_seed
PTA：
- 结合 chip ID 派生唯一身份
CA：
- 只能获取签名结果，而不是 identity 本身

九、阶段 3 的“流程级理解”（文字流程图）

Boot
 ↓
OP-TEE 启动
 ↓
解密 EKS / EKB
 ↓
PTA 初始化 Key_tag 表
 ↓
Linux 启动
 ↓
CA 发起安全请求
 ↓
PTA 校验 Key_tag + 权限
 ↓
PTA 执行安全操作
 ↓
返回“结果”，而不是“秘密”

这是你后续做任何安全业务时，必须始终保持不变的主线流程。

十、阶段 3 的验收标准（你什么时候算“真的完成了”）

你可以用下面这份清单自检：

Linux 普通程序无法直接获取任何 key
即便 root 权限，也只能调用受控 CA
PTA 内部才保存真正的安全语义
EKB 内容变化 ≠ Linux 行为变化
安全能力通过“接口”而不是“数据”暴露

只要这些条件成立，你的 EKB 设计就是业务级安全设计，而不是“演示级安全”。

十一、总结：你已经不在“学 OP-TEE”，而是在“设计安全系统”

走到阶段 3，意味着一件非常重要的事情：

你关注的已经不是“技术能不能跑”，而是“系统能不能被信任”。

EKB 在这里不再是一个文件，OP-TEE 也不再是一个模块，
而是你整个安全架构中：

信任根的延伸；
业务安全的起点；
攻击面被切断的地方。

这，才是阶段 3 的真正意义。

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

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