BLE DFU with encrypted images in MCUBoot

[Simen Eilevstjonn]

We are trying to setup image encryption in our nRF build, for use with BLE DFU.

I see that this is not supported by Nordic, but that there is support for it in MCUBoot. There exists an example from Hellevik that we followed: https://github.com/hellesvik-nordic/samples_for_nrf_connect_sdk/tree/main/bootloader_samples/keys_and_signatures/mcuboot_smp_encryption

Using this example, we get encryption to work, with the compiler reporting the correct key file, but when attempting DFU, it just reports as failed.

From my understanding, the encryption is done using an ephemeral AES key, which is encrypted with a public key. The bootloader should hence have the private key.

I could not find that key in merged.hex, so I suspect it is not included.

The example used UART DFU, is there a difference here that requires other configuration?

I also saw another question regarding using encrypted images with a two stage bootloader, which we are using. It was said that it is not supported, but is there a difference between that and using only MCUBoot?

[Menon]

Hello,

Could you please provide some additional details about the issue you are experiencing? I am unable to determine where the crash is occurring or where the error message is coming from.

Kind regards,

Abhijith

[Simen Eilevstjonn]

Hello,

I still do not have an error message, but the observed behaviour is that if one attempts to do over the air DFU with an encrypted image (using CONFIG_BOOT_ECDSA_TINYCRYPT=y, CONFIG_BOOT_ENCRYPT_IMAGE=y in mcubooot.conf) while using both NSIB and MCUboot, then the process fails, and the old image is swapped back.

However, I found a workaround by disabling NSIB. That is going to be okay for our use case, unless there exists some simple solution to get it to work with a two-stage bootloader.

[Menon]

Hello,

Sorry for getting back to you so late; it was the summer vacation period here in Norway.

Simen Eilevstjonn said:

while using both NSIB and MCUboot, then the process fails, and the old image is swapped back.

However, I found a workaround by disabling NSIB. That is going to be okay for our use case, unless there exists some simple solution to get it to work with a two-stage bootloader.

I believe that image encryption with a two-stage bootloader is not a supported feature. When NSIB  is enabled, MCUboot might not support image encryption because this process requires secure handling of keys and decryption, typically performed entirely within a secure environment. NSIB introduces complexity to the boot flow, potentially making it incompatible with image encryption. In the usual scenario, MCUboot decrypts the image before handing it over to the application. However, with NSIB enabled, the boot process is split between secure and non-secure cores, which may prevent the decryption logic from being properly executed.

If NSIB must be used, you might need to implement a custom solution to securely handle image decryption in conjunction with NSIB. Alternatively, as you're currently doing, disabling NSIB is a viable workaround, allowing you to rely solely on MCUboot for the process.

Kind regards,
Abhijith