bootloader singeing and encryption.

I am trying to use MCUBoot . Followed this Add DFU support to your application , and this works.

I generated key.pem files, and try to sign the file with 

CONFIG_SB_SIGNING_KEY_FILE= <path to *pem file>

it builds, but the I do it with a different key file, and I am still able to upload the new file via mobile device manager.

So, what am I missing?

Actually, I understand that signing the file just adds the signature as meta data to the file, but does not encrypt it. So everyone that has the file can use it with his version of MCUBoot?

I would like to have a way to encrypt the whole bin file, and let the bootloader decrypt it, so only my bootloader can be used. How can this be done?

BR

Johanan

Parents
  • Hi, 

    CONFIG_SB_SIGNING_KEY_FILE= <path to *pem file>

    Are you using nRF Secure Immutable Bootloader (NSIB) by enabling CONFIG_SECURE_BOOTCONFIG_SB_SIGNING_KEY_FILE is used for signing the NSIB firmware image. To sign the mcuboot image, it should use CONFIG_BOOT_SIGNATURE_KEY_FILE. Here is the example

    So everyone that has the file can use it with his version of MCUBoot?

    You have two keys: A Private Key and a Public Key. The firmware image is signed with the Private Key, and the bootloader has the Public Key. The bootloader can use the Public Key to verify that the firmware image is signed with the Private Key. Only you have the Private Key to sign the firmware image.

    I would like to have a way to encrypt the whole bin file, and let the bootloader decrypt it, so only my bootloader can be used. How can this be done?

    Unfortunately, encrypted DFU is a feature we do not officially support in our SDK. 

    Regards,
    Amanda H.

  • Hello,

    When using mobile app Device Manger to do the update, in case that public/private keys don't match, will the file be uploaded, and then the MCUboot will simply run the older version, or will it prevent the upload altogether?

    I other words, how does the end user, who is trying to upload a new version, get a notification that he is trying to upload a wrong file?

     Thanks

    Johanan

Reply
  • Hello,

    When using mobile app Device Manger to do the update, in case that public/private keys don't match, will the file be uploaded, and then the MCUboot will simply run the older version, or will it prevent the upload altogether?

    I other words, how does the end user, who is trying to upload a new version, get a notification that he is trying to upload a wrong file?

     Thanks

    Johanan

Children
  • The DFU should fail since you have used the wrong key.

    -Amanda H.

  • So I am doing something wrong.

    1. I create a file with

    CONFIG_BOOT_SIGNATURE_KEY_FILE="correct_key.pem"

    2 I flash memory with the file (via VSCode Flash)

    3. Check that program works.

    4. I change blink time in main.c, build a new file, then I put dfu_application.zip in my phone.

    5. I upload the file from phone to device with the Device Manager app.

    6 .All is OK, the new file runs with new blink time.

    Now I wish to make a file with different signature:

    7. I change signature line in prj.conf to:

    CONFIG_BOOT_SIGNATURE_KEY_FILE="not_correct_key.pem"

    8. I change again the blink time

    9. I rebuild configuration and project, now it is signed by a wrong private key file.

    10. I copy the new  dfu_application.zip to phone.

    11. Upload as before, all is ok, and new program with wrong key runs correctly, blink time updated.

    I expected that the second file will be notified as wrong, and the bootloader will run the older version.

    What am I missing?

    Thanks

    Johanan

  • Hi, 

    Which NCS are you using?

    Can you modify the log in the updated image to see if it updates successfully or not?

    I have tested with v2.3.0, I see it failed to update to the uploaded image.

    *** Booting Zephyr OS build v3.2.99-ncs2 ***
    I: Starting bootloader
    I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
    I: Secondary image: magic=good, swap_type=0x2, copy_done=0x3, image_ok=0x3
    I: Boot source: none
    I: Swap type: test
    E: Image in the secondary slot is not valid!
    I: Bootloader chainload address offset: 0xc000
    *** Booting Zephyr OS build v3.2.99-ncs2 ***
    Starting Bluetooth Peripheral LBS example 
    build time: Jun  6 2023 11:28:57
    E: Unable to register handle 0x0016
    I: 2 Sectors of 4096 bytes
    I: alloc wra: 0, fd0
    I: data wra: 0, 1c
    Bluetooth initialized
    Advertising successfully started
    Connected

    Here is my test project 7571.peripheral_lbs_DFU.7z for NCS v2.3.0. 

    Beware that this code/configuration is not fully tested or qualified and should be considered provided “as-is”. Please test it with your application and let me know if you find any issues.

    -Amanda H.

  • Thank you for this project.

    I am using same v2.3.0 SDK

    It looks like I have a big misunderstanding.

    in your project, you have a child image, in which you have another prj.conf file, and there you set the key file.

    I have no child image in my project at all. In order to make a bootable bin file, I just added the MCUBoot enable in my prj.conf.

    Please explain in short step by step, adding MCUboot with a key to a sample project.

    BR

    Johanan

  • Hi, 

    Since the mcuboot is built as child_image, it can be set with the configuration under the child_image folder. See Image-specific variables doc. 

    -Amanda H.

Related