LP-EM-CC2340R53: Firmware signing using our PKI keys ( public , private and root keys)

Hello Ilan T,

In our SDK we have documentation about this:

OAD Storage & Security — SimpleLink Low Power F3 SDK BLE5-Stack User's Guide 9.10.00 documentation

And in our trainings:

Bluetooth Low Energy Enhanced Over the Air Download (OAD) Fundamentals

As well as documented by MCUBoot itself, since we use the imgtool here I would recommend reading this:

Image tool | mcuboot 

Thanks,
Alex F

Hi  Alex F,

Our objective is to use our company key generation server to produce the key pair.
Also, we want to use hardware Secure storage element in our product, to secure the keys, then the MCU boot
should read the keys from the hardware secure storge element for performing image signature verification?

Is the use of imgtool to generate is mandatory to generate Key pairs for firmware signing?

Is that imgtool command "./scripts/imgtool.py keygen -k filename.pem -t ecdsa-p256 " is required to generate Keyfile
or any other external key generation program (say our Company secure server generating keys) shall be used?

- In case external Key generator tool is used, one of the inputs could be signing algorithm,
do you see any other inputs are required for external key generator tool ?

I have read through docs.mcuboot.com/imgtool.html as per the document 3 steps are mentioned,

1. For Generating Private key:
./scripts/imgtool.py keygen -k filename.pem -t ecdsa-p256
- here it is mentioned this key file [<filename.pem>] is what is used to sign images.
- So this should be private key file , is my understanding correct

2. Next step provide is how to extract the public key from Keyfile.
./scripts/imgtool.py getpub -k filename.pem
- Is [<filename.pem>] provided in the above command, is same as generated using command
./scripts/imgtool.py keygen -k filename.pem -t ecdsa-p256

3. Signing images:

${COM_TI_SIMPLELINK_LOWPOWER_F3_SDK_INSTALL_DIR}/tools/common/mcuboot/imgtool sign --header-size 0x100 --align 4
--slot-size 0x3B000 --version 1.0.0 --pad-header --pad
--key ${COM_TI_SIMPLELINK_LOWPOWER_F3_SDK_INSTALL_DIR}/source/third_party/mcuboot/root-ec-p256.pem
${BuildArtifactFileBaseName}_noheader.bin
${BuildArtifactFileBaseName}_v1.bin

In the above step which is used to sign the firmware "basic_ble_oad_dual_image_LP_EM_CC2340R53_freertos_ticlang"
"root-ec-p256.pem" key is inputted , 

Is that the Key file generated using command [./scripts/imgtool.py keygen -k root-ec-p256.pem -t ecdsa-p256],
can you confirm?

IS that the "root-ec-p256.pem" is the keyfile that MCU boot mentioned in their documenttaion , as
"Development key distributed with MCUboot that can be used for testing" ??

Also in the SDK "C:\ti\simplelink_lowpower_f3_sdk_8_40_00_61\source\third_party\mcuboot"

Following keys are present Could you please let us know details about what those are used for with respect to MCU boot
secure boot process.

enc-ec256-priv.pem
enc-ec256-pub.pem
root-ec-p256.pem

With Regards
Ilan

Hello Ilan,

To comment on your post:

Yes, the thee steps you have listed above are needed.

1. We need to use the imgtool script to sign your images with your specific target key

2. We need to again use the imgtool script to generate a public key

3. Then finally inside the post-build steps of your project, you need to change the "generic" keys to your target key. 

-On the post build steps topic, it should be possible to just "overwrite" the orignal keys in the SDK.

"NOTE: The key root-ec-p256.pem is for example use only. Provide your own key for your application."

Also note in the MCUBoot project itself we have some key related file(s):

Onto secure boot:
"

Enable as a Secondary Secure Bootloader

MCUboot can also be enabled as a secondary secure bootloader to Secure Boot.

Open the project's *.syscfg file. The Secure Boot configuration is found under TI DEVICES -> Device Configuration -> Security Configuration. If Secondary Secure Bootloader Enabled is checked in sysconfig and SSB slots are defined, Secure Boot can verify MCUboot and once verification is complete, transfer control to it. From there, MCUboot can verify the images in each slot. The boot loader base and sizes are determined by Secure Boot, meaning those options in MCUboot SysConfig will be overwritten by Secure Boot. In this example MCUboot still has control over the slot definitions.

Note that MCUboot does not support the same authentication algorithms that Secure Boot supports. This means that an application signed by imgtool will not work for Secure Boot. Likewise, an application signed by sbtool will not work for MCUboot.

Refer to SDK example secure_boot for additional details on how to enable Secure Boot and sign Secure Boot images."

Thanks,
Alex F