 I propose now to give you some details about the HUK. In fact, HUK is a generic name. In this product, we name it the root hardware unique key, AirHUK, so I propose now to detail its properties. First, the key size is 256 bits. This one is immutable and constant, so that means there is no way to modify auto-hair assets. It's a random value unique pay device and provisioned by ST at production level. And the last property is that this key is not accessible thanks debugging link or even by the embedded firmware. So the question now is, how can we use it? In fact, the root hardware unique key is hardware connected to the secure IRS IP thanks to physical private bus. The secure IRS is an IRS hardware accelerator with counter measurement against side-channel attack. I will come back later about this topic in this presentation. We have one root hardware unique key pay device. An IRS will never use directly this key to encrypt and decrypt data. It will do some key derivation from the root hardware unique key with two additional inputs, trust-tuned state and the key mode used by the IRS. Based on one root hardware unique key, the IRS is able to derive up to six key. Those one are named DHUK for derived hardware unique key. Now, I would like to give you details about secure IRS and how this one could be configured. The STM32 product already includes IRS crypto accelerator and in fact the STM32 U585 includes this classical IRS. But in addition to that, it also includes a new IP, the secure IRS. The secure IRS has been designed to be resistant to side-channel attack and I will detail those attacks in the next slide. The main side effect of this resistant is the performance decrease regarding the classical IRS accelerator. A side-channel attack attempt to gather information or influence the program execution of a system by measuring or exploiting indirect effect of the system or its hardware. Our secure IRS is resistant to single and differential power on electromagnetic analyzes and also on some differential fault analyzes. Thanks to this, the STM32 U585 is the first STM32 to achieve the PSA and CZIP certification level 3. The purpose of those certifications is to give you confidence in the security level of our product. Until now, I only talk you about the old hardware unique key. But in fact, there is an additional hardware key that could be handled by the secure IRS via a dedicated private bus, the boot hardware unique key BHUK. The boot hardware unique key is not a pre-provision key like the root hardware unique key. The BHUK must be generated by the embedded firmware and will be stored in the RTC backup register so it will be part of the power backup domain. Ungenerated and locked by the embedded firmware, this key can't be accessed anymore directly by the software but it can still be used thanks to secure IRS and this key is automatically erased in case of a tamper event. So now we can have a complete overview of the possible key source for the secure IRS. The first possible key is a key that is coming from the embedded software. The second possible source is the derived HUK which results from a derivation from the root hardware unique key. This DHUK will be different depending on the trezon state of your MCU when you use the secure IRS and the K-Mode that you are using and I will detail those K-Modes just after. The third possibility is the boot hardware unique key I've just described you before. And finally, the fourth one is the XOR between the BHUK and the DHUK. The K-Mode which allows the secure IRS to basically encrypt and decrypt data is a normal mode. If I come back to my innovative company example, a possible way to protect the assets for them would be to develop a firmware with this algorithm. At boot time, if we detect that the assets are in clear and flash, encrypt those assets with the secure IRS configure with the DHUK and replace the clear assets by encrypted assets in the flash. This will be executed once. Then on the field, when you need to access those assets, you just need to decrypt them from the secure IRS configure with the DHUK. Of course, this could be done for data but we could also imagine to do it for some code. You store your code encrypted in the flash, you decrypt it and execute it in RAM after. This is another possibility. A cryptographic recommendation is to use one cryptographic key for one purpose. We affin together the possible case source for the secure IRS but to extend those possibilities, SIRS propose some other key mode. Secure IRS has three key modes. The normal one, we already seen together, it's used to encrypt and decrypt data received from the MCU. But you've got the wrap mode. This one allow you to encrypt an application cryptographic key and also to decrypt it when needed but without expose its value. Then you've got the share mode, which allow to unwrap an encrypted application key and share this one with a classical iOS IP thanks a private bus. I will now details of different mode. First, the normal key mode. I will go quickly because we already seen it before. It's basically used to encrypt and decrypt data. We still have the four possibilities for the case sources. In this mode, the DHUK could have two different values depending on the trust zone execution state, secure or unsecure. Let's continue with the wrap mode. In this mode, the secure IRS will encrypt an application key using hardware security key. DHUK, BHUK or the XOR combination. The application will provide a key value to be wrapped. Then it will receive the encrypted value of this key. So finally, it's quite similar with normal mode. But here the key mode is different. So the derivation result DHUK will be different regarding the normal mode. The other difference is the case sources that are limited to the hardware secret one. IRS is able also to unwrap a key. That means to decrypt it but without expose its value. The application firmware will configure the secure IRS in wrap mode with a proper case source. And then will provide the wrap key in the data register. Once a wrapping task is done, the key value in clear is pushed in the key register of the IRS IP, which is a write only register from the MCU point of view. So the key value in clear is not exposed, but it can be now used by the IRS IP. At the unwrap key is now in the key register. Unbedded firmware will configure the secure IRS in normal mode on the case source as a key register. And then could encrypt or decrypt data. And in this configuration, the key value is never exposed. Let's see together a possible product life cycle using the wrap key mode. First, at production level, the wrap key need to be created. It's a kind of provisioning. Usually a random number could be used and as soon as this value is wrapped, this value could be erased. Then on the field to encrypt or decrypt your asset, you just need to unwrap the key and then to use it. And finally, at the end of life of your product, if you want to ensure that the encrypted asset can be recovered in any manner, you just have to erase the wrap key. But in fact, you can avoid the provisioning phase. If you unwrap a constant, this will generate a secret key that is stored in the key register and that can be used in a normal mode after. This will change slightly our product life cycle example. Now, no provision phase obviously. And on the field, you just need to unwrap the constant to encrypt or decrypt assets. But at the end of life of your product, you can't erase this constant. So you will have to erase all the encrypted assets. Let's see now the last possible mode of the Secure IOS, Shared Key Mode. It's quite similar to Wrap Key Mode. It allows to wrap unwrap key, but in this mode, the unwrapping key result is shared with a classical IOS IP. Thanks, Private Buzz. This allows the IOS IP to use a rapid key without exposing its value. Remember, the classical IOS IP has not been designed to be resistant to side-channel attack, but it allows better performance. So first, you will need to wrap the key in Shared Mode. It's very similar to the Wrap Key Mode. The only difference would be in the result of the key derivation of the root hardware unit key. Because remember, the key derivation input or the key mode, such as on-state on the root hardware unit key. In Shared Mode, when you unwrap the key, the result is transmitted to the IOS IP thanks to Private Buzz. Then, the IOS IP could use the unwrap key to encrypt decrypt data with better performance, but with a lower level of resistance regarding some potential physical attack. Though we reached now the end of this presentation, we have seen together how a protected Pre-Provision Hardware Unit Key could address some security requirements. The STM32U5 integrates this Hardware Unit Key in combination with a secure cryptographic accelerator resistant to side-channel attack. Those mechanisms allow us to achieve the IOS security level ever seen on a STM32 device, and that has been recognized by the PSA and CSIP certification level 3. Thank you for your attention.