STM32 MCUs Security

Hello together,I search for a solution to put calibration data in a NS area.Background Information:we are using STM35H573 with STM secure manager.we use an ethernet Rest API to update Application including request install and so onNow I want to use the same Rest API to update configuration data. The BIN file shall be signed like a normal application. The behavior should be more or less the same: Restart µC, SM checks validity; app will be started,...I have read um3254 but I do not understand the section with large profile.I have read something about ITS, but I think this is not the solution I need. The calibration data must not be stored in the trusted area. They shall only validated bei the SM during update or startup. Thanks for joining this topic. Br Sebastian 

Hi,I added some follow-up questions to a message but I'm not sure if anyone will notice as I had already clicked "Accepted Solution" :-https://community.st.com/t5/stm32-mcus-security/stm32h5-simple-security-settings/m-p/885235/thread-id/9530#M9531Copying the questions regarding setting H5 security to be more like G4 RDP setting.1) Since the regression to open performs a full chips erase, am I right in thinking that we can use a common and not secure password? i.e. Revealing the password does not allow access to the firmware.2) Can I perform all of the steps listed, from my bootloader firmware? As far as I can see, the changes to product state just require a write to write to an option byte. I have yet to find the part of the reference manual that describes how to write the password file but looking through the scripts in the git repo mentioned seems to suggest that something is written to "address_password=0x8FFF000". (Just noticed - that address looks like H503 only, and for the H563

Hi,I have a question about choosing some fairly basic security settings for an STM32H5.We are developing a system that uses both G4 and H5 micros. We have developed a largely common bootloader that receives a signed encrypted application over variously USB, UART, or CAN, and flashes it to internal memory. This is working on the G4 and H5.For the G4, we understand that if we select "Level 1" read protection, the bootloader will still be able to erase and re-flash a new application but a user will not be able to gain access to the code (bootloader, application, or data in CC RAM). Further, the G4 can be reverted to Level 0 if required, but this will erase the proprietary code.Ideally, we would like the same security behaviour on the H5. I have been reading about the bewildering selection of security settings with privileged and secure settings for individual peripherals but I feel this is more complicated than we require. Our bootloader already prevents someone installing malicious code

