Security Concerns When Flashing STM32MP1 Custom Board via USB

Abhithlal · ‎2025-02-04

Hello,

I am currently working on a custom board based on the STM32MP1. In my research, I found that flashing firmware over JTAG is not supported for the STM32MP1 series. Instead, we need to rely on USB or UART for flashing purposes.

I came across this related issue on the forum: Flashing STM32MP1 Custom Board Over JTAG.

Given this, I am concerned about the security implications of using USB for flashing firmware. Specifically:

What security measures can be implemented to prevent unauthorized access or flashing through USB?
Is it possible to enforce authentication during the USB boot and firmware flashing process?
Are there recommended techniques to encrypt the firmware or restrict access to certain boot modes?

And if I use the UART for flashing, then how can I do that? Which combination of boot mode selection switch should I use? Is there any specific documentation for flashing firmware using UART?

I would greatly appreciate any guidance or best practices to enhance security when using USB as the flashing method.

Thank you in advance!

PatrickD · ‎2025-02-07

Hi,

I will try to give some guidance for your request,
but only for software point of view.

I don't know how to restrict boot mode by hardware:

1. the security for first boot stage (authentication by ROM code) can be activated on your device

=> the authenticate of the binary loaded is done by ROM code for device boot (NOR/NAND/eMMC,...)
but also for serial boot (UART / USB).

https://wiki.st.com/stm32mpu/wiki/STM32_MPU_ROM_code_secure_boot

The serial boot is refused except if FSBL = TF-A BL2 is signed with correct key (present in device OTP)

You need to

- sign the TF-A BL2 used for serial boot and also the TF-A BL2 used for device boot (programmed in board memory)

- write authentication KEY in OTP, for example with SSP during production (https://wiki.st.com/stm32mpu/wiki/Secure_Secret_Provisioning_(SSP)_overview)

2. After this ROOT of trust (for FSBL load), you can improve security for FIP = the secondary binary (SSBL) by using the TF-A verification feature = https://wiki.st.com/stm32mpu/wiki/TF-A_BL2_Trusted_Board_Boot

=> the certificates are used to validate the binaries included in the FIP and used for serial programming

3. For encryption (STM32MP13 only), it is based on KEY programmed in OTP

- Rom Code = https://wiki.st.com/stm32mpu/wiki/STM32_MPU_ROM_code_secure_boot

- FIP content = https://wiki.st.com/stm32mpu/wiki/TF-A_BL2_Trusted_Board_Boot#STM32_firmware_encryption

With Root of trust + TF-A trusted boot encryption (forSTM32MP13), the serial boot (USB/UART) can be accessible only for user of authenticated bootloaders file which need to be private/protected.

For the UART programmer use case,

for serial boot, the ROM code check if USB VBUS if is not detected, and try to connect to several UART (with specific PIN configuration)

https://wiki.st.com/stm32mpu/wiki/STM32_MPU_ROM_code_overview#UART_Boot

Serial Boot mode (UART/USB) is based on bootpins

https://wiki.st.com/stm32mpu/wiki/STM32_MPU_ROM_code_overview#Boot_device_selection_on_STM32MP1_series

BOOT pins = b000 (Force Serial)

PS: Serial boot is alaso a falback for other boot mode when it is failing (Boot source #2 if #1 fails).

Then you can use STM32cubeProgrammer over UART:

https://wiki.st.com/stm32mpu/wiki/STM32CubeProgrammer

https://wiki.st.com/stm32mpu/wiki/How_to_use_UART_as_serial_boot_device_with_STM32CubeProgrammer

See AN5275: Introduction to USB DFU/USART protocols used in STM32MP1 and STM32MP2 MPU bootloaders for protocol details (https://wiki.st.com/stm32mpu/wiki/STM32_MPU_resources#AN5275).

NB: UART is really slow, it is OK to program small binary (boot loaders by example),

but perhaps not useful for large Linux file system.

Regards

Patrick