Updating the installed open_bootloader on nRF52840 dongle without external tools

Hello.

It seems this issue/question has been posted here on Devzone a few times. I am not sure I am convinced I have understood the responses, hence the following.

Context: I would like to update the preinstalled/default open_bootloader on the nRF52840 dongle, so that I can install a secure_bootloader that has I generate and which will be used for DFU.

As I understand the open_bootloader from (nRF5_SDK/examples/dfu) is built with a DFU key, the private key for which is not available to the public. Consequently, I cannot update itself via DFU. For the purposes I have in mind, I cannot use external tools. Would the following steps work?

  1. Identify the offset in the flash where the DFU key is present in the default/pre-installed open_bootloader. Generate a key pair, and store in  static array in a Zephyr or nRF_SDK app. Build and DFU install this app on the dongle. Reset the board.
  2. When app runs, update the ACL on the ACL peripheral as referred to in the context of  How does the nRF52840 Access Control List (ACL) work exactly? such that the write protect for the bootloader is disabled. Reset the board.
  3. When it comes up patch the offset in the bootloader on the flash where the default open_bootloader key is present. Update the ACL to write project the bootloader. Reset board.
  4. Now it should be able to upgrade the patched open_bootloader, and install the secure_bootloader that I build.

Do you see any flaw(s) in the above? Any corrections? What, if any, might be an improvement over this?

Regards.

Parents
  • Hi,

    What you describe will not be possible. The reason is that as you write, the private key is not accessible, and the corresponding public key is part of the bootloader. The bootlloader protects itself via ACL before it starts the application, and it is not possible to disable ACL protection of a region until the next reset (when the bootloader will run again and enable it). This is deliberately designed this way to prevent an attacker from being able to install an invalid application.

Reply
  • Hi,

    What you describe will not be possible. The reason is that as you write, the private key is not accessible, and the corresponding public key is part of the bootloader. The bootlloader protects itself via ACL before it starts the application, and it is not possible to disable ACL protection of a region until the next reset (when the bootloader will run again and enable it). This is deliberately designed this way to prevent an attacker from being able to install an invalid application.

Children
Related