Typical bootloaders (including some of ST's built-in bootloaders for other processors) typically allow a code image to be loaded into the processor via some kind of serial link (UART, SPI, CAN, etc), without needing an ST-Link or other debug hardware. These make bootloaders ideal for in-field upgrades of products.OEMiROT/OEMuROT has some features of a bootloader, in that a new image can be placed in a special area of flash and (if it passes all the various checks) then be executed.However, there is no way of actually putting that image in flash without an ST-Link or similar, since this is needed to unlock the chip via the DA process. So if you want to do an in-field upgrade of your product's firmware without any debug hardware, OEMiROT in its current form isn't the solution.Our approach is for our application to download the image into a reserved area of RAM and then switch to the bootloader, where our adapted version of OEMiROT copies this image from RAM to the special area of flash.

Hello Team,We have faced the Firmware ( hex file ) theft by Reverse engineering , Our competitor 2 Times. Yes, Two times , while RDP1 is set. We do not have contarct Manufacture in our whole process.Even Reading / Comparing intertlock of 96 bit UID failed.MCU is STM32F303.Can any one suggest a very high Strong Method which ensue complete guarantee for Firmware Protection from any threats. ?It seems STM32 is so famous that , its weak-leak point also Known.Getting Assembly / might be "C" code from Hex file looks Staright forward to crackers.

Hi, I'm building a medical device that will use an STM32 MCU and requires secure boot and secure firmware updates (over USB-C preferably). I have little experience with implementing secure bootloaders, and am looking for a solution that could allow me to get secure boot working out-of-the-box with minimal setup. I've seen that SBSFU offers example projects for secure boot on some MCUs, while MCUboot is also available for some others. It also looks like the STM32U5 series supports their own secure firmware updates based on AN4992. What's the difference between all of these solutions? Out of all the solutions ST offers for secure boot, which ones are the newest/recommended and easiest to get set up with? Because I'm looking for a low-cost MCU, I've identified the STM32L471, STM32L476, and STM32U575 as potential candidates that could support secure boot, but I'm lost as to how to actually set it up or what software solution to use. I'd love to hear anyone else's suggestions for other MCUs

In STM32Cube_FW_H7RS_V1.3.0, file Projects/STM32H7S78-DK/Applications/ROT/OEMiROT_Boot/Inc/flash_layout.h:The macro OEMIROT_LOAD_AND_RUN has 3 possible settings, and we're using the NO_LOAD_AND_RUN to execute code (in external flash) in place.However, we're also using external RAM in our application, and this must be enabled in the bootloader, as the app attempts to initialise values in external RAM at startup.Unfortunately, the external RAM is only initialised if you select LOAD_AND_RUN_EXT_RAM.There is a workaround: in boot_hal.c and low_level_ext_ram.c, replace every instance (3 in each file) of:#if (OEMIROT_LOAD_AND_RUN == LOAD_AND_RUN_EXT_RAM)...with something like:#if 1// (OEMIROT_LOAD_AND_RUN == LOAD_AND_RUN_EXT_RAM)For the future, would you consider having an option to run in place and enable external RAM?Thank you.  

We are seeing a very odd data corruption issue which is highly repeatable, and appears to be related to a configuration setting which we haven't yet identified.In our system (running on an STM32H7S7), we're using the STiROT + OEMuROT secure bootloader to load our application. After a minute or two, the application causes a hard fault.The issue comes down to a POP instruction. I can see in the debugger that a value is being copied from the stack to a register, but one of the bits is flipped. Subsequent instructions do some indirection which ultimately causes the hard fault.It's always the same instruction in the same line of code. It always occurs within the first minute or two of execution.Using the debugger, we can see that the value in the stack (stored in DTCM) is correct. The error occurs when it's copied to the register. And although the error always occurs at the same address, it doesn't appear to be a fault with that location, as when I moved the stack to elsewhere in DTCM,

Firmware Package: STM32Cube_FW_H5_V1.6.0 Product ProblemDA regression fails with timeout. I cannot recover the board. I was trying to run the STiROT Template example (STiROT_Appli) on the STM32H573I-DK board. 1. I ran a custom provisioning script (based on ob_flash_programming.sh + obkey_provisioning.sh)2. During image flashing step, I accidentally flashed an unsigned binary (appli.bin) instead of the signed image (appli_init_sign.hex)3. OBKey provisioning (DA_Config.obk, STiRoT_Config.obk, STiRoT_Data.obk) may have failed due to the MCU being in an unstable state4. I then set Product State to PROVISIONED (0x2E) Discovery output Discovery succeeds and shows- PSA lifecycle: ST_LIFECYCLE_IROT_PROVISIONED - ST provisioning integrity status: 0xf5f5f5f5 - ST HDPL1 status: 0x1 - Permission: Full Regression is listed as available Regression attempt Using default keys from the firmware package (not regenerated): - Key: DA/Keys/key_3_leaf.pem - Certificate: DA/Certifica

Hi everyone,I am trying to generate a professional SBOM for my project.I have a few questions regarding the best workflow:Tooling & Detection: What the best tool to generate the SBOM.I tried using ScanCode, but it didn't find any component in my project (e.g., FreeRTOS). I had to manually add .about files to the folder to get results. Is there a better tool that can generate the SBOM with minimal manual intervention?ST Cube SBOM : The Cube MCU packages contain dozens of libraries (FatFS, FreeRTOS, USB_Host, etc.). If my project only uses FatFS, the package JSON still lists everything. Do I have to manually extract the components I use from the ST JSON? how to get use of the ST SBOM?I’d love to hear if anyone has a script or a specific toolchain that automates this without the manual "copy-paste" from the ST manifests Thank you!Yahya  

Following the ST sample : STM32CubeH5\Projects\NUCLEO-H563ZII regenerated OEMiRoT_Config.obk with the STM32TrustedPackageCreator.then, rebuild the OEMiRot application and the applications OEMiROT_Appli_TrustZone_Secure & OEMiROT_Appli_TrustZone_NonSecureI ran the script : \ROT_Provisioning\OEMiROT\provisioning.batusing the 'PROVISIONED' choice.The script returns No error. But When I check the PRODUCT_STATE with STM32CubeProgrammer, the state came back to OPEN instead of PROVISIONED.But, I had to use the DA to connect to the device with the STM32CubeProgrammer. So, OBK files seems to be applied.I has already checked that the PROVISIONING state has been correct before the OBK provisioning sequence.So it's the action "set state PROVISIONED" that fails (or maybe an issue with the OBK files ???,  but no way to check if they are OK).Someone has already meet this issue ? How to fix it ?  

In OEMiROT_Boot/Src/low_level_ext_flash.c, function Ext_Flash_EraseSector(),  a call is made to EXTMEM_MemoryMappedMode() immediately before the sector erase takes place, to temporarily disable memory-mapped mode for the external flash, with the function called again afterwards to re-enable it.As @ken5 reported previously, we found that these flash erases can cause corruption in the external RAM.After a lot of experimentation and head-scratching, we've found that if the external RAM is also removed from the memory map before a flash erase, and re-enabled afterwards, these corruption issues appears to go away (pending further testing).I'm guessing that this wasn't spotted in ST's testing because OEMiROT doesn't use the external RAM until later (if at all), so any corruption doesn't matter. However, our adapted OEMiROT does use the external RAM, and the data corruption was a serious problem.(Incidentally, we saw occasional corruption in the external fla

Hi ST team,I am using X-CUBE-SBSFU V2.8.0, project: Device: STM32H753Base example: NUCLEO-H753ZI 2_ImagesI ported UART pins/port for my H753 EVAL board.ProblemBuild fails in SECoreBin with GNU14.3 toolchain:C:/.../2_Images_SECoreBin/Src/se_crypto_bootloader.c:222:(.text.SE_CRYPTO_Decrypt_Init+0x16): dangerous relocation: unsupported relocation However , Then i shifted to 13.3 tool chain , then everything works fine for me.  Please confirm whether this is a known GCC 14.3 compatibility issue for SBSFU v2.8.0 key generation. If yes, could you share an official patch for prebuild.sh / key assembly generation so generated key symbols are fully compatible with newer GNU/binutils?

Hi everyone,We’ve been using the XCUBE-SBSFU bootloader in our industrial-grade project and recently noticed that SBSFU is now labeled as a legacy bootloader. It seems the new recommended bootloader is based on MCUBoot. Additionally, I’ve come across information on STiRoT, which implements a root of trust similar to what SBSFU legacy already offers.This has left us with a few questions, and we’d greatly appreciate any clarification:Why has SBSFU been marked as legacy and replaced? Were there specific limitations or issues with SBSFU that led to this change?How do we transition to MCUBoot? The MCUBoot website mentions it doesn’t currently support STM32 controllers, and the ST wiki says support is “coming soon.”What role does STiRoT play? It seems similar to SBSFU legacy but is relatively new. Is it a better option? Should we consider switching to it, and if so, why?Any insights or guidance would be greatly appreciated.Thanks.@Jocelyn RICARD I’ve noticed your valuable input on SBSFU

Hi Everyone,I'm following the: How to enable RDP-like product state flash protection in STM32H5 microcontrollersexample using an STM32H573xx devkit and an ST‑Link. I ended up bricking my devkit while attempting the regression step. My ST provisioning integrity status:0xf5f5f5f5I have another dev kit available for testing, but I haven't been able to find an H573xx example that uses the HAL code base. If anyone can point me to a HAL-based example for the STM32H573 series implementing JTAG protection. Many Thanks! 

Hi everyone,I am working on a custom board based on the STM32U575RGT6 (TrustZone enabled, FreeRTOS). I have successfully ported the SBSFU example originally provided for the B-U585I-IOT02A.My configuration is:MCUBOOT_APP_IMAGE_NUMBER = 1 (Single combined S and NS image)No external loader.To meet my application needs, I added a custom FLASH_STORAGE area at the end of the flash for EEPROM emulation. To do this cleanly, I modified flash_layout.h to dynamically compute the available FLASH_NS_PARTITION_SIZE based on the remaining space.The Problem: When I use MCUBOOT_OVERWRITE_ONLY, the OTA update (via Y-Modem) works perfectly. However, when I try to use the Swap mode (by commenting out #define MCUBOOT_OVERWRITE_ONLY), the firmware download succeeds, the board reboots, the bootloader validates the signature, starts the swap process, but then crashes with a status write fail:FWUPDATE --- Démarrage de la mi

Hi ST team,I am trying to develop a secure bootloader and firmware update solution for STM32H735 MCU. I was looking at ST's implementations, SBSFU legacy and SBSFU by MCUboot. Could you give me some guidance, which would be the better choice to start from and port to my chip? I saw that SBSFU by MCUboot is targeted only to STM32H7S, and not STM32H7, so I assume if I want to go with MCUBoot, most of the code built on top of MCUBoot by ST is not going to be usable for me, is that correct?I need these features for the bootloader:immutable bootloader implementationapplication authentication (using signature verification)secure application updateanti-rollback protectionA/B update scheme to provide a fallback optionPreferably support for TCP communication for image download (or allowing easy integration for it)Thank you for your help.

Hello, I'm looking for some advice on how to progress, beginning from a fairly novice position, with a secure bootloader.  I'm beginning a project where at least a secure update process (where the existing application does the update) is desired.  Ideally I'd have an encrypted and signed application updates being delivered to my target application and put that away in flash, then reset the MCU and have a bootloader validate / process the update. I've found Zephyr and had a small play with the MCUBoot -- its seem pretty cool,  though I also found that some combinations of options created interesting build failures that were confusing.  I've just stumbled across the SBSFU project - which appears to utilise some of MCUBoot, but I'm having a slow time making sense of it, with its half a dozens projects and plethora of source files.  If there is not a STM project that can be configured and directly used on the U575 -- I'm hoping there is at least an overview / walk

I see only one other answer to this question, here: Solved: TrustZone Enable afterwards - STMicroelectronics CommunityHowever, others are not answered. Can you confirm that there is a solid reason why the TrustZone cannot be enabled after the project has been created? Does it scramble to ioc file? Was this an issue with previous versions of CubeMX and perhaps no longer an issue? Core: M33

Our own non-secure application is based on "SMAK_Appli" in the STM32TRUSTEE-SM example and in principle, it works, but debugging is giving me issues. This is with STM32CubeIDE latest version and all tools software and firmware updated to their latest versions, too.Issue 1: Using STLINK-V3 to start debugging, whenever there has been a code change, the first attempt results in a verification error (see log below) and the second attempt then works. This is 100% consistent and terribly annoying since starting the non-secure debugging session is very slow to begin with.Issue 2: Using J-Link to start debugging, it claims flash was programmed (very fast) and debugging seems to work at first, but I found that flash programming was not effective. The flash content is always what it was programmed with using STLINK. So if I want to use J-Link, I have to program with STLINK (twice), then switch to J-Link but I cannot successfully program changed flash content with J-Link.Are these issues know and

Hi ST team,I’m using X-CUBE-SBSFU v2.8.0 on STM32H753 (2_Images configuration), and I need guidance to move firmware transfer from UART YMODEM to USB protocol.Current setupPlatform: NUCLEO-H753ZI (also testing H753 EVAL migration)Project: 2_Images (SECoreBin + SBSFU + UserApp)Toolchain: STM32CubeIDECurrent transfer path works: YMODEM over UARTGoal: Transfer .sfb image over USB (preferably CDC), store in download slot, request install, reset, then let SBSFU verify/swap/launch ObservationLocal loader is UART-based (SFU_LL_UART_* in sfu_com_loader.c)USB PCD appears not enabled by default in stm32h7xx_hal_conf.hIn UserApp, install-at-next-reset flow is already working in fw_update_app.cSo i need some clarification What is ST-recommended architecture for USB transfer with SBSFU?USB in UserApp (receive file, write to DWL slot, call install-at-next-reset), orUSB directly in SBSFU local loader, orStandalone loader approach?Do you have any official reference/example for

Suppose I want to implement firmware for STM32U3 without TZ enabled and without the use of GTZC, then I could mostly use the MPU_NS and the TZ-Aware peripheral protection (EXTI, FLASH, RCC, PWR, GPDMA, SYSCFG, RTC & TAMP).   My goal is to limit unprivileged code execution to main FLASH, no SRAM, no OCTOSPI NOR/PSRAM.   The problem is now the ICACHE. Is there a way to force it to be privileged only ?   If not, assuming that I am allowing only unprivileged execution access via MPU_NS to the main FLASH (0x08000000 - (0x08000000 + size of flash)), could the remapping feature of the ICACHE be used to map say SRAM into this region and somehow unprivileged execution access this way ?   The docs are unclear there. The remap mechanism is described as a generic mechanism, not limited to any subset of the 0x00000000 - 0x1fffffff address space. Which means that in theory one could replace the mapping at 0x08000000 to say the SRAM1 base address.   - Thomas  

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 read UM3451 (STM32N6xx security guidance for SESIP level 3 certification) chapter 3.2.2 Secure installation and I wonder why aren't the FSBL signature public keys not written into OTP fuses? Only the 8 words (32 bytes) of hashes of all 8 public keys are written by the instructions.Chapter 2.1. Secure boot here in wiki explains that one of 8 active public key hashes in FSBL binary header is compared to the one in OTP and if they match, then "that" public key is trusted. But it doesn't explicitly say where does "that" public key come from.From UM3234 concept drawings (Figure 12-13.) I begin to understand that public key (in some changed form) is provided with the FSBL authentication extension header. So does it mean the MCU does not know the public key and it trusts the provided public key based on the hash table match only?Am I missing something here, but it appears to me that uniqueness of public keys have been heavily reduced. Since each public key hash is individuall

We've been using STiROT + OEMuROT for STM32H7S on our system, with our own application.The secure bootloader handles most of its functionality very well, and the security aspects in particular. The scripts provided by ST were very helpful, as was the documentation on the ST wiki. We are grateful to ST for providing these.However, it proved extremely challenging to get the secure bootloader working with our application, mainly because the secure bootloader makes a number of important assumptions about the user application which are not documented.These unstated assumptions initially prevented our application from running, and it took a considerable amount of time and effort to solve all the problems associated with them.AssumptionsThe main assumptions are:OEMuROT assumes that the application will use the same clock setup as itself (especially PLL1 and PLL2): as documented in a separate post, we needed to change the clock settings in our application compared to OEMuROT, and thi