Posted on October 02, 2017 at 17:36
My current project involves some pretty complicated logic, required for firmware update over the air. So I ended up with solution, which contains bootloader and application code, compiled separately. My current memory layout looks like that:
And now I should protect bootloader sectors 0 to 3 in such way, that their content cant be modified from application, running in main memory sectors 4 to 7. That situation is unlikely to happen, only in case if some malicious software will be loaded, so the goal is to ensure that even in that case device will restore after power-on-reset.
My current idea is to set RDP for entire chip and enable write protection for sectors 0 to 3. But I still have some scenario in mind when malicious firmware can break the device:
1) What if the firmware will access some option bytes, somehow turn off the sectors 0 to 3 write protection and then perform mass erase?
2) What if the firmware will modify somehow
option bytes, so the bootloader will be not able to properly reflash the firmware?
But I am not even sure whether those bytes can be accessed from firmware somehow (can someone give me explanation on that).
Could you please tell me are my fears justified and how can I improve the solution security in case if they are.
#option-bytes #flash-protection #read-out-protection #bootloader
Posted on October 03, 2017 at 09:39
There is some pretty complicated cryptographic logic (digital signature, public key cryptography) behind the firmware update, but there is still scenario, when one can load malicious firmware to device (bribed employee, which has access to updates server and signing keys, for example). The task is to ensure, that even in that case we can perform rollback and device wouldn't be damaged by malicious firmware. From this table found in the appnote
I see, that applying RDP level 2 can do the trick, but I am not sure.
