 So now let's add the secure firmware update services. So this is the main detail about this. We will need to modify kubemix to have these new services and we will use kubed and modify the application. To add the firmware update capability in our application we will need to modify it to have the capability to download a new firmware. This new firmware will be delivered encrypted and signed or sent encrypted and signed from the PC. And then we will use four different PSI API. The first one, PSI firmware update write, allow to write a new firmware in the downloading slot. Then we've got the PSI firmware installed. That means we have received this new application and we want to trigger an installation. Then we need to trigger a reboot because remember it will be the second stage bootloader, STU write that will detect first this new application. And then we'll decrypt it, check the integrity and authenticity and we'll install it. And then we have the last API which is named PSI Firmware Update Accept. This API should be called by the new application installed at its first execution. It's been okay. I'm running well. Everything is okay for this new application. If the new install application doesn't call this API and there is a reset, we will roll back to the previous version of the application. It's a way to ensure that this new application is running well. So it's up to you to have fine criteria to check if your application is running properly and to accept this. Once you have accepted this version, you can't roll back to the previous one. So let's check together the secure firmware update algorithm. On the PC, we've got the timestamp event version 2. We will use trusted package creator and also an OM key, that means new keys that will be used to encrypt but also to sign the binary. Once we've got a version encrypted and signed, we will send it to the user modem to our application version 1. This one will call the PSI API PSI Firmware Update Write. And the version 2 of our application encrypted and signed will be write in the downloaded area. Then our application will request the installation and finally request the reboot. So what happened during this reboot? The STROT, the second stage bootloader, will detect a new firmware in the downloaded area. It will check integrity and authenticity of this one. And if it's okay, it will exchange swap the content of the downloading area with the active area. That way, when we execute this new version, we can check if the accept is called and if the accept is called, we finish the installation. If the accept is not called and a reset occurs, it will roll back to the previous version. This swap mechanism is done sector by sector and is, I will say, resistant to any power loss or reset during this mechanism. It's inspired for MCU boot and you can find some documentation on the web about it. Though after the reboot, we've got in the execution slot or non-secure area the timestamp event version 2 and we still have the version 1 in the secure part downloading. Then we need to accept. On exception, the version 1 will be deleted. So let's come back to Qubemix, add the requested secure services and add the source of modification needed. So let's come back to Qubemix. Still in the secure manager API, so it was in the middleware and software. Here, regarding the services, we already have done the cryptography previously. We're just in and now how we had the firmware update. So just click on this one. Another thing we need to do is to add the CRC IP activation, which is used by the one modem protocol that we will use to transmit the new version. So I can close this category and go in the computing. In the computing select CRC, just put it in the non-secure context on activated. This is all what we need to do with Qubemix. So generate the code. I will close and now I will come back to my Qubemix ID. So here I need just to refresh my project. So again, click on the project, non-secure, right click and refresh. I will need to drag and drop some new source files from the material I deliver to you. So if you go still in the workshop on zone material, in a timestamp even detection, project page files here. From the include files, I would like you to take the update underscore firmware.h on ymodem.h. And I will drag and drop them in the include folder. I copy the files. And this is done. You can check it. ymodem update and in a similar way we go back in the source folder. And here you will take update firmware.c on ymodem.c on drag and drop them inside a source file. Source folder, sorry. I copy it and now I have to modify slightly my code. So as you can see, we just need to add the include update firmware on the check update request in the while one loop. So if I come back to my main.c and I will just copy past this code updatefirmware.h, just this include. And then I will just add a check update request in the while one loop. Okay. Then I can save. I can then compile it. And again, after the compilation, you can see that a possible script is code with a TPC success. And I would like to give you some detail about this possible script, what is done there. So I would like to give you some detail about this possible script. You will use a trusted package creator, which is a tool that is delivered in the same package at STM32Q program. As input, it will take your binary of your application and one key to generate the signatures. One to check the, which allow to check the integrity and the authenticity of your firmware. And one encryption key, which allow you to ensure about the confidentiality of this firmware. And then you will generate two files, one in a bin format on an X format. This binary is encrypted. And there is also the metadata with a signature which allow a secure boot to check integrity and authenticity of this firmware on the decrypted. The second format is generated and ensure that if you want to flash it, it will flash this binary in the downloading slot. While this binary has been, I would say, generated to be executed in the execution slot. Where does key come from? The crypto scheme that is used here is elliptic curves. For the signatures, it was ACGSA P256 and for the encryption, SAUS P256. The key has been provisioned at the same time than the secure manager. If you have a look in all the logs of the installation of the secure manager, you can find the details about them on how you can change or regenerate this key to personalizes. Because for sure, for your product, you will need to use your key for the encryption, but also for the signature generation and signature check. So let's flash this application with now all these firmware update capabilities. So I right click on the project, debug CC++ application. And if I check my data, we can see now we've got a new menu somehow. Or we invite us to press one to trigger a firmware update. So if I launch my application, sorry, here, if I press one, my firmware is now waiting for a new version of the application. So let's create a second version of this application where we will just change the printf. So if I come back to QBID, I'm stopping the debugging. And here, I just changed version one by version two. So let's compile it. And again, the possible script will be executed. So I will have those firmware sign and encrypt generated. And it was this one that I will send a Y-modem protocol. TPG success. Now if I come back to my error term, I will go in the menu file, transfer Y-modem send. So if I go in my hands-on folder, my timestamp event detection application, I've got a binary folder. And here, I've got the two files I told you before. So the encrypted and signed version dot bin on the dot X. With a Y-modem, we will use a bin format. So please select timestamp event detection non-secure and encrypted sign dot bin. I open it. So downloading is ongoing. And once the transfer is done, you can see an installation have been triggered. Let's check together exactly what happened inside our application. So we've got here the version one installed. And here are the different traces that you have observed. First, when we have finished or when we receive a different packet, we will use a PSA firmware write. The timestamp event version 2 will be write here in the downloading area, still encrypted with the signatures. Then we will request a firmware installation. That means we have finished to download this version. And you can see that the downloading slot changed from image and define to image candidate. This is just a status of this slot. The next step, we will trigger a reboot. What happened during the reboot? Remember, at startup, STU wrote check the downloading slot. You will find a new version. You will decrypt this version and check the signatures. If this one is correct, then you will swap the active on the downloading slot. I mean the content of the slot. When this is done, installation is nearly finished. The last step, I would say would be the firmware accept. You remember this one? But just about the validation is not needed here. Why? It's because you remember we have downloaded the version one with the debugger. That means without the metadata. So there is no possibility for this application to check integrity and authenticity of the version one. So this is considered as there is no image at all. So here we keep the version two as installed. And because we have nothing to roll back. So what we will do is to create a version three. And we will downloading also with Wi-Modem protocol. So with the metadata I mean encrypted and signed. And that way we will have in the execution slot and in the downloading slot, completion with signatures. And in such configuration, the firmware accept will be needed. So let's do this now. So if I come back, I will create a version three and we'll compile it. Possible is done. I come back to my Wi-Modem. And in the version two, I will trigger a new firmware installation. File, Transfer, Wi-Modem, Send. Here I still need to go to my project. And my hands-on timestamp event detection binary. And I will select the bin format. And this time I will install the version three. And in such a context, this time we will need to have the firmware accept to be cool. And this is already implemented. So you can see that just after the reboot in the active slot, we've got some pending install. That means our application is ready to be installed, but it's not completely done because the accept have not been called. And in the downloading slot, we also have an image pending install. That means an image with its metadata. So if the accept was not cool, then you will go back to the previous one. But here, between this line and this line in the code, I called the PSA API accept. So if I come back in my presentation, you can see the PSA firmware accept is just called at this step. On doing this, we finish the installation of the version three. If you want to have further details, I will say about those PSA API on information. So you can check the implementation in updatefgmware.c. But the different slots, I will say value possible, are defined also in the wiki. So it's the first time that I refer to the wiki. It's really where you can find a lot of documentation about STM32 H5 security, secure manager, and such kind of things. I will deal with this also in another part, but please remember this. If you want to check the implementation in the updatefgmware.c, you will see that the PSA API here are quite simple. Nothing really complicated. Just accept, as you can see. It was not on this line, but the next one. When I reboot, if I found that in the active slot, there is something that pending install, I automatically accept. So it's really straightforward here. So everything is in place. Our application, timestamp even detection, has encryption of data, have firmware update capability. But remember, we are still in true zone closed. So that means that each boot, we don't really check the signature of our application. Because we still want to have the capability to download a new firmware with an AD and such kind of things. So it's just, I would say, a hook to allow a developer to use a secure manager without any constraint about the signature and such kind of things. But as everything is in place now, we can go and close the device. And on the device is closed. That means you can connect, I would say, without authentication to the target. And at each boot, the signature of your firmware can be checked. That means the integrity and the authenticity of this one will be guaranteed. So for the moment, we are in true zone closed. That means the GTAG is still open on this part. And we will move to this product state, which is closed to an equivalent to AGP level 1, if you remember this. We've got still possibility to reopen the debugging link. We'll deal with this in another part. But now the integrity and the authenticity will be checked at each boot. So let's load now Q programmer to modify this option byte. So the first thing to ensure first is to change the mode. Here you should be in hot plug mode. Because you remember we can't connect under reset. At the reset, the MCU will boot in secure mode. And you are not allowed to connect in a secure mode. Only the non-secure part is open. So we will be in a hot plug. I connect. I got some error that I read here. This is mainly due to the fact that on these tabs, it tried to read the address 8 million, which is a secure location on the flash. So we can't read it. But I managed to connect. Now I will change the option byte. And in the option byte, we've got the product state. And the product state for the moment is A6. Trust zone closed. Debug partially open, only non-secure. Let's move to close. That means the debug is disabled. But regression is still possible. Don't move to lock state. Lock state is a final state. You can't reopen at all your device and you can't do a full regression of it. So for us, we will select 72. Close state. And then I will apply. Don't be afraid by the error pop-up you will have now. Because by default, as you can see, Kube programmer tried to reconnect. And when you reconnect, he will face for sure issue because we have closed the device. So first we have lost the connection. Then he tried to reload option byte that has failed. Then his style is still some other errors. And finally, he failed to reconnect. Because we have no capability without debug authentication to reconnect to the device. But if I check still with my turret term, as you can see, I press reset. My application is working fine. And you notice also the download slot image undefined. That means on the installation I've been complete. The previous version I've been removed from the downloading slot. If I press the blue button, I still have my event detection with encryption. So now your application is ready to go on the field. In the meaning that we have closed the device. So you can't reopen it except if you have got specific keys or certificate. You've got firmware update capabilities, the encryption of your data, which is secret somehow. So we have finished our application. Conclusion to this part. We have seen that PSA API is somehow quite simple to integrate and to understand. Simple to integrate, since our ecosystem which integrate everything for you. And you have seen that secure boot with secure firmware update are now really accessible. All the complexity is handled by the secure manager for you. About our 12 security function, you can see the additional one we are able to achieve now. Conclusion of the secure manager. This is a full certified solution for you. PSA and CZip Level 3. And it's completely integrated in the STM32 ecosystem to made the developer journey quite simple. You have PSA API which allows to access some secure services and you have the capability to pre-provision your secure storage. That means inject your secret in a secure way during the installation on production line. The secure update is fully managed and once it's made you just need to take care about how to download a new files. Secure manager features to go further or to give you more details. We also provide on this device two certificates signed by ST which allow an IoT authentication. There is two cloud packages, one for AWS, one for Azure, which demonstrate how you can use all these features. That means we've got these packages with the secure manager and all the user applications to register on IoT. Regarding the secure modules, it's a dedicated isolated secure application either to extend your application or it could be a third party. For this you need a specific development kit which name is SMDK and you need to sign a license for this. All the updates is managed individually by STUROT. I think you have seen this just before. Regarding the resources, again I point out on these wiki portals which is quite quite quite exhaustive in terms of information about the secure manager principle but also on all the STM32H5 security features. Thanks for your attention.