 Hello everyone, and welcome to this STM32 Trust App Notes video series on STM32 security. I'm Massimo Pansica, Security Application Engineer at ST in Microcontroller Division, and I'm going to guide you through the XCube SPSU package, a secure boot and secure firmware update solution offered by ST. Let's get started. We are going to see what this package is about, which STM32 families are supported and which STM32 security IPs are involved in this package. Also, we'll offer all the resources you need in order to move on with your own project. The XCube SPSU is a Cubax function firmware package which implements a root of trust and securely updates a new firmware version on your device. The update process is performed in a secure way in order to prevent unauthorized updates and unauthorized access to confidential on-device data. The firmware package which you can download from our website sd.com integrates everything you need, low-level drivers, crypto-related middlewares, and reference example code at application level for secure boot and secure firmware update services. Also, it certifies the SESIP level tree. Let's go in more details. The secure boot part implements a root of trust. It's an immutable code. It's always executed after a system reset. It checks and applies the security mechanism of the STM32 in order to protect critical operations and secrets from possible attacks. And it authenticates and verifies the user application before it checks execution. So, starting from this secure boot trust component, every other component is authenticated and only at that point it can be executed. On the other end, the secure firmware update part is in charge of receiving and installing the new firmware. The new firmware will not run until the secure boot, as we saw in the previous slide, authenticates it. The firmware update can be performed on the complete firmware image or just on a portion of it. Examples are provided for single and for dual-slot configurations. In single-slot configuration, the current firmware is directly replaced by the new one, allowing you to maximize the firmware image size, but you pay in terms of features. So, for instance, the rollback is not possible in this case. In dual-slot configuration, you pay in terms of flash sites, but it enables a safe image installation and the over-the-air firmware update capability that is very common in the IoT devices. Multiple images are also supported, and this is very useful, especially for complex systems with multiple firmware, such as protocol stacks and middlewares on top of the user application. So, which steps are involved in the secure firmware update? Well, a new firmware is created and stored in the server. It can be encrypted or not. This depends on the crypto-scam you choose. The new firmware is then sent to the device deployed in the field, and at this point, the new firmware image is downloaded, it's checked and installed. The examples provided in our Xcubes BSFU are based on the WayModern protocol over UART. But this loader component can be easily replaced with a different one of your choice. Let's have a look at the middlewares provided within the Xcubes BSFU firmware package. The secure engine is a secure enclave which provides a protected environment to manage your critical data and operations, such as keys and other secrets. Protected code and data are accessible through a single entry point, which we call Colgate Mechanism. Only task code is and must be part of the secure engine environment because it has access to all the secrets. In terms of crypto-ribaries, two solutions are supported, the ST proprietary crypto-ribary and the open-source Btls-Betcrypto. KMS is a secure key management service middleware, which provides crypto services to the user application through the PKCS11 APIs executed inside the secure engine. User application keys are stored in the secure enclave and can be updated securely. This means that authenticity checks and encryption and integrity checks are performed before the update. The ST safe-a middleware provides a complete set of APIs in order to access all the ST safe-a 110 device features from the STM32. ST safe-a 110 is a tamper-assistant secure element, which is certified by the common criteria EL file plus and is used to host X5-onite certificates and keys and perform verification that are used for firmware image authentication during secure boot and secure firmware update procedures. I just want to mention that the secure engine and crypto-ribaries middlewares are always part of the execute-based BSVU examples. While KMS and ST safe-a middlewares are optional and available for your reference, only in few examples like the ones for the STM32 L4 L4 plus. Without going in the details of this slide, what's really important to mention here is that several crypto schemes are already available in the execute-based BSVU for your reference and you can add the additional ones as you wish. In order to support the confidentiality, integrity and authenticity features you need in your specific design implementation. On the FDAC, the on-the-flight decryption from external memory feature is also available in one of the H7 examples for your reference. Very important, you can find all the details about the crypto schemes available in the execute-based BSVU firmware package in the user manual UM-2262 available from ST.com. The appendix D contains all the details about the supported crypto schemes and some very useful figures for a better understanding. Please refer to this UM-2262 document for all the additional details you want to know about the execute-based BSVU. It's a very well done document with all the details you need to fully understand all the features available in the firmware package. As of today, execute-based BSVU includes examples for STM32G0, L0, L1, F4, L4, L4 plus, G4, F7, H7 and WB. Some families like the STM32F0 does not provide enough hardware security mechanisms to implement a route of trust, so we do not provide examples in this case. For STM32L5, the red one in this slide, and for the other coming MCU families based on Cortex M33 with trust zone, ST provides a different secure boot and secure firmware update solution. The TFM trust firmware package, which leverages the ARM trust zone technology. The TFM solution will be discussed in a dedicated video of this series. My question is how to make sure my route of trust is properly secured and which STM32 hardware security mechanisms are used and combined together in order to offer the best possible security level in the execute-based BSVU reference code. Well, the main goals of the STM32 security IPs are one, to protect against inner attacks triggered by cold running the STM32. Those attacks may be due to either malicious firmware exploiting bugs or security breaches or unwanted operations. And two, to protect against outer attacks triggered by external tools such as the buggers or probes trying to access the device. Best protections against inner attacks are the firewall, the proprietary code-readout protection, the write protection, the memory protection unit and the unique entry boot lock. While best protections against outer attacks are the read protections, antitampering, disabling the bug port, enabling the watchdog and using the secure hide protect also known as secure user memory. I'm not going to describe how each one of those security IPs work in this video. We do have dedicated security MOOCs for this topic and I do recommend you to have a look at them. All the details about the security mechanisms of specific STM32 can be found in the related reference manual. But I really want to mention that another great resource is the AN-51-56 introduction to STM32 microcontrollers security. You find a description of possible attacks STM32 protection against those attacks and a couple of very useful tables to understand which security feature is available on which STM32. How to use those protections is part of a security strategy which is based on the following concepts. Ensure a single entry point at reset forcing code execution to start with secure boot code. Make as BSU code and as BSU secrets immutable. No possibility to modify or alter them once security is fully activated. Create a protected enclave to store secrets such as keys and to run critical operations such as crypto algorithms. Remove JTAG access to the device and monitor the system against possible intrusion. How these security strategies performed is different for different STM32 families especially when focusing on the isolation mechanism between the SBSFU code and the user application code. If we look at these differences for instance in case of L4 and L0 isolation is implemented using the firewall and secrets are protected with PCROP and firewall. Readout protection, RDP write protections, WRP memory protections, unit, MPU and antitampering are clearly used as well and these are common to the other devices as well. In case of L1 and 4F7 the firewall is not available so the isolation mechanism is implemented using the memory protection unit. Different story for the STM32WB which provides a CKS customer key storage mechanism. In this case the SBSFU symmetric key is isolated in the Cortex M0 plus core secure flash therefore cannot be accessed from the Cortex M4 core. Moving on with the H7G0 and G4 isolation is implemented using the memory protection unit and the secure user memory which is not available in other devices. Also some H7 parts like the H7B3 provide external flash protection through the OTF deck on the fly decryption IP. Well, we are at the end of this short overview and I just want to underline some very useful resources you can use to dive in more specifics. In terms of useful links the STM32 trust landing page which provides the best entry point to all the material and resources and the STM32 security ecosystem from theory to practice MOOCs video the link is available in the STM32 trust landing page and very important my best recommendation would be to keep the following documents always in hand AN 5156 the introduction to STM32 microcontroller security the UM 2262 the getting started guide to XCUBES BSFU and the AN 5056 the integration guide to easily customize the XCUBES BSFU firmware package on your own needs Well then, thanks a lot for your attention please don't forget to visit our ST.com STM32 trust landing page I look forward to seeing you in the next video of this series so please stay tuned and have a great day