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 ?

[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

[Fred]

No, Option Bytes should not be affected by the tamper.

Besides, we recommend using RDP-level 2 so the option bytes are frozen in this case.

In RDP-level2 (or production mode), SBSFU only checks the consistency of the OBs.

[ZKRAC.1]

In Dev mode Option Bytes were affected by tamper detection, in Prod mode they should not be affected, So to draw a conclusion :

• In TFM_SBSFU_Boot the tamper detection is handled by TAMP_IRQHandler() defined at low_level_security.c
• In TFM_Appli the tamper detection is handled by Error_Handler() defined at tfm_platform_system.c
• At tamper detection the SRAM2 is erased or blocked so the initial attestation information shared between TFM_SBSFU_Boot and TFM_Appli are frozen.
• TFM_Appli is always blocked once an intrusion is detected, even if we remove the Reset.
• Using Prod mode instead of Dev mode will allow TFM_SBSFU_Boot to reboot !

So the default configuration at tamper detection (forcing a RESET and Reboot) can't be changed !

Thank you.:)

Regards,

ZK