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 Sean,

Encrypted DFU is feature we do not officially support in our SDK, even though it is made available through the mcuboot project. Also be aware that the solution does not utilize a secure key storage for the private key kept on the device. This means we cannot guarantee that the key cannot be extracted.

That said, the reason you are unable to build the bootloader in its current configuration is that the cc310 runtime library (nrf_cc310_bl crypto library) linked in by the bootloader only provide ECDSA and SHA-256 support. This sufficient to perform signature validation of the FW image, but not encryption/decryption. 

While it's not really what you want, a simple workaround would be to select the TINYCRYPT SW backend instead (CONFIG_BOOT_ECDSA_TINYCRYPT=y). The other alternative would probably be to integrate the full version of the cc310 library. This will require changes to the bootloader itself. If you end up trying this, then I think a good start is to take a look at the cc310_glue file here (https://github.com/nrfconnect/sdk-mcuboot/blob/main/ext/nrf) /cc310_glue.c and the include headers in https://github.com/nrfconnect/sdk-mcuboot/tree/main/boot/bootutil/include/bootutil/crypto. These files show the functions currently implemented for the cc310 backend.

You may also edit the imgtool sign command in ncs/nrf/modules/mcuboot/CMakeLists.txt if you want the build to encrypt the update binaries for you.

e.g.

diff --git a/modules/mcuboot/CMakeLists.txt b/modules/mcuboot/CMakeLists.txt
index 6dd442214..dffc07e35 100644
--- a/modules/mcuboot/CMakeLists.txt
+++ b/modules/mcuboot/CMakeLists.txt
@@ -149,6 +149,7 @@ if(CONFIG_BOOTLOADER_MCUBOOT)
       COMMAND
       # Sign the binary version of the input hex file.
       ${sign_cmd}
+      --encrypt <insert path or symbol here that points to your key file >
       ${sign_dependencies}
       --slot-size ${SIGN_ARG_SLOT_SIZE}
       ${to_sign_bin}

Best regards,

Vidar

[FARLY7]

Hi Vidar,

Thanks for the detailed answer.

We are aware of the vulnerabilities of storing the keys in FLASH but thank you for noting that - it is important for anyone else reading.

Ok, I understand why using the CC310 for MCUBoot encryption is currently unsupported. I have opted for the simple option from your suggestions, and I am now able to successfully compile. We can still use the CC310 in our application for signing operations.

There are two further related questions I would like to ask:

1. Your last point mentioned manually editing the ncs/nrf/modules/mcuboot/CMakeLists.txt file to automatically include encrypted binaries in the build process. However, I found the KConfig option CONFIG_MCUBOOT_ENCRYPTION_KEY_FILE, that says it's meant to perform this operation automatically? However, this KConfig option is not available unless I also specify CONFIG_MCUBOOT_SIGNATURE_KEY_FILE, and enabling this option results in the warnings below:

CMake Warning at /Users/FARLY7/workspace/um/catch-firmware-active/nrf/modules/mcuboot/CMakeLists.txt:630 (message):
CONFIG_MCUBOOT_SIGNATURE_KEY_FILE is set to
"./bootloader/mcuboot/catch-active-bloodaxe_gen2-sign-p256.pem".

You are using the NCS Mcuboot signing, which means this option will be
ignored.

Image signing in NCS is done via the MCUboot image's
CONFIG_BOOT_SIGNATURE_KEY_FILE option.

Consider setting CONFIG_MCUBOOT_SIGNATURE_KEY_FILE in your application
image back to its default value, the empty string.


It seems like this feature is not fully implemented or deprecated? I found this related GitHub Issue. We are already only using the CONFIG_BOOT_SIGNATURE_KEY_FILE as suggested, so is our only option to automatically generate the encrypted binaries to use your suggestion? I would rather not edit the CMakeLists.txt file directly, as we use different key files for different board builds, so it seems we will need to perform the encryption/signing separately.

2.  Not really a question, but I see the issue still exists where if the key file path provided is a relative one, CMake will print the false warning that MCUBoot is using the default key, when it is correctly using the provided key. (see here). I hope this is fixed soon, as it is quite confusing.

