decoupling the placement of public key in mcuboot and signing the image

Hi Nordic providers of solutions to problems great and small.

Good mornings.

We have been going through the OTA/DFU process for a signed image as the final step of our product and noticed some awkwardness in the nRF Connect SDK work flow for image signing and for placing the public key in mcuboot.

The typical workflow in product developement requires developers to only get access to the public key that has to get placed in mcuboot. The folks that sign the image have some statutatory requirements where they are held accountable to any leaks of the private key so the private key is known only to a very small team.

Currently the build setup for mcuboot and a signed image requires private key access to the developers which is awkward.

I did look at the case below but its solution was a bit hazy.

https://devzone.nordicsemi.com/f/nordic-q-a/80629/decouple-mcuboot-public-key-storage-and-image-signing-nrf9160-mcuboot

Placing the C struct of the public key into the keys.c

Help to to pull the signing out of the build process and make it an explicit and separate step to generate a signed image from an unsigned image.

Thanks for the support
David

  • I did look at the case below but its solution was a bit hazy.

    https://devzone.nordicsemi.com/f/nordic-q-a/80629/decouple-mcuboot-public-key-storage-and-image-signing-nrf9160-mcuboot

    Placing the C struct of the public key into the keys.c

    This happens automatically by the current build system. What I wrote under "How it currently works" is how the build system automatically signs images (and generates the public key and places it inside keys.c). What I wrote under "How to modify it to get signed externally" is what you have to do in order to decouple the image signing.

    This was written 7 months ago, so keep in mind that there may have happen some changes since then.

    Best regards,

    Simon

  • We cannot use the automated key gen in the nRF connect SDK environment as that puts the private key into the build and increases the probability of a leak.

    This is what I have proposed for the decoupling:

    1. The core team will generate a private key and public key pair. 
    The resulting key file with the public key will be used  to generate the C Struct for the public key.
    I guess we will have to manually place this C struct in the right location and also modify the build so that it does not get overwritten.

    A. Question : We should be able use imgtool,py to get the C struct for the ECDSA key type, Is that correct ?

    B. Question: How do we manually place this in the build and ensure that it is not overwritten by the existing work flow which is autogenerating the keys ?

    ==

    2. The C struct file containing the public key is delivered by the core team to the development team.

    3. The C struct file is placed in the mcuboot build manually and the hex file is delivered to the factory for programming.

    4. The updates to the product are built by the development team  and an unsigned image(bin) is generated and delivered to the core team. 

    5. The core team signs the image and delivers a signed image to the update process through the mobile apps for OTA to the products on the field.

    C. Question : How do we manually sign the unsigned image with imgtool to get a signed image and what are the options to be used for it. The ECDSA keys also seem to have padding issues to be dealt with. The correct options to give to imgtool appear important.

    Guidance on questions A, B and C are useful.

    Thanks for the support
    David

  • daviddedwin said:
    We cannot use the automated key gen in the nRF connect SDK environment as that puts the private key into the build and increases the probability of a leak.

    If you follow the steps in the referred ticket, this will not be the case. Before answering your questions, let me make sure we're on the same page. If you follow the steps in Decouple MCUBoot public key storage and image signing (nrf9160 + MCUBoot), you will end up with this:

    This seems exactly what you're asking for. The key generation is decoupled from the application development, and the public key will be put in the correct location automatically.

    Could you clarify if I have misunderstood something

    Best regards,

    Simon

  • Yes, your understanding is reasonable. I broke it out iinto specific questions where additional input was requested.

    Thanks
    David

  • Okay, I understand. I will look into and try to answer your questions tomorrow.

    Best regards,

    Simon

Related