Skip to main content
A
Abhithlal
Visitor II
February 5, 2025
Solved

Security Concerns When Flashing STM32MP1 Custom Board via USB

  • February 5, 2025
  • 2 replies
  • 1235 views

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:

  1. What security measures can be implemented to prevent unauthorized access or flashing through USB?
  2. Is it possible to enforce authentication during the USB boot and firmware flashing process?
  3. 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!

    This topic has been closed for replies.
    Best answer by Abhithlal

    Hi Patrick,

    Thank you for the detailed response and guidance on improving security for firmware flashing on STM32MP1. Your explanation about the root of trust, secure boot stages, and OTP-based authentication is very helpful. 

    I will look into signing TF-A BL2 and using SSP to provision authentication keys during production.

     

    Thanks again for your time and support.

    Best regards,

    Abhithlal C

    2 replies

    P
    PatrickD
    ST Employee
    February 7, 2025

    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

     

     

    A
    AbhithlalAuthorAnswer
    Visitor II
    February 11, 2025

    Hi Patrick,

    Thank you for the detailed response and guidance on improving security for firmware flashing on STM32MP1. Your explanation about the root of trust, secure boot stages, and OTP-based authentication is very helpful. 

    I will look into signing TF-A BL2 and using SSP to provision authentication keys during production.

     

    Thanks again for your time and support.

    Best regards,

    Abhithlal C

    Terms & ConditionsAccessibility statement