FAQs
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

Using Tamper with TF-M in STM32U5

ZKRAC.1
Associate II

‎2022-04-29 02:16 AM

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.

Labels:
0 Kudos
11 REPLIES 11
Fred
ST Employee

‎2022-05-04 01:43 AM

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.

0 Kudos
ZKRAC.1
Associate II

‎2022-05-04 02:33 AM

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

0 Kudos
Top