OP-TEE Secure Storage 与 Sign/Verify 实战总结

最新推荐文章于 2025-12-24 22:50:09 发布

原创最新推荐文章于 2025-12-24 22:50:09 发布 · 634 阅读

15 ·

CC 4.0 BY-SA版权

文章标签：

#php #开发语言 #架构 #YOLO #数据库 #java

安全/Security 专栏收录该内容

3 篇文章

订阅专栏

2025博客之星年度评选已开启 10w+人浏览 2.2k人参与

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

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

OP-TEE Secure Storage 与 Sign/Verify 实战总结

定位说明：
本文并不试图“直接解决模型加密或 IP 保护问题”，而是从工程基础角度，系统梳理 OP-TEE 中 Secure Storage 与 Sign / Verify 两个核心能力。

它们的价值在于：

帮助你真正理解 CA / TA 架构
熟悉 TEE Core API 的使用方式与设计哲学
为后续「密钥保护 / 模型加密 / License / DRM」打下可复用的安全基础

一、整体视角：CA / TA / TEE 在干什么？

在进入 API 之前，必须先建立正确的心智模型。

1.1 CA / TA 的职责划分

REE (Normal World)
└── CA (Client Application)
    - 文件系统
    - 网络
    - UI
    - 不可信

TEE (Secure World)
└── TA (Trusted Application)
    - 密钥
    - 安全运算
    - 安全存储
    - 可信

核心原则只有一句话：

👉 REE 负责“搬数据”，TEE 负责“做决定 + 管密钥”

二、Secure Storage：不是“加密文件”，而是“可信状态”

2.1 Secure Storage 的真实定位

很多初学者会误解：

❌ Secure Storage = 安全 U 盘 / 加密磁盘

实际上：

✅ Secure Storage = TEE 内部的可信持久状态

它最适合存的是：

私钥
对称密钥
Counter / Version
Hash / 校验值
License 状态

而不适合：

大文件
模型本体

在这里插入图片描述

2.2 Persistent Object 的文件模型

OP-TEE 把 Secure Storage 设计成了一个极简文件系统抽象：

概念	类比	说明
Object ID	文件名	你自己定义
Object Data	文件内容	原始 bytes
Object Handle	fd	打开后的句柄

没有字段、没有成员、没有 schema ——

👉 一切结构，都由你自己定义。

2.3 创建对象（实战代码）

TEE_Result res;
TEE_ObjectHandle object;

res = TEE_CreatePersistentObject(
        TEE_STORAGE_PRIVATE,
        obj_id, obj_id_sz,
        TEE_DATA_FLAG_ACCESS_READ |
        TEE_DATA_FLAG_ACCESS_WRITE,
        TEE_HANDLE_NULL,
        NULL, 0,
        &object);

这一步只做一件事：

👉 创建一个“空对象容器”

此时：

没有数据
没有结构

2.4 写入与读取（关键理解）

写入

TEE_WriteObjectData(object, &secure_data, sizeof(secure_data));

读取

TEE_ReadObjectData(object, &secure_data, sizeof(secure_data), &read_bytes);

⚠️ 关键认知点：

Secure Storage 只是一个 byte stream，
你必须自己保证：

结构一致
版本兼容
长度正确

2.5 一个“推荐结构模式”

struct secure_blob {
    uint32_t version;
    uint8_t key[32];
    uint32_t counter;
};

实践经验：

永远带 version
永远整体读写
不要拆成很多零散字段

三、Sign / Verify：理解“密钥不出 TEE”

如果说 Secure Storage 是状态，
那么 Sign / Verify 是能力。

3.1 为什么要做 Sign / Verify？

现实问题：

REE 不可信
文件可能被替换
参数可能被篡改

TEE 能提供的保证：

👉 只要签名通过，数据一定来自“拥有私钥的一方”

3.2 密钥生成（TA 内部）

TEE_ObjectHandle key;

TEE_AllocateTransientObject(
    TEE_TYPE_RSA_KEYPAIR,
    2048,
    &key);

TEE_GenerateKey(key, 2048, NULL, 0);

✔ 私钥永远不出 TEE
✔ CA 永远拿不到

3.3 签名流程（TA）

TEE_OperationHandle op;

TEE_AllocateOperation(
    &op,
    TEE_ALG_RSASSA_PKCS1_V1_5_SHA256,
    TEE_MODE_SIGN,
    2048);

TEE_SetOperationKey(op, key);
TEE_DigestDoFinal(op, data, data_len, hash, &hash_len);
TEE_AsymmetricSignDigest(op, NULL, 0, hash, hash_len, sig, &sig_len);

关键理解：

TA 并不是在“加密数据”，
而是在对“数据摘要”负责。

3.4 验证流程（TA）

TEE_AsymmetricVerifyDigest(
    op,
    NULL, 0,
    hash, hash_len,
    sig, sig_len);

✔ 成功：数据可信
✔ 失败：数据被篡改 / 来源不可信

四、把两者结合：一个完整实战场景

场景：可信配置加载

config.json  (REE)
   |
   |  hash + signature
   v
CA  ------------------>  TA
                         - verify signature
                         - check version
                         - store hash in secure storage