TMS320F28386D: Only Authenticating Flash Code Beyond 16KB

Wang,

I think it is possible, i.e. to have a CMAC tag for the memory beyond 16KB from the secure entry point, and then to validate it.  However, if the device doesn't boot up into secure boot to validate the 16KB, then I believe there is a security gap to just validating the other flash memory, since there is no guarantee that the code leading up this has not been tampered with.

I don't think there is anything stopping you from running in normal flash boot, but it may not be a best practice from a security POV, since the code that executed at boot is not inside a root of trust domain.

Best,
Matthew 

Ok, thanks, Matthew. I will find a new board to test this case, due to all the boards I have in hand,already enabled secure boot.

Yes, I agreed that this is not the best practice for secure boot.

I will feedback the test result.

I find a new board, which did not enable the secure boot of OTP config. It can boot and set the GPIO high, but when invoke 

applicationCMACStatus = CPU1BROM_calculateCMAC(CMAC_AUTH_START_ADDRESS,
CMAC_AUTH_END_ADDRESS,
CMAC_AUTH_TAG_ADDRESS);

It returns failed, and enter in infinite loop.

And I pick one board which enabled the secure boot of OTP config.Flash the same software, hex file.

It runs well. The GPIO toggles.

So, if not enable the secure boot of OTP config, it is not possible to Authenticating Flash Code Beyond 16KB

Wang,

I'm debugging something similar, can you confirm the below:

In the new, user only CMAC, you will need to remove/comment out the following lines that set up the array for sb1 cmac tag(since we don't want to use that)

#pragma RETAIN(cmac_sb_1)
#pragma LOCATION(cmac_sb_1, 0x080002)
const char cmac_sb_1[8] = { 0 };

In the example project there is an addition .cmd file that is specifically for hex utility to know the address range to compute the tag.  In our example it is called boot_ex1_flash_hex_lnk_cpu1.cmd

Contents look like this

/* CPU1 Flash sectors */

/* HEX directive required by HEX utility to generate the golden CMAC tag */
/* with one entry that represents all the allocated flash memory */
ROMS
{
  FLASH_SECTOR0_13: o=0x00080000 l=0x00040000, fill = 0xFFFF /* If fill not specified, then default is all 0s */
}

Let's make sure and change this to the range of the new user region you wish to calculate the tag on, this should match the start/end address of the user CMAC struct in the main.c shown.  For user CMAC, we have freedom of placing tag address where-ever we want, I would recommend aligning this to a 128-bit boundary based on the other secure boot issue we are debugging.

uint32_t CPU1BROM_calculateCMAC(uint32_t startAddress, 
                                uint32_t endAddress, 
                                uint32_t tagAddress);

Since we are not using secure boot, I think it is valid to include the 1st 16KB in this region if desired.

Let me know if this resolves things.  BTW, for now is the DCSM unlocked?  This will make debug simpler, but if you are locked device we would need to make sure to place the CMAC calculation and tag in the same secure region as the flash address above that are also secure.

Best,
Matthew