STM32 MCUs Security

I’m building a product with the STM32U575 that needs to be able to support secure boot and firmware upgrades through UART. It should also be able to program the ST67W61 through this bootloader. I have almost no experience with secure bootloaders however. I found SBSFU by MCUBoot, which seems to be the best option for the STM32U5 series.I got the SBSFU example from the STM32CubeU5 package running on my Nucleo U575ZI-Q. This uses secure and non-secure parts however, while my own firmware is completely non-secure. From what I understand only the bootloader needs to run in the secure domain, while the firmware and loader can run in a non-secure domain. Is this correct?I also have a requirement to support OTA firmware updates. I would envision this download to use the loader application. Is this correct or do I require dual slot mode?Do I also understand correctly that to implement this bootloader for my custom firmware the best way is to modify the example in STM32CubeU5 to my needs?If the

I am working on a secure bootloader implementation for the STM32H755 microcontroller using the NUCLEO-H755ZI-Q development board.I am facing an issue where the MCU has become inaccessible after configuring the secure memory area through option bytes. I would appreciate your guidance on recovering the device.Hardware and software detailsBoard: NUCLEO-H755ZI-Q MCU: STM32H755 STM32CubeProgrammer: Version 2.20.0 Debug probe: Onboard ST-LINK V3 RDP: 0xAA (Level 0) SECURITY: Enabled SEC_AREA_START1: 0x000 SEC_AREA_END1: 0x1FF (128 KB secure area)Sequence of eventsI erased the user flash before configuring the secure memory area, so the bootloader firmware was no longer present. I enabled the SECURITY option byte and configured a 128 KB secure area from 0x08000000 to 0x0801FFFF. After applying the option-byte configuration, I could no longer connect to the MCU. The RDP level remains 0xAA (Level 0). I have not intentionally changed it to Level 1 or Level 2.Recovery attemptsI have tried the fol

Hello ST team,In a previous discussion, ​@Jocelyn RICARD confirmed that X-CUBE-CRYPTOLIB V4.x was not reentrant, partly due to its use of the CRC hardware peripheral.I understand that V5.0.0 no longer depends on the CRC peripheral, but I could not find an explicit statement in the documentation regarding thread safety or reentrancy.Could you please clarify the following? Is X-CUBE-CRYPTOLIB V5.0.0 fully reentrant and thread-safe when called concurrently from different RTOS tasks, provided that each task uses independent contexts and buffers? Does this also apply to single-call APIs such as cmox_hash_compute() and cmox_cipher_encrypt(), which do not expose an explicit context? Can ST confirm that V5.0.0 does not use any shared mutable internal state that could prevent concurrent execution? Is any external synchronization (e.g., an RTOS mutex) required when calling CMOX APIs from multiple tasks? We would like to determine whether a global mutex, previously necessary with V4.x, can

As per the subject line, is there a way to derive keys from a symmetric master key stored in a slot of an STSAFE-A120, using the `stselib` included in the X-CUBE-STSE-01 software package? Thanks,Giorgio.

Hi Folks,I was working on Secure Boot for the STM32H533, following the documented steps for the STiRoT boot path. I used the STiRoT boot path based on the STM32 documentation.https://wiki.st.com/stm32mcu/wiki/Security:How_to_start_with_STM32CubeMX_STiRoT_Boot_path_on_STM32H57 I am trying to bring the device back to the OPEN state, but I am facing an issue during the process. After providing the Key File Path and Certificate and selecting Full Regression permission, the Debug Authentication step fails.16:42:50:983 : Start Debug Authentication Sequence16:42:50:984 : SDMOpen                       :   765 : open       : SDM API v1.016:42:50:985 : SDMOpen                       :   766 : open       : SDM Library version v1.4.016:42:50:986 : open_comms                    :   606 : open       : Asserting target reset16:42:50:987 : open_comms                    :   614 : open       : Writing magic number16:42:50:987 : open_comms                    :   678 : open       : De-asserting target rese

