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

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

Vidar Berg — Wed, 27 Sep 2023 13:09:27 GMT

I'm glad to hear that the issue has been addressed upstream. The upmerge is currently in progress, and you can track its status here: PR: https://github.com/nrfconnect/sdk-nrf/pull/12112. Unfortunately, I'm not able to give you an estimate of when this will be completed.

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

eb12345 — Tue, 26 Sep 2023 22:36:03 GMT

I raised the issue with MCUBoot project.

Encrypting image and using serial recovery · mcu-tools/mcuboot · Discussion #1814 (github.com)

They said that the NCS version is behind and this issue was solved. Do you know when an upmerge will happen with MCUBoot and/or Zephyr ?

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

eb12345 — Wed, 20 Sep 2023 15:25:11 GMT

I'll post something asking, although I think the upstream repository is different than what NCS has, so not sure if it is still a valid question. I don't mind that in serial recovery you can only write to the primary slot, just don't want it disable DFU in the application.

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

Vidar Berg — Wed, 20 Sep 2023 10:43:14 GMT

I understand your concern. Unfortunately, once I enable encryption, I can no longer upload images to the secondary slot using serial recovery. I've tried various configurations and patches, but regardless of what I tried, the image was always updated "in-place". And to upload an encrypted image directly to the primary slot, we need to use the single loader to have the image decrypted on-the-fly (single loader is included through the CONFIG_SINGLE_APPLICATION_SLOT=y symbol).

The problem with activating the single loader is that it disables FW updates via the application, leaving the serial recovery mechanism as the only DFU method.

I'm afraid my only suggestion is to try raising this issue in the MCUBoot project.

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

eb12345 — Tue, 19 Sep 2023 20:51:26 GMT

Thank you. Now I can build and test. Which brings me to the original issue. When you add CONFIG_MCUBOOT_SERIAL=y, you get an error:

