This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

How to create a MCUBoot image and an application image without modifying the SDK?

Dear All,

I am trying to create  an application that uses the MCUBoot, so that later I can perform a FOTA operation.

From what I know so far there are some keys in the SDK that the MCUBoot prj.conf is pointing to and uses those keys to create the signed bin files.

So if someone wants to use a custom key, he could potentially replace thekey in the SDK and then it would work. But this would require to modify the SDK, which I would like to avoid completely.

While I was trying to figure out this issue, I came across this link that suggests that someone can first compile the application, including the MCUBoot and then sign it with a custom key, that felt right the exact thing I am looking for. But this unfortunately didn't work.

What I did is this:

west build -p auto -b nrf9160dk_nrf9160ns
west sign -t imgtool -- --key private-key.pem --header-size 32 --pad

And what I got is this:

Error: Header padding was not requested and image does not start with zeros
FATAL ERROR: command exited with status 2: 'C:\Python37\Scripts\imgtool.EXE' sign --version 0.0.0+0 --align 4 --header-size 0 --slot-size 196608 --key private-key.pem --header-size 32 --pad C:/Users/SODAQ/Desktop/GIT_Projects/bayer_tag/build/zephyr/zephyr.bin 'C:\Users\SODAQ\Desktop\GIT_Projects\bayer_tag\build\zephyr\zephyr.signed.bin'


From what I can understand the

CONFIG_BOOTLADER_MCUBOOT=y

effectively compiles and adds the bootloader in the project, but the bootloader uses the default key of the SDK and this very undesired.

So is there any way possible to effectively sign the .hex file again with the custom private key and then be able to use the .bin file with the custom private key, without modifying the SDK at all?

Also, I am not sure what is the role of the SPM in this process.

I am using the NCS SDK v1.3.0

Thank you very much for your assistance

Parents
  • Hi !

    Yes, you should be able to set the configurations I mentioned below to point to the file containing the key you want to use and MCUboot will use that instead.

     

    Also, I am not sure what is the role of the SPM in this process.

     The SPM is for when you're running an application on the non-secure domain of the chip. This application set sup the device with trusted execution so that it can run your application on the non-secure domain. 

    Let me know if you have any more questions!

    Best regards,

    Heidi

Reply
  • Hi !

    Yes, you should be able to set the configurations I mentioned below to point to the file containing the key you want to use and MCUboot will use that instead.

     

    Also, I am not sure what is the role of the SPM in this process.

     The SPM is for when you're running an application on the non-secure domain of the chip. This application set sup the device with trusted execution so that it can run your application on the non-secure domain. 

    Let me know if you have any more questions!

    Best regards,

    Heidi

Children
  • Hi Heidi,

    I am a colleague of Giannis and took over the FOTA implementation.

    I have created a mcuboot.conf file in the project folder, containing solely this line:
    CONFIG_MCUBOOT_SIGNATURE_KEY_FILE="key.pem"

    The same line I added to the prj.conf. There we also specified CONFIG_BOOTLOADER_MCUBOOT=y.

    I also added the key.pem file to the project folder. I have created this key.pem with the instructions of this link.

    As we do not want to make changes to the ncs (in this case to keys.c), I was not sure what to do with this instruction.
    I skipped it for now, which is probably not the best idea.

    During build I get the following warning:

    === child image mcuboot -  end ===
    
    CMake Warning at C:/ncs/nrf/modules/mcuboot/CMakeLists.txt:151 (message):
      
    
            ---------------------------------------------------------
            --- WARNING: Using default MCUBoot key, it should not ---
            --- be used for production.                           ---
            ---------------------------------------------------------
    
    
    
    
    CMake Warning at C:/ncs/nrf/modules/mcuboot/CMakeLists.txt:352 (message):
      CONFIG_MCUBOOT_SIGNATURE_KEY_FILE is set to "key.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.
    



    I am not sure what these warnings mean. Has the imaged been signed during build? How can I check that the image has been signed correctly? Or is there still something going wrong?

    I tried using this
    west sign -t imgtool -- --key key.pem --header-size 32 --pad
    after building but that still gives the same error as Giannis had initially.


    Also can you tell me how I should incorporate the public key in the code?

    Thanks in advance.

    Kind regards,
    Maaike

  • Hi!

    You can specify the public key file without modifying NCS in one of the following ways:

    • in a dedicated `mcuboot_prj.conf` and pass it to the build system as: `-Dmcuboot_CONF_FILE=mcuboot_prj.conf`
      containing:
      CONFIG_BOOT_SIGNATURE_KEY_FILE=<path>/public-key.pem
      If using this method, CONFIG_BOOT_SIGNATURE_KEY_FILE <path> can be omitted and path will be taken relative to the location of the conf file.
    • In a Kconfig fragment, like: mcuboot_overlay-keys.conf , and pass it to the build system as: `-Dmcuboot_OVERLAY_CONFIG=mcuboot_overlay-keys.conf` containing:
      Path must be absolute in this case.
      CONFIG_BOOT_SIGNATURE_KEY_FILE=<path>/public-key.pem
    • using `-Dmcuboot_CONFIG_BOOT_SIGNATURE_KEY_FILE=<path>/public-key.pem`.
      Path must be absolute in this case.

    So try one of these methods and let me know if you still see the warnings.

    Best regards,

    Heidi

Related