Using Tamper with TF-M in STM32U5

[ZKRAC.1]

Hi,

In TFM and SBSFU applications, by default the anti-tamper protection is enabled for both internal tamper events and external tamper events. It is activated at the start of TFM_SBSFU_Boot, and remains active.

In case of tamper detection, sensitive data in SRAM2, caches and cryptographic peripherals are immediately erased, and the tamper interruption triggers a reset and the application is blocked (can't boot).

I'm using the anti-tamper protection in TFM with stm32U585, but I don't want the tamper interruption to trigger a reset, I have changed the default configuration in TAMP_IRQHandler(), but still a reset is triggered and the application is blocked at tamper detection, I have tried to catch reset causes (reset flags), and I have found a software reset flag (Set by hardware when a software reset occurs.) and NRST Pin reset flag (Set by hardware when a reset from the NRST pin occurs.), So I wonder what would be the cause of NRST reset, and is there any relation between NRST , TAMP and RTC, could the anti-tamper protection / RTC triggers NRST reset.

Any explanation or a hint, please !

Thank you.

Regards,

ZK.

[Jocelyn RICARD]

Hello @ZKRAC.1​ ,

the tamper detection is directly connected to the reset in the TFM adaptation. See platform_sp.c

#ifdef TFM_PSA_API

  psa_signal_t signals = 0;

  while (1) {

    signals = psa_wait(PSA_WAIT_ANY, PSA_BLOCK);

    if (signals & SPM_TAMPER_IRQ)

    { 

       tfm_hal_system_reset();

    }

This probably explains what you see.

Best regards

Jocelyn

[ZKRAC.1]

Hi @Jocelyn RICARD​ ,

Thank you for your answer, but how can I configure this, it's not clear for me.

Regards,

ZK.

[Fred]

Hi,

can you clarify the behavior you expect ?

I mean : if the TAMPER detects an intrusion then your product is probably under attack.

So, basically you would like to erase the assets but let the application run ?

This means your application might be misused.

Isn't it safer to force a RESET and then refuse to boot the application ?

I agree this leads to a Denial Of Service, maybe this is what you want to avoid ?

[ZKRAC.1]

Hi @Fred​ ,

Thank you for your answer, We didn't define the behavior we want yet, we are with investigations and trying to get the full control of the decision to take. Forcing a reset and blocking the application is not probably what we expected, rather we would like to erase the assets and send an alarm to the application.

Thank you.

Regards,

ZK.

[Fred]

Ok, but I am afraid the TF-M RAM is also erased.

The UM indicates:

"Protected SRAM2: SRAM2 is automatically protected against intrusion once the system is configured in RDP level 1. SRAM2 content is erased as soon as an intrusion is detected. Moreover, SRAM2 content can be write protected (content is frozen but can be read) until the next reset by activating the lock bit. In the TFM application example, the system has been configured to use the protected SRAM2 to share and to freeze initial attestation information between the TFM_SBSFU_Boot application and the secure application."

And the layout is like this according to the UM:

 

So, I am afraid that anyway your application cannot work properly as the SRAM2 is erased and locked.

[Fred]

Ok, looks like there are some subtleties I missed...

Actually, the code in platform_sp.c is NOT used for the TAMPER IRQ.

If you look at startup_stm32u5xx.c:

 Error_Handler,          /*  4: Tamper non-secure interrupt */

And Error_Handler is defined in tfm_platform_system.c:

void Error_Handler(void)

{

/* Reset the system */

  NVIC_SystemReset();

}

So:

1. It probably makes no sense to remove this RESET because anyway SRAM2 is wiped so your application should not be able to work any more
2. All the assets in SRAM2 and backup registers...are wiped

but the assets in FLASH are preserved.

So, after RESET, SBSFU should be able to boot your application.

[ZKRAC.1]

Hi @Fred​,

Thank you for your answer, So it's a hardware configuration that the SRAM2 is protected against intrusion and the content is erased or blocked, which block the secure application !? I understand why it doesn't make any sense to remove the RESET in Error_Handler() because the SRAM2 is erased or blocked, but I don't understand why SBSFU should be able to boot ?

Thank you.

Regards,

ZK.

[Fred]

SBSFU only relies on FLASH content to initialize its RAM at startup.

So, even if the SRAM2 and backup registers and other elements have been wiped, nothing is missing for SBSFU to restart properly.

The depth of erasure depends also if you are in VDD or VBAT supply mode.

Please check in the appropriate user manual the exact behavior for your selected device.

[ZKRAC.1]

Hi @Fred​ ,

I understand that SBSFU only relies on FLASH, but option bytes (static protections) are configured at SBSFU level, and once a reset is forced after tamper detection option bytes are not correctly configured (the config is erased) and SBSFU can't boot.

Thank you.

Regards,

ZK