 Hello everyone, welcome to part 2 of STM32 Trust video series about the secure firmware install solution by ST. This video will cover the details which would help you getting started with the SFI package. The agenda for this video is to discuss the tools requires to execute the SFI process. Then we will go through the environment setup. Next, we will download the SFI package for evaluation, and then we will walk through the content of the package to get an overall idea. Let us have a look at the tools related to SFI process. This slide lists the necessary tools for the process along with the SFI package. First, hardware security module or HSM Smart Card, it is used for the secret key transfer. Second, STM32Q programmer, the tool supports SFI file programming steps along with various other tasks like reading option bytes and MCU product ID. Finally, STM32 Trusted Package Creator, which is an add-on tool of Q-Programmer. It will be used to generate various files required for the process. Let us start with STM32HSM. As discussed in the SFI part 1 video, in order to secure the AES key transfer, ST introduced STM32HSM, a hardware security module used to secure the programming of STM32SFI-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 STM32HSM are secure storage of OEM firmware encryption key and license counter, which is specific to SFI operations. Identification of genuine firmware and STM32 products. Token generation engine compatible to Smart Card format. It is directly supported by STM32Q programmer and Trusted Package Creator tools and can be purchased for evaluation on st.com. Each part number of the module supports specific maximum license counter as listed here. It should be noted here that at this point, Smart Card interface will be needed in the development or manufacturing environment to program and read the HSM card. Next tool is STM32Q programmer. STM32Q programmer supports all STM32 devices with each of their supported interfaces and it is compatible with Windows, Mac, and Linux environment. The tool is available for download from ST.com. It is available over CLI and GUI. It supports features like programming, STM32 internal and external flash over JTAG, and S2WUD interfaces in addition to various other interfaces supported by the device's specific poobloader. It also supports STM32 option by its programming and HSM Smart Card programming which is specific to SFI solution. STM32 Trusted Package Creator is delivered with both GUI and CLI interfaces and can be used to generate SFI files. The tool provides full support to all the STM32 devices compatible to SFI implementation as listed in this slide. Additionally, the tool can provision the HSM module as we will see in a moment. You can download both the tools from ST.com. You can simply search by typing QPROG in the search bar. Clicking on the first suggested link would redirect you this landing page. It contains all the features about the software. You can go to the Get Software section to find the latest version compatible to your system's OS. Now, click on the Accept button and log in to get the software. Once you have downloaded the setup, follow the steps in the installation process and click on Accept the License, then verify the installation path of the tool. The next window is for the selection for all the software components to be installed along with the Cuba Programmer. Here, make sure that the STM32 Trusted Package Creator is selected. Now, follow all the installation steps on the wizard and finally, you would be able to see the message installation completed successfully. This slide goes a bit deeper in the details of the SFI tool chain. For evaluation purpose, we will act as OEM and see them using the tools just described that are STM32HSM, STM32Q Programmer and STM32 Trusted Package Creator. In particular, the OEM will use STM32 Trusted Package Creator to encrypt the application code and to inject the firmware key in the STM32HSM smart card. On the CN side, we will use the HSM and STM32Q Programmer to securely install the code to an SFI-enabled STM32 device. This transition shows what would happen in a real-case scenario, where OEM will ship the STM32HSM smart card and encrypted firmware to the CN that will most probably use tools developed to our partners implementing the SLI process. Let us now check the environment setup which is the prerequisite for the SFI flow. Before we start, make sure you have everything listed here. STM32Q Programmer and Trusted Package Creator tools to create necessary files, including the .sfi file. STM32Q by DE for compilation of the application code in the package. XCube SFI package, which has the command line interface automation scripts and necessary binary files along with the application source code for the SFI process. STM32 development kit that supports the SFI implementation. In this case, it is STM32U585 IoT board, which we will use to test the process. STM32HSM card, which would be used for the SFI authentication process. PC with the smart card interface, it will be required to program and read HSM card on both OEM and CN side during the flow. A lot of all these components, the only thing remaining in our setup is the XCube SFI package. So let's see where we can download the package from. XCube SFI is the software expansion for STM32Q supporting secure firmware installation process for STM32 microcontrollers. The package can be downloaded from st.com. You can simply search by typing XCube SFI in the search bar. Clicking on the first suggested link would redirect you this landing page. It contains the description and important features of the package. To get detailed information about the package, you can click on the documentation tab to find the user manuals related to the package. You can notice that there are go to wiki button at the bottom of the page. You can click here to access the wiki page describing how to use the SFI package. You can go to the get software section to find the latest version of the package and download it by accepting the license agreement. You can simply unzip the downloaded file to access the package. Now that we have downloaded the package, let us check the content of the package. For the purpose of the illustration, we will have a detailed look at the content of STM32O U585 Discovery Kit. The package content would be similar for all the currently supported boards as on the day the video was recorded. The folder structure is meant to mimic the SFI flow which we have already discussed in the previous video. The package would serve as both OEM and contract manufacturer's facility. The process starts with OEM dev directory which represents the developer environment on OEM's side. It contains the example application code for simple LED blinking which will be used to build the application binary. Then OEM secure room folder which is analogs to secure room on OEM facility stores all the keys, OB or option by its configuration and application binary. The SFI file composing all these components will be generated in the same folder. The CM folder mimics the contract manufacturer's facility. Hence it would have the same .sfi file which was created in the OEM secure room. The secure firmware flash would be handled from this directory itself. The package on the local file system would look something like this. The project's folder contains the dedicated SFI implementation for each boards that the package currently supports. Going back to the package there is a release note. Here you can go through the overview of the process and list the wiki page of the supported hardware. The wiki page is designed for the user to understand step by step implementation on how to use each components of the package which we will further see in detail. Going back to the release note, it also lists the supported SD-M32 devices along with their respective compatible RSS and bootloader versions. It must be noted that before trying the SFI process hands-on, the user must check if the hardware you are planning to use complies with these requirements. If not, then there are fair chances that the MCU would not support SFI implementation. If you are planning to buy a new board for this purpose, then please consider this information and the reference numbers given below to make sure that the system bootloader of the hardware supports SFI implementation. The user can check the RSS and bootloader version for any MCU using the SD-M32Q programmer command line interface and graphical user interface tools. Explanation on how to do so is covered in the next video of this series. Let us now have a detailed look at each of these folders in the SFI package. We will follow the process flow and start with OEM dev folder. It contains the complete project for the application code in the supported IDE like STN32, QBID, Kale, and IAR. Next is OEM secure room. It further includes folders like binary that holds the OEM dev.bin and .sfi file. Moving on to keys folder, it contains the AES key.bin and nonce.bin files. Next is option bikes folder, which contains the ob.csv file with option bytes configurations. All these files are given with the package in order to facilitate the user to directly test it. But the real process would include generating these files. We will demonstrate it in the next video of this series. The folder also contains scripts for both Linux and Windows environment to automate each step on the OEM side of the process. In case of Windows OS, you can simply double click on .bat scripts. Moving on to CM folder, it contains the binary folder with the .sfi file created from OEM folder. The other folder is the scripts folder that holds the scripts to automate the process, like preparing the board and flashing the .sfi file over each support interface as discussed in the previous video. Finally, the .sfi folder also has a readme file that provides the description of the content of the package along with a brief description of each file. It also explains how to use the package including the hardware preparation followed by the order of execution of scripts, which would ultimately mimic the .sfi flow. That concludes the part to have secure firmware install video series. We hope by this point you have acquired the necessary information to start with the .sfi process. We are looking forward to see you for the next videos of the series where we will demonstrate how to use the package and replicate the .sfi flow. 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.