Hello ST team,I am working on a NUCLEO-H533RE board with TrustZone enabled and the following boot chain:STiRoT → OEMuRoT → Secure/Non-secure applicationMy device reports SFSP version 1.2.0 (0x01020000).For a secure-boot timing experiment, I would like to use an LSE-clocked RTC as a time reference across a software/system reset.I found the ES0621 erratum titled “Backup domain erased upon reset when STiRoT boot is active and the clock other than LSI selected.”My understanding is that, on affected SFSP versions, STiRoT selects LSI for RTC/TAMP. If the application subsequently switches the RTC clock to LSE, the backup domain is erased during a subsequent reset. Is there any supported initialization or reset sequence that preserves an LSE-based RTC time reference across reset on SFSP 1.2.0, while retaining the STiRoT boot path?I can use DWT for measurements within OEMuRoT, but I need a continuous reference across reset to include the earlier STiRoT stage. Reference: STM32H523xx/STM32H533xx

I am trying to understand the readout protection functionality in the STM32G4 series. When I read the G4 series manual, I get the impression that level 1 protection will protect the flash, option bytes, CCM SRAM and RTC backup registers from JTAG / SWD readout – but curiously not the regular SRAM.Have I understood this correctly?Furthermore, I understand that level 2 will protect the entire chip – but that this is irreversible. So, if I do that to a chip, I can never again use that one for debugging. Not even after a full chip erase, which I’m not even certain that I can perform. As a developer, I see this as pretty much bricking the board.If I am correct that RDP level 1 will not protect the regular SRAM from readout via JTAG or SWD, are there other ways to protect it from JTAG / SRAM probing?

Hello ST Support team,We are building a product on the STM32N645 with the STM32CubeN6 OEMuRoT secure boot flow (MCUboot-based OEMuRoT, application image in external XSPI2 NOR, executed in place). We want to re-open debug on closed devices with the OEMuRoT password debug authentication (DA), using STM32CubeProgrammer, the way it is shown in ST's videos. CubeProgrammer cannot start the DA on our devices. We wrote our own host tool, and with it the same OEMuRoT firmware opens debug correctly. We need your help to make the standard CubeProgrammer flow work, because it is the procedure we want for production and service.1. SetupItem Version / state MCU STM32N645 (DBGMCU DEV_ID 0x486) Firmware package STM32CubeN6 [version]; debug_authentication.c of OEMuRoT is unchanged from the reference (same in V1.1.1 to V1.4.1) apart from the points in section 4 STM32CubeProgrammer v2.23.0 (SDM library v1.4.0, SDM API v1.0) Probe ST-LINK V3SET, firmware V3J16M8B5S1, SWD, NRST connected Boa

I have switched an STM32H562 to PROVISIONING product state (from my bootloader code).The plan was to program DA data (certificate), then set TZEN_ENABLE, and finally set product state to CLOSED.When I do this all in one go, with the STM32CubeProgrammer tool, without power cycling the STM32H5 in between, I can set the product state to CLOSED, and after that perform a REGRESSION using the DA certificate and private key. So I know my procedure and DA data must be correct. However, I am now trying to do this step by step, from within my bootloader code.After the first step, just setting product state to PROVISIONING, when the MCU power cycles, I cannot recover.I cannot write DA data from STM32CubeProgrammer, because I get this error:16:26:35 : Error: Unable to reset MCU !16:26:35 : Error: OBKey Provisioning failedI cannot directly write the product state to OPEN (which makes sense)Also, writing it to REGRESSION is not possible in STM32CubeProgrammer.I think REGRESSION is only possible usin

Hello ST Support,I am using the NUCLEO-H533RE board and would like to clarify whether the STM32H533 supports hardware-accelerated SHA-3, particularly SHA3-256.I noticed an inconsistency in the documentation:The product page and datasheet feature summary list “HASH (SHA-1, SHA-2, SHA-3)”. Section 3.30 — HASH hardware accelerator of datasheet DS14539 Rev 3 describes SHA-1/SHA-2 algorithms but does not mention SHA-3. I could not find a SHA-3 operating mode in RM0481, or a corresponding algorithm selector/API in the STM32CubeH5 HAL version installed in my project.Could you please confirm:Does the STM32H533RET6 physically support hardware-accelerated SHA3-256? If so, which registers, HAL APIs, and STM32CubeH5 version should be used? Is an example available?Thank you for your clarification. 

  I am integrating the STSAFE-A110 as a secure element with the STM32H523 as the host MCU. I am using the latest version of the X-CUBE-STSE01 middleware and want to establish and use a secure channel between the secure element and the host. Using the Host Key Provisioning example provided in X-CUBE-STSE01, I provisioned the Host MAC and Host Cipher keys into the secure element. I want to store 12 bytes of data in data partition index 2 during provisioning and read the data back during runtime in the host environment. Currently, I can successfully store and read the data using the following APIs with STSE_NO_PROT:             stse_data_storage_update_data_zone()            stse_data_storage_read_data_zone() However, I want to perform these operations using STSE_HOST_C_MAC_R_MAC, as this is the Host Session protection mode supported by X-CUBE-STSE01. On one board, I receive the STSE_INVALID_C_MAC error. I provisioned the keys on another board, but on that board, I receive the STS

