Setting sysbuild encryption of DFU images

[Crox]

I have had luck setting up signatures using MCUBOOT and sysbuild.

However, I have not been able to encrypt the images.

sysbuild.conf:
SB_CONFIG_BOOTLOADER_MCUBOOT=y
SB_CONFIG_BOOT_SIGNATURE_KEY_FILE="C:/Users/user/app/mykey.pem"
SB_CONFIG_BOOT_ENCRYPTION=y
SB_CONFIG_BOOT_ENCRYPTION_KEY_FILE="C:/Users/user/app/mykey.pem"

MCUBOOT seems to get both the keys setup correctly based generated files in build/mcuboot/zephyr/ (autogen-enckey.c and autogen-pubkey.c)

And on the output in terminal:

MCUBoot bootloader key file: C:/Users/user/app/mykey.pem
MCUBoot bootloader encryption key file: C:/Users/user/app/mykey.pem
-- Configuring done
-- Generating done
-- Build files have been written to: C:/Users/user/app/build_1/mcuboot

However, the binary generated within build/dfu_application.zip does not itself appear to be encrypted.  What am I missing to actually encrypt the update binary?

Running nrf connect SDK 2.7.0 and toolchain 2.7.0

I mostly referred to these pages: 
https://developer.nordicsemi.com/nRF_Connect_SDK/doc-legacy/latest/nrf/releases_and_maturity/migration/migration_sysbuild.html
developer.nordicsemi.com/.../bootloader_signature_keys.html

 

[Vidar Berg]

Hello,

Please browse the build/<application name>/zephyr folder to see if you have a file named zephyr.signed.encrypted.bin. This should be the encrypted and signed variant of the image. The other file named zephyr.signed.bin is the file that becomes included in the dfu_application.zip. Creation of the the zip file is a nRF Connect SDK specific feature which is not tested with encrypted images (encrypted DFU is not officially supported in our SDK).

Best regards,

Vidar

[Crox]

Indeed, I do have the ...encrypted.bin file. Thanks for the helpful response.

Regarding the post you linked, it notes that the solution does not use secure key storage.  Is it possible to use secure key storage on the nrf52840?  If not, is this a limitation of hardware?

[Vidar Berg]

It cannot be guaranteed that the key stored in the bootloader or firmware images on this device cannot be extracted through a physical attack, such as decapping the chip. Additionally, the key may be leaked by exploiting an undiscovered vulnerabilities in the code, as the key must be accessible to the CPU during decryption.

That said, the bootloader can use the ACL through the FPROTECT module to lock the bootloader flash area from read and write access before branching to the main application. This will limit the window where the key in flash can be accessed internally by the CPU.

It is also important to use silicon revision 3 as this revision introduced changes to mitigate a known fault injection technique to bypass the readback protection: https://docs.nordicsemi.com/bundle/IN/resource/in_141_v1.1.pdf