 Hello everyone, and welcome to this STM32 trust app notes video series on STM32 security. My name is Maurizio Gentili, security application engineer at ST in the microcontroller division, and I will guide you through the TFM package for STM32, a secure boot and secure firmware update solution offered by ST. Let's start with the agenda. First, we are going to go through an introduction of the TFM solution for STM32 microcontrollers. Then we will go a bit more into the details of the ARM trust and firmware amp solution focusing on the architecture and offer features. We will then present which microcontrollers are supported in the current implementation. Next, we will focus on the protection measures and on the security strategy that ST used to enhance the implementation for STM32. And finally, we will share where you can find all the resources that you may need to move on with your project. TFM provides a root-of-trust solution, including secure boot and secure firmware update functionalities, and at the same time it offers secure services at runtime, as specified in the TFM architecture and described in ARM PSA specification. This implementation is based on the open-source ARM TFM reference code enhanced by ST to benefit of STM32 hardware security features. The application is delivered as part of the STM32Q package and it is PSA Level 1 and Level 2 certified. The first service provided by the TFM package is secure boot that implements the system root-of-trust. It is an immutable code. It is always executed after a system reset. It is responsible for checking the status of STM32 static protections and for enabling STM32 runtime protections in order to protect sensitive data and operations. As with any secure bootloader, it verifies the authenticity and integrity of the application code before executing it. Integrity is verified in order to make sure that the image that is going to be executed has not been corrupted or maliciously modified. The authenticity checks aims to verify that the firmware image is coming from a trusted and known source in order to prevent unauthorized entities to install and execute code. Apart from this trusted component, every other component is then authenticated before its execution. The second service offered by the TFM package is the secure firmware update, an immutable code in charge of detecting that a new firmware image is available and of checking its authenticity and integrity before installing and executing it. Examples are provided for single and two-slot configurations. In single-slot, the current firmware is replaced by the new one, allowing you to maximize the firmware image size but removing any possibility for a rollback to the previous firmware image in case of issues during the update. The two-slot configuration requires a bigger amount of flash, but it enables a safe image installation and it is commonly used for over-the-air firmware update for IoT devices. The firmware update can download either a single binary including both the secure and non-secure parts of the firmware image or two different binaries, secure and non-secure independently. Firmware update supports internal and external flash configuration. So what are the steps of a typical firmware update procedure? The first step, a new firmware is created and stored in the server. Then the new firmware is sent to the device deployed in the field over a potentially non-secure channel. The firmware image stored in the server and sent over the communication channel could be encrypted depending on the firmware configuration so that only authorized devices that have access to the encryption key can decrypt the firmware package. At this point, the new firmware image is downloaded, checked and installed. Integrity is checked to be sure that the received image is not corrupted, while authenticity is verified to prove that the firmware image is coming from a trusted and known source. In addition to the secure boot and secure firmware update, TFM package provides secure services at runtime, a set of upgradable services managing critical assets that are isolated from non-secure code. With this approach, non-secure applications don't have direct access to critical assets. The secure service will export specific APIs to allow the non-secure code to perform operations with the critical assets without ever exposing it. For example, considering a sensitive key, non-secure code could use a secure service to encrypt or decrypt confidential information using that key, without ever having direct access to the key itself. Secure services are provided with two levels of isolation, enabled by the privileged and unprivileged mode usage. As we will see in the next section more in detail, the TFM specification defines secure services such as cryptographic services, allowing crypto variations with OPFUSK decays, secure storage and internal trusted storage to protect data confidentiality and authenticity and integrity in the device, and attestation to prove a device identity. Let's have a look at the middleware used by the STM32Q TFM application example. The first one is MCU Boot Middleware. It is the middleware that includes the open source implementation of MCU Boot that is the foundation for the secure bootloader implementation of the TFM package. The second one is the trusted firmware middleware that includes the specification of the software components of the TFM solution, such as inter-process communication, secure partitioning and interrupt handling. In addition, it includes the implementation of the secure services at runtime. The embed crypto library is the reference implementation for PSA cryptographic operations for symmetric, asymmetric and hash computation. It is used by both the MCU Boot and the TFM middlewares for cryptographic operations. This section will focus on the details of the TFM color architecture. This figure shows the building blocks of the solution and the isolation boundaries between them. The ARM TFM specification divides the architecture into two worlds, the secure processing environment on the right that includes the USB-SFU route of trust and the TFM core and services and the non-secure processing environment on the left that includes the application firmware and associated drivers. The isolation between these two worlds is guaranteed by the ARM trust zone that is configured to treat the secure processing environment as trusted and the non-secure processing environment as untrusted. On top of the reputation between trusted and untrusted, an additional isolation level is achieved through the privileged and unprivileged secure attribute. This allows for an additional isolation boundaries inside each of the two worlds. We will now review a bit more in detail the major building blocks of the architecture, focusing on the secure processing environment. The first block is the immutable PSA route of trust. It is a secure privileged service that includes the implementation of a secure boot and secure firmware update application. As the name implies, it is an immutable code that is executed after every reset and it is the unique entry point of the system. This application is based on the MCU boot open-source software. The second block is the updatable PSA route of trust. It is a secure and privileged application that implements a set of secure services that can be called by the non-secure application at runtime via the PSA APIs. TFM character support services are secure storage service, SST, that implements the PSA protected storage APIs, allowing to encrypt data and write the result in a potentially untrusted storage. The SST services implements an ESGCN-based encryption policy as a reference to protect data integrity and authenticity. The internal trusted storage, EITS, that implements PSA internal trusted storage APIs, allowing to write data in a microcontroller built-in flash memory region that is isolated from non-secure or from un-privileged applications by the hardware security protection mechanisms. The crypto service implements the PSA-crypt APIs that allow non-secure applications to use cryptography primitives, such as symmetric and symmetric ciphers, hash or message authentication codes. It is based on the embed crypto open-source software. The initial SST service that allows the application to prove the device identity during an authentication process to a verification entity. The initial SST service can create a token or request, which contains a fixed set of device-specific data. DTFM architecture is structured to allow the definition of third-party services with trusted but unprivileged attributes. These services would be isolated from the privileged components of the mutable and updatable PSA route of trust. The current implementation of DTFM today doesn't include any third-party service. So which microcontrollers are currently supported by the DTFM package? A STM32Q BTFM application example is available today for STM32L5 only, that is the first STM32 with ARM trust on support. Secure Boot and Secure Filmer Update Reference Code for other STM32 families are included in the STM32Q expansion software XQBSBSFU. We recommend you to refer to the dedicated video on XQBSBSFU that is part of this STM32 trust video series. The package includes two examples for STM32L5, one basic configuration running on a NUCLEO-L552 board and an advanced configuration running on the STM32L562 Discovery Kit. The first one is the TTFM example code where security services have been removed and therefore it basically implements a secure boot and secure filmer update solution, while the second one implements a full TTFM solution and it is therefore the reference code for this presentation. So how to make sure that the route of trust is properly secured and which STM32 protection mechanisms can be used and combined in order to reach the highest level of security possible? The main goals of STM32 security APIs is to protect against inner attacks that are attacks triggered by code running in the STM32 that could be due, for example, to malicious code exploding bugs or security breaches or unwanted operations and outer attacks that are triggered by external tools such as the bug probes trying to access the device. Security APIs used in the TTFM reference code to protect against the inner attacks are the armed trust zone, the memory protection unit, the security attribution unit, the global trust zone controller, high protection, and the secure backup registers. For what it concerns outer attacks instead, the TTFM package makes use of readout protections, the unique entry boot lock, a protected SRAM2, and tight hamper and the bug access for the activation, the independent watchdog, and the secure high protection. We are not going to describe all the security APIs in details in this video. We would recommend you to refer to STM32 security books videos on these topics that are available on ST.com. All the details on STM32 security APIs are also described in each device reference manual. In addition, another useful resource for having a better idea on attacks and STM32 security APIs is the application note AN5156, introduction to STM32 microcontroller security. In this document available on ST.com, you will find a description of possible attacks and which security feature is available on your STM32, and how they can be combined to achieve the best level of security for your device. The combination of these security APIs allowed implementation to reach a maximum level of security. In particular, the security strategy followed before this implementation is based on the following concepts. First, create three protected isolated domains. The first one is the secure privileged for the PSA mutable root of trust. The second one is the secure privileged for the PSA updateable root of trust. And the third one is the secure and privileged for PSA application updateable root of trust. In order to protect the mutable PSA root of trust implementation, the security strategy is to ensure a single entry point at reset to make sure that the authentication flow starts from a trusted code. To make SVSFU root of trust code and related secrets, keys, counters, sensitive information immutable. To limit execution surface according to the application state so that only the execution of SVSFU code is allowed at boot and until the application is verified. And finally, to remove JTAG access to the system secure partitions. The STM32 hardware security APIs are enabled and combined to implement the security strategy. Starting from the right, RDP is used to protect against access from the outside world. While the trust zone and the NPU protections are used to provide a runtime isolation between the trusted and untrusted domains. HDP, WRP, and boot lock are used to secure a single entry point and to make the PSA root of trust code and secrets immutable. For specific information, such as the anti-robbed counters, WRP can be applied since the values will change during the lifetime of the device. In this case, HDP only is used to protect the sensitive information. And by crypto software library is combined with STM32 hardware acceleration for cryptographic operations in both PSA immutable and updateable root of trust. While secure SRAM2 and secure backup registers are used to protect sensitive data in the PSA updateable domain. OK, we are at the end of this short overview and we just want to underline some useful resources that you can use to dive in more specifics. You can find usable information at the STM32 trust landing page, which provides the best entry point toward the material and resources, including the links and references for the STM32 security ecosystem from theory to practice MOOCs videos. Another important recommendation is to keep the following documents always in hand. The AN-51-56, that is the introduction to STM32 micro control security that we mentioned before. The AN-54-47, that is the overview of the secure boot and secure firmware update solution on ARM trust on STM32-L5. And finally, the UM-26-71, a getting started with the STM32-QBEL-5 TFM application. Thanks a lot for your attention. Don't forget to visit the STM32 trust landing page at st.com slash stm32 trust. I look forward to seeing you in the next video of the series.