Secure bootloader dfu ACL MBR security

[bywang]

I'm looking at the secure boot in the sdk for nrf52840 and have noticed that nrf_bootloader_flash_protect uses the ACL to protect the MBR and the bootloader from being overwritten. Next, during a DFU, the bootloader is overwritten, I think by the MBR.

I have two questions:

1. How does the MBR overwrite the bootloader even while it is protected by the ACL?
2. More generally, what does the ACL protect from, is it the SoC Library only?
3. What prevents the MBR prevent itself being used to overwrite the bootloader, bypassing the ACL?

Thanks for any help

[Hung Bui]

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). 

[kubark42]

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?