S32K144 CSEc Secure Boot

[Kishore_14]

Hardware: S32K144EVB-Q100
Software: S32 Design Studio, OpenBLT Bootloader, an5401-csec

1.Can we use the BOOT_DEFINE to protect only the bootloader region?

csec_error = BOOT_DEFINE(16*1024*8, 1); // Only 16KB for bootloader

2.What is the exact CPU behavior difference between boot flavors 0 and 1 when bootloader MAC verification fails? Specifically:

• Flavor 0(strict): Does the CPU halt/block execution or where does control remain?
• Flavor 1(serial): Does the CPU continue to user code or where does control remain?

3.If bootloader verification passes (BOK = 1), can we directly calculate MAC for application using MAC functions without requiring another BOOT_DEFINE? CSEc hardware verifies bootloader autonomously using BOOT_DEFINE for bootloader only. Then bootloader calculates MAC for application directly using CMAC functions with no BOOT_DEFINE needed for application region. Is this approach fine?

[lukaszadrapa]

Hi @Kishore_14 

1. Yes, it is common practice to protect only a bootloader. The bootloader then can check MAC of application(s) to create a chain of trust.
Just for reference, we have this application note for first device with CSE module (quite old device MPC5646C, CSE module is different but the functionality is still the same):
https://www.nxp.com/docs/en/application-note/AN4235.pdf
https://www.nxp.com/docs/en/application-note-software/AN4235video.zip

2.
Sequential or parallel boot mode: if secure boot fails, the only consequence is that boot protected keys (i.e. keys with BOOT_PROT attribute set) cannot be used. The application is still executed as usual.

Strict sequential boot mode: if secure boot mode fails, the device will never leave reset state. There’s no way to recover, the only solution is to replace the chip.

3. As mentioned above, yes. Bootloader is supposed to check MAC of the application. Autonomous secure boot can cover only one area which always starts at 0x0. This is hardwired and it cannot be changed. User can only define length of that area.

Regards,
Lukas

[Kishore_14]

Hi Lukas

I configured CSEc with BOOT_DEFINE(128*1024*8, 1) which should be sequential mode (flavor 1), but when secure boot verification failed, my board went into continuous reset and I was unable to recover - similar to what you described for strict sequential mode.

My setup details:

• Used sequential boot mode (flavor 1)
• Flashed secure boot function to debug RAM
• Application flashed to debug flash area starting at address 0x0
• Expected: Application to execute normally despite verification failure
• Actual: Board stuck in continuous reset loop, no recovery possible

 Is there something in my setup that could cause sequential mode to behave like strict mode?

[lukaszadrapa]

This should not happen, I can't see a reason for that. The command BOOT_DEFINE(128*1024*8, 1) selects sequential mode, not strict mode. Even if it fails, everything should be working, just boot protected keys cannot be used. 

Is the reset line asserted all the time or is it toggling? 

[Kishore_14]

Reset line was toggling when observed.

Also was not able to load the application again and Resetting to Factory state was also not possible.
As my understanding, unable to Reset to factory state might be due to Master_ECU_Key being Boot_protected.

[lukaszadrapa]

Is it possible to load any RAM application?

[Kishore_14]

We are not able to load any RAM Applications too.
We have tried load reset to factory was in RAM. But can't able to load.

[lukaszadrapa]

It looks like we are getting back to this:

https://community.nxp.com/t5/S32K/S32K144-CSEc-Secure-Boot-Device-Stuck-in-Secure-State-Cannot/m-p/2...

https://community.nxp.com/t5/S32K/S32K144-CSEc-Secure-Boot-Device-Stuck-in-Secure-State-Cannot/m-p/2...

But it’s not clear to me why this happens. I can see no problem in your procedure. I was used to test this in different order – I usually loaded some application to the flash as a first step and then I run 4_secure_boot_add_BOOT_MAC_manual from AN5401 to enable secure boot. But it should be possible to do that also in opposite way, I can see no problem here.

When do you import BOOT_MAC key? Maybe that’s the problem. If you do that at the same time when BOOT_DEFINE is executed, BOOT_MAC will be calculated and stored to secure flash automatically after next reset. If you are going to load an application right after that, there could be a collision between this automatic calculation and your debugger loading new application. This is the only scenario I can think of.