Getting Started with Cryptographic Operations on the STM32 B-U585I-IOT02A Using SBSFU

Introduction

In connected products, security is no longer optional. Firmware updates, device identity, and data confidentiality all rely on robust cryptography implemented correctly on the target MCU.

In this first part of my STM32 B-U585I-IOT02A security series, I focus on the cryptographic operations available when using the Secure Boot and Secure Firmware Update (SBSFU) solution on the STM32U5. This article follows the structure of my YouTube video and serves as a written reference with extra details and links.

We’ll look at:

• The B-U585I-IOT02A board and SBSFU ecosystem

• AES hardware acceleration

• Hashing with SHA

• Public Key Infrastructure (PKI) concepts used by SBSFU

• How these crypto blocks support secure boot and firmware update

Later videos and articles will go deeper into TrustZone, secure/non-secure boundaries, secure key storage, and attestation.

1. Platform Overview: STM32 B-U585I-IOT02A + SBSFU

The B-U585I-IOT02A Discovery kit is built around the STM32U585 microcontroller, a low-power MCU featuring:

• Arm Cortex-M33 core with TrustZone-M

• Hardware cryptography accelerators (AES, PKA, HASH)

• True random number generator (TRNG)

• On-chip secure memory and multiple protection mechanisms

On top of this hardware, ST provides the SBSFU (Secure Boot and Secure Firmware Update) reference implementation. SBSFU typically offers:

• A secure bootloader validating firmware authenticity and integrity

• Encrypted firmware update support

• Root of trust using asymmetric cryptography

• Integration with TrustZone on STM32U5

In short, SBSFU shows how to use the crypto hardware in a real end-to-end system.

2. Cryptographic Operations in SBSFU

From a functional point of view, we can group the cryptographic operations into three main categories:

1. AES – Symmetric encryption for firmware images and sensitive data

2. SHA – Hashing for integrity checks and signatures

3. PKI – Asymmetric cryptography for validation of firmware and device identity

In this article I won’t walk line-by-line through SBSFU sources, but I’ll describe how these mechanisms fit together and what you should look for in the project.

3. AES on STM32U5 / B-U585I-IOT02A

3.1 Role of AES in SBSFU

AES (Advanced Encryption Standard) is a symmetric block cipher used to:

• Encrypt firmware images during distribution so only authorized devices can decrypt them.

• Protect confidentiality of sensitive data (e.g., credentials, configuration) stored or transmitted.

SBSFU typically uses AES in modes such as CBC or GCM for firmware encryption. The exact mode depends on the configuration and example package used.

3.2 Hardware AES Accelerator

The STM32U5 includes a hardware AES accelerator, which offers:

• Much higher throughput than software AES

• Lower power consumption

• Resistance against certain implementation attacks due to constant-time hardware operations

SBSFU uses HAL or low-level (LL) drivers to access this accelerator. In the project you’ll see functions like:

or the corresponding LL versions, depending on configuration.

3.3 Typical AES Encryption Flow

The high-level steps in SBSFU for AES encryption/decryption are:

1. Key provisioning: a symmetric AES key is either compiled in for demo purposes or provisioned securely into the device (in production you’d use secure provisioning tools and secure storage).

2. Initialization: configure the AES peripheral with key, IV (for CBC/CTR/GCM), mode, and data sizes.

3. Processing: feed plaintext firmware blocks and retrieve ciphertext, or vice versa for decryption.

4. Verification: if using AEAD modes (e.g., GCM), verify authentication tags to catch tampering.

You can demonstrate this in the video with a small example function that encrypts a buffer and prints the ciphertext over UART, emphasizing that in real SBSFU the same primitive secures entire images.

4. SHA Hashing on STM32U5

4.1 Why Hashing Matters

SHA (Secure Hash Algorithm) is used for:

• Integrity checking of firmware and critical data

• As input to digital signatures

• Deriving keys in key derivation functions (KDFs)

SBSFU typically computes a hash over the firmware image and then verifies a signature on that hash.

4.2 Hardware HASH Accelerator

The STM32U5 integrates a HASH accelerator supporting algorithms like SHA-256. Benefits:

• Offloads the CPU, especially for large images

• Provides consistent timing and optimized performance

HAL/LL provide APIs such as:

In SBSFU you’ll often find wrapper functions in the security or crypto middleware that abstract the exact hash implementation.

