Introduction to Secure Firmware Install (SFI) for STM32 MCUs

Table 1. Applicable products

1. These are the only supported order codes, only samples Revision B, only with 128 kB of RAM.

Related documents

Refer to the following documents available from www.st.com (unless an NDA applies):

• [AN3155] USART protocol used in the STM32 bootloader
• [AN3154] CAN protocol used in the STM32 bootloader
• [AN3156] USB DFU protocol used in the STM32 bootloader
• [AN4221] I2C protocol used in the STM32 bootloader
• [AN4286] SPI protocol used in the STM32 bootloader
• [AN5054] Secure programming using STM32CubeProgrammer
• [AN5927] I3C protocol used in the STM32 bootloader
• [ES0478] STM32H7A3xI/G, STM32H7B0xB and STM32H7B3xl device errata
• [ES0491] STM32H72xx/73xx device errata
• [RM0399] STM32H745/755 and STM32H747/757 advanced Arm®-based 32-bit MCUs
• [RM0433] STM32H742, STM32H743/753 and STM32H750 Value line advanced Arm®-based 32-bit MCUs
• [RM0438] STM32L552xx and STM32L562xx advanced Arm®-based 32-bit MCUs
• [RM0453] STM32WL5x advanced Arm®-based 32-bit MCUs with sub-GHz radio solution
• [RM0455] STM32H7A3/7B3 advanced Arm®-based 32-bit MCUs
• [RM0456] STM32U5 series Arm®-based 32-bit MCUs
• [RM0468] STM32H723/733, STM32H725/735 advanced Arm®-based 32-bit MCUs
• [RM0477] STM32H7Rx/Sx Arm®-based 32-bit MCUs
• [RM0481] STM32H563/H573 and STM32H562 Arm®-based 32-bit MCUs
• [RM0493] Multiprotocol wireless Bluetooth® Low-Energy and IEEE802.15.4, STM32WBA5xxx Arm®-based 32-bit MCUs
• [UM2237] STM32CubeProgrammer software description
• [UM2238] STM32 Trusted Package Creator tool software description
• [WikiSFI] https://wiki.st.com/stm32mcu/wiki/Security:SFI_overview
• [WikiSTM32H5] https://wiki.st.com/stm32mcu/wiki/STM32StepByStep:SFI_Step-by-step_on_STM32H5

Note: Programming tool manufacturers who want to support SFI/SMI/SSP solutions from STMicroelectronics and integrate them into their production line equipment should contact ST sales office for additional information under NDA.

Note: Arm is a registered trademark of Arm Limited (or its subsidiaries) in the US and/or elsewhere.

Glossary

STM32 secure firmware install (SFI)

SFI principles overview

SFI is a secure mechanism implemented in STM32 microcontrollers that allows secure and counted installation of OEM firmware and STM32TRUSTEE-SM in untrusted production environment (such as OEM contract manufacturer). SFI is implemented in a secure bootloader.

The SFI process prevents the OEM firmware and STM32TRUSTEE-SM code from:

• being accessed by the contract manufacturer.
• being extracted or disclosed.

This mechanism consists in having the following content encrypted with an AES secret key, thanks to STM32 Trusted Package Creator tool(1), during OEM firmware development:

• the whole OEM firmware
• STM32TRUSTEE-SM
• OBK (in case of STM32H5 and STM32H7RS)
• the option bytes.

OEM must use STM32 Trusted Package Creator tool to program HSM with its own AES secret key(2), its own nonce, and a maximum installation counter.

In order to properly protect the firmware confidentiality, the AES secret key must be different every time the OEM encrypts a new firmware or a new release of the same firmware.

OEM contract manufacturer have to use STM32CubeProgrammer to initiate SFI process and send encrypted SFI image (3) to STM32 device.

A hardware security module (HSM) is in charge of:

• Securely storing OEM AES secret key
• Checking STM32 device certificate (4) that is used to authenticate STM32 device (5)
• Generating and providing the license (6) to the secure bootloader to securely install the encrypted firmware on STM32 device.
• Counting number of produced STM32 devices.

