• State Verified Answer
  • Locked Locked
  • Replies 6 replies
  • Subscribers 69 subscribers
  • Views 1705 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 287285
Options
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Override MCUBoot build directory

sachrmed

Hello,

It appears as though nRF Connect does not currently support building encrypted images, so I am trying to implement it myself.

Part of creating encrypted images is providing the encryption key in mcuboot/boot/zephyr/keys.c

To that end, I have copied mcuboot into my project directory and edited that file. However, I'm unsure how to direct the build system to build from my copy of mcuboot and not from the one installed by nRF Connect.

Note that I am able to build encrypted images by editing keys.c in the nRF Connect installation and editing the nrf/modules/mcuboot/CMakeLists.txt to provide the "--encrypted" argument to imgtool.py. This proves that building encrypted images is possible, however I would like to avoid editing the installed SDK as several projects will be built against it, each with their own encryption.

Ideally I'd like to leverage the nRF Connect build as well since it figures out things like the header size and alignment to pass to imgtool. This would allow me to build a template that can work across projects as well.

Is it possible to point the build system to my copy of mcuboot?
Or is there perhaps another way to build encrypted images?

Thank you very much!

  • 0

    Hi Sachrmed, 

    I haven't tried to build MCUBoot with encrypted image myself, but could you give me more information on the limitation you found in NCS that encrypted image can't be use ? 
    As far as I know it's at least supported by MCUBoot ? https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/mcuboot/encrypted_images.html

    Regarding your question, if you have a look at CMakeLists.txt in zephyr.txt folder you can find this: 

    So mcuboot.cmake is included when you enable CONFIG_BOOTLOADER_MCUBOOT. If you have a look inside mcuboot.cmake you can see the build system used to include the child image. 

    In addition in multi_image.cmake you can find CONFIG_NCS_MCUBOOT_IN_BUILD is added when CONFIG_BOOTLOADER_MCUBOOT. You may want to include it in your application configuration. 

    If you use partition manager, then you need to look into pm.yml.tfm as well. 

  • 0

    Hi Hung Bui,

    Thanks for the reply!

    Sorry, it's not that encrypted images cannot be used, but that I'm having trouble generating the encrypted image without editing files within the NCS installation.

    One limitation I've noticed is that the NCS build scripts do not pass the "--encrypt" argument when invoking imgtool.py. It also seems that even for signed images, the signature .pem file needs to be placed in the mcuboot directory inside the NCS installation. Ideally I wouldn't have to edit anything in the NCS installation directories.

    In nrf/modules/mcuboot/CMakeLists.txt you can see where the "sign_cmd" is created to invoke imgtool. Here, it calls the "sign" subcommand to create a signed image. If I edit this file to also pass the "--encrypt" flag, I am able to successfully create encrypted images.

    However, to make encrypted images work, I need to edit the "keys.c" file found in the mcuboot sources.

    I'm trying to copy the mcuboot source files out of the NCS installation and into my project repository where I can edit "keys.c" as well as place the signature and encryption .pem files.

    I'm then able to build this fork of mcuboot separately from my application, but I'm unable to get it to boot the application itself.

    The problem comes with putting this all together with the NCS build scripts.

    As you've said, once you set CONFIG_BOOTLOADER_MCUBOOT to build a bootable image, NCS includes mcuboot.cmake and goes and builds it's own mcuboot. My guess right now is that the resulting application image is placed according to where NCS's mcuboot will find it, but not where my forked mcuboot will find it. I'm not sure if this is necessarily the case since the build scripts are rather complicated and I'm still trying to wrap my head around it all.

    Ultimately, I'm trying to create encrypted images that boot with mcuboot and can be updated over SMP.

    So far, I've proven that it's possible, but I have to edit files in the NCS installation which will cause problems for other projects we are working on.

    If we can find a way to build mcuboot from a directory outside of the NCS installation, and get the "--encrypt" flag passed to imgtool.py, I think that will create bootable encrypted images.

    Hopefully that all make sense Slight smile

    Also, thanks for the info about multi_image.cmake and partition manager. I'll have a look at those today.

  • 0

    Hi Sachrmed, 
    I'm sorry for late response. It was Easter vacation in Norway last week. 

    I will check with the developers to see if there is any solution to do "--encrypt" without modify the SDK and let  you know what I find. 

  • 0 in reply to Hung Bui

    No problem! Thanks for looking into that.
    I'm looking forward to seeing if you can come up with a solution.

  • +1 in reply to sachrmed

    Hi Sachrmed, 

    I got the response from the team. I don't have the solution on how you can configure to choose your own mcuboot but the explanation why encrypted image is not fully supported in our solution. 

    The main reason is the security concern. We don't want to provide a solution that you would use a single master key for all of your devices.  Since there isn't a way to secure store the key on nRF52 flash, when one of the device is hacked and the master key is extracted you have the risk that all your device can be hacked using the same master key. 

Related