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

Parents
  • 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

Reply
  • 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

Children
No Data
Related