Secure boot implementation for boot loader as well as application image security

[baseerahmadpiracha]

Hello NXP Team,

I am implementing secure boot for bootloader integrity and authentication as well as for application image (main firmware). I have studied AN5401 as well as AN12218. I have also looked at the firmwares of both, But I am a little bit confused with the implementation methodology.

What I want is that at power up bootloader should be authenticated and executed after verification. Similarly, the firmware should be verfied after signature verification executed.

BR,

Baseer

[lukaszadrapa]

Hi @baseerahmadpiracha 

Let me re-use a text which I wrote for another customer (well, this sentence is also used in the text

Yes, that’s correct. Start address of secure boot is 0x0. This is hardwired, it cannot be changed. And max size for secure boot is 512KB.

To check the bootloader which is placed to FlexNVM, it is necessary to create chain of trust. Let me re-use a text which I wrote for another customer:

******************

The procedure should be like this:

• Let’s say the bootloader occupies area 0x0  - 0xFFF (just an example)
• The secure boot is configured to cover this area.
• The bootloader checks if the secure boot was successful (read if FCSESTAT[BOK]==1)
• If the secure boot failed, do something (this is up to you)
• If the secure boot was successful, start checking of the application – this is just calculating of the CMAC over the application image.
• If the CMAC is correct, run BOOT_OK command which finishes the secure boot process and then it is possible to use boot protected keys. Jump to the application.
• If the CMAC is not correct, run BOOT_FAILURE command which finishes the secure boot process and then it’s not possible to use boot protected keys. It’s up to you if you want to jump to the application or not.

******************

For your use-case, it needs to be little bit modified: you should have very small application starting at 0x0. This application should be protected by the secure boot. And this application should calculate CMAC over bootloader in FlexNVM (instead of calculating CMAC over application as mentioned in the original text above) and then run either BOOT_OK or BOOT_FAILURE and then jump to the bootloader. This is just a principle, you can modify the procedure as needed.

The customer wanted to protect a bootloader which was placed in FlexNVM. That's the case of AN12218.

Another thing is that if sequential or parallel secure boot mode fails, the only effect is that boot protected keys cannot be used. If strict sequential secure boot mode fails, the device will never leave reset, there's no way to recover.

Regards,

Lukas

[baseerahmadpiracha]

Hello @lukaszadrapa 

Thanks for detailed explaination. I have used AN5401 example and integrated AN12218 example with it.
After checking FCSESTAT[BOK]==1, I start checking for application image over UART.

Now I am confused on how to calculate the CMAC of application image and how to authenticate the application image. I have also gone through AN4235 document but it is very confusing.

Can you guide if the 1st part I implemented for authenticateing bootloader is correct way and also please guide me how can I implement autheication of application firmware which I will boot through UART.

[lukaszadrapa]

Hi @baseerahmadpiracha 

here's an example from AN5401:

/* CMAC generation and verification */
uint32_t data_and_cmac[8], cmac[4];

//Generate CMAC for the plain text using key-1
csec_error = CMAC(cmac, plain_text, KEY_11, 128);

//Append plain text and cmac
for(i=0; i<4; i++)
data_and_cmac[i] = plain_text[i];
for(i=4; i<8; i++)
data_and_cmac[i] = cmac[i-4];

// Run MAC verify command on above concated array
csec_error = CMAC_VERIFY(&verification_status, data_and_cmac, KEY_11, 128);
if(verification_status == 0)
success=1; //Verification Passed
else
success=0; //Verification Fail

So, it's just about generation and verification of the CMAC.

Notice that AN5401 code implements only normal commands CMD_GENERATE_MAC and CMD_VERIFY_MAC. But there are also "pointer method" versions of both commands which are faster. See the reference manual for details. Drivers in SDK implements also these commands. I already wrote somewhere on the community:

"Csec_GenerateMacAddrMode uses pointer method, so it’s faster than Csec_GenerateMac. When using Csec_GenerateMac, it’s necessary to copy all the data to CSEc engine manually (this is done by the function). Next important difference is that Csec_GenerateMacAddrMode works only for Program Flash. If you need to calculate MAC over data in Data Flash or in RAM, it’s necessary to use Csec_GenerateMac."

Regards,

Lukas