How to encrypt FW for MCUBOOT image update?


In our project we must have FOTA functionality, and we want to encrypt these updates

I'm trying to create an encrypted firmware image update for MCUBOOT with "blinky" and "smp_srv" samples. I'm sucessfully updated a signed image without encryption, but can't find any manual how to do create an encryped update. According to this description I understood, that I must encrypt FW packet only, but how should I do it: which tool, which commands, what is the sequence ..? 

I tried adding CONFIG_MCUBOOT_EXTRA_IMGTOOL_ARGS="-E my_key_file" to prj.cfg, but all generated hex/bin files contain the same FW payload without encryption (checked with hex editor). 

There is some info here  about the encryption process, but sorry, it's still not obvious for me what I should do. Is there any step-by-step manual how to create encrypted FW images? Maybe an example project or something else? 

Thank you in advance for any help

  • Hi,

    The documentation you point to is from the MCUBoot documentation. However, we do not have an examples of encrypted firmware images in the nRF Connect SDK, nor support for it in tools. It should be possible, though. In principle you build MCUBoot with BOOT_ENCRYPT_EC256 (or _RSA etc, depending on algorithm), and use imgtool as specified in the documentation.

  • I believe that firmware encryption is a very important feature, which is important for many developers - it helps protecting their IP. Unfortunately NRF Connect SDK still doesn't support firmware encryption "from the box", but it's possible. I would like to share some partial results. Would be nice if someone (more experienced than me) could fix this issue finally
    I use NRF5340-DK for my experiments.

    1) In original mcuboot github repository "firmware encryption" has already made more user friendly - they added new Kconfig option MCUBOOT_ENCRYPTION_KEY_FILE I tried do modify cmakelists.mcuboot in the same way, but eventually found that it doesn't have any impact on imgtool (which is used for firmware encryption).
    Even more: changing of CONFIG_MCUBOOT_EXTRA_IMGTOOL_ARGS option also doesn't work. Just nothing happens... The reason for this - this Kconfig option is mentioned in v1.7.1\zephyr\cmake\mcuboot.cmake, but NRF CONNECT SDK uses v1.7.1\nrf\modules\mcuboot\CMakeLists.txt for Mcuboot instead of it. And it doesn't contain any mentions about additional imgtool arguments.
    2) Obviously, v1.7.1\zephyr\cmake\mcuboot.cmake should be modified by adding imgtool extra arguments. Another option - is to sign "app_to_sign.bin" file manually with imgtool via command line. Just copy signing command from your file and add "-E path_to_your_key" option to this copied command. I tried both variants, and they works - the "app_update.bin" is becoming encrypted and contains 0x04 encrypted flag
    3) Unfortunatelly, after uploading a new encrypted firmware image to MCU (I use BLE OTA DFU) the result is strange and not predictable. Regardless I use an app core image update, mcuboot is trying to update net core - of course without success, thus it fails and recovers the previous image
    4) The way I found to solve this issue - is to disable perform network core updates all together. To do that you need to set the following Kconfig variable in your project:
    This allowed me to perform DFU with the encrypted image successfully. Unfortunately this solution is not so good, because in future I will probably need to update net core image also. But it is disabled...

    I created a github repository with my test project  This project only blinks LED on NRF5340-DK, and allows to updated firmware via Bluetooth OTA. Could someone check it and tell me how to update an encrypted firmware with CONFIG_NRF53_UPGRADE_NETWORK_CORE=y option?
    Thank you

  • Hi,

    Did multi image DFU (app core and net core) work before you added firmware encryption? Comparing with nrf\samples\bluetooth\peripheral_lbs\boards\thingy53_nrf5340_cpuapp.conf (just to use a sensible reference) there are some things missing, like CONFIG_UPDATEABLE_IMAGE_NUMBER=2 (I see you have it for the subimage for cpunet, but it should be used in the application in cpuapp).

    Regarding the importance of firmware encryption I just want to note that it can give a false sense of security. Even if you use encrypted DFU images and disable debugger access it is possible to dump flash content in a lab by decapping the IC and probing on the die in the hypothetical case where someone wanted to analyze your product.

  • My project now is supposed to use separate DFU for app and net core. I haven't finished trying multi image DFU - I wasn't able to compile with CONFIG_UPDATEABLE_IMAGE_NUMBER=2, but I beleive it is because I haven't added mcuboot_primary_1 and mcuboot_secondary_1 partitions (need some time to figure out how to do it)

    I do agree, that any MCU can be dumped in a lab - but without encryption anyone even don't need a lab: just copy a dump from a firmware update and clone your product