Thanks,

Sean

[Vidar Berg]

Hi Sean,

No problem. I just wanted to make sure you and anyone else reading this thread were aware that this is is not an officially supported feature.

1. We only use the CONFIG_BOOT_SIGNATURE_KEY_FILE and CONFIG_BOOT_ENCRYPTION_KEY_FILE symbol in our SDK.

FARLY7 said:

It seems like this feature is not fully implemented or deprecated?

I think it is available in upstream zephyr. As noted in the warning message, NCS has its own signing mechanism. I guess we needed this to support multi image builds.

FARLY7 said:

I would rather not edit the CMakeLists.txt file directly, as we use different key files for different board builds, so it seems we will need to perform the encryption/signing separately.

It is not ideal to have to patch SDK files, but I think it is the easiest solution in this case. It should be possible to use the CONFIG_BOOT_ENCRYPTION_KEY_FILE symbol defined by your MCUBOOT child image.

2. Thanks for making me aware of this issue. I will check if it something we can try address in the upcoming release.

I usually place the key files in the child image folder together with the mcuboot configuration file so I don't have to use a relative path:

4786.child_image.zip

Regards,

Vidar

[papatel]

Thank you Sean for your post illuminating that this isn't a supported feature.  

Is there any update on firmware image encryption?  I know APP Protect is totally broken so a hacker can easily dump any firmware on any NRF52 device anyway.  But some SoCs from Nordic are now supporting secure key storage so it seems that NRFConnect development environment should make image signing And image encryption front-center and super easy to use.  Maybe I'm missing or misunderstanding some information on the 2.3.99 environment?  I don't want to go through modifying the SDK to make this work as needed.  That's a recipe for having to code again and again as we port to new silicon released by Nordic.  My understanding is that the nrfConnect ecosystem and integration with Zephyr and MCUBoot was to prevent just that...

[Vidar Berg]

There haven't been any updates regarding support for encryption, unfortunately.

papatel said:

Is there any update on firmware image encryption?  I know APP Protect is totally broken so a hacker can easily dump any firmware on any NRF52 device anyway.

We have introduced a new silicon revision for all 52 variants that mitigates this vulnerability. For more details, please refer to the relevant IN for your IC.e.g. IN141 Informational Notice v1.1. if you use the nRF52840.

papatel said:

Maybe I'm missing or misunderstanding some information on the 2.3.99 environment?  I don't want to go through modifying the SDK to make this work as needed

You don't have to modify the SDK if you're okay with not having hardware-accelerated crypto support in the bootloader. The change I proposed in my initial reply was in case you wanted the build script to encrypt the update binaries for you.

[papatel]

Thank you for the fast response Vidar!

I'm having a good deal of difficulty enabling image encryption regardless of the encryption library used.  I see good (but incomplete) documentation around imaging signing and verification and what KConfig values to set but there seems to be missing guidance entirely on how exactly to enable encryption on the image as well.  At this moment I have signing working by creating an mcuboot.conf and defining CONFIG_BOOT_SIGNATURE_KEY_FILE with an absolute path to an ECDSA private key.  I cannot figure out what settings to add to this conf file or prj.conf to enable image encryption as well.  I found the CONFIG_BOOT_ENCRYPTION_KEY_FILE setting but I've had had no luck setting that analogously with a another key...

Can you assist or point me to the documentation I missed?

I also have the below added to my CmakeLists.txt file just after the  "cmake_minimum_required(VERSION 3.20.0)" line.  Getting boot signature was hard enough; I was only able to figure it out after watching someone's video on the subject.  

if (EXISTS "${CMAKE_CURRENT_SOURCE_DIR}/mcuboot.conf")
    list(APPEND mcuboot_OVERLAY_CONFIG
      "${CMAKE_CURRENT_SOURCE_DIR}/mcuboot.conf"
      )
endif()

Personally, I think signature and image encryption should be front and center and super easy to configure on every platform it's supported.  Curious why it's so difficult given that nearly every organization that deploys firmware on this platform is going to want these features.