 Now we come to the last hands-on for the bootloader. This will be a bootloader that will be able to authenticate the application. Again, in this hands-on we're going to use the same application from previous ones, no change on that. And for the bootloader we're going to build another project of bootloader with the capability to authenticate the application firmware. We will also run some hostPC tool to build a binary with bootloader application and its metadata. So this metadata will include all the necessary information for the bootloader to verify the authenticity of the application. And we will also explain and observe the application firmware verification procedure in the bootloader before jumping to the application. That procedure includes the checking of magic number, the signature verification of the metadata, computation of the firmware hash, and the comparison of the computed digest with the hash value coming from the firmware metadata. How do we board and software tools wise? That's similar to the previous hands-ons except that we will need to use XCube crypto library in the project this time. And actually if you have made the hands-on for the firmware protection you should have downloaded the same thing. Just make sure that you downloaded the latest version of the patch of crypto library package which is version 3.1.3 because this one includes the support of G0. Again, we will keep using the same application project, no change on that. You can keep using whatever you have previously. And for the bootloader project we will use this G0 BIOS.zip file. You can get the project file from this one. And we will also use the tool from host to folder. We will use this script to generate the binary with firmware metadata. Metadata includes hash, signature, magic number, and so on. In case you don't have an ECC key pair yet then you will need also to run this open SSL tool coming from the X2 folder to create the ECC key pair. And also you need to run the preview.bat file to convert the ECC key into a data array to be included in the source code. Before moving on let me explain a little bit of the data structure of the firmware metadata. So at the beginning we have 128 bytes reserved for the firmware info. And that info includes 4 bytes of magic number, 4 bytes of firmware size, 4 bytes for the firmware version, and 32 bytes of the firmware hash. And then the reserved bytes are not used. This is just to make sure that the metadata consumes up to 128 bytes. And then after that this section of the data will be used to generate the metadata hash and then the ECDSA signature. So that is the overall data structure of the firmware metadata. This flowchart is just to give you an idea of the firmware verification procedure that is included in the bootloader. So the first thing to be checked is the magic number. If magic number is correct then the bootloader will compute and verify the metadata hash. If the metadata hash is also correct then the bootloader will do a signature verification of the metadata itself. If that is also okay then the bootloader will also compute and verify the application from our hash. If everything goes fine then the bootloader will jump to the application. If anything goes wrong within those steps then the bootloader will go into error handling procedure. Now you have an idea of what we are going to have. So let's see it in the practice. Now this is the last handsome on the bootloader. So this one we are going to use the same application, no need to change anything for the application. And for the bootloader we are going to add the firmware authentication before jumping to the application. So we will add this capability to the bootloader. So the project that we are going to use this time is this GZero underscore bios. Meaning this is a bootloader with authentication. Inside this folder there is supposed to be a cryptographic folder. This is something that you need to download from ST website. So make sure you downloaded CryptoLibrary especially this latest version of the patch. This is patch CryptoLibrary version 3.1.3. So inside this one you will find GZero folder. And in the middleware folder ST you will find this SDM32 cryptographic folder. Here you have the library and include files for GZero. So make sure that you copy this folder to your project folder. Otherwise your project won't view. And we can take a look at the source code again. So in the main.cfile in the main function we have something similar to the previous project. But before jumping to the application there is an extra function call to verify the firmware. So we can go inside and see what is done there. So in this function there will be several steps to check the firmware. As we explained in the previous slide. So this firmware verification will check the magic number. Check the magic number. We'll check the metadata hash, the signature of the metadata. And then we'll check also the firmware hash. So that's several steps for the firmware verification. Okay in case anything goes wrong during this firmware verification procedure. The software will go into a fatal error handle. So again we are using ECDSA for the signature verification. So that means there will be a public key required to be embedded in the software. It's the same way that you can generate the ACC key as we previously mentioned. So first you can use OpenSSL, which is included in the X tools inside hos and the score tools folder. And run this command to generate a ACC key file. And then you can also run the pre-built .bat file with parameters. Giving the ACC key file as well as the folder where you want this header file to be generated. So we will use the same ACC key, but we need to generate the header file because this is the old one. We have already modified the ACC key. So I will generate another header file to be put in this folder, let's say. So now this content of the header file is changed. So this is the new public key that we will embed in the software. And then we can make a build. So we can make a build. Now we have the binary of the bootloader, but then we will also need to generate a binary to have the signature, to have the header valid metadata for the application. Otherwise, if you just program the two binaries to the board, it won't work. So we can have a try. So let's say, okay, flash is empty. Make sure there's no write protection on the board. No PCROP applied. No write protection. Okay, we can download this new bootloader. And we also need to download duplication. This one to address 8-2. Okay, we can have a look at what will happen this time reset the board. So from the print message coming from bootloader, you can see that right now we don't read any valid data. So magic number, former size, everything is FF. So of course the verification will fail and we will enter this fatal error handler. It's just add this loop. Okay, so the next thing we need to do is to generate a binary with valid metadata. So this metadata includes magic number, version, former size, former hash, and also the signature of the metadata hash. Okay. For this purpose, we have also a post-built, a post-built, that script. And we can take a look at what this script is doing first. So this is a script that we are going to use. So this script expect two input parameters. The first one is the bootloader binary. The second one is application binary. Again, this script will assume the key file to be named ecc.key and located in the same folder as this script. So let's see what it is doing. So the first thing is to compose the binaries of the magic number, the former size, former version, and so on to make a binary of the metadata. And then the metadata will be padded to make sure it consumes 128 bytes in total. So those are the whole data going to be signed. So the next is to generate the digest of this metadata to be signed. And do assigning. Okay. And again, convert the signature data from ASM1 format to the pure binary. Okay. And then there will be some stuffing bytes after that to make sure the whole header is up to the size of 512 bytes. And then in the end, this script will generate a full image with both application and the bootloader and metadata all combined into one single binary. Okay. So this is what this script is doing. Then we can run it. So the first parameter is the bootloader binary. We have it in this folder debug. This is the binary of the loader and the binary of the application. We have it here for loader, so debug. Okay. Then we run this script. It asks for a version number you can give any decimal number. For example, ASM1. Okay. So this script will first generate the hash of the former application format binary. And then we generate the metadata with magic number, size, version, and so on. So this is the set of data going to be signed. And this will be the metadata hash. And this is the signature data in ASM1 format. And then it will be converted into pure binary. And then we have a full header data composed. So this is in the size of 512 bytes. Okay. And then at the end it's just to combine several binaries into a single binary. So this time we can just program this binary to the board and take a look. Connect. This binary is generated in the application binary folder. So, okay. You can see here now there is an out underscore full dot pin. So this is the one to be programmed. We just program because this one includes loader as well. So we just program to the base address of user flash. Okay. Then we take a look at the output. Do a reset. So, now we can see the process of former verification. It starts with, here is just some print message. So it starts with the former magic number check and then check the metadata hash and signature. If the metadata signature verification passes, then it will also compute the former hash. I mean the application former hash and compare with the hash value that is read from the metadata area. If everything goes fine, then it will jump to the application. So now I think we still have the security memory defined. Yes. So we can still run this test. We should also generate a hard fault. Okay. So that's the hands-on for you to understand how the boot loader could be protected and also doing the application former authentication before jumping to it. Let's have a summary of the last hands-on for the boot loader which is a boot loader with authentication. In this hands-on, we have seen how to add application authentication in the boot loader, what kind of tools can be used to generate ECC key pair and how to build a binary of application with metadata that includes necessary information for boot loader to verify the authenticity of the application former. And also, what is the application authentication procedure that could be included in the boot loader code?