 So, let's talk now about the STM32H5 scalable security. In this part, I would like to introduce you all those new mechanisms that have been introduced on the H5. We have a new temporal isolation level. We have a real secure storage coupled with this temporal isolation. We've got those product states that we've already discussed in previous parts, debug authentication, and this embedded secure boot with secure firmware update capability called STIrot, which is a raw secure boot. And we also are ready to use code example of two-stage bootloader in open source. So, you can use and combine all those mechanisms to build your own security. In this part, I would like to quickly give you an overview about this temporal isolation, and some information about the secure storage, the product lifecycle, the different secure boot paths that are supported by our tools, and the STIrot, which is some detail about this one. Let's start with the temporal isolation. What is a temporal isolation? It's a protection that evolves during the code execution. The HGPH5 temporal isolation on the name is HTTP. The principle is two portions of user flash that could be hidden until the next reset. So, when you are booted at reset time, you are on HTTP level one. You can define some options by a portion of the user flash. The code will be executed in this portion, then you can call an API in the RSS services. This one will increase the HTTP level. And this portion of flash disappears until the next reset. That means it can't be accessed anymore in any manners. Then, thanks to the flash register, we can define a second portion of the user flash. On again, the code will be executed in this portion. We can call a RSS services. It will increment the HTTP level to HTTP level three. And the second portion of flash disappears. Two portions of flash disappears. Doesn't make you reminding something? Two-stage bootloader. So, in fact, this mechanism with two portions of flash that disappears has been designed to address two-stage bootloader architectures. You could imagine you have the first-stage bootloader defined in this first portion of flash, a second-stage bootloader, and after each execution, we will increment the HTTP level and make disappear the code. Let's talk now about the secure storage, also named OBEKI, for OBEKI storage. Okay, secure storage, OBEKI storage, that means you can store also some data, not only keys. So to give you a definition of the secure storage, a specific area in a system that can be provisioned securely, that are isolated and can be accessed only by auto-race part of the system. Data can't be extracted from one system to be reused on another system. On the STM32, we have a real secure storage named OBEKI storage. It's the first product that got this functionality. The data stored are protected from temporal isolation, I just described this protection before, true zone MPU isolation. Optionally, those OBEKI's are encrypted and thanks to hardware unique and a monotonic control. The option by is a specific storage in the system flash, so it's not part of the user flash. Total storage of this one is 8 kilobytes, and it has been split into five predefined areas corresponding to HDP level 0, HDP level 1, HDP level 2, HDP level 3, secure and non-secure. So there is a combination between the temporal isolation and the secure storage. So on HDP level 0, everything is accessible, HDP level 1, OBEKI level 1 disappears, level 2, level 3, and regarding the secure and non-secure, those both can only be accessed in secure mode. But we can have some dedicated part for the non-secure issue, do a regression that means if you remove all the non-secure part, only the non-secure part, OBEKI will be removed also. What is not detailed in this part is how those key could be encrypted. The encryption of the different OBEKI is different depending on the level. That means not the same key that you use for each one. The key used for encryption of those one are using the hardware unique key. That means unique per device. But also there is a combination with a monotonic counter, each time you do a regression or a partial regression, then it will change the key encryption. So really quite secure configuration. So if I combine the both, temporal isolation and secure storage, you can put the first stage bootloader in this first portion of flash protected, second stage bootloader. So you are booting in HDP level 1, the first stage bootloader will check the integrity and the authenticity of the second stage bootloader, so on the OBEKI level 1. Then you will code the RSS services increment the HDP level, then the second stage bootloader will check the integrity and the authenticity of the application. Thank the OBEKI, which are stored in OBEKI level 2. Again, it will increase the HDP level, and then it will load our application, which will be executed in HDP level 3. Provisioning of the OBEKI should be done in a dedicated product state, which name is provisioning. A dedicated provisioning mechanism is implemented. And programs just need to send a binary file containing the key with a predefined format. We've got a tool to create those files, which is named packet trusted creators. So you need to give as input what you want to store our key. Again, I wrote key here, but it can be also some data that could be used by your application. It's up to you to decide what you want to put there. It's a secure storage. Then you need an OBEKI config file.qxml, which describes the destination address, so at which level it will be provisioning. And if the encryption is done or not, because it could be activated or deactivated, it's just a matter of level of security you want to achieve. And then you will use Q-Programmer with your target in a provisioning state. Life cycle. This was already introduced a little bit in the workshop previously. Main addition regarding the path of provisioning state that is dedicated to provision the secure storage. The closed state and the locked state only difference is the inability to connect to debug authentication in lock state. And we have the debug-opening sub-state, which allows to reopen the debugging link. The regression principle is exactly the same that on other SGM32. The different possible states open. That's mean fully open. You can do whatever you want. You can connect with a debugger and access all the resources. In provisioning state, the only thing you can do is to provision the OBEKI storage. You can't execute code from the user flash on the channel things. It's really dedicated to this. Dresden close is when the non-secure is still open and all the secure part is closed. It has been used for the secure manager, but it could be also used by you if you want to split in your team from a secure team to a non-secure team. But those are not final states. A real final state is closed or locked. I call final state, I mean a state of your product on the field. In the case of close, it's a final state, but we have the capability to reopen the debugging or to do a regression. This has been detailed in the previous part. Lock state, it's a final state without any reconnection possibility. It's up to you to decide which one you want to use. I gave you here some equivalent with ADP level and the different transition possible. Remember, it's always good in provision to provision the debug authentication access. If you don't have the DAQ, no possibility to reopen or to do a regression after. This is the main difference regarding ADP level that we've got previously. Regarding the regression, you can do it from provisioning, I wrote provision just on close. You've got the capability to do a partial regression or a full regression. From lock state, you can do anything. What happened or what are the details about those non-secure regression or regression? On the partial regression, what's happened? The non-secure flash code is erased. The OB key, HDP level 3, non-secure are erased. And there is this epoch counter that is incremented. This one, which is used to generate a specific key to encrypt the secure storage. That means after each non-secure regression, encryption of non-secure OB key storage will be different. Regarding a full regression, in such case, everything is erased. The complete content of the OB keys, the user flash, secure and unsecure. And we have a second epoch counter that is incremented. Now let's talk to you about the secure boot path. Just naming convention, but I think now you are quite familiar with this. The two first letters indicate the owner of the component. It could be ST or OEM. Y is either key for immutable, it was a first stage bootloader, U for updateable, the second stage bootloader. And Routers test often stands for secure boot. So the different possibilities you can have. STI rot, the ROM bootloader, which is available on H573. The ST UROT that is a second stage bootloader from ST, which is only delivered in the context of the secure manager. But it was included in this use image and you don't see these details. But after you can have your own implementation of the first stage and second stage bootloader. It will be OEM IROT, OEM UROT. And we provided example code for this, based on MC UBOT. Regarding the H5 boot path, configuration is mainly done thanks option byte. Trezone enable or not, boot UBU for unique boot entry. And also some option byte, non-secure boot address and secure boot address. Now I will details depending on the different family or product in the H5 family, the possible boot path. For the H5 0x, there is no Trezone. So just a unique boot entry to NS boot address option byte. We have some code example of one stage bootloader for OEM IROT. Frankly speaking, a second stage bootloader regarding the size of the flash is just hypothetical because the size of the flash is too small here. So we've got an example of based on MC UBOT, which name is OEM IROT that launched just an application on this product. Now if we are talking about the family H5 6x, here we've got Trezone but we have no crypto accelerator and no STI ROT. Why no STI ROT? Remember STI ROT is certified CZIP and PFR level 3, resistant to some physical attack which rely on some crypto accelerators which are DPA or side channel attack resistance which are not present here so we don't have any STI ROT here. But you have the possibility to activate a not Trezone and to have your own implementation of first stage and second stage bootloader. Again, we deliver code example for this. Only one stage bootloader example is available. And finally with the H5 73, here you've got all the possibility because you've got Trezone, you've got the crypto accelerator and you've got STI ROT. So depending on the unique boot entry, you can either use your own implementation of first stage or two stage bootloader, but you can also rely on STI ROT or you can use just STI ROT to launch your application or to launch a second stage bootloader. What is supported by Cubemix? All those configurations. The first one is one stage bootloader where you are, I would say, responsible for the secure boot and secure firmware update capabilities. Or you can use STI ROT to launch a second stage bootloader or you can have STI ROT plus secure manager. That means STI ROT plus STI ROT plus secure manager. Here I want to sum up all the security features available depending on which product. On the H5 0x, you still have HTPL protection. Regarding the debug authentication, you only have password. That means you can only control the regression thanks to password. But you don't have the capability to reopen the debugging link to do real debug your application. This is not available on this platform. You don't have neither any secure storage. On the H5 6x, you've got the HTTP level protection through this temporal isolation. You've got the OBK storage and the provisioning mechanism. Regarding the debug authentication, if you activate TrueZone, you have certificate. That means the capability to reopen and debug your application even in a closed state. While if you don't use TrueZone, you are only the capability of password control and this means only regression. That means if you want to have the capability to reopen to debug something, you need to activate TrueZone. And finally on the H5 7x, 3x for amendments, you've got everything I would say. You've got also the STI ROT and you've got the secure manager. On those two last breaks are PSA, CZP level 3. Unrequired to have TrueZone activated. This is an important point to keep in mind. If you want to use STI ROT just to load your application, at least you need to activate TrueZone. Now let's give you some details about STI ROT. STI ROT is the Immutable Route of Trust. A secure boot code with secure firmware update capabilities. The code is basically based on MCU boot. And we add it inside some content measurements against a board-level attack. It has been what will be certified as PSA level 3. So which is a guarantee of our business against a board-level attack. To activate it, it sends an option byte bootUBU but it requires to have TrueZone enabled. And you need to provision two specific things in the OB key, HDP level 1. One file or data concerning the configuration of this one. And the key that will be used to do the authentication and the decryption of a new firmware. You also need to provide to provision some zero initialized data that will be used by STI ROT to check or to store the current version installed on the product. So again here it was a CC key that is used for authentication of the application. Your application could be full secure or could be secure plus non-secure. But it was only one image for the both. That means you have one signatures for the application secure and non-secure which are concatenated together. Regarding the firmware update, it was a dual-slot setup. That means you have an active slot on a downlink slot. So application can use almost half of the size of the flash but no more because you need to have the same size of download and execution slots. Regarding the firmware loader, how you will get a new version. Either you can implement it in your application but you also have the possibility to jump to the embedded bootloader, the system one, not the secure one, which allow you to download the new version and this is what I will do in the next hands-on. So as I previously said, one image for secure and non-secure application only. So in the Qube H5 you will get script and code example for this one and it's also supported by Qube MX. So I propose in the next part to do an hands-on and show you how we can create an application that will be launched by the secure manager and that could be updated by the secure manager. Thank you.