 Former confidentiality. One of the basic security concern is to protect the former accountant from reading to avoid stealing the firmware, copying the product, etc. SGM32 provides two levels of protections for this purpose. First level is RDP readout protection. RDP level one is mostly used. Second level is PCROP proprietary code readout protection. Of course, here we are mainly talking about external attacks. In case there is further concern about internal attack, meaning reading the former content from the code, then isolation mechanisms could be used, such as NPU, firewall, truzon, and so on. Protection through RDP. This mechanism is very simple to set up. Once firmware is loaded in flash, this protection could be activated either from programmer or from embedded firmware itself. There are two protection levels. Both levels will prevent the reading of internal flash from outside the chip set. RDP level one allows regression to a clean device. RDP level two, no more possible regression. There are some pros and cons of RDP level one. This level is very easy to test because you have the chance to go back to a virgin chip set. And the regression from level one to level zero involves an automatic flash erase. That means even though you can go back to level zero, but the confidentiality of the former is not compromised, because everything is erased in this regression procedure. This feature can be used for basic firmware updates through either JTAG, SAPD, or system bootloader. So the update procedure starts from a running device in RDP level one, and then you need to connect to the board and perform RDP level one to RDP level zero regression, and then you can download a new version of the former. But this update mechanism is not fully secured because the former is downloaded in clear. Only way to keep security is to perform these updates in a secure place. RDP level two has also some pros and cons. In this level, there's no more JTAG or system bootloader connection possible. Update is still possible, but has to be managed by the former itself. You cannot download another new version through the debug port. But that also means the level of security is higher comparing to RDP level one. And in this level, there's no regression allowed. You cannot go back to level one or level zero from level two. And to set up level two, it is as simple as setting up RDP level one. With RDP level one, JTAG and bootloader can be connected. This increased the surface of attack, but relatively easy to do for maintenance. With RDP level two, no access to the chip through debug port anymore. So attacks to retrieve the content of a flash require very high expertise and very expensive equipment. Maintenance, I mean, update of the former requires more code to be developed. Of course, STM32 is not part of the secure chip family. This is just general purpose MCU, so the level of protection cannot be compared to a secure element, for instance. In addition to RDP, former could be protected further using PCROP. Security can be compared with the castle with the level of protections. The PCROP brings the second level of protection in case first level has not been forced. PCROP brings protection against flash reading and writing. Even at RDP level zero, code is still protected. The only possible action is to execute the code. PCROP is also set up through option byte and can be used to protect a region of the flash. When RDP level one or RDP level two is activated, PCROP protects against reading of the code instructions. Only instruction fetch is possible when accessing the PCROP protected area. This is true not only through debug port, but also through the code. That means even the code itself cannot read the content of the code on the flash. Using PCROP also brings some constraints on the code development. The code should be compiled with specific compile option to remove any data access from the generated assembly code. This is going to be a compiler configuration. You can find some additional compile options in IDE. And the code generated is a little bit bigger than without this option. Apart from that, the code to be protected should also be isolated from the rest of the code. Meaning you need to put the code to be protected in a standalone flash page or flash sector. That is because the PCROP protection is in the granularity of a flash page or flash sector. So this needs to be managed in the linker configuration. And the PCROP region has to be activated only after firmware is programmed to the flash. For more details, you can find application note about PCROP in this link. If you see RDP1 and the PCROP doing a regression to RDP level zero, you can have the choices to keep the PCROP zones or to have the PCROP zones erased at the same time. That depends on the PCROP configuration in option bytes. This allows, for instance, to preserve the PCROP content and perform only the update of the rest parts. This mechanism could be used when you have some calibration data to keep, for example. And in that case, data have to be converted into some instructions. This is achievable thanks to some simple scripts. In combination with RDP2, PCROP areas becomes immutable. Up to now, on the topic of firmware confidentiality, we have addressed here only very basic firmware protection. But this level is enough in many cases and does not require significant investment. One main point not addressed here is the ability to update firmware while keeping the firmware protected at the same time. With these mechanisms, we can only ensure firmware is protected during execution on the field. If an update is needed, it has to be done in a secured way by dedicated people, for instance. This diagram explains the firmware confidentiality lifecycle. So the OEM developed their first version of the firmware. They deliver the firmware and transfer the virgin chipsets to the EMS. Then this first version of firmware will be programmed to the board and then with RDP level 1 applied. Then the device with firmware version 1 plus RDP level 1 protection will be transferred to the end user. After some time, OEM developed version 2 of the firmware, maybe with some bug fixes or maybe with some new features added. Then firmware version 2 will be delivered to maintenance office. In order to update the version of the firmware on the board, the customer needs to send back the device to the maintenance office. And technician will first do an RDP level 1 to 0 regression and then program the new version of the firmware to the board and apply RDP level 1 again. Then this device with new firmware plus RDP level 1 still protected will be delivered back to the customer. Now it's time to have a hands on for firmware confidentiality. The goal of this hands on is to show the different steps to develop the code and create the firmware binary, program the binary, set RDP level 1, use a working device, update the device using RDP regression and use the new working device.