Feedback
Feedback

If you are having issues with the exercises, please create a ticket on DevZone: devzone.nordicsemi.com
Click or drag files to this area to upload. You can upload up to 2 files.

Application verification

The bootloader can typically not be updated/changed and is therefore referred to as an Immutable Bootloader (see note). When the immutable bootloader is programmed onto the chip by a trusted party, the immutable bootloader is considered to be trusted forever, as we know it can not be changed. In security terminology, this is known as a Root of Trust.

Note

The above section talks about a (First-stage) Immutable bootloader. While not covered in this course, it is also possible to have an upgradable Second-stage upgradable bootloader.
To learn more about this, see our documentation on Bootloaders and Device Firmware Updates.

Now, the trusted immutable bootloader can be used to verify the application, using public-key cryptography. There are a lot of resources on public-key cryptography on the internet, so if you have never heard about this before, we suggest you look it up (specifically digital signatures).

Digital signatures are used to verify the application. To explain briefly how this works:

  • The developer has a private key, which should not be shared with anyone and should be kept secret.
  • A public key is generated from the private key.
  • The public key is embedded into the bootloader code.
  • The application firmware is signed using the private key.
  • The bootloader can match the public key with the signature, to verify that the application firmware is signed by the private key. This guarantees that the application firmware also comes from the developer, as only the developer has the key.

With this signature verification, we know only our signed applications can be run on the chip.

From the image above: In the left picture, the verification is successful as the bootloader is able to find the signature (red dot), In the right image, the bootloader can not find the signature (empty magnification glass), it will skip step 2 and not run the application.

Note

As developers, we do not have to handle the verification ourselves. We only need to generate the private key and give it to the build system, and then the bootloader will handle the rest automatically. Verification is enabled by default in nRF Connect SDK bootloaders. Details on how to set the private key will be covered later in this lesson, in bootloader-specific sections.

Register an account
Already have an account? Log in
(All fields are required unless specified optional)

  • 8 or more characters
  • Upper and lower case letters
  • At least one number or special character

Forgot your password?
Enter the email associated with your account, and we will send you a link to reset your password.