 Welcome to this PSA TFM presentation. PSA stands for platform security architectures. In fact, it's an ARM initiative which establishes a general method for securing devices from the very start of the product lifecycle. It covers the entire IoT ecosystem, from silicon vendors up to cloud providers. And as you can see, ST is involved as a silicon vendor. This initiative started in 2018 with ARM Hanon's first version of PSA certification. This platform security architecture is made up of 4K stage, Analyze, Architect, Implement and Certify. You can find many details as well. If I just sum up these four steps and analyze documentation, you will find three TMACs which stand for threat model and security analyzes. It's three different examples done for each IoT where they identify what are the assets they want to protect, what are the threats and where to mitigate them. So it's a full security analysis. An architect will find documentation about the security architectures definition. In the implementation, you will find some API definition, but also you will have documentation about implementation. And you also have a full release of an example of implementation, which is a TFM. I will just detail this after. And the last step is a certification which ARM defined with some labs how to certify your product and define three level of certification from level one up to level three. So level one is just self declarative, level two is done by labs with some security tests or attack, and level three which advance attack. For the STM32L5, we have been certified level two. So now let's define what is TFM. So this implementation of the PSA on the Cortex M33 for the moment. We don't focus yet on the L5. So we based on Cortex M33. We've got isolation from trusted and untrusted mode with trust zone. So what is the component of the TFM? First we have the first software block which is the SBSFU, secure boot, secure firmware update. I think now after the presentation of the first part, you know what is a secure boot and what is a secure firmware update. The other block is all those one. So all those things are, I would say, a secure OS or firmware update on some security services. That could be code by the non-secure part, some thumbs up API. So I will detail after all those services which are defined by PSA and how they can be used by the untrusted part. What is important to see is that the TFM SBSFU is immutable and can be updated, but this portion of code could be updated. In blue, you've got what is defined by PSA, the different services, and in green is where you can put your own secure function you want to be available for the non-secure parts. And of course, the last block is the application firmware. I will detail after a different block. Now let's talk about isolation. PSA defines three levels of isolation. The first one is the isolation between the secure and non-secure. So quite simple. Isolation level two will drive to put an isolation between what is defined by the TFM or the PSA and what is available for the third party. And the level three is isolation between the different third party functions. Today, the TFM has been only supported isolation level two. I mean at harm level. So in our device or on the STM32L5, we also use isolation level two. Just a warning, previously I told you about the certification level, which is from level one up to level three. There is no link between certification level and isolation level. This is quite important because sometimes there is some confusion on people. So some detail about this TFM. First TFM stands for trusted firmware for Cortex-M. So it's a reference implementation of the PSA standard on the Cortex-M CM33. The current version supports level of isolation one and two. So now she should be clear for you. And ST ported the TFM core on the STM32L5 with isolation level two. So let's come back on the different software brick. And now I just explicit a little bit how we do the isolation level two. Level one is done by the trust zone. And in fact, the level two, which is this one, is done by the privileged and unprivileged mode of the MPU. Okay. So let's detail each block. First, we've got the TFM SBSFU. So the functionality, secure boot, secure firmware depth. So secure boot ensures about the signatures of secure application before launching it and ensures the signatures also or the integrity and the authenticity of the insecure application. This is mainly the purpose of secure boot. We also check, I will say, the security of your platform. Secure firmware updates can detect that a new firmware needs to be installed, a secure one or a non-secure one. In fact, this is based also on an open software sources, which is MCU boot. And you can find details about this boot mechanism at this address with all the documentation. This one is immutable. This means it can be modified and it can be updated. Okay. The second binary, I will say, would be the secure application. So this portion of code and this one and the non-secure application, which is another application. What are the different services? So first, we've got the TFM core, which is a kind of, I will say, secure OS, which under the different request. Let's talk about the secure storage. So secure storage, it's a services. So it's got an API which allows to encrypt data and to write the result in a non-hardware protected storage. That means the non-secure application could request to store something in a location where it's not hardware protected. So it needs to be encrypt before. There is another storage services, whose name is internal trusted storage. And this time, we will store the data in clear somewhere where it's protected by hardware. In fact, it could be in the flash protected thanks to a zone, for example. Then we've got cryptography services. So again, some API which allows you to encrypt and such kind of thing. And it's based on embed crypto open source software. On the last one, which is initial attestation, maybe more complicated to explain, but let's try to do it. It allows a server to identify or authenticate the device. Let's try to explain how it will work on the security part. You will receive a challenge from a server. That means just a number. And you will give it to this API, initialization, initial attestation, sorry. So with this challenge, we will concatenate information of your platform. For example, a version, the lifecycle state, the secure binary hash, the insecure binary hash. You will put all those things together and you will sign it inside the secure part with a private key. And then you will return this value. This is the initialized attestation services. Then this value could be sent to the server who have the public key that can check the signatures and have all the information about the status of your platform. Third-party services are where you can implement your own, I will say, secure API. Today, it's empty, even at the PSS specification on GFM example. So it's ready, but not empty when delivered. Now about the protection. I would like in this slide to show you what are the hardware protection that we use, or hardware mechanism of the L file that we use to protect the different functionality. CSBSFU secure boot needs some services, well-defined, unique boot entry, the root of trust, hardware unit key, it's a key that should be used and should be unique by each device. Initial attestation info is what I just sum up with the services. We've got secure firmware updates which need also some services. And here are the hardware mechanisms that we can use to protect. For the unit boot entry, for sure, we rely on bootlock mechanism. So it's a static protection which allows you to ensure you're always boot from the same location. For the root of trust and mainly everything except the anti-rollback counter, we will use the right protection of the flash. The high protect, so high protect is also secure mem. That means after the execution of the secure boot, once it has finished to do the secure boot process, it will disappear and can't be seen anymore by the rest of the system. We will use also the MPU in mode privilege. We will use the trust on secure protection and ADP level 1 at least, could be also ADP level 2. As you can see, anti-rollback counter is not right protect because this one will be updated when we install a new version. For the services that could be updated thanks to the secure firmware update, so here we've got also other mechanism. For the crypto operation, we've got an accelerators, so hardware accelerator of asymmetric cryptography and the symmetric cryptography. Here you can see we use the RTC backup register on SRAM for encryption key because they are fanned by the secure boot, or shared by the secure boot. Because as I said before, the secure boot will disappear after its execution but need to transmit some key value or some secret value to the services and this will be done thanks RTC backup register that are protected and also the SRAM. And the SRAM have some additional mechanism when you are in ADP level 1 if there is an intrusion, it will be a RAS. ADC backup register could be secure or not. Then you can see NPU privilege still for the services through zone and ADP level 1 and we use the NPU and privilege to isolate the application updateable PSI root of trust regarding the services. So ST delivers for you a full TFM and there is some features. What are the things that you can configure on what you get with this software? First you've got 3 versions of crypto scheme authentication. You can use RSA 2048, RSA 3072 or elliptic curves. For the integrity we've got the SHA256. For the confidentiality we use ISCTR with a symmetric key which is encrypted in RSA or in elliptic curves. We are in dual slot mode. So dual slot mode that means you've got a slot for execution on the slot for the download. Dual image mode that means you've got one image for the secure application and one image for the non-secure application. External memory support of OTF deck. So only the secure application primary slot is in internal flash. It's allowed to give a lot of space for your application. But I will show you this in the next slide with the memory map. In green I put the default config. That means you can change RSA to this one or to the elliptic curves. You can deactivate the external memory if you don't have an external memory. And that's it for the SBSF blocks. The services. So we've got a PSI isolation level 2. We've got all those cryptographic services and you can use software crypto or mix it software and hardware. And this is configurable. In the Solar Attestation token services I told you about this. For the secure storage here we use a high-res GCM and internal trusted storage. We also deliver a GFM local loader which is just an application which is responsible to download and that is standard load. It's an example. You can activate it or not. It's up to you. If you don't activate it you can have the loader inside your user application. The memory layouts. So here you can find with the internal flash. So this is a default configuration of course. So in the secure part of the internal flash we've got the TFMSBSF reboot. Some secure non-volatile data that is needed. The TFM API secure where you've got all the TFM services and you've got this possible local loader that can be called by the SBSFU. And in the external flash we can put the happiness secure and the downloading slots. Now if you don't need all the security services of the TFM for example you just want to do a SBSFU. You don't want to have the full TFM. In fact we deliver for you packages with SBSFU boot with an example of the TFM where we remove all the security services and this allows to give you more space and also to have different functionality. I will detail this right now. So this SBSFU boot now has got the same authentication possibility. SHA-256 also confidentiality is the same mechanism. But now you can be in single mode or in dual mode. So in single mode that means the downloading slot is also the execution slot. That means when you download something you will erase your current firmware. That implies you need an external loader. That means the loader can be inside your application. But we also deliver an example. The second possibility is to have one image mode. That means you combine the secure and the non-secure binary into one firmware or one image with one metadata set. That means one signatures. So this is again something that you can configure. So I put in green what is configured by default in the package when we deliver it. We're still delivering a secure application which is just a secure lead blinking example. That means services that you can call from the non-secure application to just make a lead blinking. And we deliver for you also a local loader. But this time this local loader will need to have a secure and non-secure part. Do you know why? In fact remember here we've got a possibility of one slot. That means the local loader will need to write in the secure flash and in the non-secure flash. And to access a secure flash you will need to have a services to write in the secure flash. And it will be what will be inside the secure part portion of the application. The sbsfu will be admittable. That means you can update it. And it's rely on why modem in our example. The memory layout. So in the cage of single slots. That means remember the same slot is used for execution or for downloading. One image. That means we combine just this up to secure and the non-secure application in just one image. We've got our secure loader at the end. And portion of it will be in secure part. And the portion will be in a non-secure part. Local loader and sbsfu are immutable. Here I give you again the same picture as before regarding TFM with the sbsfu. We just have the sbsfu block block. We've got this local loader that is inside the privileged trusted. And also in the privileged trusted part just for the services. The lead blinking on your application. So as you can see local loader is not updatable. sbsfu is immutable also. Now about the package. As you can see in the cube l5 now you've got for the nuclear we deliver only the sbsfu example. And for the development kit we deliver the full TFM. For the hands-on that is following this presentation. I put for you the TFM on the nuclear. And I will explain what I have done in the hands-on. So if you just need a secure boot and secure firmware functionality. This is the cube sbsfu you have seen on other platform. sbsfu is for sure the packages that's more interesting for you. But if you want to have a full TFM then go there. On the top we've got some common parts that will be used by the sbsfu or by the TFM. So we've got the embed crypto that will be used inside the sbsfu boot inside the TFM sbsfu boot. Also in the TFM apply secure when you've got some crypto services it will rely on embed crypto. In the mcu boot you've got mainly the open source of the mcu boot. And that will be used by TFM sbsfu boot and sbsfu boot. In the trusted firmware you've got the full TFM. That means the middleware that's used in the TFM middleware application. On the nuclear so as I previously said here we just have the sbsfu. The folder linker you can find the memory mapping. So it's where you find two headers that's explained on where you can activate the different functionality and where you can set the size of the different slots. So quite interesting folder. And have a look please in the realme.txt at the top. Here you've got all the description how to compile, flash and set the option by to make this package functional. Then in the sbsfu boot you've got the secure the sources and you also have a realme.txt with some in detail implementation. Then we've got the secure application which is only a services secure gpu toggle. And you've got a non-secure application which is just an example which is quite similar with the xsbsfu one from the functional point of view. But we will experiment this after in the hands-on. The last one it's this possible sbsfu folder. Quite important so it's rely on why modem in our example but you can modify it to put whatever you want. And you've got a secure and non-secure part because here you will need to write in the secure flash. So that's why we've got this services that could be called by this non-secure application. Now for the TFM so it's targeting the development kits. I will say the architecture is nearly the same. This linker folder with a different activation of functionality and also the memory mapping. The realme.txt again at the top where you've got all the information to compile and to flash. Then we've got the TFM sbsfu boots. We've got the application secure. So in the application secure this time we've got all the TFM services plus the TFM core. And the non-secure application which is just a code example. And we've got this TFM loader. This time it's just a non-secure application and no need to write in the secure flash because all the download slots will be in the non-secure flash. If I do a quick comparison between sbsfu versus TFM. So what we have seen this morning the sbsfu have the same functionalities and TFM sbsfu. The security evaluation is CZP level 3 for this and we've got some key management services on L4. For the TFM we've got the boots for sure but we have all those security services and those ones are certified PSI level 2. So we achieve this certification on the STM32 L5 and I think we are the first company to achieve this level of certification. So it's level of certification with isolation level 2 also but no link between the certification level and isolation level. Here I put for you the useful link for sure. The first one is quite interesting and you will have many details about the TFM, the implementation and where are the different information on architectures. The overview of this application note is more a comparison between the sbsfu and the TFM and you also have or I put again the ARM and the trusted firmware link documentation. As conclusion I will say that TFM is a secure boot basically with secure firmware update capability but it also has many security services during the runtime and it's rely on a PSS standard defined by ARM. Open source project. It was targeting high OT system but you can be adapt to other system also. The STM32 L5 TFM implementation shows the usage of all the STM32 L5 security feature to achieve the PSI certification level 2. So this package should help you to achieve this certification if you want to do it but we also deliver for you a basic secure boot secure firmware update without the services if you need it. Thanks for your attention.