RE: Secure bootloader dfu ACL MBR security

kubark42 — Tue, 10 Sep 2019 19:16:37 GMT

Can this answer be further explained? Is it *only* when using DFU that the BL can be overwritten despite ACL bits, or is there a way that this can be triggered from application firmware?

Other comments such as https://devzone.nordicsemi.com/f/nordic-q-a/47431/there-is-any-secure-storage-in-nrf52840/188007#188007 suggest that it is possible to lock down memory through intelligent use of the ACL at boot time, but if the bootloader can be overwritten from application firmware via SD_MBR_COMMAND_COPY_BL then there seems to be no way to protect a secret key.

Put differently, what can we do to prevent an application from calling SD_MBR_COMMAND_COPY_BL?

RE: Secure bootloader dfu ACL MBR security

Hung Bui — Wed, 03 Apr 2019 15:35:34 GMT

Hi Wang,

1. There is a reset after you call the MBR command SD_MBR_COMMAND_COPY_BL to replace the bootloader. After a reset the MBR should be able to access the bootloader's flash area.

2&3. The ACL protection for MBR and bootloader is just to avoid the application to accidentally erase/modify the MBR or bootloader. It's not a measure to protect the bootloader from being attacked by the application code. It's important to make sure the application image is authorized and is safe (using signature as in our secure bootloader).