The applicable STM32 microcontrollers are provisioned by STMicroelectronics with device dedicated public/private keys (unique key pair per device). The device keys can be accessed only through the embedded secure bootloader that retrieve AES secret key(7) by decrypting license using device private key.

Thanks to STM32 security features and cryptographic algorithm, the STM32 supports the programming in internal flash memory of:

• secure OEM firmware
• STM32TRUSTEE-SM
• OBK (in case of STM32H5 and STM32H7RS)
• and ensures OEM firmware protection (confidentiality, authenticity and integrity) during OEM CM manufacturing stage. The secure firmware install solution securely receives and decrypts the firmware, OBK (in case of STM32H5 and STM32H7RS), and option bytes inside STM32 internal flash memory(8) and optionally external flash memory. Section 2.1.1 focuses on the way SFI process securely installs firmware and data within the internal flash memory, whereas Section 2.1.2 focuses on the way SFI process securely installs firmware and data within the external flash memory.

More information is available in [WikiSFI].

SFI and internal flash memory

This section describes the execution of the SFI process for internal flash memory.

The secure bootloader is a standard ST bootloader with additional security features. If the STM32 microcontroller is reset during retrieving AES secret key (7), all sensitive data are erased before restarting initial SFI procedure. During SFI process, the secure bootloader never allows any other code to access user flash memory or SRAM.

SFI and external flash memory

This section applies to STM32 products with OTFDEC:

• STM32L562xx
• STM32U585xx/STM32U5Axxx/STM32U5Gxxx
• STM32H7B0xx/STM32H7B3xx/STM32H730xx/STM32H733xx/STM32H735xx
• STM32H573xx/STM32H533xx

Note: When speaking of external flash memory, it matters to clearly identify the firmware and data that reside in external flash memory from the firmware and data that reside in user flash memory. Firmware and data in user flash memory are named hereafter internal firmware and data. The firmware and data that reside in external flash memory are referenced as external firmware and external data throughout the next sections.

The internal firmware must enable the read/fetch of data/code within external flash memory, using OTFDEC and OCTOSPI peripherals.

SFI cannot handle internal flash memory in a first sequence and external in a separate independent one: when SFI handles external firmware and data, it must first handle internal firmware and data that in turn enable decryption at runtime of external firmware and data.

External firmware and data on-the-fly decryption is handled by the OTFDEC peripheral. This peripheral can encrypt and decrypt on-the-fly external firmware and data stored in external flash memory connected to STM32 microcontrollers through the OCTOSPI interface. The OTFDEC can handle up to 4 regions of external flash memory, each one with its own dedicated Key. The OTFDEC uses standard AES CTR 128-bit algorithm for encryption and decryption operations. Refer to the OTFDEC section of the STM32 microcontroller reference manual to get more insight.

OEM can ensure the confidentiality of external firmware and data within external flash memory through 3 different use cases that are depicted within next sections.

External flash memory encryption without secure bootloader

The cryptographic engine responsible for the on-the-fly external flash memory decryption (OTFDEC) supports AES standard cryptographic algorithm. Thanks to this standard algorithm, OEM can encrypt external firmware and data on host before programming external flash memory, without using secure bootloader.

If external flash memory programming is done within a non-trusted facility, OEM must encrypt the external firmware and data before sending them to the non-trusted facility.

OEM internal firmware must handle the configuration of the OTFDEC peripheral with the AES key for external flash memory decryption. OEM must implement this part within the secure internal firmware in order to guaranty the confidentiality of the external flash memory AES encryption keys.

OEM internal firmware must also handle external flash memory drivers (through OCTOSPI) in order to get access to the external firmware and data.

Since OEM programs external flash memory on host, OEM must not encrypt external firmware and data thanks to STM32 Trusted Package Creator. However, OEM must send the external firmware and data AES encryption keys within the SFI image. Then, when building the SFI image thanks to STM32 Trusted Package Creator, OEM must create the SFI image with at least:

• Internal firmware and data (include external flash memory drivers).
• External firmware and data AES key.