4.3 Firmware Integrity Verification Flow

A typical SBSFU check during boot:

1. Compute SHA-256 over the entire firmware image.

2. Retrieve the expected hash (or expected signature) from metadata stored alongside the image.

3. Compare them or verify the signature (see PKI section below).

4. If verification fails, abort boot, signal an error, or roll back to a known-good image.

5. PKI and Asymmetric Cryptography in SBSFU

5.1 Why PKI?

Public Key Infrastructure (PKI) is at the heart of secure boot:

• Ensures that only firmware signed by the owner of the private key can run on the device.

• Enables scalable distribution: the device only needs the public key; the private key stays offline with the firmware publisher.

• Facilitate identity and attestation for future features.

In SBSFU, the bootloader stores a public key (or a certificate containing it). Firmware images are signed offline using the corresponding private key, typically with ECDSA or RSA.

5.2 Signature Flow in Secure Boot

A simplified secure boot process with PKI looks like this:

1. Device boot → execution starts in SBSFU bootloader.

2. Bootloader reads the firmware image and associates metadata (hash, signature, version).

3. Bootloader computes SHA-256 hash of firmware.

4. Bootloader applies signature verification using the public key stored in its secure area:

• If VerifySignature(public_key, hash, signature) is successful → firmware is authenticated.

• Otherwise → boot fails or falls back to another slot.

5. After successful verification, control jumps to the user application (or non-secure application when TrustZone is used).

5.3 STM32U5 PKA Hardware Support

The STM32U5 includes a Public Key Accelerator (PKA) that speeds up operations like:

• Elliptic curve scalar multiplication (for ECDSA/ECDH)

• Modular exponentiation (for RSA, depending on configuration)

SBSFU uses this accelerator through the HAL or middleware so that signature verification is fast enough even with large firmware images and low-power constraints.

From a code perspective, you’ll see calls to crypto middleware (for example based on mbedTLS integrated with STM32 hardware acceleration). The exact APIs vary by SBSFU version, but conceptually it’s:

with low-level calls offloaded to the PKA peripheral.

6. How AES, SHA, and PKI Work Together in SBSFU

To summarize the relationships:

• AES: protects confidentiality of the firmware and sensitive data (encrypted images).

• SHA: provides integrity through hashes of the firmware and other critical assets.

• PKI (ECDSA/RSA): provides authenticity and a root of trust, ensuring that only firmware from trusted sources is executed.

A secure firmware update scenario might look like this:

1. Developer builds firmware and signs it (PKI).

2. Optional: firmware is also encrypted with AES for confidentiality at rest/in transit.

3. Device downloads the new image and stores it in a secondary slot.

4. SBSFU bootloader at next reboot:

• Decrypts (if needed) using AES.

• Computes SHA-256 of image.

• Verifies signature via PKI + SHA-256.

• If all checks succeed, swaps to the new image and boots it.

7. Practical Pointers: Where to Look in the SBSFU Project

When you open the STM32CubeU5 SBSFU project for B-U585I-IOT02A, some typical areas to explore are:

• Projects/B-U585I-IOT02A/Applications/STM32_SBSFU/

• Bootloader application (folder often named SBSFU_Boot or similar)

• Crypto middleware folder (may be 2_Images_SECoreBin, SBSFU/Drivers/BSP, or Middlewares/ST/STM32_Crypt depending on version)

• Configuration files where keys, algorithms, and memory layouts are defined

8. Teaser for Next Blog: Security Features Beyond Crypto

Cryptographic operations are the core feeding into a broader set of security features:

• TrustZone implementation and secure/non-secure boundaries

• Secure key storage: protecting AES / private keys in secure flash, OTP, or hardware key storage

• Attestation: proving to a remote server that firmware and device are genuine

These topics will be covered in the next videos and articles. 

9. Conclusion

In this introductory article we focused on understanding how cryptography is used on the STM32 B-U585I-IOT02A with SBSFU:

• AES hardware acceleration for encryption

• SHA hardware hashing for integrity

• PKI for secure boot and firmware authentication

Armed with this conceptual model, you can now explore the SBSFU project, follow the code pathways, and start modifying them for your own secure IoT product.

In the next article and video, we’ll take this further and look at TrustZone, secure/non-secure separation, and how keys and secrets are stored and protected on STM32U5.