📺B站视频讲解（Bilibili）：https://www.bilibili.com/video/BV1k1C9BYEAB/
📘《Yocto项目实战教程》京东购买链接：Yocto项目实战教程
Jetson 安全体系的最后一块拼图：EKB 与 OP-TEE 如何真正保护你的密钥
在 Jetson 平台上，很多工程师在完成 Secure Boot 之后，都会产生一种“系统已经足够安全”的错觉。然而在真正的产品化阶段，这种认知往往是危险的。
Secure Boot 只能回答一个问题：设备启动的代码是否可信。但它无法回答另一个同样关键的问题：系统中最敏感的“秘密”是否得到了可靠保护。
这些“秘密”包括但不限于：磁盘加密密钥、UEFI Payload 加密密钥、设备身份私钥、云端认证凭据等。一旦这些密钥泄露，攻击者即使无法篡改启动链，也可能直接解密用户数据，甚至伪造设备身份。
EKB（Encrypted Key Blob，加密密钥块）正是 NVIDIA 为解决这一问题而设计的关键机制。它并不是 Secure Boot 的附属品，而是 Jetson 安全体系中专门用于密钥保护与密钥使用的核心组件。
一、为什么 Secure Boot 之后，仍然需要 EKB？
在没有 EKB 之前，密钥通常只能存放在以下位置：
- 文件系统（rootfs、配置文件）
- 固件或设备树
- 应用程序内部
这些方式在调试阶段或许“能用”，但在量产设备上几乎等同于明文保存。一旦系统被获取 shell、镜像被提取，密钥便不再是秘密。
Secure Boot 只能防止“启动代码被替换”，却无法阻止攻击者在系统运行后读取存储介质中的敏感数据。
EKB 的核心价值在于：
它让“密钥”不再是普通数据，而成为只能在安全世界中被使用的受保护资产。
二、EKB 在 Jetson 安全架构中的真实位置
要理解 EKB，必须先把 Jetson 的安全体系分层看清楚：
- 硬件层（Root of Trust）：Fuse
- 启动与固件层：BootROM / MB1 / MB2
- 安全操作系统层：OP-TEE（Secure World）
- 普通操作系统层：Linux（Normal World）
EKB 横跨其中两个关键层级：
- 在存储层面，它以二进制镜像的形式存在于 EKS 分区
- 在使用层面，它只会被 OP-TEE 解析和解密
Linux 永远无法直接看到 EKB 中的明文内容，这一点是整个设计的安全前提。
三、从 Fuse 到 EKB：真正的信任链在哪里？
Jetson 的信任根并不在 OP-TEE，也不在 EKB 文件本身，而是在硬件 Fuse 中。
在 Jetson AGX Orin、Orin NX、Orin Nano 平台上，OEM_K1 是一个烧录在 Fuse 中的 AES 密钥：
- 软件无法直接读取
- 只能由安全引擎（SE）在受控环境中使用
EKB 的所有安全属性，最终都可以追溯到这个硬件密钥。
在启动早期，OEM_K1 会被加载到安全引擎的 Keyslot 中，随后由 OP-TEE 使用它派生出 EKB 相关的根密钥。这条路径，构成了 Jetson 设备真正不可伪造的信任链。
四、EKB 并不是一个“密钥”，而是一套密钥体系
很多初学者会误以为 EKB 本身就是一个密钥文件，这是一个常见但危险的误解。
实际上，EKB 内部至少涉及四类不同层级的密钥：
- OEM_K1：硬件根密钥，存在于 Fuse 中
- EKB_RK：由 OEM_K1 派生出的根派生密钥
- EKB_EK / EKB_AK：用途隔离的功能密钥
- User Keys：真正用于业务的用户自定义密钥
其中，EKB_RK 的派生公式如下：
EKB_RK = AES-128-ECB(FV, OEM_K1)FV 是一个随机向量，存储在 EKB Header 中，用于确保即使 OEM_K1 相同，不同 EKB 也无法相互复用。
五、为什么必须使用 KDF 派生不同密钥？
在安全系统中，一个基本原则是：不同用途的密钥，绝不能复用。
Jetson 使用符合 NIST SP-800-108 标准的密钥派生函数（KDF），从 EKB_RK 派生出两个用途完全不同的密钥：
- EKB_EK：仅用于加密和解密 EKB 内容
- EKB_AK：仅用于验证 EKB 内容的完整性
通过 Label 和 Context 的区分，即使攻击者在某个场景中获得了派生密钥，也无法反推出其他用途的密钥，更无法回溯到硬件根密钥。
这种设计并非“增加复杂度”，而是现代安全架构中对抗密钥滥用和横向攻击的必要手段。
六、EKB 文件内部到底保存了什么？
从格式上看，EKB 是一个高度结构化的二进制文件，主要由三部分组成：
- EKB Header：描述版本、随机向量（FV）和认证信息
- EKB Content Header：描述加密内容的基本属性
- Encrypted Payload：真正的用户密钥数据
Payload 区域使用 AES-128-CBC 算法加密，而完整性校验则由 AES-CMAC 完成。即使攻击者获得了完整的eks_t234.img文件，在缺少 Fuse Key 的情况下，也无法解密其中任何有效信息。
七、用户密钥在 EKB 中是如何组织的？
EKB 并不限制只能存放单一密钥。相反，它被设计为一个可扩展的安全数据容器。
每一项用户数据都遵循统一的格式：
- Key_tag：标识数据类型
- Key_len：数据长度
- Key_data：实际内容
通过这种方式，用户可以在同一个 EKB 中同时存放：
- 磁盘加密源密钥
- UEFI 变量认证密钥
- 业务级私钥或 Token
而无需改变整体安全架构。
八、EKB 是如何被“安全地生成”的？
EKB 的生成通常发生在设备量产或安全配置阶段，其流程高度标准化：
- 定义 EKB 内容（明文）
- 烧录 OEM_K1 到 Fuse
- 生成随机 FV
- 派生 EKB_RK
- 派生 EKB_EK 和 EKB_AK
- 使用 EKB_EK 加密内容
- 使用 EKB_AK 计算 MAC
- 生成 EKB 镜像并刷写到 EKS 分区
这一流程确保了 EKB 与具体硬件设备强绑定，任何试图在不同设备之间复制 EKB 的行为都会失败。
九、运行时：OP-TEE 如何安全地使用 EKB？
在设备启动过程中，OP-TEE 中的jetson-user-keyPTA 会执行与生成流程几乎完全对称的操作：
- 从 EKS 分区读取 EKB
- 使用 Fuse Key 派生 EKB_RK
- 派生 EKB_EK 和 EKB_AK
- 验证 MAC
- 解密 EKB 内容
- 在安全世界中缓存用户密钥
如果任何一步验证失败，EKB 都会被直接拒绝使用。
Linux 世界中的应用程序，只能通过 TA / CA 接口请求“使用密钥”，而永远无法直接获取密钥本身。
十、EKB 真正解决了什么问题？
综合来看，EKB 为 Jetson 平台带来了四个关键能力：
- 密钥不再以明文形式存在于系统中
- 密钥与硬件设备强绑定，无法被复制
- 不同安全用途的密钥严格隔离
- 安全机制可被稳定地用于量产和 OTA 场景
Secure Boot 解决的是“代码是否可信”的问题，而EKB 解决的是“秘密是否可信”的问题。
当 Jetson 从开发板走向真正的产品时，EKB 往往不是可选项，而是安全体系中不可或缺的最后一块拼图。
📺B站视频讲解（Bilibili）：https://www.bilibili.com/video/BV1k1C9BYEAB/
📘《Yocto项目实战教程》京东购买链接：Yocto项目实战教程
