 Hello everyone and welcome to this STM32 Trust Video Series on the Secure Firmware Install Solution by ST. My name is Ruchit Nyak, Security Application Engineer with ST Microelectronics in the Microcontroller Division, and I will guide you through the details of the SFI solution for secure manufacturing. Here is the agenda for this video. We will start with an introduction of the problem solved by the Secure Firmware Install Solution. Then, we will present the tools needed for SFI. Next, we will review the SFI flow and the steps needed to complete the process and achieve secure manufacturing. We will then cover some details on the SFI implementation for each STM32 family. And finally, we will share some of the resources that you can refer to for your evaluations and developments with SFI. Let us now start with the introduction. The problems SFI addresses are mainly two. How to protect OEM application firmware at contract manufacturer when devices are programmed for the first time and how to avoid overproduction. The graph shows a typical manufacturing process where an OEM develops a firmware and needs this firmware to be flashed to the STM32 during manufacturing. The manufacturing process is responsibility of the contract manufacturer that purchases STM32 virgin parts from ST through either sales or distribution channels. In this typical scenario, the OEM sends the firmware to the contract manufacturer in clear. The application code is potentially exposed to attacks. The OEM must trust the contract manufacturer, hoping that its application code is not stolen tampered with and that the CM does not overproduce parts. To meet the new market security requests and protect customers from any leakage of their IP, ST Microelectronics introduces a new security concept, the secure firmware install or SFI, which allows the CM to program OEM firmware into STM32 MC use internal flash memory in a secure way. STM32 series supports protection mechanisms permitting to protect critical operations such as cryptography algorithms and critical data such as secret keys against unexpected access. As described in the next sections, the solution guarantees authenticity, integrity and confidentiality of the OEM firmware through the whole manufacturing process. It ensures that only genuine STM32 microcontrollers are programmed with the OEM firmware and enables the counting of the number of STM32 program with a given firmware. The SFI process is compatible with STM32 parts provided with RSS or root security services. RSS is a security expansion of the STM32 system bootloader and as we will see in more details in the next section is responsible for the SFI steps that happen at the device side. RSS embeds a unique asymmetric ECC private key together with a corresponding certificate for device authentication. In addition, it makes use of the STM32 security features such as read protection or RDP to prevent the OEM code from being accessed or extracted by the CM. The image on the right depicts the SFI solution to have all the discussed benefits so far. The customer is responsible to generate the encrypted firmware from the original firmware image which is transferred to the untrusted environment along with physical transfer of HSM card which stores the encryption key. In the untrusted environment the HSM card is used to authenticate the target STM32, generate installation license and equip the firmware to flash it on the target device. This is just an abstract flow of the process. We will discuss all these steps in detail further in the video. As depicted here, SFI is supported by STM32H7, STM32L5, STM32U5 and STM32WL that are provided by the RSS extension of the system bootloader code. Additional details are provided in this section dedicated to STM32 implementation later in this video along with some references to the necessary documentation where you will find all information for each family. In an SFI enabled manufacturing the OEM creates and manages his own secret encryption key or firmware key is indicated in the figure that is used to encrypt its application code and then securely transfers the key which will be used by the CM for decryption of the SFI package. ST produces secure RSS enabled STM32 provision with a unique private key and certificate that will be available for purchase by the CM through regular sales or distribution channels. The CM will then be able to securely install the OEM application code using secure manufacturing SFI tools. To sum it all up, SFI offers a complete tool set to encrypt OEM binaries securely transfer OEM credentials to the programming partners securely program the STM32 at contract manufacturers and verify the program account to avoid cloning of STM32 devices and overproduction of parts. Now let's have a look at the tools necessary to perform the SFI process. As shown in the previous slides the SFI process guarantees a secure way for the OEM to deliver to the CM the key used to encrypt the application code. In order to secure this transfer ST introduced STM32HSM a hardware security module used to secure the programming of STM32 SFI enabled devices and avoid product counterfeiting at contract manufacturers premises. The OEM key is securely stored in the HSM smart card that guarantees the same level of protection of your credit card. Main features of STM32HSMR secure storage of OEM for more encryption key and license counter for SFI operations identification of genuine firmware and STM32 products token generation engine in the smart card format. It is directly supported by STM32 Cuba programmer and trusted package creator tools and can be purchased for evaluation on st.com. At this point it should be noted that the user that is both OEM and CM should have smart card reader interface as a standalone setup or integrated in their development environment. It would be required to program and read HSM card for the SFI process. You can go on to ST.com and look for STM32HSMv2 in the search bar. After clicking on the first suggested result would redirect you to this landing page for the product where you will find the description and all the features of the HSM smart card. To get some more details you can go on to the documentation tab and click on the data brief to find this document. Other tools that we will use to demonstrate the SFI process are STM32Q programmer and STM32 trusted package creator. STM32Q programmer supports all STM32 devices and it is compatible with Windows, Mac and Linux environment. Q programmer comes with an optional add-in STM32 trusted package creator that enables the SFI process. STM32 trusted package creator comes with both a graphical user interface and command line interface and can be used to generate SFI files and provision the HSM module as we will see in a moment. All the information about Q programmer and its added module trusted package creator are available on ST.com. You can look for STM32Q programmer in the search bar and click on the suggested link related to the same. It would redirect to the tools landing page on the website. Here you can find the description of the tool and all its features. You can navigate to the get software section from where you can download the latest version of the software that is suitable for your operating system. To get detailed information about the tool you can navigate to the documentation section. You can access the application notes and user manuals for the tools and its add-on modules. Now that we introduced the tools enabling SFI we can get a closer look to the whole process. This section is covered in application note 4992. You can refer to the related section for additional details. The graph shows the steps the SFI process goes through to secure the manufacturing. The first phase happens at the OEM responsible for firmware development for creating and managing the secret keys used to protect the transport of the firmware image and for the creation of the SFI package. In step one the OEM creates an AES secret key. It is OEM responsibility to maintain the key secrecy and uses STM32 trusted package creator to create the encrypted SFI image. That includes the original firmware and the option bytes configuration of the device after the SFI process. In step two the OEM program the STM32HSM with the AES secret key used in step one for encrypting the SFI image and initialize it with a counter that will limit the number of STM32 device that could be programmed with this card. The second phase of the process takes place at the contract manufacturer that receives from the OEM the encrypted SFI package and theHSM card. Now the manufacturer is responsible for installing the STM32 firmware to the device. In step three the STM32Q programmer initiates the SFI process. In step four it asks STM32 for its unique certificate. In step five the device certificate is checked to make sure the STM32 is authentic. After verifying the device authenticity in step six theHSM provides a license a unique per device cryptographic package including the AES secret key. At this step the counter of theHSM is decremented so as to avoid overproduction. The STM32 can then retrieve the AES secret key and proceed in step eight with the firmware installation and option bytes programming. As it will be described in more details in the following section the secure bootloader is a standard ST bootloader with additional security features. The implementation of the secure bootloader makes use of STM32 security features to prevent access to user flash memory or SRAM. An additional feature available for selected STM32 microcontrollers is the support of external flash programming named SFIX. SFIX is based on the on-the-fly decryption or OTFDEC peripheral designed to protect confidentiality of data and code in external memories. Content is stored encrypted in the external memory and the OTFDEC allows for on-the-fly decryption using a dedicated key. In the SFIX scenario together with programming the internal memory as described before the SFI process can be used to securely flash the content of the external memory and at the same time to protect the provisioning of the key needed for decrypting it. The key can either be part of the internal firmware image or it can be randomly generated. You can refer to SFI application notes at N4992 as mentioned previously for additional information. The document includes a dedicated section for support of external flash memory for the SFI process. It describes the vital details on how the external flash is managed and securely encrypted for the SFI flow. Together with SFI the process enables also what is referred to as SFI secure module install. It is a process very similar to SFI that can be used to securely install a third-party module. The scenario is the one where a third-party develops a firmware IP and wants to protect its confidentiality during manufacturing. The module makers develop their code and create the SFI image as in the SFI process but the encryption credentials are stored in a different HSM card. The OEM and the CM uses this card to load the encrypted module in the MCU using STM32Q programmer. Once it is programmed, the module is protected using PCROP or Proprietary CodeRidout Protection. You can refer to application note 5156 for more details. Before going to the hands-on session, let's see some of the details of the implementation of SFI on STM32Q. As mentioned already, the SFI process is based on the execution of a secure-enhanced system bootloader implemented in STM32Q that makes use of the available security features like RDP, TXAN, etc. to prevent access and disclosure to the OEM code. In this section, we will highlight some details of this implementation for each STM32Q that support SFI. Let's start with STM32H7. In this configuration, the system bootloader is expanded with the secure functionalities at his RSS services which are needed to perform SFI. As depicted in the slide, the RSS-enabled secure bootloader is stored in the internal boot ROM, so the whole STM32 flash is therefore available for the OEM application code and the part is delivered in RDP level 0. The SFI process in STM32H7 can be performed over various interfaces like USART, SPI, USPDFU, in addition to JTAG and SWD interface. The support for this additional interface is unique to each device. All the information related to the STM32 bootloader are available on the application note AN2606 on ST.com. Here you will find all the necessary information related to the peripherals in GPO supported by the bootloader for each specific board. In addition, for selected part numbers, the OTFDEC peripheral is available, enabling SFI-X for external memory provisioning. The implementation for STM32L5 and U5 are essentially the same. In this case, the secure bootloader is an expansion of the system bootloader, but on STM32L5 and U5 the code is split in two parts. The first with RSS services is stores in system memory boot Rome while the second part that is executed in SRAM is loaded by the host during the SFI execution. This allows for more flexibility to the process. Similar to H7, L5 and U5 has the whole flash available to the ODM code, the products are delivered in RDP level 0. The bootloader supports USART, SPI, I2C, FD, CAN, USB interfaces in addition to JTAG and SWD interfaces. But as on the date when this video was recorded, SFI process on the U5 chip supports USART, USB and JTAG and SWD interfaces only. Finally, the devices like STM32L5-6 and STM32E5-8 supports SFI-X, which is enabled by OTFDEC as discussed earlier. One important note, STM32SFI process makes use of the trust zone to secure the process. This requires the ODM application to be compatible with a trust zone enabled system. In case of STM32WL, the structure is similar to the one used in L5 with the bootloader split in a fixed part in Rome and one loaded in SRAM by the host. Also in this case, this leaves the whole flash to the ODM code and allows the delivery of the device in RDP level 0. The SFI process supports JTAG and SWD. Additionally, through the system bootloader, it also supports USART and SPI interfaces. This concludes the overview of the SFI solution. In this section, we are going to summarize the resources you can use to find all the additional information for your developments. The best entry point to all the material and resources is the STM32 trust landing page that includes a section dedicated to SFI. The page includes the links and references for the STM32 security ecosystem from theory to practice MOOC videos. Another important recommendation is to keep the following documents always handy. Application note 4992 that provides an overview of SFI solution and process. This is where you will find all information explained in this video. User manual 2237. It is the generic STM32Q programmer reference manual, which also includes the section on the SFI specific commands on tools command line. Application note 5054, which expands the principle mentioned in UM 2237 and is focused on how to use the STM32Q programmer in combination to STM32 trusted package creator for SFI. User manual 2238, mentioning STM32 trusted package creator tools software description. Application note 2606 that includes all the information about system bootloader and details on the supported interfaces for each microcontroller. And finally, data brief 4265, which includes all the information about the HSM cards and respective permissible upper limit for firmware licenses. This concludes the first video dedicated to SFI. We are looking forward to see you for the next videos of the series, where we will go into more details of the process and understand how to perform secure manufacturing using SFI. Don't forget to visit st.com slash xcube SFI for additional information. Thank you for your time and see you in the next video.