accessMode wrong implementation in Crypto driver RTD 3.0.0_P07

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

accessMode wrong implementation in Crypto driver RTD 3.0.0_P07

Jump to solution
1,114 Views
ovidiubriscan
Contributor IV

Hi NXP team, we have the RTD driver 3.0.0 P07 for # S32K3 uC.

What we observed is that the Crypto driver is not correctly interpreting the mode coming from upper layers (eg. CSM), in case CRYPTO_OPERATIONMODE_STREAMSTART (which is a START and an UPDATE operation together) is passed to the Crypto driver, this does not work as expected, in one method "Crypto_Hse_OperationModeControl" is translated to CRYPTO_OPERATIONMODE_STREAMSTART==CRYPTO_OPERATIONMODE_START==CRYPTO_OPERATIONMODE_SINGLECALL and in other method "Crypto_Hse_ConfigureAccessMode" it directly translates to HSE_ACCESS_MODE_ONE_PASS (as STREAMSTART is not contemplated and goes to default processing) which is incorrect from our point of view as mode is a bit-wise mask and shall be treated as such. Please see attachment pictures also.

We think at Crypto driver level if there is a STREAMSTART mode coming shall be implemented in 2 calls (Crypto_Hse_SendMsg) towards the HSE FW one with START and one with UPDATE.

According to AR spec SWS_Crypto_00017 : ... These operations can be combined to execute multiple operations at once. Then, the operations are performed in the order “START”, “UPDATE”, “FINISH”.

Thanks a lot for supporting,

Ovidiu

0 Kudos
Reply
1 Solution
1,069 Views
DanNguyenDuy
NXP Employee
NXP Employee

Hello @ovidiubriscan,

The development team confirmed this is a bug (ticket ID: SECRDR-2417). This issue will be fixed on the next releases in the future.

Best regards,

Dan

View solution in original post

2 Replies
946 Views
AlexBarkat
Contributor I

I appreciate you bringing up this issue with the Crypto driver for S32K3 microcontrollers. It's crucial to tackle such discrepancies to ensure the driver performs as expected. It seems there might be a misunderstanding of the mode in the Crypto driver, leading to unexpected behavior. Your idea of splitting it into two separate calls (START and UPDATE) aligns with the AR spec SWS_Crypto_00017, which outlines the order of operations. In case you're still hunting for more information, I have a suggestion. You can also try using a cryptomixer, which could help with crypto-related issues. Hopefully, the NXP team can address this problem and provide a solution to ensure the Crypto driver functions correctly, maintaining the security of crypto operations.

0 Kudos
Reply
1,070 Views
DanNguyenDuy
NXP Employee
NXP Employee

Hello @ovidiubriscan,

The development team confirmed this is a bug (ticket ID: SECRDR-2417). This issue will be fixed on the next releases in the future.

Best regards,

Dan