STM32 MCUs Security

Does anyone know whether STM32U585 contains a die shield?

Hello,I've looked at X-CUBE-PQC (ML-KEM, ML-DSA, LMS/XMSS verification) and the recently announced ST54M with its PQC accelerator. Two things I couldn't find answers to:X-CUBE-PQC currently targets the STM32H563. Are other STM32 families planned? Is the implementation hardened against side-channel attacks, or is it intended for unprotected use? Does ST plan hardware acceleration for ML-KEM/ML-DSA (NTT, Keccak) in future STM32 parts, like the SHA-3 accelerator in Stellar or the ST54M engine? If so, which families, broadly?I understand roadmap details may not be public, so "under consideration" or a pointer to the right contact would already help. Thanks!

I am following this link for OEMiROT example with STM32C5 : https://wiki.st.com/stm32mcu/wiki/Security:How_to_start_with_OEMiRoT_on_STM32C5 But this example and steps are with IAR embedded workbench and Open-CMSIS.I need example and configuration with STM32Cube IDE to achieve OEMiROT with STM32C5 series. Let me know if any hint or example already provided

Hello,I am working with an STM32H7S3L8 and I am currently testing the SAES and CRYP AES hardware accelerators using the STM32Cube HAL. I am using:MCU: STM32H7S3L8 Board: NUCLEO-H7S3L8 Firmware package: STM32Cube_FW_H7RS V1.3.0 API: `HAL_CRYP_Init()` and  `HAL_CRYP_Encrypt()` AES mode: AES-128-ECB SAES and CRYP are tested independently with the same NIST AES-128 test vector://CRYP TEST:int tests_cryp_aes128_ecb(void){ /* * NIST SP 800-38A * F.1 ECB-AES128.Encrypt */ __ALIGN_BEGIN static const uint32_t key[4] __ALIGN_END = {0x2B7E1516, 0x28AED2A6, 0xABF71588, 0x09CF4F3C}; __ALIGN_BEGIN static const uint32_t plaintext[4] __ALIGN_END = {0x6BC1BEE2, 0x2E409F96, 0xE93D7E11, 0x7393172A}; __ALIGN_BEGIN static const uint32_t expected_ciphertext[4] __ALIGN_END = {0x3AD77BB4, 0x0D7A3660, 0xA89ECAF3,

