Hi Kevin,
Recently there are two major change in TF-M MCUBoot: - images signed separately with different keys and concatenated after to make one blob. It drives by MCUBOOT_IMAGE_NUMBER (default is 2 on AN521) - It's possible to use keys from HW and not hard-code the public key to the MCUBoot code at compile time. It derives by MCUBOOT_HW_KEY (default is True on AN521) - You can check the bl2/ext/mcuboot/MCUBoot.cmake two see how the scripts are invoked, which order, what kind of attributes. Additional info is in docs/user_guide/tfm_secure_boot.rst
You can revert back to previous behaviour, single(S+NS) signed image(key is: *3072.pem) and public-key is embedded in MCUBoot code base with setting MCUBOOT_IMAGE_NUMBER=1 and MCUBOOT_HW_KEY=False
Tamas
-----Original Message----- From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of Kevin Townsend via TF-M Sent: 13 September 2019 11:48 To: Thomas Törnblom via TF-M tf-m@lists.trustedfirmware.org Subject: [TF-M] Signing merged single image with dual keys
Hi,
Updating to the latest code in the TF-M repo, I noticed that there are now two separates keys for signing images:
- *3072.pem for the S image - *3072_1.pem for the NS image
It's not clear to me how to make this work with a single merged image, which is what we generally need, with an IPC-based system where the S image is generated via the TF-M repo and the NS image in Zephyr, making calls to the S services via the PSA APIs.
Previously, we used the ASSEMBLE.PY tool in BL2 to merge the TF-M S and Zephyr NS images, outputting a single binary that we then signed via IMGTOOL.PY using the default or user-defined .pem file. This no longer works, and any attempt to use a binary generated via this method results in:
[INF] Starting bootloader [INF] Swap type: none [INF] Swap type: none [ERR] Authentication failed! Image in the primary slot is not valid. [ERR] Unable to find bootable image
With the latest dual-key TF-M code, when we build the TF-M repo, we get an S image that is signed using the 3072.pem key, but after a bit of trial and error I haven't found the secret handshake on how to sign the NS image and merge them into a single binary and then copy them over to the MPS2+ (or other HW) and have the BL accept them at startup.
Any pointers on how to generate a single merged image with both parts signed using the different keys, or am I going about this the wrong way?
Kevin -- TF-M mailing list TF-M@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hi Tamas,
Thanks for the explanation.
Reverting to the previous behaviour works fine, and I'll go through the updated documentation to understand how the signing procedure would work with IPC where only one image is being used from the TF-M build, and the NS image is coming from another build system and must be signed. It's not clear to me how mcuboot/BL2 would handle the separate images, but I'm sure it's detailed in that .rst file, or there are at least sign points in the right direction.
Thanks, Kevin
On Fri, 13 Sep 2019 at 13:40, Tamas Ban Tamas.Ban@arm.com wrote:
Hi Kevin,
Recently there are two major change in TF-M MCUBoot:
- images signed separately with different keys and concatenated after to make one blob. It drives by MCUBOOT_IMAGE_NUMBER (default is 2 on AN521)
- It's possible to use keys from HW and not hard-code the public key to the MCUBoot code at compile time. It derives by MCUBOOT_HW_KEY (default is True on AN521)
- You can check the bl2/ext/mcuboot/MCUBoot.cmake two see how the scripts are invoked, which order, what kind of attributes. Additional info is in docs/user_guide/tfm_secure_boot.rst
You can revert back to previous behaviour, single(S+NS) signed image(key is: *3072.pem) and public-key is embedded in MCUBoot code base with setting MCUBOOT_IMAGE_NUMBER=1 and MCUBOOT_HW_KEY=False
Tamas
-----Original Message----- From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of Kevin Townsend via TF-M Sent: 13 September 2019 11:48 To: Thomas Törnblom via TF-M tf-m@lists.trustedfirmware.org Subject: [TF-M] Signing merged single image with dual keys
Hi,
Updating to the latest code in the TF-M repo, I noticed that there are now two separates keys for signing images:
- *3072.pem for the S image
- *3072_1.pem for the NS image
It's not clear to me how to make this work with a single merged image, which is what we generally need, with an IPC-based system where the S image is generated via the TF-M repo and the NS image in Zephyr, making calls to the S services via the PSA APIs.
Previously, we used the ASSEMBLE.PY tool in BL2 to merge the TF-M S and Zephyr NS images, outputting a single binary that we then signed via IMGTOOL.PY using the default or user-defined .pem file. This no longer works, and any attempt to use a binary generated via this method results in:
[INF] Starting bootloader [INF] Swap type: none [INF] Swap type: none [ERR] Authentication failed! Image in the primary slot is not valid. [ERR] Unable to find bootable image
With the latest dual-key TF-M code, when we build the TF-M repo, we get an S image that is signed using the 3072.pem key, but after a bit of trial and error I haven't found the secret handshake on how to sign the NS image and merge them into a single binary and then copy them over to the MPS2+ (or other HW) and have the BL accept them at startup.
Any pointers on how to generate a single merged image with both parts signed using the different keys, or am I going about this the wrong way?
Kevin
TF-M mailing list TF-M@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
tf-m@lists.trustedfirmware.org