 Bonjour et bienvenue à cette vidéo sur l'exemple d'isolation avec STM32-HEL-5 TRES-ZONE. On définit souvent le TRES-ZONE comme un mécanisme qui permet d'améliorer le hardware en software en deux extérieurs, le secure et le non-secure. Ce mécanisme d'isolation augmente le niveau de protection de nos assets. On usually gives this definition during sessions or training sessions on the result is source question. What should I put in the secure or non secure world? Can I put everything in the secure world? Why it increases the security? And please give me an example. The purpose of this video is to give you a short example and I hope it will clarify for you this isolation concept. So we use the STM32-HEL-5 in two configuration. TRES-ZONE not activated, that means no isolation, and TRES-ZONE activated. So as a reminders, when TRES-ZONE is activated, any IP or portion of the flash portion of the RAM could be assigned to the secure or to the non-secure world. The non-secure world can only access the non-secure world. Secure code or the code that is running in the flash secure can access anything. My concrete example is the HEL-8 monitor. So we've got a sensor, we've got a HEL-8 module, so it could be accessed remotely. If I just sum up how it works. A remote user can send a request, send me data. This one arrives through the RF module, he squares interfaces in our STM32. And then we've got the code in flash, which under this request. He would analyze it, if it's correct. Then he will get the value from the sensor through the SPI interfaces. Then we will encrypt this value, because it's a sensitive value and we will send it back to the remote user. We don't want somebody to have it, so we will encrypt it with a secret key, which is also stored inside our flash. And then we will return this value encrypted to the high square C, the RF module to the hand user. Now with a hacker in the picture. This one will also send a send me data request. But not a normal one, he will put some hack inside. When we will receive it in our code in flash, in fact we've got a weakness in this code. This code allow a buffer of a flow attack. I don't want to deal with such kind of attack during this training, it's too short. You can just have a look on the literature on our internet. This allow the injection of code in RAM. Our hacker found we've got a weakness in our code and inject some code. And the code injected will get the value from the sensor on jump to the step 5. So we will send the value in clear. That means the hacker could have access to the value of the iterate monitor. It's exactly what we want to protect. But if you cut a closer look to this architecture, we could imagine the injected code get a secret key from the flash because it's not protected neither. And send this value back, which is in a worse situation because the hacker have got our secret key and can decrypt all the communication. You can't tell me but we know there is a weakness in the under of the request. So the new request received too. Yes, because here it's simple code but imagine you've got a huge stack of communication like LWIP or something like that. You can still have some issue of such kind of issue. So now we will activate the choice zone. So we will activate the isolation. What should I put in the secure world and in the non-secure world? Basically keep in mind in the secure world you have to put what you want to protect. We want to protect. It was a trade monitor sensor on the value of the access to this. To the SPI interface for sure and the associated GPIO. In the flash, we will also split between secure and insecure. And we will put in the secure world the interfaces with SPI for sure. And also the capability to encrypt and the secret key. The secret key is also something you want to protect because you don't want anybody to have access to it. And now we will define only one single API for the non-secure world. The non-secure world can call only one API, which is get encrypted value. This one just return a value from the sensor or region encrypt. In the non-secure world, don't have access to the secret key to the value but can only ask to receive an encrypted value. In the non-secure world, I will put all other stuff. I mean the communication with the outside because here there is no secret. It's just functional, it's just some generic code and no secret valuable secret for us. If a hacker manage to access this, you will just see a communication stack. No, I will see interest for you. So this is our isolation definition now. So let's come back with our hacker. ECN is a hack request. It will be handled by our code which still have our weakness because we don't have discover this weakness yet. And we manage to inject on code. The code will be injected in RAM but the new request receive code is in the non-secure world. So we only have access to the RAM non-secure. So it was inside the RAM non-secure that the code is injected. And if this code tries to access the sensor, it will fail because we've got the isolation. This code which is running in the non-secure RAM can only access the non-secure world. So the only thing he can ask, maybe he can call the API get encrypted data but it's working as usual so it will receive an encrypted value and can do anything. So this is basically what I want to show you. Here you've got a concrete example of this isolation on how it prevents this attack. So as conclusion, I hope this example clarify for you this isolation concept and how it can increase the security level of your platform. Last point I want to understand during the line story, there is not only the treasure zone. We've got other isolation mechanism in our STM32 families. We've got the MPU, firewall and secure memory. The mechanisms are quite different and they don't protect exactly the same thing so please have a look in the reference panel before using them. I hope you like this video and thanks for your attention.