SBSFU - Build Structure

[Vinay_Shirol]

Hi everyone,

I’m currently working with STM32 Secure Boot and Secure Firmware Update (SBSFU) and integrating it with my custom application. I’m trying to design the project in a modular and scalable way for long-term use, and I would really appreciate some guidance from those who have worked with SBSFU in production.

 Current Scenario

• MCU: STM32 (Cortex-M series)
• Bootloader: SBSFU
• Application: Custom firmware using HAL, middleware, and CubeMX-generated code
• Development tool: STM32CubeIDE

 Challenges I’m Facing

1. Shared Drivers & Middleware

Both my bootloader and application require:

• HAL Drivers
• Some middleware components

 What is the best way to manage duplication vs sharing?

• Should bootloader and application maintain completely separate copies of Drivers/Middleware?
• Is there any recommended way to keep them in sync without tight coupling?

 2. Impact of .ioc Changes

I use CubeMX via .ioc for peripheral configuration.

If I:

• Add a new peripheral
• Modify clock or pin configuration

How should this be handled without breaking SBSFU?

• Should bootloader and application always have separate .ioc files?
• Any best practices to avoid regeneration issues affecting secure boot?

3. Folder Structure for Maintainability

What is a recommended folder structure for:

• SBSFU Bootloader
• User Application
• Shared interfaces (if any)

Goal:

• Easy reuse across projects
• Clean separation of responsibilities
• Minimal integration issues

4. Crypto / Encryption Flexibility

I may want to experiment with different encryption schemes in the future.

What is the best way to:

• Abstract crypto implementation in SBSFU?
• Replace or extend existing encryption (e.g., AES-GCM)?

Are there any extension points/hooks provided in SBSFU for this?

5. Project Integration in CubeIDE

What is the recommended workflow to:

• Import SBSFU and Application projects into CubeIDE
• Manage them as separate or linked projects
• Build and flash step-by-step (bootloader + application + secure image)

6. References / Best Practices

Could you please suggest:

• Application notes
• Reference projects
• Real-world examples

especially for:

• Clean SBSFU + Application separation
• Maintainable architecture
• Production-ready setups

 Goal

To build a robust, reusable, and scalable secure firmware update architecture using SBSFU that can support:

• Future feature additions
• Crypto changes
• Multiple applications

---

Any insights, architecture suggestions, or real-world experiences would be extremely helpful.

Thanks in advance!

[Pavel A.]

Which STM32 MCU do you use? Different STM32's have different security mechanisms for SBSFU. If not decided yet, can you tell more about the requirements, this will help to choose the MCU.

> Should bootloader and application maintain completely separate copies of Drivers/Middleware?

Most likely yes. Because, with "hiding protection", when the app starts, the bootloader code "disappears" and cannot be called from the app. So you don't have to arrange for sharing any runtime code. The projects can be separate. Sharing the drivers & middlewares source code, of course, is possible.

> Should bootloader and application always have separate .ioc files?

Of course, hardware & clock settings of the bootloader and the app should be "harmonized" so that the app won't have to undo what the bootloader did. Basically, the bootloader sets up the environment for the app: if the app runs in external memory, it must be initialized with all dependencies (power, clocks) and the app obviously should not touch these settings in their startup code.

Outside of that, the app is free to enable and set up additional pins, peripherals etc. So if you later change the .ioc to add stuff for the app, you won't have to regenerate the code for bootloader. The same with multiple apps: different apps may need different changes in the .ioc, but as long as these changes do not affect the bootloader - no problem.

For experimenting with crypto methods you can use software simulators or Linux on ARM machines such as Raspberry Pi etc.

Good luck.

[Onizuka09]

Hello @Vinay_Shirol,

Sorry for the late response.

ST provides many SBSFU solutions, you can consult:
- Also this is ST SBSFU solutions and the supported boards : link  
- The wiki to understand which solution is better for you link

From your previous questions, it seems that you are focused on SBSFU for STM32H7.

ST provides for that board X-CUBE-SBSFU a secure boot and secure firmware update solution.

This solution is highly opinionated, meaning it comes with a very predefined structure. It is not a middleware that you can simply drop into any project. ST provides examples that you can adapt and port to your own hardware and software requirements.

In each example, you will typically find 3 folders:

• SBSFU: runs the secure bootloader
• SECoreBin: contains the secure services
• UserApp: contains the user application

To answer your questions:

---

1. Shared Drivers & Middleware

The bootloader and the application typically use the same HAL driver APIs, since both are developed for the same board. 

For middleware, SBSFU comes with the necessary components: mbedTLS for cryptography, KMS (Key Management Services), the Secure Engine (which provides a secure environment), and STSAFE middleware (which provides APIs to access STSAFE-A110 devices).

You only add the middleware required for your specific needs.

---

2. Impact of .ioc Changes

You normally do not configure the SBSFU project through CubeMX.

• For the bootloader, hardware configuration is handled through the HAL / BSP layers, not via CubeMX-generated .ioc files.
• To modify hardware-related behavior in SBSFU, you usually work in the Target folder:
  • SBSFU/Target
• For the user application, you can develop it independently in CubeMX, test it, and then port it into SBSFU.

You can refer to AN5056, section 8, for user application porting guidance.

---

3. Folder Structure for Maintainability

A common structure is:

• SBSFU → bootloader / secure update logic
• SECoreBin → secure engine / secure services
• UserApp → main application
• Optional shared code can be isolated carefully, but keep the dependencies minimal

The key goal is to maintain a clean separation of responsibilities.

---

4. Crypto / Encryption Flexibility

SBSFU supports predefined crypto schemes controlled by the compiler flag:

SECBOOT_CRYPTO_SCHEME

Examples include:

• SECBOOT_ECCDSA_WITH_AES128_CBC_SHA256 (default)
• SECBOOT_ECCDSA_WITHOUT_ENCRYPT_SHA256
• SECBOOT_AES128_GCM_AES128_GCM_AES128_GCM

These define:

• whether firmware is encrypted
• which hash is used for integrity verification
• which asymmetric cryptography method is used for signatures

If you want to implement a new cryptographic scheme, refer to AN5065, section 7.1, which explains how to implement a new crypto scheme for SBSFU.

---

5. Project Integration in CubeIDE

For integration with CubeIDE:

1. Import the 3 projects

2. Make sure the required Python packages are installed:

   Middlewares/ST/STM32_Secure_Engine/Utilities/KeysAndImages/requirements.txt

3. Build in the correct order:

   • SECoreBin
   • SBSFU
   • UserApp

For flashing:

• start with SBSFU.elf
• then upload the application using the bootloader’s download capability

---

6. References :

• AN5056  How to integrate the X-CUBE-SBSFU STM32Cube Expansion Package
• UM2262 Getting started with the X-CUBE-SBSFU STM32Cube Expansion Package