returns HSE_SRV_RSP_INVALID_PARAM

[hangwu]

S32K314 After integrating "Crypto_43_HSE_TS_T40D34M50I0R0", calling the function "

“Crypto_43_HSE_Exts_FormatKeyCatalogs” “

Crypto_43_HSE_KeyElementSet”

returns HSE_SRV_RSP_INVALID_PARAM. What could be the possible causes? Additionally, I confirm that all RAM used by Crypto is configured as non-cacheable.

[strofald]

Hello,
I am facing the same Issue with driver Crypto_43_HSE v6.0.0 (Crypto_43_HSE_TS_T40D34M60I0R0) on S32K312 and I am facing the exact same issue.
I successfully formatted the key catalogs, and I can see that after that the HSE Status is reported as 0x0B60 so CUST_DEL should be active.
In the NvM and Ram Key Catalogs I have the following configuration:

but I get 

HSE_SRV_RSP_INVALID_PARAM when I try to do KeyElementSet to initialize the key.

[strofald]

On a side note, I can tell you that I am trying to load the AES key without actually doing anything with the SHE keys.

[lukaszadrapa]

Hi @hangwu 

Is it possible to share some simple project to reproduce the issue? 

Regards,

Lukas

[hangwu]

Due to project constraints, I cannot provide a complete runnable project. Below are the two main source files. I integrated the "S32K3XX_S32M27x_RTD_R21-11_5.0.0_P08" RTD package. The EB configuration strictly follows:
"\S32K3XX_S32M27x_RTD_R21-11_5.0.0_P08\eclipse\plugins\Crypto_43_HSE_TS_T40D34M50I0R0\examples\EBT\S32K3XX".

I tested random number generation, hash values, UpdateFw, GetFwVersion, and other services – all worked normally. However:

• "Crypto_43_HSE_Exts_FormatKeyCatalogs"
• "Crypto_43_HSE_KeyElementSet"
• "Crypto_43_HSE_KeySetValid"
• "Crypto_43_HSE_ProcessJob"
  all returned "HSE_SRV_RSP_INVALID_PARAM".

I discovered the ‌HSE_STATUS_INSTALL_OK bit is cleared‌, so I tried calling FormatKey – but it failed.

[lukaszadrapa]

Hi @hangwu 

I'm sorry for delayed response. 

Are you still in CUST_DEL life cycle? Easiest option to confirm this - please send me a screenshot of memory at 0x1B00_0220 - 0x1B00_026F. 

The catalogs can be formatted only in CUST_DEL life cycle, so this could be the root cause. Next failing commands (keyelementset...) could be just a consequence because the catalogs are not formatted. 

Regards,

Lukas

[hangwu]

Thank you for your reply. Based on this memory screenshot, can you identify any issues?

[lukaszadrapa]

Well, there's no problem with the life cycle. Your device is still in CUST_DEL. 

Could you show me how are NVM and RAM catalogs defined?

[hangwu]

Thank you for your reply; I have attached the EB configuration file and some screenshots

[hangwu]

‌Thanks for your help. Problem solved! Much appreciated.

[Bhushan1312]

Hello @hangwu , Can you please share the details how you resolved it.

I am also facing similar kind of issue while programming the ADKP using HSE Library

[hangwu]

/* Table containing NVM key catalog entries */
const hseKeyGroupCfgEntry_t aHseNvmKeyCatalog[] =
{
/* NvmKeyGroup_0 */
{(HSE_MU0_MASK | HSE_MU1_MASK), HSE_KEY_OWNER_CUST, HSE_KEY_TYPE_AES, 10U, 256U, {0U, 0U}},
/* NvmKeyGroup_1 */
{(HSE_MU0_MASK | HSE_MU1_MASK), HSE_KEY_OWNER_CUST, HSE_KEY_TYPE_ECC_PAIR, 10U, 521U, {0U, 0U}},
/* Marker to end the key catalog */
{0U, 0U, 0U, 0U, 0U, {0U, 0U}}
};

/* Table containing RAM key catalog entries */
const hseKeyGroupCfgEntry_t aHseRamKeyCatalog[] =
{
/* RamKeyGroup_0 */
{(HSE_MU0_MASK | HSE_MU1_MASK), HSE_KEY_OWNER_ANY, HSE_KEY_TYPE_AES, 10U, 128U, {0U, 0U}},
/* RamKeyGroup_1 */
{(HSE_MU0_MASK | HSE_MU1_MASK), HSE_KEY_OWNER_ANY, HSE_KEY_TYPE_ECC_PAIR, 10U, 521U, {0U, 0U}},
/* Marker to end the key catalog */
{0U, 0U, 0U, 0U, 0U, {0U, 0U}}
};

The root cause of my error is the absence of the RAM marker（/* Marker to end the key catalog */）—I simply never configured ramKeyCatalog, and it turns out this entry is mandatory.

[Bhushan1312]

Thank you for the Information..