Figure 2 below shortly depicts SFI of an internal firmware that manages external firmware and data. The sequence part that addresses internal flash memory is the same than the one depicted in section Section 2.1.1: SFI and internal flash memory.

Figure 2 shows that the secure programming of internal flash memory(1) and the encryption plus programming of external firmware and data(2) are done in two separated flows within SFI. The first flow uses secure bootloader, the second one uses host for programming respectively internal flash memory and external flash memory.

External flash memory encryption with secure bootloader and global key

In the next two sections, this document focuses on SFI use cases with encryption of the external firmware and data by the secure bootloader. The STM32 receives encrypted external firmware and data, decrypts them with the SFI OEM key, and re-encrypts them with an external flash memory AES key common to all devices to be programmed or with a unique external flash memory AES key per device. This section focuses on the first scenario: a key common to all devices.

The STM32 secure bootloader uses the OTFDEC peripheral to encrypt external firmware and data, the STM32 secure bootloader stores the encryption result within SRAM. Then an external flash memory loader takes the previous result and program it within the external flash memory.

The external flash memory programming is under the responsibility of OEM, meaning that OEM must use an external flash memory loader that fits its external flash memory specificities. ST does not provide such external flash memory loader, except for demonstration purpose on ST boards supporting external flash memory.

Consequently, OEM must implement in internal flash memory the firmware parts dedicated to external flash memory handling (external flash memory keys and drivers).

OEM must create SFI image with:

• Internal firmware and data (include external flash memory drivers).
• External firmware and data AES key.
• External firmware and data.

OEM must take care to specify, in STM32 TPC, the same address in internal flash memory for external firmware and data AES key than the one its internal firmware uses for external flash memory on-the-fly decryption with OTFDEC peripheral.

The picture below shortly depicts an SFI sequence where STM32 secure bootloader handles both internal firmware installation and external firmware installation with the help of external flash memory loader.

Figure 4 above shows that internal firmware and external firmware and data AES key must be installed first(1), then the previously mentioned key is copied within the OTFDEC peripheral (2) that is used to encrypt the external firmware and data for external flash memory(3). At last, OEM external flash memory loader programs the encrypted external firmware and data into the external flash memory(4).

Figure 5 below depicts the execution of the same internal firmware that, among other tasks, manages external firmware and data decryption.

External flash memory encryption with secure bootloader and unique key

This section focuses on the scenario where the secure bootloader encrypts the external firmware and data with a unique key per device. During SFI, the STM32CubeProgrammer first performs secure programming of the internal flash memory(1) then it requests the STM32 to randomly generate a key dedicated to the external flash memory encryption(2). The STM32 uses the TRNG peripheral to generate this key. After key generation the secure bootloader programs this last key(3) in the internal flash memory.

The STM32 uses the OTFDEC peripheral to encrypt the external firmware and data(4)(5). The STM32 stores the encryption result within SRAM. Then an external flash memory loader takes the previous result to program it within the external flash memory(6).

The external flash memory programming is under the responsibility of OEM, meaning that OEM must use an external flash memory loader that fits its external flash memory specificities. ST does not provide such external flash memory loader, except for demonstration purpose on ST boards supporting external flash memory.

Consequently, OEM must implement in internal flash memory the firmware parts dedicated to external flash memory handling (external flash memory keys and drivers).

OEM must create the SFI image with:

• Internal firmware and data (include external flash memory drivers).
• External firmware and data AES key.
• External firmware and data.

The STM32CubeProgrammer requests the STM32 secure bootloader to randomly generate a unique set of keys during the SFI sequence. Then OEM must take care to specify, within STM32 TPC, the same address in internal flash memory for key generation than the one its internal firmware uses for external flash memory on-the-fly decryption with OTFDEC peripheral.

The picture below shortly depicts an SFI sequence where the STM32 secure bootloader handles both internal firmware installation and external firmware installation with a unique external flash memory AES key and the help of an external flash memory loader.

Figure 7 below depicts the way the internal firmware manages the OTFDEC and external flash memory unique key to decrypt on-the-fly external firmware and data.

SFI security features

