S32KのトピックRe: [Security] secure boot Verify interface confirm

[Security] secure boot Verify interface confirm

Gideon — Thu, 25 Apr 2024 12:49:45 GMT

Dear NXPs：

S32K146

background:

CMD_BOOT_DEFINE→BootManager 6KB Use CSEC's secureboot mechanism for verification.

The secondary verification area is Flex NVM Bootloader;

The area of third-level verification is Application;

question:

Q1: When BootManager verifies the Flex NVM Bootloader area, does it call the CMD_VERIFY_MAC or CMD_VERIFY_MAC (pointer method) interface? There are differences between these two interfaces but I don't understand them thoroughly. please. Which one should I use?

Q2: When the Flex NVM Bootloader checks the Application area, should CMD_VERIFY_MAC or CMD_VERIFY_MAC (pointer method) be used? It’s the same question as Q1.

Q3: When the second-level verification fails or the third-level verification fails, CMD_BOOT_FAILURE needs to be called. Is this true?

Q4: If the trust chain image verification is successful (the entire three-level verification is successful), CMD_BOOT_OK needs to be called, is that right?

Re: [Security] secure boot Verify interface confirm

lukaszadrapa — Mon, 29 Jan 2024 11:37:16 GMT

Hi @Gideon

the pointer method works only on program flash. If you want to check also FlexNVM code, you need to use normal CMD_VERIFY_MAC command. In case of program flash, I recommend to use pointer method which is much faster.

Yes, if second-level verification fails or the third-level verification fails, CMD_BOOT_FAILURE should be called to finish the secure boot process. Then the boot protected keys cannot be used.

If it is successful, you should call CMD_BOOT_OK to finish the boot process. It's not mandatory but it's recommended. It will lock the process, so no one can call CMD_BOOT_FAILURE or CMD_BOOT_OK again.

Regards,

Lukas

Re: [Security] secure boot Verify interface confirm

Gideon — Tue, 30 Jan 2024 08:13:23 GMT

Dear NXPs:
Thank you for your strong support. I want to verify the content of D-Flash (Bootloader) on P-Flash (BootManager). According to your suggestion, I should use normal CMD_VERIFY_MAC command. But IC's resources are limited.
RAM size: 22K
D-Flash size: 32K

I understand that first, the contents of D-Flash (1000_0000, 1000_8000, 32K) need to be copied to RAM, and then the normal CMD_VERIFY_MAC command is called for verification.

Q1: How to copy the contents of D-Flash to RAM? memcpy? ?
Q2: Our actual RAM size is only 22K. It seems that the entire D-Flash (32K) cannot be copied to RAM. In order to verify the D-Flash, what should I do?

Re: [Security] secure boot Verify interface confirm

lukaszadrapa — Tue, 30 Jan 2024 07:26:53 GMT

You are not supposed to copy whole flash image to the RAM when using CMD_VERIFY_MAC. You are supposed to continuously push 128bit data blocks to CSEc via CSE_PRAM interface, so you do not need normal RAM. Do you use SDK? Or do you use drivers from application note AN5401? If yes, you can just call a function which will do that for you (AN5401 - CMAC_VERIFY(), SDK - CSEC_DRV_VerifyMAC()).

Regards,

Lukas

Re: [Security] secure boot Verify interface confirm

Gideon — Wed, 31 Jan 2024 02:42:14 GMT

Dear NXPs：

Thank you for your strong support. For the verification of D-Flash, I use the SDK - CSEC_DRV_VerifyMAC(), then I need to read the 128bit data of D-Flash (1000_0000, 1000_8000, 32K) to the CSEC_DRV_VerifyMAC() interface each time.
Q1: It seems that this is a loop process. Every time there is a loop, the verifStatus of the CSEC_DRV_VerifyMAC() interface will return false. VerifStatus will not return true until the last data block is verified. Is my understanding correct?

Re: [Security] secure boot Verify interface confirm

lukaszadrapa — Wed, 31 Jan 2024 12:17:53 GMT

Yes, that's correct. Function CSEC_DRV_VerifyMAC will do that for you. Just call that function and check the result.