 Hello and welcome to this introduction to Trusted Firmware for Cortex-M, also called TFM. The TFM framework is composed of a secure boot and secure firmware update application executed after reset and a set of secure services available at runtime. MCU boot is a root of trust and is immutable. It's the first code executed after each reset. A non-secure application and part of secure application can be updated via the MCU boot application. The TFM core manages the PSA level 2 isolation inside the secure application and controls access to the secure services from the non-secure application via the PSA APIs. The following secure services can be requested by the IoT application, crypto services, secure storage and attestation services. TFM is modular. Each gray box can be deactivated independently via compilation switches so that secure services can be easily reduced to only keeping the MCU boot part. Secure crypto services can be configured to only support the crypto algorithms needed by the application. TFM core and TFM secure services are used for STM32U5-PSA level 3 certification that includes resistance against physical attack in addition to PSA level 2 certification requirements. They're based on the hardware protections provided by the STM32U5 series referred to as TBSAM hardware in the figure. A device deployed in the field operates in an untrusted environment and is therefore subject to threats and attacks. To mitigate the risk of attack, the objective is to run only authentic firmware on the MCU. The secure firmware update relies on a server providing the encrypted firmware and SBSFU service available in the MCU. The EOM server and web services are responsible for storing the new version of the device firmware and communicating with the device and sending the new image version in encrypted form. The STM32U5 is deployed in the field. It embeds a code that runs the firmware update process. It communicates with the server and receives a new firmware image, authenticates and decrypts it and installs the new firmware image before executing it. The TFM secure storage or SST service implements PSA protected storage APIs. The service is supported by hardware isolation of the flash access domain and relies on hardware to isolate the flash area from non-secure accesses. The current design of the SST service relies on the hardware abstraction level provided by TFM. The SST service implements an AEAD encryption policy base on ASGCM as a reference to protect data integrity and authenticity. The design also meets the following high level requirements. Confidentiality, resistance to unauthorized accesses by hardware software attacks. Access authentication, mechanism to establish the identity of the requester, i.e. a non-secure entity, a secure entity or a remote server. Integrity, resistance to tempering by the normal users of a product, package or system or by others with physical access to it. If the content of the secure storage is maliciously modified, the service is able to detect. Reliability, resistance to power failure scenarios and incomplete write cycles. Configurability, high level of configurability to increase or decrease the memory footprint to cater for a variety of devices with varying security requirements. Performance, optimized for use in resource constrained devices with a very small silicon footprint, the PPA assured for power performance area should be optimal. The TFM internal trusted storage or ITS service implements PSA internal trusted storage APIs that can write data in a microcontroller built in flash memory region that is isolated from non-secure or unprivileged applications by hardware security protection mechanisms. The design also meets the following high level requirements. Confidentiality, resistance to unauthorized accesses by hardware software attacks due to hardware isolation of the flash access domain. Access authentication, mechanism to establish the identity of the requester, i.e. a non-secure entity, a secure entity or a remote server. Integrity, resistance to tampering by attackers with physical access is provided by the internal flash device itself while resistance to tampering by non-secure or application updatable ROT attackers is provided by the hardware isolation mechanism. Reliability, resistance to power failure scenarios and incomplete write cycles. Configurability, high level of configurability to increase or decrease the memory footprint to cater for a variety of devices with varying requirements. The TFM cryptographic service provides an implementation of the PSA cryptographic API in a PSA updatable ROT secure partition in TFM. It's based on embedCrypto which is a reference implementation of the PSA cryptographic API. For more details on the PSA cryptographic API or the embedCrypto implementation, refer to the embedCrypto GitHub repository directly. The service can be used by other services running in the secure processing environment or SPE or by applications running in the non-secure processing environment or in SPE to provide cryptographic functionality. TFM initial attestation service allows the application to prove to a verification entity the device identity during an authentication process. The initial attestation service can create an entity attestation token or EAT on-demand which contains a fixed set of device specific data. The device must contain an attestation key pair which is unique for each device. The token is signed with the private part of attestation key pair. The public part of the key pair is known by the verification entity. The public key is used to verify the authenticity of the token. The data items in the token are used to verify the integrity of the device and assesses trustworthiness. The provision of the attestation key is beyond the scope of the attestation service and should take place during the manufacture of the product. Thank you for attending this presentation. You can now refer to the presentations that detail the operation of the TFM, TFM flash memory footprint, TFM offer in the STM32 U5 and TFM pointers.