The SFI security features are the following:

• Only genuine STMicroelectronics STM32 microcontrollers can install the protected firmware.
• The number of STM32 devices on which the firmware has been installed can be counted.
• Authenticity, integrity and confidentiality of the OEM internal firmware and option bytes are checked and user flash memory is programmed with decrypted firmware, OBK (in case of STM32H5 and STM32H7RS), and option bytes. If applicable, for the confidentiality of the OEM external firmware, the STM32 receives encrypted OEM external firmware, decrypts this firmware, and re-encrypts with a device unique or global key before programming in external flash memory.

STM32 secure bootloader

STM32H75xxx/STM32H7B0xx/STM32H7B3xx/STM32H730xx/STM32H733xx/STM32H735xx

Secure bootloader overview

On the STM32H75xxx/STM32H7B0xx/STM32H7B3xx/STM32H730xx/STM32H733xx/STM32H735xx, the secure bootloader is stored in the internal boot ROM (system memory) and supports following interfaces: USART, SPI, USB-DFU and JTAG.

The STM32H75xxx/ STM32H7B0xx/STM32H7B3xx/ STM32H730xx/STM32H733xx/STM32H735xx secure bootloader permits to run the SFI process several times after complete erase of the internal user flash memory, if erase allowed by installed application.

For more details on STM32 bootloader protocols, refer to [AN3155] (USART protocol), [AN4286] (SPI protocol) and [AN3156] (USB DFU protocol). The documents are available on www.st.com (unless an NDA applies).

1. OTFDEC peripheral is only available on STM32H7B0xx/STM32H7B3xx/STM32H730xx/STM32H733xx/STM32H735xx devices.

User flash memory mapping

On STM32H75xxx/ STM32H7B0xx/STM32H7B3xx/ STM32H730xx/STM32H733xx/STM32H735xx, since the secure bootloader is stored in the system memory, the product is delivered in RDP level0 and all the user flash memory is available for OEM.

The OEM firmware can be built to start at the beginning of the user flash memory (starting address 0x0800 0000).

STM32H7RS

Hereafter, "STM32" refers to STM32H7RS (applicable to whole Section 3.2).

Secure bootloader overview

The STM32 SFI process can only perform secure programming in user flash memory firmware when all necessary data are loaded in SRAM (no interaction between host and STM32 device during SFI process) and product state is set to provisioning at the beginning of the SFI procedure.

On STM32, the secure bootloader is split in two parts. The first part is stored in boot ROM (system memory). It is responsible for loading the second part of the bootloader in SRAM through the supported interfaces. The supported interfaces are USART, SPI, I2C, I3C, FDCAN, USB and JTAG. The second part runs in SRAM and is responsible for executing the SFI process, applying the SFI protocol and parsing all the data previously loaded in SRAM.

The STM32 secure bootloader permits to run the SFI process several times after complete erase of user flash memory, if the erase is allowed by the previously installed application.

For more details on the STM32 bootloader protocols, refer to [AN3155] (USART protocol), [AN4286] (SPI protocol), [AN4221] (I2C), [AN5927] (I3C), [AN3154] (FDCAN) and [AN3156] (USB). The documents are available on www.st.com (unless an NDA applies).

User flash memory mapping

On STM32, the secure bootloader is stored in system memory and SRAM, the product is delivered in Open product state and all the user flash memory is available for OEM.

STM32L5, STM32U5, STM32WBA5 and STM32H5

Hereafter, "STM32" refers to STM32L5, STM32U5, STM32WBA5 and STM32H5 series (applicable to whole Section 3.3).

The STM32 SFI process can only perform secure programming in user flash memory firmware using Arm® TrustZone®, i.e with TZEN bit from FLASH_OPTR register set to 1.

Secure bootloader overview

On STM32, the secure bootloader is split in two parts. The first part is stored in boot ROM (system memory). It is responsible for loading the second part of the bootloader in SRAM through the supported interfaces. The supported interfaces are USART, SPI, I2C, FDCAN, USB and JTAG. The second part runs in SRAM and is responsible for executing the SFI process and applying the SFI protocol thanks to the commands received through the above mentioned supported interfaces.

