[Security] Secureboot witch Flash configuration filed

[Gideon]

Dear NXPs：

S32K146

P-Flash 1M(2 Block)

D-Flash 32K 

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;

define symbol m_flash_config_start = 0x00000400;

define symbol m_flash_config_end = 0x0000040F;

Q1:We calculated the CMAC value of BootManager on the PC, and after importing it into the BOOT_MAC slot, enabling BootManager failed to verify. Found the following problem: noticed that the value in Flash configuration filed (0x00000400-0x0000040F) may change when the program is running. The values 0x00000400-0x0000040F in *.hex are inconsistent with the values 0x00000400-0x0000040F in memory. This is the root cause of verification failure. Secureboot starts verification from the 0x0 address. It seems that the address of Flash configuration filed (0x00000400-0x0000040F) cannot be changed. So how do I calculate the CMAC value of BootManager on an external PC?

PS：After IAR enters Debug mode, the data in the Flash configuration filed (0x00000400-0x0000040F) in the *.hex file changes, which poses a challenge to the implementation of the secureboot function.

Q2：The Bootloader CMAC value calculated on the PC is always inconsistent with the value calculated on the chip. It is suspected that CSEC_DRV_GenerateMAC/CSEC_DRV_VerifyMAC is used incorrectly.
I first used the CSEC_DRV_GenerateMAC interface to calculate the CMAC value in the 8K area in order to correct the PC's CMAC algorithm. Is my CSEC_DRV_GenerateMAC interface used correctly?
//for test.
#define BL_VRF_DATABLOCK_SIZE 16u
#define BL_VRF_CMAC_SIZE 16u
static uint8_t bl_mac[BL_VRF_CMAC_SIZE] = {0};
static uint32_t auwOffsetAdr = 0x0;
static uint8_t aubReadData_a[BL_VRF_DATABLOCK_SIZE] = {0};
static bool nubVerifStatus = false;
for(uint32_t auwLoog = 0; auwLoog < 512; auwLoog ++)
{
for(uint32_t auwLoop = 0; auwLoop < BL_VRF_DATABLOCK_SIZE; auwLoop ++)
{
aubReadData_a[auwLoop] = *((volatile uint8_t *)BL_VRF_ADDR_START + auwOffsetAdr + auwLoop);
}
auwOffsetAdr += BL_VRF_DATABLOCK_SIZE;
csec_error = CSEC_DRV_GenerateMAC(CSEC_KEY_1, aubReadData_a, 8*1024*8, bl_mac, 1000);
memset(aubReadData_a, 0, sizeof(aubReadData_a));
}

Q3：

status_t CSEC_DRV_GenerateMAC(csec_key_id_t keyId,
const uint8_t * msg,
uint32_t msgLen,
uint8_t * cmac,
uint32_t timeout)

uint8_t msg[16] = {0};
To verify 8K data, do we need to call the CSEC_DRV_GenerateMAC interface 512 times? msgLen=8*1024*8bit?Does CSEC_DRV_GenerateMAC support CMAC cumulative calculation?

[lukaszadrapa]

Hi @Gideon 

1. Some debuggers protects the flash configuration field against unwanted modification to avoid locking of the device. If you want to changed the flash configuration field to a value different from default one, it's necessary to explicitly inform the debugger about this. Not sure about IAR, I do not have experience with this one, so please ask them directly.

2. AN5401 shows how to calculate the BOOT_MAC manualy. See example 4_secure_boot_add_BOOT_MAC_manual in the app note.

3. You should call the function 1x only. I can't see a reason to call it more times. Notice that there are two versions of the function. CSEC_DRV_GenerateMAC and CSEC_DRV_GenerateMACAddrMode. The second one will be much faster because the functin does not copy all the data to PRAM. But it works only for flash data, not for RAM. Please read the description in the S32K3 reference manual and also in SDK user manual.

Regards,
Lukas

[Gideon]

A3： You should call the function 1x only. I can't see a reason to call it more times.
====>I already know these two interfaces CSEC_DRV_GenerateMAC and CSEC_DRV_GenerateMACAddrMode. I want to generate the CMAC value of the Bootloader, but the Bootloader is on D-Flash and the size is 32K. In this case, I need to use the CSEC_DRV_GenerateMAC interface. The RAM resources of the chip are limited. How can I calculate the 32K CMAC by calling CSEC_DRV_GenerateMAC once?

Regarding the CSEC_DRV_GenerateMAC interface, please refer to the reply below.

Solved: Re: [Security] secure boot Verify interface confirm - NXP Community

[lukaszadrapa · Accepted solution]

You are just supposed to call the function one time while msgLen covers whole code area you want to check. The function will do everything on background. Yes, it's kind of loop process when all the data need to be copied to PRAM interface step by step. But no normal RAM is needed for that and this operation is NOT done by user. You can take a look at the source code in csec_driver.c to understand how it works.