 Now we come to the third part of the hands-on for former protection, and in this hands-on we're going to see how to ensure the former authenticity. Again, in this hands-on we're going to use some pre-generated projects. In such projects we have the application that is able to do not only hash computation, but also signature verification. And the signature verification scheme that we're going to use will be ECDSA, so we will need to generate ECC key pair. We will see what kind of tool can be used to generate such kind of key pair, and how we can embed the public key in the former code. We will also run some HousePC tool to generate the binary with both the former code, the hash digest, as well as the ECDS signature. And then we can program such binary to the board and observe the signature verification procedure from the application. The hardware board and the software tools required for this hands-on is exactly the same as the previous one. In case you didn't run the second hands-on, you skip that one and jump to this one directly. Make sure you have downloaded XCube Crypto Library from SD website. And make sure you have downloaded the latest patch of Crypto Library, which is version 3.1.3, because that one includes the support of G0. The project to be used for this hands-on will be this one, G0appauth.zip, so this is an application with authenticity check. And we will also run several tools from HostTools folder. So to generate the binary with signature, we will run this postbuild underscore sick.bat. And to generate the ECC key pair, we will first run OpenSSL tools coming from extTools folder. And then we will run prebuild.bat to convert the ECC key pair into a header file to be embedded in the source code. Before we start the practice, let me explain a little bit of the format of the binary to be programmed on the board. So again, starting from the base address of user flash, there will be the firmware of application followed by some padding bytes just to make sure that this chunk of data will be aligned to page size of flash. And then those data will be used to generate hash digest, which will be put to the starting address of a standalone flash page. And then there will be the signature consumed 64 bytes. ECC signature. So in order to be able to verify the signature, there will be the public key data embedded in the application firmware. And the same public key will also be put following the signature data. This is just to make sure that we will have a data that is protected by WRP. That means the ECC public key in this area will not be able to be modified. So we will do a comparison of the ECC key data in the code and the one in a standalone flash page just to make sure we're using the right public key. Now ready? Let's start. In the previous hands-on, we have seen how we can use hash verification to ensure the firmware integrity. And in this hands-on, we're going to extend the integrity check to authenticity verification. So we are still going to use a pre-generated project. So this time we will use a project from this folder, GZERO app off. So again, we still need to use some functions coming from the crypto library of SM62. So make sure that you have downloaded the crypto library, especially the latest patch, patch version 3.1.3. So inside this folder, you should see a GZERO folder and then middleware ST and this SM62 cryptographic folder. Then you just copy this one to your project folder. So make sure you have this folder, including the necessary header files and libraries. Then again, you can choose to use IR or KO or IDE. So this time, let's say we use QBID. So we can first take a look at what is modified from the previous project. So in the main.c, main function, we have something very similar to the previous project. We still have the COM init and the static protection check and apply function and also the function call to hash verification. And on top of that, we have one additional function call here to do the signature verification. Okay, we can take a look at what this function is doing. So the signature verify function will do a signature computation and verification using the digest, which is the hash value of the former. Since in this function, we already verified that the former digest is equal to the hash value that is stored on the flash. So in this function, we just take the hash value from the flash address and do a signature verification using this as the digest. So signature verification function is doing an ECDSA signature verify. So here is the parameter of the ECC curve. Okay. And then there will be some function calls to initialize the EC, initialize a point. And validate the public key to make sure the key is actually on the curve. And then we'll do a ECDSA verify. So all those are the ECC functions from the crypto library. Okay. So that's it. So again, if anything goes wrong during this verification procedure. The software will go into an error handler. Okay. In our case, the error handler is just a endless loop. You can, of course, change that to something else to take further actions if you want. And since this is an ECDSA signature check, of course, an ECC public key will be required. So where does this public key comes from? So we expect an ECC public key.h file. So this one. This is the public key data. There is a public key that means there is also corresponding private key. So when you get the project, you have this public key already generated in the format of a header file. But in actual case, you don't have that initially. So we need to know how you can generate a ECC key pair and convert it into a header file like this. So for that purpose, we have some also tools and script provided in the host tools folder. You can also find some pre-generated keys here. Those are the keys corresponding to the header file in the project. For the generation of the ECC key pair, we can just use openSSL. So if you go inside host underscore tools folder, you will see a folder named extTools. And here, you can find openSSL.exe. Of course, on your system, if you have already installed openSSL, you can also use that. If they're the same or similar version, it should work as it is. So in other case, okay, let's first generate the ECC key. So we can do a openSSL command. For example, we can use ecparam tool. Give the name of the curve, which we are going to use crime256v1. This is the name of the curve. And let it generate a key. And then output to a file named ecc.key. Okay, then if we take a look at the content, it will be something like this. This is the private key of the ECC key pair. Okay, the next thing we need to do is to generate the public key and convert the public key to a header file with a data array to hold the ECC public key data. So for that purpose, we have a script named preview.bat. We can just run this tool giving ECC private key as the first parameter. And then the second parameter, you just need to point out the folder that you want to have the header file generated. Where do you want to put the generated header file? So our project locates here. So we can just let's say we put it in this folder. Okay, so this tool will generate the ECC public key from the private key and convert it into the header file. So we can also take a look at the content of this public key header file. So it's something like this. Okay, so if we go back to the project, so now it changed to the new one. Okay, then now we have the public key. We have everything. You can just compile this project to a compilation. And now we have this binary generated. And the next thing we need to do, as we explained in the slides previously. So we will need to generate a binary with not only just the former binary, but also the hash, the signature. And we also want to put the public key into the binary. So we're going to run another script. So this time we will use this bed file. Okay, let's take a look at the content of this BAT file. So this bed file expect just one input parameter, which is the binary file that you want to process. The former binary basically. And for the ecc key file, it's written here, meaning by default this script expect ecc key file named ecc.key located in the same folder as this tool. Okay, so of course you can change modify this script and change a different ecc key file name. The first thing this script will do is just to do a padding to make sure that the former binary to be signed is going to be a size that is aligned to the flash page size. And then it will again run OpenSSL by just tool to generate the hash. Okay. And then to sign the hash. Actually, there are different ways to use OpenSSL to do the signing. For example, we are using this one, we're still using the digest tool to do the signing. You could also, for example, use this kind of public key utu to do the signing. Okay. It's just doing the similar thing using different ways. Okay. And this part of the code will just convert the generated signature into a pure binary. Because if you run OpenSSL command, the signature generated is encoded in ASM1 format. So this is just a conversion. Okay. I'm not a real expert of Windows bad script. So this might not be the best way to do the conversion, but it's one way. So if you have better ways to do it, of course, you can change it. And then the next part is also some OpenSSL command to convert the to generate the public key out of the private key, because we want to put the public key at the end of the binary. So that's the public key. We have a version of public key in the flash page that is right protected. Okay. So this part of the code is just to do the generation of public key and then convert it to, again, the pure binary. That's it. And at the end, we combine all the binaries into one. So actually, this script will generate several binaries and only this one is the one to be programmed to the flash is the final one. All the others are just intermediate binaries for you as a reference. You can take a look at, for example, the pad.bin file to see what is the binary that is going to be signed. And also with hash.bin is just the padded binary plus hash. And this one is with hash and signature. This one will be everything together. Okay. So then let's run this script. Postpute seek.bat and give the binary of the former that we have just compiled. She is up off. We are using QBID. So the binary generated in this folder. Okay. Okay. So you can see some prints here. So this is the hash value. This is the signature and then the public key binaries. So at the end, it also tells you that this is the binary to be programmed on the board. Okay. The next weekend. Actually, there are several binary generated. We can program different ones to the board and see what's the effect. Okay. So first, let's make sure we don't have any protections on the board. Okay. No write protection. RPP level zero. No P0 up. Okay. Then we can program the binary. Auths debug. This one. It should be APP auth debug. Okay. So first, let's just program this file. This one is with hash value only. No signature. Let's see what will happen. Okay. And open the tarot. Do a reset. Okay. So if we take a look at print message, we can see here that the signature data is not valid. We don't, because we didn't program the final binary. So now we enter and end this loop because the public key is not consistent. Okay. So then let's connect again and program a different binary. So let's do this one. This is a final binary that is supposed to be used to program this one. Let's see what's going on. Okay. There is the protection activated. So maybe we can just disable that first. Command out this line because otherwise each time it will ask you to remove the protection. Let's compile it again and run the same post build script. Okay. And then program this binary. Let's do a foochip erase. Ah, remove the protection. Do a foochip erase. Okay. Then program this final binary to the board to run it again. Okay. It's already there. It's disconnect. Sorry. And run it again. So this time the signature verification is okay. Okay. So in the code it's actually not just doing signature check at the end. Not at the end. And before the signature check, it also tried to make sure that the public key embedded in the software is in line with the one that is located on the flash. So if you don't have a valid public key on the flash, then this verification will also fail. Okay. So here if we take a look at the log, the hash start address is here. So we can take a look at the content on the flash. So the first 32 bytes are the hash data. And then following by 64 bytes of signature and then 64 bytes of public key. Okay. That's how it works. Okay. So now you understand the weight of doing a signature check for the former authenticity. You have finished this part of the hands-on. Let's do a recap quickly. So in this hands-on we have seen how to use signature verification to ensure authenticity of the application firmware. What kind of tool could be used to generate the ECC key pair? And how to build a binary with both application firmware code and its ECDSA signature? You should also have an idea of what could be the former authentication procedure in the code.