The STM32 secure bootloader permits to run the SFI process several times after complete erase of user flash memory, if the erase is allowed by the previously installed application.

For more details on the STM32 bootloader protocols, refer to [AN3155] (USART protocol), [AN4286] (SPI protocol), [AN4221] (I2C), [AN3154] (FDCAN) and [AN3156] (USB). The documents are available on www.st.com (unless an NDA applies).

User flash memory mapping

On STM32, the secure bootloader is stored in system memory and SRAM, the products are delivered in RDP level0 and all the user flash memory is available for OEM.

No STM32TRUSTEE

The OEM internal firmware can be built to start at the beginning of the user flash memory (starting address 0x0800 0000). After a SFI, the SRAM is fully available for OEM.

STM32TRUSTEE (only on STM32H5)

Only a part of the user flash memory is available for OEM firmware (see 4.3.2)

STM32WL5

Secure bootloader overview

The secure bootloader is split in two parts. The first part is stored in boot ROM (system memory). It is responsible for loading the second part of the bootloader in SRAM2 through the supported COM ports. The supported COM ports are USART, SPI and JTAG. The second part runs in SRAM2 and is responsible for executing the SFI process and applying the SFI protocol thanks to the commands received through the above mentioned supported COM ports.

The secure bootloader permits to run the SFI process several times. For this, the STM32WL5 has been reprogrammed to its initial OB configuration (as delivered by STMicroelectronics).

For more details on the STM32 bootloader protocols, refer to [AN3155] (USART protocol) and [AN4286] (SPI protocol).

User flash memory mapping

The secure bootloader is stored in system memory and SRAM2, the products are delivered in RDP level0 and all the user flash memory is available for OEM.

The OEM internal firmware can be built to start at the beginning of the user flash memory (starting address 0x0800 0000). After a SFI, the SRAM2 is fully available for OEM.

Secure boot path

In order to get the STM32WL5 booting on secure user flash memory after successful SFI, it is recommended to set nSWBOOTO to 0 and nBOOT0 to 1 in FLASH_OPTR register.

More information is available in [RM0453].

SFI image preparation

SFI firmware image format

The SFI format is an encryption format for firmware created by STMicroelectronics. It uses AES-GCM algorithm with a 128-bit key to transform a firmware in Elf, Hex, Bin or Srec formats into an encrypted and authenticated firmware in SFI format.

An SFI firmware image is composed of a header plus several areas. The areas are usually contiguous firmware areas. The last area is the configuration area containing the option byte values to be programmed when the SFI is complete.

SFI firmware image creation procedure for STM32H7/L5/U5/WBA5

To obtain SFI firmware images in the correct format (see Section 4.1: SFI firmware image format), the OEM must follow the steps below to build an SFI image:

1. Build the firmware image(s) using regular development tools.
2. Build the option byte configuration file. This file contains the option bytes that the customer plans to apply on the STM32 and that are programmed thanks to SFI. Among option bytes, the user must define the intended RDP value to be applied in order to enable the protection of user firmware and data against debug connection. Refer to applicable reference manual for more details on RDP level.
3. Generate the binary image(s). A binary image does not need to be contiguous (that is it can cover multiple disjoint areas).

1. Applicable to STM32L562xx, STM32U585xx, STM32U5Axxx and STM32U5Gxxx only (with OTFDEC).

2. With DDS = 1 and FSD = 0.

Internal flash memory only

To successfully generate an SFI image from the supported input firmware formats, click the SFI GUI tab, select the targeted micro-controller and fill in the interface fields with valid values:

