MCUBoot: Can't Configure For Image Encryption

[vytautas.virvicius]

Using v2.8.0-rc2 as v2.7.0 doesn't support the SCRATCH partition.

I am not able to enable BOOT_ECDSA_TINYCRYPT (required for Image Encryption).

I suspect this is because the nRF sysbuild CMake will include external_crypto.conf:

The external_crypto.conf is going to enable BOOT_NRF_EXTERNAL_CRYPTO:

... and this can't be overwritten.

I tried setting the option in <APP_DIR>/sysbuild/mcuboot/prj.conf.

If I comment out CONFIG_BOOT_NRF_EXTERNAL_CRYPTO=y in external_crypto.conf, I am able to modify the value and everything builds successfully. Otherwise, I get spammed with build errors:

[Vidar Berg]

Hello,

We do not test our configurations with encrypted DFU as we do not support this feature in our nRF Connect SDK, but it is possible that it may still work. That said, from SDK v2.7.0 and newer, you need to configure to configure the encryption and signature support through sysbuild. You can create a file named sysbuild.conf that you place in your project root to apply sysbuild configurations (https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/releases_and_maturity/migration/migration_sysbuild.html). 

Best regards,

Vidar

[vytautas.virvicius]

You don't support the feature, even though multiple questions regarding image encryption have been answered here previously?

  NCS encrypted MCUboot images supported? 

Including documentation that references this feature:

https://docs.nordicsemi.com/bundle/ncs-latest/page/mcuboot/encrypted_images.html

It is very frustrating to understand what features are supported by the nRF SDK.

You can't trust official samples, as we discovered in this ticket:

 Software Maturity for TF-M PSA Template  

We now have a situation where changes to nRF's sysbuild CMake have completely broken the selection of different cryptographic libraries. Neither TINYCRYPT nor CC310 can be selected when using the NIST-P256 signature. This decision seems arbitrary to me.

What solution can you offer us?

How can we have any confidence that the features we currently use will not be declared as 'not-supported' in the future and bugs related to them will not be fixed?

PS. I'm setting the signature type in sysbuild.conf.

SB_CONFIG_SECURE_BOOT_APPCORE=y
SB_CONFIG_BOOTLOADER_MCUBOOT=y
SB_CONFIG_MCUBOOT_MODE_SWAP_SCRATCH=y
SB_CONFIG_BOOT_ENCRYPTION=y
SB_CONFIG_APPROTECT_LOCK=y
SB_CONFIG_SECURE_APPROTECT_LOCK=y
SB_CONFIG_BOOT_SIGNATURE_TYPE_ECDSA_P256=y
SB_CONFIG_SECURE_BOOT_SIGNING_KEY_FILE="keys/nsib-priv1.pem"
SB_CONFIG_SECURE_BOOT_PUBLIC_KEY_FILES="keys/nsib-pub2.pem,keys/nsib-pub3.pem,keys/nsib-pub4.pem,keys/nsib-pub5.pem"
SB_CONFIG_BOOT_SIGNATURE_KEY_FILE="\${APPLICATION_CONFIG_DIR}/keys/mcuboot-priv.pem"
SB_CONFIG_BOOT_ENCRYPTION_KEY_FILE="\${APPLICATION_CONFIG_DIR}/keys/mcuboot-priv.pem"

[Vidar Berg]

Encrypted DFU is supported in the MCUBoot project, but not officially supported by SDK. I understand the confusion, and it is unfortunate that this is not more clearly communicated in our documentation. I wrote something about this in my answer here: 

 RE: Using MCUBoot with nRF5340 

I will report this internally.

vytautas.virvicius said:

What solution can you offer us?

How can we have any confidence that the features we currently use will not be declared as 'not-supported' in the future and bugs related to them will not be fixed?

The solution is to prevent the the external_crypto.conf fragment from being applied to MCUBoot here: https://github.com/nrfconnect/sdk-nrf/blob/f50b5d5c7027e9c7bb61a3d34f8f656ebfb1bb0f/sysbuild/CMakeLists.txt#L318. This only happens when NSIB is enabled as the first stage bootloader.  

Edit: 

vytautas.virvicius said:

We now have a situation where changes to nRF's sysbuild CMake have completely broken the selection of different cryptographic libraries. Neither TINYCRYPT nor CC310 can be selected when using the NIST-P256 signature. This decision seems arbitrary to me.

the bootloader uses a special version of the cc310 runtime library tailored for the bootloader to minimize the memory footprint. Therefore it does not include crypto services needed to decrypt the image.