nRF52840 + NCS + MCUBoot, CC310-enabled image encryption?

[FARLY7]

Hi there,

I am working on a new product iteration that uses the nRF52840. Our existing application is already using nRF52832 + NCS + MCUBoot with image signing.

I would like to take this opportunity to enable image encryption in MCUBoot and use the CC310 crypto hardware accelerator to perform image verification and decryption. However, I cannot find a working KConfig configuration that enables image encryption on MCUBoot with CC310.

Normally I can eventually figure these configuration issues out, but this one is difficult. I cannot find a relevant example project, or similar questions on the devzone.

The main compiler errors I am getting are:

 #error "One crypto backend must be defined: either MBED_TLS or TINYCRYPT"

Could someone tell me what KConfig options are required, or point me to an existing sample project?

Thanks,

Sean

[Vidar Berg]

Hello,

We have not implemented support for encryption in the signing mechanism because we don't support DFU FW encryption in our SDK. This means we have not evaluated or verified the encryption support offered by the MCUBOOT project. Therefore, if you want the signing function to include encryption, you must patch the cmakelist file as described in my first reply in this thread. You should also consider including the --clear flag (https://github.com/mcu-tools/mcuboot/blob/8724081f9056291023c5d8be3e9df11f91a6bd78/scripts/imgtool/main.py#L291) if use external flash (this will ensure the image is re-encrypted if moved to secondary slot). 

[papatel]

Thank you Vidar.  We will attempt to follow that guidance but your comments give us great pause toward continuing this high volume project in the nrfConnect SDK.  I must confirm: is there any other mechanism/infrastructure that Nordic *does* support in the nrfConnect SDK for image encryption?  Please interpret the question broadly, not just in the scope of the NRF52840.

[Vidar Berg]

We currently do not provide an official solution for encrypted DFU. One of the reasons for this is that the solution provided by MCUBoot does not utilize any secure storage for the encryption key and that the same encryption key will be shared across all devices. 

[papatel]

Thank you Vidar. Maybe I'm miss understanding but isn't the encryption key stored in SOC flash which can then be read-back protected and with the latest silicon (at least on NRF52840) that *should* be protected?

[Vidar Berg]

No, your understanding is correct, but there are potentially other ways the key may be leaked. For instance, if someone gains access to the hex file used in production or exploits unknown software vulnerabilities, etc. But the latest silicon certainly helps limit the risk.

Here is the threat model defined by MCUBoot: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/mcuboot/encrypted_images.html#threat-model