[参考译文] PROCESSOR-SDK-AM62X：【OPTEE RPMB SECURE STORAFE】AM62x SDK 升级后 RPMB 验证失败(8.6→10.01)–DKEK 不匹配

感谢您的答复。 但是、我有一些后续问题：

我们已升级到  SDK 10.1的文档 、哪一个版本应包含最新的 TIFS 版本以及以下 DKEK API、正确？

/** Message to derive a KEK and return it via TISCI  (SDK 9.1.0.8) */
TISCI_MSG_CRYPTO_GET_DKEK         (0x9029U)

/** Message to derive a constant DKEK and set SA2UL DKEK register (SDK 9.2.1.9) */
#define TISCI_MSG_SA2UL_SET_DKEK_CONST          (0x902AU)
 
/** Message to derive a constant DKEK and return it via TISCI (SDK 9.2.1.9) */
#define TISCI_MSG_SA2UL_GET_DKEK_CONST          (0x902BU)

问题：

1. 为什么 SDK 10.1中的 OP-TEE 4.4仍然使用较旧版本 TI_SCI_MSG_SA2UL_GET_DKEK (0x9029)而不是TISCI_MSG_CRYPTO_GET_DKEK 用于 DKEK 检索的较新版本(也是0x9029)？

   optee_os/core/arch/arm/plat-k3/drivers/ti_sci.c
   int ti_sci_get_dkek(uint8_t sa2ul_instance,
   		    const char *context, const char *label,
   		    uint8_t dkek[SA2UL_DKEK_KEY_LEN])
   {
   	struct ti_sci_msg_req_sa2ul_get_dkek req = { };
   	struct ti_sci_msg_resp_sa2ul_get_dkek resp = { };
   	struct ti_sci_xfer xfer = { };
   	int ret = 0;
   
   	ret = ti_sci_setup_xfer(TI_SCI_MSG_SA2UL_GET_DKEK, 0,
   				&req, sizeof(req), &resp, sizeof(resp), &xfer);
   	if (ret)
   		return ret;
   
   	req.sa2ul_instance = sa2ul_instance;
   	req.kdf_label_len = strlen(label);
   	req.kdf_context_len = strlen(context);
   	if (req.kdf_label_len + req.kdf_context_len >
   	    KDF_LABEL_AND_CONTEXT_LEN_MAX) {
   		EMSG("Context and Label too long");
   		return TEE_ERROR_BAD_PARAMETERS;
   	}
   	memcpy(req.kdf_label_and_context, label, strlen(label));
   	memcpy(req.kdf_label_and_context + strlen(label), context,
   	       strlen(context));
   
   	ret = ti_sci_do_xfer(&xfer);
   	if (ret)
   		return ret;
   
   	memcpy(dkek, resp.dkek, sizeof(resp.dkek));
   	memzero_explicit(&resp, sizeof(resp));
   	return 0;
   }
   

2. 只需将 OP-TEE 修改为使用即可、 TISCI_MSG_SA2UL_GET_DKEK_CONST 而不是使用即可  TI_SCI_MSG_SA2UL_GET_DKEK(in fuction ti_sci_get_dkek)

3. 功能差异 ：

   • 什么是  旧的和新的 DKEK API 之间的差异 什么  优势  是否有新的 DKEK？存在  缺点  对旧的 DKEK ?
   • CAN  双 DKEK 验证  (如果新的 dkek 验证失败、请使用旧的 dkek)是否要实现向后兼容？

你好 Hong

您能否在内部对此进行优先排序、因为这会使客户无法继续推进其项目。 谢谢。

此致

Zekun

您好 Zekun

洪某目前正在休病假。 此主题的回复可能会延迟一周左右。 将评估在 Hong 不在办公室时是否可以将其重新分配给其他人  

你好  

以下是 Hong 外出时与开发团队讨论后的一些指导  

1. 为什么 SDK 10.1中的 OP-TEE 4.4仍然使用较旧版本 TI_SCI_MSG_SA2UL_GET_DKEK (0x9029) 是否需要使用较新的 TISCI_MSG_CRYPTO GET_DKEK (也称为0x9029)来检索 DKEK？
2. 是否只需修改 OP-TEE 即可使用 TISCI_MSG_SA2UL_GET_DKEK_CONST 而不是 TI_SCI_MSG_SA2UL_GET_DKEK (在函数 ti_sci_get_dkek 中)
3. 功能差异 ：

• 什么是 旧的和新的 DKEK API 之间的差异 什么 优势 是否有新的 DKEK？存在 缺点 对旧的 DKEK ?
• CAN 双 DKEK 验证 (如果新的 dkek 验证失败、请使用旧的 dkek)是否要实现向后兼容？

在#1上、它们是相同的 API、无行为差异、重命名 API 以使服务名称通用。 我们保留了旧名称也不会破坏任何兼容性。

将加密相关消息从 SA2UL 重命名为 crypto、是为了使该服务通用、而不会在消息中包含加密加速器名称。 我们从 SA2UL 改为 dthe 以表示 AM62L、并计划使用相同的 TISCI 消息。

TI_SCI_MSG_SA2UL_GET_DKEK == TISCI_MSG_Crypto_GET_DKEK

衍生的 KEK TISCI 说明—TISCI 用户指南

在#2上、TISCI_MSG_SA2UL_GET_DKEK_CONST 是  已使用之前 API 的客户的临时解决方案。

关于#3A)我们建议并鼓励使用最新的 API 和 SDK 10.1

在#3 b)中、您能否进一步说明为什么需要这一点？ 您是否在现场部署了设备等？

我们需要一个兼容性解决方案。如您建议的那样、您的团队建议使用最新的 API。 检索旧的 DKEK 仅用作临时 解决方案。 我们的具体要求是：对于尚未使用 RPMB 密钥编程的新核心板、我们希望它们能对照新的 DKEK 进行验证、同时保持与已使用旧的 DKEK 编程的核心板的兼容性。 因此、我们需要一个双 DKEK 兼容性解决方案、如果新 DKEK 的验证失败、系统会自动返回到旧的 DKEK。 这种方法可确保具有传统 DKEK 的核心板能够通过验证、而新的核心板将使用新的 DKEK 进行验证。

嗨、Xiaoshui

感谢您提供更多背景信息。 不幸的是,由于各种原因,我们无法支持双 DKEK 兼容性请求  

旧的 DKEK 仅可用于帮助迁移到新的 DKEK。 为了向后兼容性、不应该回退到使用它、 新的 API 是更稳健的、以及我们计划支持的长期功能。  

此致

Mukul