PROCESSOR-SDK-AM62X: 【OPTEE RPMB SECURE STORAFE】RPMB Verification Failure After AM62x SDK Upgrade (8.6 → 10.01) – DKEK Mismatch

Thank you for your response. However, I have some follow-up questions:

We have already upgraded to SDK 10.1, which should include the latest TIFS version with the following DKEK APIs, correct?

/** 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)

Questions:

1. Why does OP-TEE 4.4 in SDK 10.1 still use the older TI_SCI_MSG_SA2UL_GET_DKEK (0x9029) instead of the newer TISCI_MSG_CRYPTO_GET_DKEK (also 0x9029) for DKEK retrieval?

   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. is it sufficient to modify OP-TEE to use TISCI_MSG_SA2UL_GET_DKEK_CONST instead of TI_SCI_MSG_SA2UL_GET_DKEK(in fuction ti_sci_get_dkek)

3. Functional Differences:

   • What are the differences between the old and new DKEK APIs?What advantages does the new DKEK ？Are there drawbacks to the old DKEK ?
   • Can dual-DKEK verification (If the new dkek verification fails, use the old dkek) be implemented for backward compatibility?

Hi Hong

Could you prioritize this internally as this has get customer stuck for their project moving forward. Thanks.

Regards

Zekun

Hello Zekun

Hong is currently on a medical leave of absence. Reponses on this thread maybe delayed for another week or so. Will evaluate if this can be reassigned to someone else while Hong is out of office 

Hello 

Here is some guidance after discussing with development team while Hong is out 

1. Why does OP-TEE 4.4 in SDK 10.1 still use the older TI_SCI_MSG_SA2UL_GET_DKEK (0x9029) instead of the newer TISCI_MSG_CRYPTO_GET_DKEK (also 0x9029) for DKEK retrieval?
2. is it sufficient to modify OP-TEE to use TISCI_MSG_SA2UL_GET_DKEK_CONST instead of TI_SCI_MSG_SA2UL_GET_DKEK(in fuction ti_sci_get_dkek)
3. Functional Differences:

• What are the differences between the old and new DKEK APIs?What advantages does the new DKEK ？Are there drawbacks to the old DKEK ?
• Can dual-DKEK verification (If the new dkek verification fails, use the old dkek) be implemented for backward compatibility?

On #1, they are the same APIs, No difference in behavior, The API was renamed to make the service name generic. We kept the old name also to not break any compatibility.

The rename of crypto related messages from SA2UL to CRYPTO was done to make the service generic without the crypto accelerator name in the message. We moved from SA2UL to DTHe for AM62L and plan to use same TISCI messages.

TI_SCI_MSG_SA2UL_GET_DKEK == TISCI_MSG_CRYPTO_GET_DKEK

Derived KEK TISCI Description — TISCI User Guide

On #2, TISCI_MSG_SA2UL_GET_DKEK_CONST was a temporary  solution for customers who already used the previous API.

On #3 a) We recommend and encourage to move to the latest API and SDK 10.1

On #3 b) can you clarify further on why you need this? Do you have units deployed in field etc?

We want a compatibility solution.As you suggested, your team recommends using the latest API. Retrieving the legacy DKEK is only intended as a temporary  solution. Our specific requirements are: for new core boards that have not yet been programmed with RPMB keys, we want them to validate against the new DKEK, while maintaining compatibility with core boards already programmed with the legacy DKEK. Therefore, we need a dual-DKEK compatibility solution where the system automatically falls back to the legacy DKEK if validation with the new DKEK fails. This approach ensures that core boards with the legacy DKEK can pass verification, while new core boards will use the new DKEK for validation.

Hi Xiaohui

Thanks for the additional background. Unfortunately due to various reasons we are not able to support the dual-DKEK compatiblity request 

The old DKEK is available only for helping with migrating to the new one. One should not fallback to using it for backwards compatibility, the new API is what is more robust and what we plan to support long term. 

Regards

Mukul