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

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

Parents
  • 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

Reply
  • 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

Children
  • 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

  • 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

Related