1. Add the firmware file using the Add button located within the Firmware files area appended to the input firmware files list.
2. Make sure you are referring to the right valid firmware. Details are available in the Firmware information section once you have the Input firmware file is selected.
3. Select the Encryption key and Nonce files. They can be selected either by entering their absolute or relative paths, or by selecting them with the Open button.
4. Make sure that the size of the Encryption key file (16 bytes) and the Nonce file (12 bytes) are respected. In order to properly protect the firmware confidentiality, the AES secret key must be different every time the OEM encrypts a new firmware or a new release of the same firmware.
5. Select the Option bytes file in .csv format. This is the only format supported.
6. Enter the image version of the SFI to be generated. It must range from 0 to 255.
7. Select Random key area file using the Open button (this is optional). Key area requests STM32 to randomly generate data of a specified size and at a specified address filled by user within key area file in .kcsv format.
8. The Generate Hash option must be enabled on all STM32 devices supporting SFI.
9. Select MCU to fill available RAM size for the SFI operation.
10. Select the address where the continuation token is going to be stored. This field is only relevant for STM32H75xxx/ STM32H7B0xx/STM32H7B3xx/ STM32H730xx/STM32H733xx/STM32H735xx products, depending on firmware mapping, 0x081FF000 can be used as a nominal value (0x080FF000 as nominal value for STM32H733xx/STM32H735xx).
11. For STM32H75xxx/ STM32H7B0xx /STM32H7B3xx/ STM32H730xx/STM32H733xx/STM32H735xx only, select SMI files, if any (optional field).
12. Select the Output file folder path where the SFI image, out.sfi, is going to be generated.

13. Generate the SFI file by clicking the Generate SFI button. If all the fields are filled properly, the "SFI created successfully" message is displayed. More information is available in [UM2238].

Note: SMI files selection is only mandatory for secure module installation process. It is only supported on STM32H75xxx/ STM32H7B0xx/STM32H7B3xx/ STM32H730xx/STM32H733xx/STM32H735xx products.

Both internal and external flash memories

To successfully generate a SFI image including external FW and Data (also called SFIx image) from the supported input firmware formats, click the SFIx GUI tab, select the targeted micro-controller and fill in the interface fields with valid values:

1. Add the internal firmware file(s) using the Add button located within the Internal firmware files area appended to the input firmware files list. If the file is in bin format, the destination address has to be filled. If OEM uses global AES external flash memory keys, then internal firmware files must include those keys at the right address.
2. Add the external firmware file(s) using the Add button located within the external firmware files area appended to the input firmware files list. When adding an external firmware, several additional fields have to be filled (destination address in external flash memory, OTFD region number, OTFD mode and global AES external flash key address).
3. Select key area file using the Open button (this is optional). Key area requests STM32 to randomly generate data of a specified size and at a specified address filled by user within key area file in .kcsv format.
4. Select the Encryption key and Nonce files. They can be selected either by entering their absolute or relative paths, or by selecting them with the Open button.
5. Make sure that the size of the Encryption key file (16 bytes) and the Nonce file (12 bytes) are respected. In order to properly protect the firmware confidentiality, the AES secret key must be different every time the OEM encrypts a new firmware or a new release of the same firmware.
6. Select the Option bytes file in .csv format. This is the only format supported.
7. Enter the image version of the SFIx image to be generated. It must range from 0 to 255.
8. The Generate Hash option must be enabled on all STM32 devices supporting SFI.
9. Select MCU to fill available RAM size for the SFIx operation.
10. Select the address where the continuation token is going to be stored. This field is only relevant for STM32H75xxx/STM32H7B0xx/STM32H7B3xx/STM32H730xx/STM32H733xx/STM32H735xx products, depending on firmware mapping, 0x081FF000 can be used as a nominal value (0x080FF000 as nominal value for STM32H733xx/STM32H735xx).
11. Select the Output file folder path where the SFIx image, out.sfix, is going to be generated.

12. Generate the SFIx image file by clicking the "Generate SFIx" button. If all the fields are filled properly, the "SFIx created successfully" message is displayed. More information is available in [UM2238].

OEM Passwords for RDP Regression (STM32U5 and WBA5 series only)

On STM32U5 and STM32WBA5, it is possible to set the OEM1 and OEM2 passwords during the option bytes programming. To do so, the OEM must provide passwords different than 0x00000000 or 0xFFFFFFFF in the dedicated fields inside the Option-Bytes configuration file.