C:\ncs\v2.4.2\bootloader\mcuboot\boot\boot_serial\src\boot_serial.c:634: undefined reference to `boot_handle_enc_fw'
collect2.exe: error: ld returned 1 exit status

The only way I found to alleviate this is to enable CONFIG_SINGLE_APPLICATION_SLOT=y. This is in the mcuboot child image. I think it's important failsafe to be able to use DFU/SMP Server (USB CDC, UART/Serial, or BLE) from the mcuboot image (can enter DFU in the bootloader using gpio or wait for DFU command for a short time). I don't care about switching images when you're in the bootloader, but there will be some cases where this will be the only way to recover a faulty image (correctly signed and encrypted, but one that needs to be overwritten manually).

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

Vidar Berg — Tue, 19 Sep 2023 09:20:09 GMT

Please add 'CONFIG_BOOT_SIGNATURE_TYPE_ECDSA_P256=y' to the mcuboot.conf overlay in your child_image folder. This should remove the dependency on mbedtls and allow you to use Tinycrypt module for both the signature validation and decryption.

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

eb12345 — Mon, 18 Sep 2023 17:01:24 GMT

I tried to build the sample application from the link above for the nrf52833dk board. It builds fine for the nrf5340dk, but not for the nrf52833dk. Below is a snippet of the build log, as I can't upload the complete log file.

<command-line>: warning: "MBEDTLS_CONFIG_FILE" redefined
<command-line>: note: this is the location of the previous definition
C:\ncs\v2.4.2\bootloader\mcuboot\ext\tinycrypt\lib\source\ctr_mode.c:33:10: fatal error: tinycrypt/constants.h: No such file or directory
33 | #include <tinycrypt/constants.h>

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

Vidar Berg — Mon, 18 Sep 2023 07:11:53 GMT

Hi,

Please try this sample put together by a coworker of mine: https://github.com/hellesvik-nordic/samples_for_nrf_connect_sdk/tree/main/bootloader_samples/keys_and_signatures/mcuboot_smp_encryption. It has been tested for the 'nrf52840dk_nrf52840' board.

[quote user="eb12345"]A lot of the documentation talks about encrypting images on secondary paritions, but to get this to compile, mcuboot requires CONFIG_SINGLE_APPLICATION_SLOT=y.[/quote]

To support encrypted DFU, the image must be stored in a secondary slot. So I'm not sure why the build fails without the CONFIG_SINGLE_APPLICATION_SLOT=y setting. I would help to see the build log if you want to investigate this further.

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

eb12345 — Sat, 16 Sep 2023 23:19:48 GMT

Thank you for this update. I was able to build the application.

A lot of the documentation talks about encrypting images on secondary paritions, but to get this to compile, mcuboot requires CONFIG_SINGLE_APPLICATION_SLOT=y.

Have you been able to get mcuboot image encryption to work with secondary paritions ? The version of mcuboot bundled in ncs talks about secondary partitions, but it seems to me that only newer versions of mcuboot support it. Is there a way to build a newer version of mcuboot without too much headache ?

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

Vidar Berg — Tue, 06 Jun 2023 13:35:26 GMT

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

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

papatel — Tue, 06 Jun 2023 13:08:58 GMT

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?

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

Vidar Berg — Tue, 06 Jun 2023 10:54:12 GMT

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.

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

papatel — Tue, 06 Jun 2023 10:17:23 GMT

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.

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

Vidar Berg — Tue, 06 Jun 2023 09:49:40 GMT

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).

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

papatel — Tue, 06 Jun 2023 09:37:35 GMT

Hello Vidar,

Thanks to your help (specifically your rather specific sample child_images zip file) I was able to compile my project with desired image signing and encryption support. There are no warnings/errors in the build log and I see the MCU child image pointing to the desired key files, hurray!.

Unfortunately, one last Huge issue remains: the build process does not generate an encrypted DFU file or firmware image. It does generate a signed image as expected. Reading around, all posts are a few years old on this subject so I'm hesitant to try them toward creating the TLV + encrypting the firmware image myself from the generated signed bin file... Looking forward to your guidance.

I know we've long strayed from the topic of this post and it may be wise to move this elsewhere. I can't imagine I'm the only one struggling here.

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

Vidar Berg — Wed, 31 May 2023 09:54:17 GMT

Hi,

The CONFIG_BOOT_* Kconfig symbols are used for MCUBOOT specific configurations. Therefore, they need to be applied to the MCUBOOT build, and not the application.

As you found out, you can point to a specific Kconfig file or fragment for your MCUBOOT build by editing the CMakelists.txt file. However, the more common approach for applying changes to a child image configuration is to create a 'child_image' folder in the project directory and add the Kconfig file/overlays there as outlined in the 'Image-specific variables' section of the SDK documentation.

[quote user="papatel"]But you have me concerned given your last response was defining a single .pem file.[/quote]

This file is only for encryption and not for signing. You should provide another key file to derive the public signing key from. Attached below is an example of what the 'child_image' folder may look like.

devzone.nordicsemi.com/.../6445.child_5F00_image.zip

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

papatel — Wed, 31 May 2023 04:07:35 GMT

Hello Vidar,

Instead of going back and forth too much. Let's start over. We want to enable both signature and encryption, can you give me the correct set of symbols to set and exactly what file to put them in? I expected to have everything in prj.conf but from searching around everyone puts these settings in mcuboot.conf (which that detail isn't documented?) and then you have to modify the CMakeLists file...

If you provide or point me to documentation on all the required details, I will execute verbatim and report back. To be 100% clear: we need bootloader signature verification using only a derived public key (the private key is NOT stored anywhere in the firmware image). For image encryption, we obviously need a private key in the image (but that will be a different key than the signing key pair). I believe this is the intended implementation based on Nordic's MCU boot errata. But you have me concerned given your last response was defining a single .pem file.

Thank you!

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

Vidar Berg — Tue, 30 May 2023 09:59:43 GMT

[quote user="papatel"]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[/quote]

What happens when you point this symbol to your key file, do you get a build error? To enable encryption in the bootloader, it should be sufficient to set the following symbols:

CONFIG_BOOT_ENCRYPT_EC256=y
CONFIG_BOOT_ENCRYPTION_KEY_FILE="<encryption key file>.pem"

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

papatel — Fri, 26 May 2023 12:07:02 GMT

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.

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

Vidar Berg — Fri, 26 May 2023 11:40:09 GMT

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

[quote user="papatel"]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.[/quote]

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.

[quote user="papatel"]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[/quote]

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.

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

papatel — Fri, 26 May 2023 07:15:13 GMT

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...

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

Vidar Berg — Fri, 26 Aug 2022 15:00:20 GMT

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.

[quote user="FARLY7"]It seems like this feature is not fully implemented or deprecated?[/quote]

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.

[quote user="FARLY7"] 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.[/quote]

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:

devzone.nordicsemi.com/.../4786.child_5F00_image.zip

Regards,

Vidar

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

FARLY7 — Fri, 26 Aug 2022 06:25:11 GMT

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

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

Vidar Berg — Thu, 25 Aug 2022 21:58:33 GMT

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