Hello,I am evaluating cryptographic performance for a secure boot using a NUCLEO-H533RE board and the OEMiRoT example from STM32CubeH5.I compared two AES-128-CTR implementations:Software: mbedtls_aes_crypt_ctr(). Hardware-backed: bootutil_aes_ctr_encrypt() using SAES.The mean encryption times are:Input size Software SAES-backed implementation 32 bytes 10.55 µs 29.46 µs 256 bytes 76.70 µs 222.88 µs 1024 bytes 303.50 µs 886.02 µs  For an academic comparison, is it accurate to describe this result as “software AES-CTR versus SAES ECB with software CTR and driver protection overhead”? Thank you!

Hello to all, I follow the creation of OEMiROT_Boot, app secure, app not secure with NUCLEO-H563ZI like suggested into  https://wiki.st.com/stm32mcu/wiki/Security:How_to_start_with_STM32CubeMX_OEMiRoT_Boot_path_on_STM32H563.I want to use Visual studio Code with  extension STM32CubeIDE.Follwing the instructions into the web page “:How_to_start_with_STM32CubeMX_OEMiRoT_Boot_path_on_STM32H563.” I have to compile the OEMiROT_Boot, if I import the project OEMiROT_Boot from STM32Cube_FW_H5_V1.7.0 for NUCLEO-H563ZI, into vs code there are error I have to copy  “stm32h5xx_bl2.ld” to utput.ld into the same folder to let vs code to import without error but it’s not possible to compile the project, then I’ll compile the other with keil without problem.After I’ve follwed the list of operation to do but at the point “ 5. Debug Authentication configuration” I cannot select configure (into the project configuratione of MXCube I’ll try to create a project KEIL and CMAKE without lack because I can comp

Hi,The CRA is making Secure Boot and Secure Update increasingly important for a wide range of products.I have fully reviewed the playlist at https://www.youtube.com/playlist?list=PLnMKNibPkDnGd7J7fV7tr-4xIBwkNfD-- as well as documents UM2262 and AN5056.Unfortunately, AN5056 is far too brief to properly understand how to implement this yourself.The video series only features controllers that are already covered in the existing examples.I wanted to ask if it might make sense to continue the video series and address these specific points. I believe this would be a huge help to many customers.Right now, I feel like it will take me months to customize SBSFU for my needs.Both the video series and AN5056 lack coverage of fundamental aspects, such as:-Changing the update interface from UART to something else—for example, USB (virtual COM) or CAN. Where exactly are the lines of code that need changing?-Implementing and explaining a controller that isn't currently covered by an example (e.g., ST

Hello everyone,I'd like to know if anyone has tried setting the size of the FLASH memory in a .ld file so that the unsafe zone is larger than the safe zone, for example, by changing the size of the unsafe zone .ld file to more than half the size of the flash memory and leaving the size of the safe zone .ld file at half the size of the flash memory.

Hello everyone,I'm testing the use of trustzones in my application. The examples are working fine, however my application requires more FLASH in the non-secure zone than in the secure zone. The initial examples have the following parameters (default):The memory definition in the secure linker script is as follows:/* Memories definition - Secure Zone */MEMORY{ RAM (xrw) : ORIGIN = 0x30000000, LENGTH = 320K FLASH (rx) : ORIGIN = 0x0C000000, LENGTH = 1016K FLASH_NSC (rx) : ORIGIN = 0x0C0FE000, LENGTH = 8K}The memory definition in the non-secure linker script is as follows:/* Memories definition - Non-Secure Zone */MEMORY{ RAM (xrw) : ORIGIN = 0x20050000, LENGTH = 320K FLASH (rx) : ORIGIN = 0x08100000, LENGTH = 1024K}The Option bytes is as follows:So far it works. My application requires me to use 80K of memory in the secure zone and 1968K of memory in the non-secure zone, as I will show below:The memory definition in the secure linker script i