The OEM can also decide to diversify these passwords for each programmed chips thanks to the KEYDIVERS field in the Option-Bytes configuration file. This diversification is done during the secure programming of the SFI image using the KDF256 algorithm, with the two OEM-Key registers and the chip's Device Authentication ID as inputs.

Knowing the master keys, the OEM can read the Authentication ID from the DBG_MCU interface, compute the chip's diversified keys on his own and then trigger the desired RDP regression.

The OEMDIVERS field from the Option-Bytes can be configured in multiple ways:

• 0x00000000 means that no OEM password is diversified.
• 0x0000EABE means that only OEM1 password is diversified.
• 0xEABE0000 means that only OEM2 password is diversified.
• 0xEABEEABE means that both OEM1 and OEM2 passwords are diversified.

SFI firmware image creation for STM32H5

No STM32TRUSTEE

The steps are the same than in 4.2 with the following 2 modifications:

• Step2 build the option byte configuration file: There is no RDP option byte in STM32H5. The equivalent option byte is the PRODUCT_STATE. It must be set to minimum PROVISIONED (that is PROVISIONED, TZ_CLOSED, CLOSED or LOCKED)
• OBK provision: It is new compared to 4.2

Debug authentication

Provision OBK to be able to perform debug authentication procedure that is used to:

• perform a full or partial regression
• open the debug for a given HDP level and security state (HDPL1_S, HDPL1_NS, HDPL2_S, HDPL2_NS, HDPL3_S, HDPL3_NS)

STM32TRUSTEE

See [WikiSTM32H5].

SFI firmware image creation for STM32H7RS

Internal flash memory only

The steps are the same than in 4.2 plus the OBK to provision, SFIx is not supported on STM32H7RS:

Minimum OB requirements

For FLASH_ROTSRP register, it is mandatory to follow these rules:

• OEM_PROVD must be set to 0xB4 (provisioned)
• DBG_AUTH must be set to 0x51, 0x8A or 0xB4 (ECDSA, password or Locked)
• IROT_SELECT must be set to whether 0x6A or 0xB4 (configuration ignored on STM32H7R3/H7R7)

OBK provisioning

The OBK must be provisioned to be able to perform the debug authentication procedure that is used to:

• perform a full regression
• open the debug for a given HDP level (HDPL1, HDPL2, HDPL3)
• force download (allow application update using BL)

Optionally, provision the OBK to configure firmware application. It is mandatory to provision debug authentication OBK first.

More information is available in [RM0477].

SFI HSM key provisioning

HSM smartcard configuration is done using STM32 Trusted Package Creator tool following the below steps:

Note: HSM configuration can be done only once, the HSM is locked after successful programming. Contact ST sales representative for HSM ordering information.

1. Insert a virgin HSM in smartcard reader.
2. Select HSM tab of STM32 Trusted Package Creator.
3. Add a firmware identifier (allows OEM to identify the correct HSM for a given firmware).
4. Open the Encryption key and Nonce files. They can be selected either by entering their absolute or relative paths, or by selecting them with the Open button. In order to properly protect the firmware confidentiality, the AES secret key must be different every time the OEM encrypts a new firmware or a new release of the same firmware.
5. On HSM V2, select the personalization data file according to specific STM32 MCU, productID and license type (stm32xx_productID_licenseType_....enc.bin). ProductID is defined in STM32 chip certificate and the different license types are detailed in Section 6.2. For security reasons, it is advised to use the most recent personalization data file available in the latest STM32CubeProgrammer version. More info on personalization data in [AN5054].
6. Configure the maximum installation counter.
7. Configure HSM by clicking the Program HSM button. A feedback window indicating that HSM is going to be completely locked is displayed, to confirm and continue the procedure click Yes. If all the fields are filled properly, the "HSM programmed successfully" message is displayed.

After key provisioning, HSM can be used to secure install protected firmware on counter number of STM32 devices.

More information on HSM provisioning is available in [AN5054].

SFI image programming by OEMs or CMs

Secure firmware installation flow

Once the SFI image has been prepared using the STM32 Trusted Package Creator, the OEM sends it to the CMs. CM production lines need to be equipped with a flash memory programming tool (FT). This tool is used to:

1. Download the SFI image prepared with STM32 trusted package creator, including the image header and the encrypted part of the SFI image.
2. For each STM32 device:

1. STM32L5, STM32U5, STM32WBA5 and STM32WL5: load secure bootloader part II within SRAM.
2. Request the device certificate from the secure bootloader.
3. Request a dedicated license from the HSM. The HSM uses the device certificate to produce a dedicated license for a given firmware to be stored in this particular STM32 device. HSM can generate different license types according to the provisioned personalization data file in HSM (see Section 5 step 5). The different licenses types are detailed in Section 6.2.
4. Ask the secure bootloader to process the license, decrypt and flash the SFI image in internal flash memory.
5. Ask secure bootloader to decrypt and re-encrypt SFI image section dedicated to external flash memory if applicable.
6. Ask external flash loader to program encrypted external flash section to external flash memory if applicable.
7. Program STM32 option bytes.

STM32CubeProgrammer is the flash memory programming tool provided by STMicroelectronics. It is available in CLI mode and can be downloaded free of charge from www.st.com.

STM32CubeProgrammer is not certified for production lines, but can be used for testing SFI.

It supports the secure programming of SFI images for:

• STM32H75xxx/STM32H7B0xx/STM32H7B3xx/STM32H730xx/STM32H733xx/STM32H735xx microcontrollers via USART, SPI, USB-DFU bootloader or JTAG interfaces.
• STM32H7RS microcontrollers via USART, SPI, I2C, I3C, FDCAN, USB or JTAG.
• STM32L5 and STM32U5 microcontrollers via USART, SPI, I2C, FDCAN, USB or JTAG.
• STM32WL5 microcontrollers via USART, SPI or JTAG.
• STM32WBA5 microcontrollers via USART, I2C, SPI or JTAG.

STM32CubeProgrammer communicates with the chosen interface that triggers the secure bootloader in order to handle the OEMs' encrypted SFI image during SFI operations.

On STM32H75xxx/STM32H7B0xx/STM32H7B3xx/STM32H730xx/STM32H733xx/STM32H735xx only, to start the SFI process, the bootloader activates the security via OB programming, which in turn activates the secure bootloader.

On STM32U5 and STM32WBA5, if OEM password keys have been set, it is necessary to reset them to start a SFI or SFIx. The value 0xFFFFFFFF must be written in OEM password keys to reset these keys.

STM32CubeProgrammer example command using USART interface on STM32 devices supporting SFI and with HSM smartcard usage:

sfi command example allowing secure installing of firmware "data.sfi" into STM32 user flash memory:

STM32_Programmer_CLI.exe -c port=COM1 -sfi "C:\SFI\data.sfi" hsm=1 slot=1

More information is available in [UM2237] and [AN5054].

License types

Here are the different license types generated by the HSM depending on the selected personalization data file:

Note: Be careful when selecting SFIA license, it is used to load firmware or data in user flash before launching SFI. If SFIA personalization data file is not available under STM32CubeProgrammer, contact ST sales representative.

In order to properly protect customer firmware confidentiality when using SFIA license, SFI installed firmware must control and restrict preloaded firmware or data during OEM firmware boot and execution.

By default, "SFI." license must be used so that user flash is erased or checked during SFI installation.

Known limitations

STM32H75xxx known limitations

SFI limitation

During a SFI involving a firmware which has to be written on last word of a flash memory bank, an error is raised by the secure bootloader and the firmware is not programmed.

Recommendation

If the firmware to program in internal flash memory exceeds the size of one memory bank, it must be splitted in two parts (from linker point of view) with the first part avoiding the last word of the bank.

STM32U5 known limitations

SFI limitation

For SFI on STM32U575I evaluation board (STM32U575I-EV), SWD frequency must not exceed 8000 kHz. On the STM32U5G9J-DK2 board SFIx is unavailable.

STM32WBA5 known limitations

SFI limitation

SFI can only run on samples Revision B. SFI can only run on products with 128 kB of RAM.

Revision history