 So let's start with the last part of this workshop. I will address one important point related to security, even if this is not a workshop dedicated to security. But this part has been changed, and basically, we are addressing the radar protection, which is used by nearly everyone. So we wanted to show you what has changed on this topic. First, we have a new mechanism for the protection of the code in the internal flash. And so let's see what has changed and what is the impact. So first, a little reminder about RDP protection on our legacy STM32, meaning all other STM32, basically. We have RDP level zero, which is the open state you get by default when you get the device. And it is in this state that you work in development mode. Then you have this RDP level one, where the flash is protected against readout. The debugger can still attach, and you can read the RAM content. Then you can regress the device to RDP level zero. And regression means that you erase all the content of the flash so that your code cannot leak. This state is mostly used by our customers because of this regression capability. And then we have RDP level two, where the device is locked in a... And we don't have any more debugger access, and we cannot go back. So the device is still able to run, obviously. If you have implemented an update mechanism, it can update itself, receiving a new firmware update, a new firmware through any communication link. But the device cannot be reopened anymore. This is the state of all legacy STM32. There was a small change on the STM32 U5, where you have the ability to have provision a key in the device that would allow you to regress the RDP level two to RDP level one, and then from one to zero. So this was the first step with allowing to have a better protection because here with RDP level one, you have still some surface of attack because you can read the content of the RAM, for instance. So this was the first step. And with H5, we started from this first step and went on to increase the security and improved this mechanism. So what has changed in H5? We have replaced RDP by product state. So this is basically the state, just renaming, but we have now more states. In both cases, it's an option byte that you program through a key programmer, for instance. For RDP, we had three values. So AA for RDP level zero, RDP level two was CC and any other value meant RDP level one. Product state, we have a value for each state. So there is no default value as before. And also something completely new in this SDM32 is the debug authentication feature. This is a feature that is accessible through dedicated access points of the JTAG. So as a JTAG or SWD, it is using open protocol, I would say, from ARM, which is called ADAC. That is available as a specification. And we use a password for the regression as we used to do for the U5. But this password is used only in the case of, I would say, legacy usage of the device. This means that you don't activate the TROS zone. In case you have more security requirement, usually you will enable the TROS zone to be able to have the isolation between secure and unsecure. And in that case, you have also a more secure way to open the device through a certificate. We will not address this case here, but more in the next workshop. So here, the goal is really to show you the minimum change you need to do, compare, for instance, to a F4 device, SDM32 F4. Just to show you the first product states. So now the product states are named. They have dedicated value, but we use a name to have them more, yes, useful. Dedicated for development is open state. Then we have a new provisioning state. This provisioning state is a specific state of the device where you can send provisioning files. So it is waiting in a dedicated state provisioning data. And two other states, the closed state and the locked state. There are some intermediate states, I will not talk about here, but they are more related to TROS zone enabled state. So here you need only to care about those states. So the closed state is a state where you are able to come back to open state. So this is in some way the equivalent of RDP level one. And the locked state is a definitively locked state. So equivalent of RDP level two. But the difference with RDP level one here is that in closed states, you don't have any more debug interface available. So this is an improvement in terms of security. So the regression is now controlled by the debug authentication. So coming back to the states. So during provisioning of the device, we will provision hash of a specific key. So hash is a cryptographic operation that changed the input in 256 bits, 32 bytes. Then you have the closed states where you don't have any more debug access. Then here, your device is ready to go to the field and is ready to run with its firmware. Then you need to take back your device from the field and analyze it. You have a way to reopen the device thanks to the key you have provisioned here. So you need a key programmer or equivalent that would implement the same ADAC protocol. And this programmer will communicate with debug authentication. So I will show you how it works later. And then the programmer sends a key. So the original key that was used for generating this hash and the debug authentication firmware will generate the hash of the received key and will compare with the one that was provisioned earlier. And then if they match, the regression can happen and the content of the flash is erased. So impact on the production process, compared for example, with the F4, you need to have this provisioning state. So switch from open to provisioning in the product state. Send a specific file to the device to have this key hash provision. So this is the main point of this demo to show you that there is something that is changing and impacting your production process. Now let's see how it works. I will show you this regression capability. We will use the trusted package creator that is provided together with the key programmer in the same package when you download key programmer. Now you have also this trusted package creator. So we will have an application firmware with a chosen disabled. So this use case is to be compared with a typical use case with F4 using RDP level one. We have a simple lead application and as we don't enable trust zone, we use a password for this debug authentication. So the different steps we have is that we need to create this provisioning state that we call OBK file. OBK means option byte key. This is something that implicitly shows that the key will be stored in the specific area. It's a secure storage that we call OBK. Then we will flash a land baking binary like your firmware. We will go to provisioning state provision the OBK file on the board. So the one that we generated here. We will move to closed state and we will be back to the original state. So let's start. Let me this interface. You have different point on the left. So here we have new H5 dedicated tab and we have OBK. So OBK is to generate the OBK file. Image generation and the certificate generation is for other security topics that we will not address here. So XML file, let's check. So I prepared XML file that actually you have one example in the firmware, in the cube firmware. And in this XML file, you have a content that is interpreted and actually you can see that we have a password. You can change the value of the password. You can see here the destination address. This is where the address inside the secure storage where you need to store this value. And here we have encryption disabled because we need to store this value and we have encryption disabled because we are in here. I display the board H563 which doesn't have hardware encryption. So here everything is ready. We will generate in a binary directory .OBK file. So generate this file and if I can show you here we have the OBK file that we just generated now and also another file that is generated together with the XML file is a password.bin. This file is the one you need to keep in a safe to be able to reopen your device later. Now we have created the file. We can go to a kube programmer so that we can see how it works. First I will connect to the device. You can see that well it's a flash is erased. So I will first program the... So I've prepared this iotoggle. So I program it and you can show you can show you with the camera so that you have a LED toggle. I hope you can see the toggling of the LED here. And now we have a programmer firmware. We will change the product state. So you can see here the different product states. So I show you open, provisioning, closed and locked. The two others here are not useful for demo. So here I changed to 17 provisioning. I apply. I will not provision D4DA because I have generated my own. So I don't do it. There is a warning that you should set DA config. So DA config means debug authentication config. This is the obeky file that I have just generated before. So here I'm now in provisioning state and you can see that the LED is not blinking anymore. This is because you have... We are in a state where we are waiting for provisioning files. So to provision the obeky file now, there is this tab that we have here where you have obeky provisioning tab. You can select the obeky file that was generated in the binary here, the one that we just generated. And we can see again the destination address, the size of the obeky and the fact that we do not encrypt it. And then we just have to provisioning. So here the provisioning is okay. We can now switch to close state. So let's go. Here we are in a provision. We are going to close state. So here it's important that switching to close state if you must have provision debug authentication key. If you go to close state without doing this, it's like you are in a locked state. So that's important to understand. So I apply to close the device. Yes. So here you have some warnings because the programmer tries to reconnect. But now we are not able to connect anymore. The device is closed. And you can see that now the LED is blinking so your firmware is ready to go to the field. No more, I try to connect. If I try to connect under reset, it will fail. No way to reconnect whatsoever. So come back to hotplug, connect. Nope, not possible. So the last part of this demo is to show you now the regression. So to do the regression, you need to go to debug authentication here. And there is a button discovery, discover. So the discover here is going through SWD in that case. But with a different access point, you can see the access port, sorry. The access port used for debug is one and the access port used for discover is zero. So it's a different access port dedicated to this feature. And here you can see that the device is in close state. So it could communicate with the device through this specific channel. And now we can select the password that we have generated when generating also the OBEKI. So this password that needs to be stored somewhere in your NSF. And you can press full regression and this will do the regression to the device. So you have here the regression that is done and automatically a QProgrammer connects to the device. And we can check here product state. We are now in open state. And the flash is erased. So this is what I wanted to show you. I hope it is clear. So I just showed you that how to provision a password and then to be able to do this regression.