STM32H573 : RNG Seed Error (SEIS) when used with TZEN=1 and STiRoT

[hicham75]

Hi,

I try to use PKA for some ECDSA computation. For this purpose I needed to use PKA block. However, in SR register, I never get INITOK bit set.

I am working with TrustZone enabled. So, STiRoT is executed before my program.

After investigation, I've seen that bit SEIS in  RNG_SR is set. (while CEIS=0)

Despite reference manual stating in this case, it means some thing went wrong and RNG was able to auto-reset and recover, I think this is what is preventing PKA INITOK to be set.

"INITOK: PKA initialization OK
This bit is asserted when PKA initialization is complete. When RNG is not able to output proper
random numbers INITOK stays at 0."

With same program and with TrustZone disabled(Hence, STiRoT is not executed), RNG is correctly configured without any SEIS error and PKA INITOK bit is set.

I am using RNG in A configuration.

RNG = {
  CR = 0xf00e04,
  SR = 0x41,
  DR = 0x31b4c84e,
  NSCR = 0x3af66,
  HTCR = 0x6a91
}

HCLK(AHB2) is 250 Mhz and HSI48 is used for RNG sampling.

Could someone help with this issue or point any additional configuration to be checked?

Regards

[STea]

Hello @hicham75 ,

Thank you for sharing this. 
You will need to clear this flag as you don't have SECS and only SEIS is set indicating that the RNG has automatically recovered for the error and you application must clear this flag in order to make PKA init working properly 

it is worth noting that this will not impact the security entropy or performance of your application since you are using the recommended configurations in AN4230.
Regards

[hicham75]

Hi @STea ,

Thank you for your reply.

Unfortunately, I've already read that in another post. I tried to clear it but it will be set few instructions later.

Even, If I ignore it and proceed, PKA_SR_INITOK will not be set and PKA init will timeout.

I think it's related.

[STea]

Hello @hicham75 ,

Can you share the project which you are using and the configuration and tool versions to try and reproduce this from our side.
Regards

[hicham75]

Hi @STea 

I created a STM32CubeMX project following this tutorial:

https://wiki.stmicroelectronics.cn/stm32mcu/wiki/Security:How_to_start_with_STM32CubeMX_STiRoT_Boot_path_on_STM32H57

My changes to the tutorial are :

SYSCLK : 250 Mhz through clock configuration tool.

Activated RNG and PKA blocks.

How to reproduce the issue:
after MX_RNG_Init() is exectued, RNG is OK and SR register value is 0x1 (everything OK.)

Once you will step into MX_PKA_Init(), the RNG SR will change de 0x41 (SEIS error).

The PKA will timeout and cannot initialize, certainly due to RNG not correctly configured.

Regards,

[STea]

Hello @hicham75 ,

Thank you for your patience and for sharing this I'll check it as soon as possible and get back to you.
Regards 

[STea]

Hello @hicham75 ,

can you mention the steps you are following to execute this Firmware, as when I tried to debug it there is no problem in the RNG and PKA init functions:

Regards

[hicham75]

Hi @STea 

I use gdb for debug. I run the program with a breakpoint on MX_RNG_Init() and dispalys RNG structure:

after step over MX_RNG_Init() is executed, I step into MX_PKA_Init(), then after one or two instrctions, RNG->SR = 0x41.

I see unexpected values regarding RNG NSCR and HTCR registers in your screenshot.
Yours, do not contain NIST values but seems to contain default ones.
using NIST value(for configuration A), those registers should contain : 0x3aff66 and 0x6a91 respectively.

RN = {
  CR = 0xf00e04,
  SR = 0x41,
  DR = 0xe544d000,
  NSCR = 0x3af66,
  HTCR = 0x6a91
}

In zip file I handed to you, I was using HAL v1.3.0 which contains an bug for HAL_RNG_Init. I patched that issue ( STM also fixed it, as I see, in v1.4.0).
the wrong line is at file stm32h5xx_hal_rng.c:204

The fixed one is :

as per RM0481, when ever you need to update configuration, you have to set CONDRST bit at same transaction.

it seems for some reasons, you are not using HAL provided in ZIP archive.

[STea]

Hello @hicham75 ,

I have used the same firmware you provided without any migration with the patch that you added still I don't get problems:

just wanted to know did you provision the board as per the mentioned wiki page because the wiki instructs you to execute scripts to set option bytes and download the Firmware securely and it gets to the closed state, so no debug is available. so, I wanted to know what you are using to download the image. also did you change other OBs with CubeProgrammer?

Regards

[hicham75]

Hi @STea 

I used the script provisioning.sh as per ST wiki.

I've chosen when I was asked by the script, OPEN state. I avoid in dev phase to set state to CLOSE.

Is this has any impact? that seems not mandatory per ST wiki.

For the whole option bytes, I've just run on my target:

~/STMicroelectronics/STM32Cube/STM32CubeProgrammer/bin/STM32_Programmer_CLI -c port=SWD ap=1 mode=Hotplug -ob displ

Please find attached the complete list.

Those OB have been programmed by the script : provisioning.sh

Nothing has been done manually through ST Programmer.

Regards,