Secure Boot Missmatched - Calculated CMAC and stored CMAC do not match.

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Secure Boot Missmatched - Calculated CMAC and stored CMAC do not match.

Jump to solution
822 Views
BrK_
Contributor II

Hi everyone,

I have an cmac value for a binary code file. Code size is 7308byte.

BrK__0-1674132943734.png

 

I defined this cmac value in my csec code and loaded it as boot_mac via debug RAM.

BrK__1-1674132943675.png

 

BrK__2-1674132943730.png

 

Then i debug the RAM again to enable secure boot.

BrK__3-1674132944114.png

The size variable that the CSEC_DRV_BootDefine function takes is defined as follows,

BrK__4-1674132943766.png

But, in the reference manual, boot size is explained to as follows :

BrK__5-1674133153584.png

As a result, secure boot gives an error as boot_mac_key_missmatched.

I think the problem is in the boot size entry.

How can i solve this boot_mac_key_missmatched problem ?

I look forward to your help on the subject.

 

Also i follows these steps :

* Operate flash partition for csec via Debug Ram.

* Define master_ecu_key, boot_mac_key, boot_mac via Debug Ram.

* Loade code into Flash.

* Define secure boot with CSEC_DRV_BootDefine  via Debug Ram.

* Reset device.

 

Regards,

0 Kudos
1 Solution
808 Views
lukaszadrapa
NXP TechSupport
NXP TechSupport

Hi @BrK_ 

that's a good point, yes, BOOT_SIZE is a number of bits. The SDK documentation is wrong. Thanks for bringing this into our attention, I will report it.

But there's one more point. Take a look at AN5401:

lukaszadrapa_0-1674490246322.png

You can also take a look at function MAC_SECURE_BOOT() in the AN5401.

And because CMD_GENERATE_MAC calculates the MAC on 128bit data blocks, the best way is to keep the boot_size aligned to 128bits.

Regards,

Lukas

 

View solution in original post

0 Kudos
3 Replies
809 Views
lukaszadrapa
NXP TechSupport
NXP TechSupport

Hi @BrK_ 

that's a good point, yes, BOOT_SIZE is a number of bits. The SDK documentation is wrong. Thanks for bringing this into our attention, I will report it.

But there's one more point. Take a look at AN5401:

lukaszadrapa_0-1674490246322.png

You can also take a look at function MAC_SECURE_BOOT() in the AN5401.

And because CMD_GENERATE_MAC calculates the MAC on 128bit data blocks, the best way is to keep the boot_size aligned to 128bits.

Regards,

Lukas

 

0 Kudos
800 Views
BrK_
Contributor II

Hello @lukaszadrapa

Thank you for reply, but i dont use CMD_GENERATE_MAC() function for generate cmac. I use external software to signing my binary code that follow AES-128 CMAC method.

This binary is 7308byte and calculated cmac is (CSEC_BOOT_MAC) {0x16, 0x3c, 0xc5, 0xdc, 0x7b, 0x0f, 0xcd, 0x7e, 0x24, 0x5b, 0x98, 0xa5, 0x9b, 0x30, 0xcd, 0x66}.

Actually my problem is CSEC_DRV_BootDefine() function.

Firstly, i load keys (CSEC_MASTER_ECU, CSEC_BOOT_MAC_KEY and CSEC_BOOT_MAC) in my EVB via RAM_Debug.

After that i load my application code to EVB via FLASH_Debug.

/// 7308 * 8 = 58464

And finally i use CSEC_DRV_BootDefine(58464, CSEC_BOOT_SERIAL); for enable secure boot.

So, should i follow 4.4.3.1 Manually in RM like CSEC_DRV_BootDefine(58464 + 128, CSEC_BOOT_SERIAL);

or should i keep boot_size aligned to 128 bits

Does secure boot operation do automatic 128-bit alignment?

How secure boot handles boot size?

How can i secure boot with external specified boot_mac on my binary file?

Which key is used in boot_mac calculation of secure boot operation? Is the key used csec_boot_mac_key?

0 Kudos
786 Views
lukaszadrapa
NXP TechSupport
NXP TechSupport

Hi @BrK_ 

yes, it is necessary to follow section "4.4.3.1 Manually". This is given directly by SHE specification. You need to append 128b frame before your binary (zeros + boot size) and the CMAC must be calculated over all these data, so size for your offline CMAC calculation must be increased +128.

The documentation says nothing about alignment of secure boot, so it should not be necessary to align the size.

And yes, BOOT_MAC_KEY is used for secure boot.

Regards,

Lukas

0 Kudos