[参考译文] AM625：【OPTEE 客户端代码开发】【基准：SDK 10.1】关于 TI 基准 Yocoto 构建代码的问题

嗨、Jibin、
关于 OPTEE/PKCS11/TA...的一些参考
https://static.linaro.org/connect/lvc21/presentations/lvc21-215.pdf
https://optee.readthedocs.io/en/latest/building/userland_integration.html
https://optee.readthedocs.io/en/latest/building/trusted_applications.html

下面是 OPTEE xtest 套件 PKCS11 测试代码,您可以在其中浏览此文件,了解如何在 OPTEE 中测试各种 PKCS11 函数。
https://github.com/OP-TEE/optee_test/blob/master/host/xtest/pkcs11_1000.c

请注意、OPTEEE 就是开源社区项目。 OPTEE/PKCS11 是通用库、TI 提供的支持有限。

此致、
- Hong

尊敬的 Xu：
正如我上次答复中第一个链接的第 6 张幻灯片所述
“OP-TEE TA 中的 PKCS#11 令牌
目标：交付 PKCS#11 解决方案、由 OP-TEE 社区提供可靠和维护“

关于 OPTEE 中的硬件加密引擎支持、我们于 2025 年 5 月通过电子邮件与客户进行了沟通
- OPTEE 中的 RNG 通过硬件加密 RNG 模块得到支持
- OPTEE 中的其余加密操作通过软件实现得到支持
https://optee.readthedocs.io/en/latest/architecture/crypto.html
-在 OPTEE 中运行硬件加密引擎 SAX_UL 时没有 CPU 卸载优势,因为 OPTEE 不能被抢占

此致、
- Hong

我知道 OPTEE 在大部分情况下是一个 opensoure。 但这点对于 RPMB 部分,有一些关键修改必须根据实际的硬件平台修改,你应该真正阅读你发送给我的 URL。 这就是为什么我问这个问题…

例如：

第 1 点：

要允许 Secure Storage 在您的平台上安全运行、您必须在您的平台代码中定义实现：

void tee_OTP_get_hw_unique_key (struct tee_hw_unique_key *hwkey)；

int tee_OTP_get_die_id (uint8_t *buffer、size_t len)； 

这些实现应根据 SoC 供应商定义的方法从 SoC 特定电子保险丝或加密单元获取密钥数据。

第 2 点：

但是请注意、由于 RPMB 密钥只能写入一次控制器、因此在保护主板之前访问 RPMB 将导致主板安全后、将来 RPMB 访问将被拒绝。 为防止这种情况发生、OP-TEE 提供了一个软件挂钩、平台应使用该软件挂钩来实现其安全逻辑  plat_rpmb_key_is_ready()

Just wonder if there is any points that are hardware platform dependent, TI should help to point them out.

Hong、请从硬件平台相关性角度回答 Jinbin 提出的 RPMB 问题、特别是必要的问题  

OPTEE 规范/文档明确突出显示了 TEE_OTP_GET_HW_UNIQUE_KEY 和 TEE_OTP_GET_DIE_id 核心 API。 最好将 Jinbin 指向正确的源代码、以便识别 TI 的实现方案。 
非常感谢。