 Hello everyone and welcome to the Part 3 of STM32 Trust video series on Secure Firmware Install Solution by ST. In this video, we will see how to use XCube SFI package and emulate the roles of OEM and contract manufacturer to demonstrate the SFI usability. We will use STM32 U585 Discovery Kit for the SFI demo. Here is the agenda for this video. We will start with the application compilation process which is a general emulation of OEM developer. We will then look at the SFI programming section where we will divide the entire process in terms of OEM and contract manufacturer and their dedicated roles. Next, we will review various roles of OEM's secure room and demonstrate them using both GUI and CLI of STM32 Q programmer tool. Then we will look at the contract manufacturer roles demonstration with both CLI and GUI support of the tool. As discussed in the previous video on getting started, the description of the process is mentioned in readme file, included in the SFI packages application folder. You can refer to this document to find the steps covered in this video. Another useful reference is application note 4992, the document includes separates sections 4, SFI image preparation, SFI HFM key provisioning, and SFI image programming by OEM or CM. You should also look out for the wiki page which describes the step-by-step execution process. You find the link to it on the XCube SFI product page, although the page for STM32 EFON is under development at the time of recording this video. But you can find a similar wiki page for STM32 H7 board. The dedicated page for EFON will be published soon. Let us start with application code compilation process. The OEM underscored depth folder in the SI package holds the example project with application code. The project supports various integrated development environments or IDE's, including STM32 CUBE IDE, which we will use for this video. Once the project is opened in the CUBE IDE, we can see that the code contains a simple logic to toggle 2 on board LEDs, that is LED6 and LED7. Before compiling the process, we need to make sure that the project is configured to generate .binary file on build. We will right-click on the project and go to properties. Then navigate to the CC++ build option and then to the settings. Here go to the MCU post-build outputs option and enable the first option that is convert to binary file. Finally, click on apply and close to save the changes. Now we are ready to build the project to generate the binary file. We will simply click on the build icon on the top panel of the IDE. You can now see the build logs on the build console below. Finally, when the build is finished, you can check to logs to find the .binary file is generated along with the .ELF or executable file. To find the binary file, we can go back to the folder holding the project and navigate to debug folder. Here you can find the .binary file. Now that we have generated the binary file, we will go to the SVI programming in STM32E5 section. During the demo, we have divided the SVI process into two parts, that is, OEM's tasks and contract manufacturer's tasks. We will look into each of this task and their step-by-step process. We have already discussed these tasks theoretically in the previous videos of this series. Let us now start performing OEM secure room roles. The first one on the list is OB or Option Bytes Generation. As discussed earlier, we can set the OB configurations by generating .csv file for the configuration. The download package already includes a sample Option Bytes configuration saved in OB.csv file in the Option Bytes folder. If you want to custom configurations, you can generate the file using STM32 Trusted Package Creator Tool. Here you can go to the SVI Option Bytes section. Now select the microcontroller from the drop-down list. We will select STM32E575 or 585, the board which we are using for this video. The register area now shows all the configurable register in STM32E5 and we can modify each of them. For example, we can change the RDP level here by selecting the appropriate one, toggled TZEN register simply by clicking on it. This way all the registers here can be modified. You can find a description about each of these bytes by clicking on the plus sign. You can also refer to the Flash Option Bytes section of STM32E5 user manual. Once the configuration is completed, we can select the path where this file will be generated and click Generate OB to generate the .csv file. You can parse the generated file by loading it from here. This was it is easier to double check the configuration. Now, next task in the ODM secure room is to generate the AES key and NONS binary files. All of the package already contains these files in the keys folder. To create it, there are two ways to do so. First generate your own binary file. For this, we need to make sure that size of each of these files are fixed. Encryption key must be 16 bytes and the NONS has to be 12 bytes in size. We can open an empty text file and fill it with desired key value. Let's say AES-TEST-U585-01. Now save the file with .binary extension and the AES encryption key file is ready to use. We can do the same for NONS file too. The second and straightforward method is to randomly generate these files. For this, we will again use STM32O Trusted Package Creator Tool. Go to SFI window, click on generate next to encryption key file field and select the location to generate it. Same can be done to generate NONS file. Next job for the OEM secure room is to generate the SFI file using all the file we have generated so far. This task can be performed by both GUI and CLI interface of STM32O Trusted Package Creator. First, we will use GUI to create the file. For this we will use the SFI window of the tool. At the beginning, we will select the microcontroller from the drop-down list, which is STM32O E5. Then we will give the path to files for each of the SFI components. For the purpose of demonstration, in this video we will use the binary files already provided along with the downloaded SFI package. Starting with firmware file where you will add path to .binary file by navigating to it from the file system. Once the file is selected, the tool will prompt to enter the start address of the binary in the internal flash. For this example, we will use the address as 0x8 million, as mentioned in the readme file. Similarly, add paths to encryption key binary, NONS binary and option bytes, .csv files from their respective folders. Now, enter the image version for your own reference. For instance, we will set it to 1. Do not forget to check the generate hash option here. If SFI file is generated without hash enabled then the bootloader would not validate the image. It would lead to installation failure at the end. Every other fields can be ignored for now in case of STM32O E5. Finally, give the path for the output SFI file by selecting the desired folder. And click on generate SFI. The file would now be generated. You can check the segment section of the tool to verify the start location of the firmware binary. The other segment visible is for the configuration header, which includes the OB configurations and encryption keys. Let us now have a look at CLI-based approach for the SFI file generation. As we already discussed, the package supports both Windows and Linux environment. If you are using Windows machine, you can use the batch scripts. And in case of Linux environment, you can use shell scripts. We will be using generate SFI underscore OEM underscore dev batch script for our Windows environment. The script essentially follows the same steps as we did in case of GUI. The script includes the path to the tool. Make sure to update it with your own path, if it is not installed at the default location. Next, it mentions the name and path to the files for SFI components. In case if you are working on your custom project and not the package, please make sure you update the path and file name accordingly. You can see that the scripts includes all the information which we used while using the GUI-like version, output file path and name, binary address, RAM size, hash enable, etc. Now that we have understood how the script supports the KU programmers CLI command and how it replicates the user flow on GUI, we can proceed to its execution. Before executing the script, make sure that the application binary is moved to the binary folder. Now simply double-click on the script. You can see the execution logs on the command prompt. And finally, it will show the success message. If you face issues while executing the scripts, you can try running it as an administrator. Next step is to transfer the generated SFI file to the contract manufacturer. In this case, it can be done using the transfer SFI to CM script. It would simply copy the SFI file to CM's binary folder. Next and final step in the process on OEM side is to program the HSM card. You must be noted that the smart card interface will be required at this point, along with your laptop or computer. Let us first look at how it can be done using GUI of the tool. Going back to trusted package creator and to the HSM window. Now set the slot number to 1. This is only needed if you are using a card reader which is not embedded on the laptop. Then enter the value for firmware identifier. This is just for the user to identify the HSM card. It is useful especially when working with multiple HSM cards. It can be any random value as it is only for your own reference. In this case, let us enter the value as u5 underscore 48202000. It corresponds to the MCU family and its product ID. Such values would give clear identification for the user. We will get into the details of product ID and where to find it in a moment. Then we will add the encryption key file and the nonce file. Make sure that these files are the same as that used in the previous step while generating the SFI file. The personalization package is specific to each MCU. It contains the hardware certificate which is linked to the product ID. Hence, we will need to find the product ID of the MCU we are using. To do so, we will use STM thirded WCUE programmer. Open the tool and connect the board using onboard ST link. As the board is connected, check the boobloader version and double check it with the SFI requirements from the release node as discussed in the previous video. Now go to the secure programming section and select the SFI or SFIX option. Navigate to the HSM section and click on get product ID. Here you can find the ID of the board. Now we can disconnect the board. And going back to trusted package creator, select the MCU from the drop down list. It would filter the available personal data files. The files are already included in the bin folder with the tools installation. Click open and select the binary file corresponding to the product ID. That is 48202000 in this case. Now set the maximum license counter by entering the number. Refer to the maximum possible counter corresponding to the HSM card you are using. The counter can be set to any value between 0 to the max possible count. It would determine how many firmware installations are permitted on the ODM facility. In this case we are using STM32 HSM V2BE and we want our card to allow maximum possible licenses. So we will set the value as 300. Double check all the information as it cannot be changed once the card is programmed. Now click on program HSM button. Read the message prompts carefully and continue. I will stop at this point as I have already programmed the card. Finally you will see a success message. Also you can verify the information by reading the card from HSM information section by refreshing it. Although you can see that max counter is 265. That is because I have already used this particular card several times before recording this video. Now that we have learned how to use GUI, let's check the CLI implementation of it. In this case we will use the program HSM script. Open the script in a text editor and verify the necessary file paths, product ID and maximum license counter. Update these information if needed. Before executing the script double check the information as there will not be any warning prompts in this case. Now execute the script like any other script by double clicking it. With this we have covered all the tasks on the OEM side. Let us now look at the contract manufacturer's responsibilities. The CM's responsibilities start once. It securely receives the HSM card and the SFI file. The first task is hardware setup. The contract manufacturer is responsible to connect the board with a programming environment. By plugging connector CN8 on U5A5 Discovery Kit with a USB cable. Make sure Chumper 4 is connected in 5V USB ST-Link mode. Now switch the SW1 to position 1 and reset the board to get the MCU in the boot mode. Although it may not be necessary in case of the SWD interface or for option bytes regression. Next task after the hardware setup is done on the CM's side is option bytes regression. This step will reset the option bytes configuration including RDP level to default state. It will also erase the internal flash for SFI programming. We will be using prepare target scripts for the regression. As we have already discussed the package supports various programming interfaces. In the case of STM3205 it currently supports USB and UART in addition to SWD interfaces. Hence we find scripts corresponding to each interface in the package. For the demo we will be using SWD interface. You can refer to the README file to get more details on how to use other interfaces. Going to prepare target SWD script. The first line set the RDP to level 1. It is required specifically when the RDP is set to 0.5. To reset the RDP from level 0.5 first it must be set to level 1 and then reset to level 0. The next line is the main regression command. It resets level back to 0 and programs other option bytes to the default state. Also the command would trigger a mass erase to prepare the MCU for SFI programming. Now that we have understood the script let us execute it. You can see the execution steps from the command line logs. And finally after successful execution of the script it would indicate that the flash is a race and OB is configured. Now the board is ready for secure firmware installation which is the next and final step for the contract manufacturer. We will use the SFI file supplied by the OEM. Let us go through the flashed SFI script which we will use further. The script includes SFI file name which is to be programmed. If you are working on your custom package please be sure you update the file name and path accordingly. Next it includes the path to RSC binary file which acts as security extension of the system bootloader. We have already discussed about RSC in the part 2 video of this series. The script essentially uses the SFI command of the CUBE programmer CLI for programming. Before execution of this script we need to make sure that we have plugged in the HSM card. Also check the HSM has the right licenses programmed by reading the firmware I did the card. We can use the read HSM script for this. Let us now execute the script to program the SFI file. Let us slow down the video to understand what exactly is happening during the execution by following the logs. The script execution logs indicates the certificate exchange. At this point the MCU and HSM card exchange the keys and certificate to validate the process. The HSM license counter will be decremented after successful authentication regardless of any further failures in the process. Now the actual installation process starts after the HSM authentication stage. We can see that the RSS-E is programmed and then it processes the license and image header to flash on the desired memory address. We can now see the SFI process is completed successfully and the board is ready to run the application firmware on the hardware. To do so set the boot pin to zero by switching SW1 to boot zero and reset the board. And we can see the user LEDs blinking as programmed in the application code. We can also verify the OB configuration by reading them using the Q programmer or the read option bytes script in the package. In the Q programmer connect the board and go to the OB window. While connecting the board make sure SW1 is set to boot one and board is reset. Only then the board would be connected to the tool. Now press read. You can observe the configuration. Check the RDP level which is set to hex 55 that is level 0.5. Also the Tzenbit is enabled. We can also observe in the device memory section the data on each flash address is set as zeros. That is because read protection is enabled to level 0.5 which does not allow the user to read the flash. Hence we can conclude that the option bytes are programmed successfully. That marks the end of the part 3 of secure firmware install video series. We hope by this point it is clear how to use SFI solution on STM320U5 Discovery board.