Board: STM32N6570-DK. STM32CubeIDE FSBL + Appli project, Appli XIP from external flash (EXTMEM_XIP_IMAGE_OFFSET = 0x100000, EXTMEM_HEADER_OFFSET = 0x400). Appli signed with STM32_SigningTool (-align) and flashed at 0x70100000.Symptom:- DEV boot (debugger loads and runs): the FSBL → Appli handoff works and the application runs normally.- Flash Boot (standalone): the FSBL prints "init done, calling BOOT_Application" and then nothing, every time. No fault handler output, no reset.Already checked:- JumpToApplication() disables SysTick, IRQs and both caches before setting VTOR/MSP (standard ST pattern). Under DEV boot, a valid SP/PC is read from the image.- Removed all snprintf/newlib use from the FSBL boot path, and a print after the VTOR switch; no change.- Offsets and signing match the extmem config.Key observation (SWD hot plug, STM32CubeProgrammer, no reset):- DEV boot: AP1 (Cortex-M55) reachable, core identified, memory readable.- Flash Boot while hung: AP1 completely unreachable (cor

I am evaluating STiRoT + OEMuRoT on an STM32H5F5J-DK using the STM32CubeH5 v1.7.0 package by following the ST documentation:Security:OEMiRoT OEMuRoT for STM32H5 - stm32mcu How to start with STiRoT_OEMuRoT on STM32H573 - stm32mcu Getting started with STiRoT (ST immutable Root of Trust) for STM32H5 MCUs - Application noteThe board can be provisioned and the following currently work correctly:-  STiRoT starts successfully.-  OEMuRoT starts successfully.-  Secure and non-secure applications are authenticated and executed normally.-  Application updates (swap mode) through the OEMuRoT flow are functional.The next step is to confirm whether the OEMuRoT authentication and encryption keys can be updated after the board has already been provisioned, without reprovisioning the complete board. Test procedures as below:Generate new OEMuRoT keys Using STM32TrustedPackageCreator (TPC), a new set of OEMuRoT authentication/encryption keys were generated through ‘OEMuRoT_Config_Keys.xml’ Generate the O

Hello,I am using an STM32H562RGT6 (1 MB Flash) on a custom board.When TrustZone is enabled, the non-secure area of Bank 2 can be programmed successfully, but it cannot be erased sector by sector. The erase operation only works when performing a full mass erase. If I attempt to erase individual sectors, the operation appears to complete without error, but the flash contents remain programmed.My development environment is:STM32CubeIDE 2.2.0 STM32CubeMX 6.18.1 STM32CubeProgrammer 2.23.0I have attached the current Option Bytes configuration.This issue becomes particularly significant during debugging, when updating the non-secure firmware. Since the old contents are not actually erased, the programming operation results in a verify mismatch.I have also noticed some inconsistencies in the flash memory configuration:When enabling TrustZone (TZEN = 0xB4):SECWM1_PEND is automatically set to 0x7F, covering flash up to address 0x080FE000. SECWM2_PSTRT = 0x00 and SECWM2_PEND = 0x7F, covering flas

I am using the NUCLEO-U575ZI-Q board.In ST32CubeProgrammer, the option byte TZEN is enabled.In this state, when I changed the readout protection level from Level 0 to Level 1, I was no longer able to connect via ST-Link.Please tell me how to recover so that ST-Link connection becomes possible again.

In the STM32H5 series security document, STM32H5F4 is missing from the OEMiRoT + OEMuROT support controller list. Is STM32H5F4 a derivative of STM32H5F5, and does STM32H5F4 have the same security support as STM32H5F5?  

Hello ST Team,I am evaluating the secure boot and secure firmware update solutions for the STM32H5 family and plan to implement OEMuRoT  on an STM32H5F4 device.While reviewing the wiki article OEMiRoT OEMuRoT for STM32H5, I noticed that the STM32H5F4xx is not listed as a supported device family.Security:OEMiRoT OEMuRoT for STM32H5 - stm32mcuI would like clarification on the following points:Is STM32H5F4xx intentionally excluded from OEMuRoT support? Are there any hardware or security-feature limitations in STM32H5F4 that prevent OEMuRoT implementation? My target device is STM32H5F4, and I am planning a secure firmware update architecture based on Root of Trust and authenticated firmware updates. Any guidance or roadmap information would be appreciated.  Thank you,             RJ

Hello ST Team,We are evaluating STM32TRUSTEE-SM (Secure Manager) on STM32H5F4 devices and would like clarification regarding the external flash support architecture.From the STM32TRUSTEE-SM documentation and wiki pages, we understand that:Secure Manager provides an External Flash Profile.An External Flash Driver is referenced as part of the Secure Manager configuration flow.External firmware and data confidentiality can be enabled through OTFDEC.OTFDEC-based secure external memory access is described together with the OCTOSPI peripheral.Secure Manager supports firmware download slots located in external flash memory.However, we need clarification on the supported external memory architecture and driver model.Questions1. External Flash Interface Support restricted to memories connected through the OCTOSPI peripheral, or are other                  external memory interfaces also supported? Specifically, does the External Flash Profile support:     Octal SPI NOR Flash, Quad SPI NOR Flash,

Hello ST Community,I am working with an STM32H7S78-DK board and trying to perform Debug Authentication using STM32CubeProgrammer v2.21.0.The Discovery sequence succeeds successfully, and the target is detected correctly. However, the Debug Authentication fails after selecting the required permission.EnvironmentBoard: STM32H7S78-DK STM32CubeProgrammer: v2.21.0 SDM Library: v1.2.0 SDA version: 2.0.0 PSA lifecycle: ST_LIFECYCLE_CLOSED PSA authentication version: 1.0 Cryptosystem: Ecdsa-P256 SHA256 Key: Keys/key_3_leaf.pem Certificate: Certificates/cert_leaf_chain.b64 Password: Binary/password.binDiscovery resultThe discovery command completes successfully      -------------------------------------------------------------------                       STM32CubeProgrammer v2.21.0      -------------------------------------------------------------------Start Debug Authentication SequenceOpen SDM LibSDMOpen                       :   624 : open       : SDM API v1.0SDMOpen                       :

Hello,We are going to use the STM32H573 MCU (STM32H573IIK3Q) on our board, and we are now preparing for mass production. Production will be done at an external contract manufacturer (not in-house), and we need to provision keys and firmware securely during programming.My main question: Is the STM32HSM-V2 card strictly required for secure programming at high volume, or are there supported alternatives?Specifically:1. As far as I understand, the SFI license mechanism is tied to ST's key hierarchy inside the ROM bootloader, so a third-party/commercial HSM (Thales, nShield, etc.) cannot generate licenses that the chip will accept. Is that correct, or is there any supported way to run SFI with our own HSM infrastructure instead of the ST smartcard?2. If STM32HSM-V2 is the only option: for volumes well beyond 300 units, V2ML (10K) and V2HL (100K) do not seem to be orderable through distributors. Is the intended path to request them through an ST sales office, and what lead time should we pla

OverviewDebug Authentication Discovery occasionally succeeds in CLOSED state, but Full Regression fails (“Unable to boot on RSS_DA” / “Unable to detect DBGMCU Mailbox”)Get ready for the stm32 safari! Product / Environment- Board: Custom based off of STM32H7S78-DK (MB1736)- MCU: STM32H7S7L8H6H- Debugger(s) used: STLINK-V3SET- Tool: STM32CubeProgrammer v2.19.0- ST-LINK FW: V3J17M10B6S1- Board setup used during recovery attempts:- tried altering Boot0 (boot from RSS/system flash)- tried manual reset- tried low SWD speed and hardware reset modes Summary of the issueI was attempting to recover the board after secure configuration experiments. The board was originally reachable over SWD, but after running the **`ROT_Provisioning/DA/provisioning.sh`** flow from the STM32CubeH7RS package, normal SWD access stopped working. The board is now in **CLOSED** state, and **Debug Authentication Discovery** can occasionally succeed if I hit a very narrow timing window at power-up, but an

Hello,I would like to add Secure Boot + SFU functionality to my TouchGFX app with STM32N6. Since it is a graphics app, i don’t want to partition the external flash memory as installation and download slots as shown in the ST wiki for OEMuROT. https://wiki.st.com/stm32mcu/wiki/Security:OEMuRoT_for_STM32N6 To use external memory for apps and assests efficiently; below architecture is more suitable for me. Which changes are needed in the ST example ROT projects? With this, is it possible to debug the app code?                  Normal boot                      │                     ▼BootROM → Secure FSBL → verify App + Assets → HMI            Firmware update                      │                     ▼             USB / CAN                      │           signed package                      │                     ▼                Secure FSBL                      │     signature + version check                      │                 program NOR                      │                  verify

I am working on a batch script to disable TrustZone on an STM32U595VJT connected via JLINK using the STM32CubeProgrammer CLI tool.The device has both OEM1KEY and OEM2KEY set to [31:0] = 0xABCDEFAB, [63:32] = 0x12345678I am trying to run the following command when the RDP level is 1 and TrustZone is enabled with the device booted into the root secure services:STM32_Programmer_CLI.exe -c port=JLINK mode=HotPlug reset=HWrst freq=4000 ap=0 speed=Reliable -unlockRDP1 0xABCDEFAB 0x12345678 -ob RDP=0xAA TZEN=0The command fails to set the RDP level and TZEN flag with the following output: ------------------------------------------------------------------- STM32CubeProgrammer v2.20.0 -------------------------------------------------------------------Connecting to J-Link/Flasher ProbeWarning: The frequency input is not supported by the connected J-Link/Flasher !Device=Cortex-M33Unlock RDP1 password successfully doneDevice ID : 0x481Voltage : 3.33VFrequency

On the STM32C542RC, this is my current FLASH layout:-- OEMiRoT flash layout:-- Bootloader : 0x08000000 .. +0x10000-- Keys : +0x10000 (0x2000)-- NV counters : +0x12000 (0x2000)-- Primary app slot : 0x8014000 size=0x16000-- App code (post-hdr) : 0x8014400 size=0x15c00-- Secondary app slot : 0x802a000 size=0x16000-- OEMiRoT option bytes to program:-- HDP1_END = 0x9 WRPSGn1 = 0xfe00Everything is working well (update of user application, boot, etc...) (MCUBOOT_USE_HASH_REF is not defined).But I have an issue:I want to use the external User Data Flash at the address FLASH_EXT_USER_BASE 0x08400000UL, requiring the option byte EDATA_EN = 0. When I read from that address in the User Application, I only read zeroes (RAZ) -- simple as `*(const int *)FLASH_EXT_USER_BASE == 0`, so this feels like the cause is some sort of HDP. By the way, the writes do work (at least when the MCU is reset, as STM32CubeProgramm

Hi all,Are these available for these samples? I am working on some secure boot devices and would like to try these chips as I am familiar with the STM32 ecosystem. Are you guys have any suggestion which NUCLEO can use for secure-boot purpose?I see there are NUCLEO-H5xx are designed for hardware crypto, sample project and we can build for chain of trust from these family chips?Please let me know, thank you.

 I have been reading the discussion here: Understanding the bootloader GO command on the STM32H5 seriesI am trying to understand one point in particular. The discussion describes the problems associated with using the bootloader GO command on STM32H5, and refers to the state of the device and peripherals when the bootloader transfers control to the application. Does the H5 system bootloader GO command actually support transferring execution to an application loaded into SRAM? I ask because the wording left me uncertain about whether the issue being discussed applies to SRAM applications, Flash applications, or both. Perhaps ​@STea or someone else from ST, could clarify please?

Hi Community,I’m provisioning an STM32H573 (installed on a NUCLEO-H563ZI board; I replaced H563 with H573). I followed the ST example STiRoT_OEMuROT from STM32Cube FW H5 v1.6.0. During provisioning the script aborts with:Error when trying to Set SECBOOT_LOCK option byte to 0xC3 (unlock secure boot address)  Provisioning aborted.Environment: - MCU: STM32H573 (2 MB flash)- Host tools: STM32_Programmer_CLI v2.19.0- Product state chosen in provisioning script: OPEN.after i read the option bytes using STM32_Programmer_CLI -c port=SWD -ob displ i found that,   Product state: PRODUCT_STATE: 0xED (Open) BOR Level: BOR_LEV : 0x0 (BOR Level 1, the threshold level is low (around 2.1 V)) BORH_EN : 0x0 (0x0) User Configuration: IO_VDD_HSLV : 0x0 (0x0) IO_VDDIO2_HSLV: 0x0 (0x0) IWDG_STOP : 0x1 (0x1) IWDG_STDBY : 0x1 (0x1) BOOT_UBE : 0xC3 (ST-iRoT (system flash) selected) SWAP_BANK : 0x0 (0x0) IWDG_SW : 0x1 (0x1

Hi ST Team,We are currently considering the STM32H5F4 for an upcoming product, and Secure Manager support is a key factor in our device selection process.Could you please confirm whether STM32H5-SMAK support for STM32H5F4Z devices is planned and whether there is any documentation, reference project, or preliminary guidance available for evaluation?This information will help us assess the suitability of STM32H5F4 for our product architecture.Thank you for your support.Best regards,RJ

Dear ST Team,I am writing to follow up on my request for access to the STM32TRUSTEE-SM (Secure Manager) resources. I submitted my request several weeks ago, but I have not yet received any update, approval notification, or access instructions.Could you please check the status of my request and help expedite the approval process? If any additional information or action is required from my side, please let me know.The product page I am referring to is:https://www.st.com/en/embedded-software/stm32trustee-sm.htmlThank you for your support. I look forward to your response.Best regards,RJ

Reverting STM32H7B3 from Secure Access Mode to Standard ModeHello,I am working with an STM32H7B3 and currently evaluating the Secure Access Mode and secure user area functionality.I am going to configure the device as follows:Create a secure user area in Bank 1 with DMES1 = 1 Create a secure user area in Bank 2 with DMES2 = 1 Enable Secure Access Mode (SECURITY = 1) The device is currently at RDP Level 0My requirement is to support reverting the device from Secure Access Mode back to Standard Mode during development/service.My understanding is that the following sequence can be used:Change RDP from Level 0 to Level 1. Perform an RDP regression from Level 1 to Level 0. Since DMES1/DMES2 are set to 1, the secure areas should be erased during the RDP regression. After the secure areas have been removed, disable Secure Access Mode (SECURITY = 0). Reset the device and boot normally in Standard Mode.In other words:RDP Level 1 → RDP Level 0 regression → secure areas removed due to DMES1/DMES2

In my application on an STM32H7S3 I’ll have to often read option byte keys, and I want to limit the possibility of accidentally writing to option byte keys.According to the reference manual, that’s where the PG_OPT bit of FLASH_OPTCR comes in:PG_OPT: Program options0: Update operations to user option bytes and option byte keys do not start1: Write operation to user option bytes and option byte keys is enabledPerfect, so I just need to be sure this bit is not set when I don’t want writes.To double check this bit is not needed to be set during the configuration of FLASH_OBKCR to initiate read operations, the description of the KEYPROG bit - when set to 0 - seems to hint the PG_OPT bit doesn’t need to be set according to the reference manual:KEYPROG: Key programThis bit must be set to write option byte keys (keys are read otherwise).0: Read key. Result of the operation is stored in FLASH_OBKDRx registers, if applicable.1: Program key if PG_OPT is set in FLASH_OPTCR register, and KDREF fla

Hi everbody,we are using an STM32H573 with ST Secure Manager and would like to perform the final Product State transition from TZ-CLOSED to CLOSED at the end of production.At this point, the device is already assembled and SWD/JTAG is no longer accessible. Therefore, we would like to trigger the transition through an authenticated internal command from the Non-Secure application.From the documentation, we understand that:PRODUCT_STATE is controlled via Flash Option Bytes. The Non-Secure application cannot directly modify the relevant Secure Flash registers. We could not find a documented Secure Manager runtime API for changing the Product State.Could you please clarify:Is there an existing Secure Manager API to perform TZ-CLOSED → CLOSED at runtime without SWD/JTAG? If not, can this be implemented via an OEM Secure Module? Is an OEM Secure Module allowed to modify the PRODUCT_STATE Option Byte?Thanks and best regardsMario