S32K324 - Crypto_KeyElementSet duration is too long (~60ms) when SHE container loaded

[ovidiubriscan]

Hi NXP community, 

I am involved in a S32K324 project, where HSE_B FW 2.1.0 is used. We have 2 use case where this API is failing :

1) FBL (Bootloader) 1st message on CAN within 300ms --> KeyElementSet duration is ~60ms and we initialize 5 keys so all time is eaten by Crypto DRV / HSE_B FW

2) APPL : Update of a SHE key is triggered from an not preemptive task (WDG reset is triggered) due to large duration of the execution of KeyElementSet API. 

So assumption is the problem is on the other side (not host) in HSE_B while handling SHE crypto material and implicit NVM immediate handling of the data. 

Any ideas how to tackle this issue ? (Note: at CSM level according to AUTOSAR specification requirement SWS_Csm_00957 this API Csm_KeyElementSet cannot be configured as async). 

Thanks in advance,

Ovidiu

[ovidiubriscan · Accepted solution]

Hi, seem there is a work around about this proposed by NXP team, the work around consists in enabling the HSE attribute HSE_ENABLE_PUBLISH_KEY_STORE_RAM_TO_FLASH_ATTR_ID this way splitting somehow the update of the new SHE key (secure RAM vs secure NVRAM), and service HSE_SRV_ID_PUBLISH_NVM_KEYSTORE_RAM_TO_FLASH need to be called afterwards in a preemptive context as it will take a while to force a writing/save key from secure RAM to secure NVRAM. 

It is not a pretty solution, as the atomicity of the call Crypto_KeyElementSet is broken, giving the possibility to loose the new updated key (as it is saved only to secure RAM) if an unexpected reset happens on the host side.

[DanNguyenDuy]

Hello @ovidiubriscan,

What is the RTD package you are using?

Could you send me the configuration files?(as .xdm files or .arxml files)

Best regards,

Dan

[ovidiubriscan]

Hi Dan, thanks for your interest into this topic, 

On HSE_B side we have : s32k3x4_hse_fw_0.5.0_2.1.0_pb220625.bin.pink (FULL_MEM)

On host side we have : RTD 3.0.0 P07

But i think i saw this in the latest HSE_B FW also (0.2.40.0) 

As for the configuration, i am not sure it is relevant, for testing purposes, use one catalog, 1 nvm key (KEY_1 (0x04)) , and call the Crypto_KeyElementSet with the M1 | M2 | M3 packages (which will eventually translate to a HSE_SRV_ID_SHE_LOAD_KEY 0x0000A101UL service) , for the container calculations you can use this : https://github.com/frankie-zeng/ECUBus/releases 

Key Id - KEY_1 (0x04) 

New key - any 16 bytes 

Auth key - previous value of KEY_1 which is all zeros 

Counter - 1 

Flags - wildcard (UID is all zeros) 

Thanks,

Ovidiu

[DanNguyenDuy]

Hello @ovidiubriscan,

1. I can't download your project on the GitHub because this is violate the security policy of NXP.

Could you attach your project on this link?

2. Follow to the Release Note of S32K3 3.0.0 P07: "All of the drivers (except CRYPTO) support ASR R21-11 and are also highly backwards compatible with ASR 4.4, ASR R19-11, ASR R20-11." So, most likely, the potential issues can occur when you use this package version. I proposal you should use SW32K3_RTD_R21-11_3.0.0 for your project (this package tested S32K344 with s32k3x4_hse_fw_0.5.0_2.1.0).

Best regards,

Dan