S32K148 firmware verification using SHA3

[m_mishrikey]

Looking for help getting a high level understanding of an approach to embedded cybersecurity.

Right now my concept is that when we have our production firmware ready to go, we would generate an SHA3 hash on the application binary, and store that in a secure memory location.

Then upon application start, the application would create another hash over all application memory (or I guess a pre-defined start/stop address).  

The something has to compare the two hashes (not sure if the cSEC module does this in hardware?).  If it passes then the application can go ahead, if not then be bricked.

Does this understanding seem correct?

My system does not have a bootloader.  

[m_mishrikey]

Thanks Lukas.

If you did not want to stay in reset forever, what you could you do based on an unavailable key?  And if the key is available, how do you use it?

How is the key stored to begin with?  Is there anything to prevent a hacker from overwriting it or reprogramming the whole device?

There is a project example in S32DS called csec_boot_protection_S32K148.  I was looking at it but having some difficulty understanding how it worked.  Is there some documentation of this specific example, or only the code itself?

[lukaszadrapa]

The main goal of secure boot is to protect the keys, not the code. Strict sequential boot mode is an exception because it shuts down everything  and the device stays in reset forever. So, it's a matter of application or matter of whole system (like car) to decide what to do when secure boot fails and when boot protected keys are not available.

As a first step, I highly recommend to read whole application note AN5401. It's the best source of information.

Documentation of csec_boot_protection_S32K148 can be found in user manual in SDK at path like:

c:\NXP\S32DS.3.5\S32DS\software\S32SDK_S32K1XX_RTM_4.0.1\doc\S32SDK_S32K148_UserManual.pdf

But I still recommend to start with AN5401.

Regards,

Lukas

[lukaszadrapa · Accepted solution]

Hi @m_mishrikey 

CSEc follows SHE specification, so it does not support SHA3.

You described a feature which is called secure boot. CSEc can be configured to automatically calculate MAC over defined part of flash (always starting from address 0x0, size can be defined). If the MAC is different than MAC stored in CSEc previously, sanctions take effect. Depending on selected mode, either boot protected keys cannot be used or the device will be kept in reset forever (and there's no way to recover). For more details, see "4.4 Secure Boot" in:

https://www.nxp.com/webapp/Download?colCode=S32K1XXRM

Or there's an application note:

https://www.nxp.com/webapp/Download?colCode=AN5401&location=null

https://www.nxp.com/webapp/Download?colCode=AN5401SW&location=null

Regards,

Lukas