We are officially launching the Secure Software Install (SFI) feature of the STM32H7 and inaugurating Secure Module Install (SMI) on an STM32 microcontroller. ST introduced the first dual-core versions of the H7 last June along with architectural updates. At that time, some of the software solutions necessary to take advantage of these new hardware security features needed a little bit more polish. Now that they are ready for prime time, we decided to look at SMI and see what makes SFI unique on the STM32H7 since the new models represent our latest flagship security MCU. Additionally, we are also taking part in Arm TechCon 2019 and wanted to highlight some of the innovations that drive these devices.
SFI and SBSFU: The Foundations of a Secure System at All Stages of Its Life
A secure firmware install (SFI) is now a relatively popular technology that enables system makers to ship an encrypted version of their firmware to an OEM. Since the code only gets decrypted inside the MCU, developers can reduce the risk of IP theft. Similarly, OEM can offer significant guarantees without investing in major machines or technologies, since the only thing they need is STM32CubeProgrammer and an HSM smart card, which contains the security credentials that will enable the secure installation of the firmware onto the microcontroller. Once a product arrives in the hands of its final users, developers can benefit from secure boot and secure firmware upgrades (SBSFU) to protect them against attacks. The secure boot checks the boot loader signature to ensure that a hacker didn’t insert malicious code, while secure firmware upgrades allow manufacturers to patch vulnerabilities and fix potential bugs to enhance the customers’ experience.
Any discussion about the security features of the STM32H7 microcontrollers must first explain that the new SMI feature is only available on STM32H750, STM32H753, STM32H755 or STM32757 part numbers. Just like SFI or Secure Boot and Secure Firmware Update (SBSFU) on other STM32, engineers need an MCU with crypto-cores and other specific hardware mechanisms. Nucleo, Discovery, and Evaluation boards integrating these new STM32H7s are already available, which will significantly help test and deploy these functionalities. All these technologies also belong to the STM32Trust, our initiative that focuses on software and hardware solutions, and they were all audited by a third-party laboratory to ensure their robustness and efficacy. Hence, today marks a symbolic launch, but it is also the continuation of our desire to improve security on embedded systems to protect end-users, system vendors, and module makers.
STM32H7 and SMI: What Is It and Why Is It Important?
The STM32H7 is our first family of MCU to benefit from SMI, which enables third-party module makers to encrypt their binaries. The application running on the MCU calls the module, just like any other regular module, but the system maker can’t access the source code, which significantly reduces the possibilities of IP theft. Very often, a company working on a system’s firmware will purchase a third-party module to add features without having to develop them from scratch. Module makers can now develop their code for an STM32H7, then encrypt the binary with Trusted Package Creator, which is part of STM32CubeProgrammer. They then store their encryption credential in a hardware secure module smart card that they ship to the OEM, who will use it when loading the encrypted module to the MCU with STM32CubeProgrammer.
Attentive readers will notice that the SMI process is identical to SFI, but instead of encrypting the entire firmware, developers encrypt a module. Additionally, SFI and SMI processes use distinct HSM cards. One smart card cannot store all credentials, but each firmware and module must use its card for obvious security reasons. Additionally, unlike SFI, SMI requires compiler support for unique extensions. Our STM32CubeIDE, the free IDE that integrates STM32CubeMX, is already compatible, and its most recent update just brought support for the STM32H7, making it an excellent tool for professionals and enthusiasts. Keil and iAR are also compatible, and we are working with other IDE makers to ensure the broadest support possible. Additionally, we are already working with some module makers that wish to take advantage of this new feature, and we will promote their solutions once they are ready for the public.
SFI and SBSFU on STM32H7: What Specific Implementations Make Them Even More Powerful
Just like their predecessors, the new STM32H7 with crypto cores is also compatible with Secure Firmware Install as well as Secure Boot and Secure Firmware Update. However, the latest MCUs are unique because their SMI and SFI codes are all inside a secure system memory. On other devices, such as the STM32L4, the SFI is inside the user memory because the component doesn’t have all the secure spaces that the STM32H7 has. We protect the code inside the STM32L4 with special locks, and once the OEM uses SFI to install the firmware, the system automatically deletes the mechanism to ensure that the user application can use more memory. On the other hand, the STM32H7 stores SMI and SFI codes in a system memory that’s inaccessible by the user, and the code stays in that memory for the life of the device.
Like the STM32WB, STM32G0, and STM32G4, the SBSFU of the STM32H7 integrates a Readout Protection Level 2 (RDPL2) that shields the Flash, backup registers, and the SRAM content from any external access while also disabling the JTAG/SWD interface permanently. Once active, RDPL2 is irreversible, protecting developers from a forgotten debug backdoor, even when the device is at the ST factory. Traditionally, STM32 devices that only use Readout Protection Level 1 open their RAM to JTAG access if the user performs a system reset. However, the STM32H7 forbids such access, even at RDPL1. Similarly, when switching from RDPL1 to RDPL0 (no more protection), the STM32H7 keeps its Proprietary Code Read Out Protection (PCROP) active.