Hello ST Community,I am using a NUCLEO-H533RE board with STM32CubeH5 and STM32CubeProgrammer. I would like to clarify the correct procedure for programming firmware over ST-LINK/SWD with these boot configurations:STiRoT → Secure/Non-secure application STiRoT → OEMuRoT → Secure/Non-secure applicationMy current standalone STiRoT configuration was provisioned using the supplied scripts, with the final product state set to OPEN.When CN7 pins 5 and 7 are connected (BOOT0 tied to VDD), the application runs, but STM32CubeProgrammer cannot connect through SWD. It reports:I have tried the following settings:Port:        SWDFrequency:   400–1000 kHzMode:        Under ResetAccess port: 1Reset mode:  Hardware resetIf I remove the CN7 pin 5–7 jumper and power-cycle the board, SWD connection and programming work. After programming the signed/encrypted update image, I disconnect, power off, reconnect the jumper, and power on. The application then runs with the updated LED blinking behavior.Could you

Hello, We are trying to implement ECDSA where cloud generates Public and Private key and calculates hash of our firmware using SHA 256 and Sign the firmware using P256 method. I am using ECDSA API to verify the firmware in our bootloader I am facing some issues in verification I am using all the things based on example project prime256v1.c file for constantsuint32_t verify_firmware_signature_P256( const uint8_t* hash ){  PKA_ECDSAVerifInTypeDef in = {0};   in.primeOrderSize  = 32U;            // 256 bits = 32 bytes  in.modulusSize   = 32U;            // 256 bits = 32 bytes  in.coefSign     = 1U;             // 1 indicates a is negative (-3)  in.coef       = prime256v1_absA;      // Coefficient |a| = 3  in.modulus     = prime256v1_Prime;      // Prime p  in.basePointX    = prime256v1_GeneratorX;   // Generator Gx  in.basePointY    = prime256v1_GeneratorY;   // Generator Gy  in.primeOrder    = prime256v1_Order;      // Curve order n  in.pPubKeyCurvePtX = pub_x;           // Public key X 

Hi,I am working on flash memory protection mechanisms on STM32 microcontrollers (specifically STM32L476RG) and I have two closely related questions that I want to confirm at the hardware level.I understand that:RDP (Readout Protection) levels are stored in the Option Bytes The Option Byte Loader (OBL) reads these values at every power-on reset, before any user code executes Under RDP1, external debugger access to flash is blocked but the CPU can still read its own flash normally Under RDP2, the debug port itself is permanently disabledMy question is: what specific hardware block is actually responsible for enforcing this protection? and blocking the read request to secure flash region ?Specifically I want to confirm:Is this enforcement done purely in silicon/hardware, with no software component involved? Under RDP1, why does the CPU running normal user code still get real flash data, while an external SWD/JTAG debugger gets blocked — is this distinction made by the flash controller its

I’m using the OEMiROT_Boot example with the OEMiROT_Appli_TrustZone secure and non-secure example applications.I can build the code and correctly provision the NUCLEO-H563ZI board. The applications run correctly and I can attach to the secure and non-secure applications using the debugger. If I use regression to return the board to the OPEN state, I am not able to debug the applications by downloading the code from the debugger. When I try, I receive HardFault when the secure app tries to switch to the non-secure app. I have followed the directions in application note “AN5421” when configuring the secure and non--secure projects. I’m using V9.70.4 of the IAR Embedded Workspace. Using the debugger, I can see the correct code in the secure and non-secure addresses.Below is the debug log.Thu Oct 01, 2026 16:20:47: IAR Embedded Workbench 9.70.4 (C:\iar\ewarm-9.70.4\arm\bin\armproc.dll)Thu Oct 01, 2026 16:20:47: Loaded macro file: C:\iar\ewarm-9.70.4\arm/config/debugger/ST/STM32H5xx.dmacThu

Hello,its the first time for me trying to use the X-CUBE-SBSFU. So I downloaded the latest version (V2.8.0) and updated to the STM32CubeIDE V2.2.0 to be up to date.But the SECoreBin Project is not compiling. I get the error message:C:/Program Files/ST/STM32CubeIDE_2.2.0/STM32CubeIDE/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.14.3.rel1.win32_1.0.100.202602081740/tools/bin/../lib/gcc/arm-none-eabi/14.3.1/../../../../arm-none-eabi/bin/ld.exe: ./Application/Startup/se_key.o(SE_ReadKey_1): Unknown destination type (ARM/Thumb) in ./Application/User/se_crypto_bootloader.o./Application/User/se_crypto_bootloader.o: in function `SE_CRYPTO_AES_ReadKey':C:/Users/……./Application/ThirdParty/ST/STM32CubeExpansion_SBSFU_V2.8.0/Projects/NUCLEO-H753ZI/Applications/1_Image/1_Image_SECoreBin/Src/se_crypto_bootloader.c:222:(.text.SE_CRYPTO_Decrypt_Init+0x16): dangerous relocation: unsupported relocationC:/Program Files/ST/STM32CubeIDE_2.2.0/STM32CubeIDE/plugins/com.st.stm32cube.ide.

Hi,Unable to set the Product state to OPEN using the Provisioning script in the STiROT_OEMuROT example.Getting the below error: But,when i’m trying to set the Product state as CLOSED it is getting Success.Note: Ensured to connect the CN7/pin5 to CN7/pin7. Also,Below is the obkey_provisioning.log content:C:\My_New_Stuff\GIT\STM32H5\Projects\NUCLEO-H533RE\ROT_Provisioning\STiROT_OEMuROT>call ../env.bat Provisionning the .obk files ...      -------------------------------------------------------------------                       STM32CubeProgrammer v2.20.0                        -------------------------------------------------------------------ST-LINK SN  : 000E00264142501820353451ST-LINK FW  : V3J13M4Board       : NUCLEO-H533REVoltage     : 3.29VSWD freq    : 8000 KHzConnect mode: Hot PlugReset mode  : Software resetDevice ID   : 0x478Revision ID : --Error: Fail to read Flash SizeDevice name : STM32H533/523Flash size  : 512 KBytes (default)Device type : MCUDevice CPU  : Cortex-M33BL

There is a problem with STM32 signing tool version 2.21.0. When header version is 2.3 and alignment flag is used, then image length in header is greater by the alignment byte count.To reproduce:Create dummy.bin that is filled with 256 bytes of FF's. For example with HxD tool.Sign it with no keys:STM32_SigningTool_CLI.exe -bin dummy.bin --type fsbl --no-keys --option-flags 0x80000000 --output signed.bin --dump-header signed.bin --header-version 2.3 --alignView the signed.bin with hex viewer (e.g. HxD) at offset 0x6C which is Image length by UM3234 rev 2:It is 0x2C0 = 704. This is 448 bytes more than original 256 bytes.When removing --align flag from signing call, the length becomes correct, but this image is not bootable anymore because STM32N6 Boot ROM expects FSBL image start address to be aligned to 0x400.I want to use this length field to check during OTA that FSBL upgrade file size and checksum are correct before programming it into Flash. But I wonder how does N6 Boot ROM treat th

I am using the STM32H5F5 and plan to implement the Secure Manager. I would appreciate clarification on the following questions: Can the user application key be provisioned to the OBKey area during Secure Manager installation? After the Secure Manager is installed, can the user application write a key to the OBKey area? How can an application—secure or non-secure—read a provisioned OBKey?

Hello Team,We need clarification regarding OBKey Storage, Internal Trusted Storage (ITS), and Protected Storage (PS) in the STM32H5F5 device when using the Secure Manager framework.Is the OBKey, ITS and PS storage physically located within the device's 4 MB internal Flash memory, or does it reside in a dedicated secure memory region? Can a Non-Secure (NS) application directly read from or write to ITS, OB KEYS, PS storage areas in terms secure manager? If direct access is not allowed, what are the security mechanisms that prevent NS access?Regards,RJ