 Hello and welcome to this MOOC about STM32-U5 CAID RDP. All the STM32 integrate security mechanism to protect embedded flash content. After a short reminder about this protection, I would like to introduce you this new CAID RDP mode. This mode allows you to control all the possible RDP level regression in a secure way. During this reminder, I will give you another view of the protection regarding the RDP level without and with trust zone. Then I will remind you the possible transition between those levels. Let's start with the RDP level 0 without trust zone. Here the device is fully open, that means the debug access is open and you can access S-RAM, flash content and all the IP registers in your system. In RDP level 1 without trust zone, any debug access will lock the flash on the S-RAM 2. Flash locked means it can't be accessed in any manner through the debugging link but also by the core of your STM32. If you remove your debugging link and do a simple system reset, execution from flash is still not possible. To unlock the flash, you will need to remove any debugging link and do a full power-on reset. In RDP level 1, access through debugging link to S-RAM 1 and 3 is possible and also to any IP registers in your target. The option byte could be modified and the embedded bootloader could be activated. In RDP level 2 without trust zone, your device is somehow closed. The debug access is deactivated, so you can't access any more from this link, any resources or your targets. But additionally to this protection, the option byte modification is no more possible even from the embedded software and the embedded bootloader can be activated that means you can only boot from flash. When trust zone is activated, we now have to distinguish secure and unsecured words and this for all the resources S-RAM, flash and also the register IPs. For the level 0, all the resources are accessible through the debugging link. RDP 0.5 is only available when trust zone is activated. This level prevents the access of all the secure resources through the debugging link. But be careful, in this configuration, you can only connect with debugger when the CPU is in non-secure state. And when trust zone is enabled at boot time, the CPU is in secure state. So if your flash is empty and you activate the RDP 0.5, you can't connect anymore to your targets. So if you lock your device in such a way, you can activate the embedded bootloader which allows to put the CPU in non-secure state and will allow to recover. But anyway, I would advise to always ensure there is a secure code executed at boot time that properly called the non-secure application before activated the RDP 0.5. RDP level 1 has the same protection as the RDP 0.5 but additionally, the non-secure flash access is not possible. That means all the flash content is protected, the secure and the non-secure parts. RDP level 2, the device is closed. Debugging link is deactivated. Additionally to this, option byte modification is no more possible even from the embedded firmware or you can't activate anymore the embedded bootloader. So we have described the different RDP level. Let's see now the possible level modification and the consequences. There is no specific restriction to increase the RDP level. You can jump from level 0 to 0.5 and to 1 then to level 2 and you can also directly jump from level 0 to any level. The regression from level 1 to level 0.5 imply the errors of the non-secure flash content. The regression from level 1 to level 0 imply the full flash mass errors. On the device lock in RDP level 2, you can change this level anymore. On STM32L5 family, direct regression from 0.5 to 0 was possible. This is not possible anymore on STM32U5. From RDP level 0.5, you must first increase to RDP level 1 and then you can do the regression to level 0. So after this short reminder about the RDP, let's talk now about this new feature, U5cade RDP. RDP transition previously described is still valid on STM32U5 and can be used as it is. To activate the RDPcade feature, you will have to provision keys in protected option byte. The option byte access rights are right only. That means you can write in the option byte but you can't read them. First, you can provisioning the OM1 key. This one allows to control the RDP regression from level 1 to level 0. In other words, you need to know this K-value to be able to trigger this regression. We have a second possible key, OM2 key. This one allows to control the RDP regression from level 1 to level 0.5. And sharing on the cake, this one also controls the RDP regression from level 2 to level 1. In such configuration, the level 2 is no more a final state. Only if you know the K-value, you can reopen a closed device. So to sum up this functionality, it's a kind of password-based RDP level regression. We have two possible keys, OM1 key, which control the RDP level regression from level 1 to level 0. The OM2 key, which control the RDP level regression from level 2 to level 1 and also from level 1 to level 0.5. An important point, those values only control the capability of regression but doesn't change the protection of the flash content regarding the legacy mode. Let's talk now about key management. The keys are statically stored in a protected option byte. Once written, those key values can't be recovered from the device. But you can check if a device has been provisioned, sunk the OM lock bit in the flash NSSR register. Let's check now what are the provisioning rules for the OM1 key regarding the current RDP level. Remember the OM1 key controls the regression from level 1 to level 0. If my target is in RDP level 0, I can provision errors and modify the OM1 key. But if my target is in RDP 0.5 or in level 1, I can only provision the OM1 key. Impossible to delete or modify an already provisioned value. And finally in level 2, I can't do anything. Erasing a key consists in settings only 64 bits to 1. Remember, if you erase a key, you are in RDP legacy mode. That means the regression is always possible. Let's check now what are the provisioning rules for the OM2 key regarding the current RDP level. Remember OM2 key allows control regression from level 2 to level 1 and from level 1 to level 0.5. If my target is in RDP level 0 or in level 0.5, I can provision errors and modify the OM2 key. And finally, if my target is in RDP level 1, I can only provision the OM2 key. Of course, in level 2, I can't do anything. To ease the key management, STM32U5 integrates a 32-bit device-specific ID. This one is provisioned by ST and can be reached through GTag in all RDP levels except level 2 if you are in legacy mode. This value could be used to associate key values with STM32 or it could be used as a part of a specific cryptographic scheme to find OM keys value. Let's imagine now you have finished your product developments. You have flashed your firmware, you have provisioned the OM keys and you have set the RDP level to level 2 because you want to protect your product as much as possible. You sell your product all over the world and suddenly on the field, you've got an issue with one of them. This was sent to you maintenance services and you will need to reopen it. So what are the different steps to be done here? First, you will recover the device ID thanks to GTag connection. Then, thanks to this value, you will recover the OM2 key value in your internal database. Then you will ship this value through GTag. If the key value match, the RDP regression is automatically done and then a power on reset is needed. If the key value mismatch, you need to do a full power cycle to do a new trial. For the RDP regression from level 1 to level 0.5, it's slightly different. The first step is the same, but when you ship the OM2 key value, this one is only stored internally. Then you will have to request the RDP regression to level 0.5. This will trigger the comparison with the OM2 key and if the value match, then the regression will take place. Associated to this regression, the non-secure flash is automatically erased. Finally, let's see the regression from level 1 to level 0. The first step to recover the GPID is the same. Then you will ship the OM1 key value which will be only stored inside the STM32. Finally, you request the regression to level 0. This will trigger the comparison with the OM1 key and if the value match, the regression will take place. Associated to this regression, the complete flash content is automatically erased. If you are using the U5 RDP legacy mode, before any RDP change level, I would recommend to ensure the STM32 has not been provisioned previously by anybody. For this, you just need to check the OM lock bits inside the flash and SSR register. The other possibility is to erase systematically the OM keys. Some useful documentation with the reference manual of the STM32 U5 of course, but also the application note 5347, which describes fully this feature. We have reached the end of this presentation, so as conclusion, STM32 U5 still has the RDP protection mechanism with legacy lifecycle of course, but it brings an improvement of this mechanism with the key features. This mechanism allows you to control in a secure way the RDP regression from any RDP state, including the famous RDP level 2. So now I propose to switch to the hands-on part of this MOOC. Thank you.