Injecting public keys into FTDs for FIT verification
Hi all,
in order to use CONFIG_FIT_SIGNATURE and also CONFIG_SPL_FIT_SIGNATURE, a public key needs to be placed into the control FDT. So far, I only found mkimage being able to do that during FIT image signing. That is fairly unhandy and often incompatible with how firmware is built & signed vs. how the lifecycle of the artifacts to be loaded and verified look like. Is there really no other way than mkimage -K?
I'm currently considering to derive a tool that, given a public key (which is easy to hand around, compared to the private key needed for signing), injects them into a FDT. Then I would hook that up as generic feature for U-Boot builds, enriching all control FTDs already during the first build with this when requested.
Am I missing an even simpler approach?
Thanks, Jan
On 05/11/2021 11.16, Jan Kiszka wrote:
Hi all,
in order to use CONFIG_FIT_SIGNATURE and also CONFIG_SPL_FIT_SIGNATURE, a public key needs to be placed into the control FDT. So far, I only found mkimage being able to do that during FIT image signing. That is fairly unhandy and often incompatible with how firmware is built & signed vs. how the lifecycle of the artifacts to be loaded and verified look like. Is there really no other way than mkimage -K?
I'm currently considering to derive a tool that, given a public key (which is easy to hand around, compared to the private key needed for signing), injects them into a FDT. Then I would hook that up as generic feature for U-Boot builds, enriching all control FTDs already during the first build with this when requested.
Am I missing an even simpler approach?
You're not missing an existing upstream simpler approach, but it's certainly an itch that others have had [1] [2]. My latest attempt
https://lore.kernel.org/u-boot/20210928085651.619892-1-rasmus.villemoes@prev...
does now have an R-b by Simon, so now I'm just waiting for that to actually make it into master. I have the script(s) that will convert a public key to a .dtsi fragment, and I'm happy to share that.
Rasmus
[1] https://lore.kernel.org/u-boot/CAO5Uq5TyTMacERo01weTEda-5X4Fx-VUoYFHa=mBYhW-... [2] https://lore.kernel.org/u-boot/94d75c521aed46dbb54a8275be2f529e@kaspersky.co...
On 05.11.21 11:28, Rasmus Villemoes wrote:
On 05/11/2021 11.16, Jan Kiszka wrote:
Hi all,
in order to use CONFIG_FIT_SIGNATURE and also CONFIG_SPL_FIT_SIGNATURE, a public key needs to be placed into the control FDT. So far, I only found mkimage being able to do that during FIT image signing. That is fairly unhandy and often incompatible with how firmware is built & signed vs. how the lifecycle of the artifacts to be loaded and verified look like. Is there really no other way than mkimage -K?
I'm currently considering to derive a tool that, given a public key (which is easy to hand around, compared to the private key needed for signing), injects them into a FDT. Then I would hook that up as generic feature for U-Boot builds, enriching all control FTDs already during the first build with this when requested.
Am I missing an even simpler approach?
You're not missing an existing upstream simpler approach, but it's certainly an itch that others have had [1] [2]. My latest attempt
https://lore.kernel.org/u-boot/20210928085651.619892-1-rasmus.villemoes@prev...
does now have an R-b by Simon, so now I'm just waiting for that to actually make it into master. I have the script(s) that will convert a public key to a .dtsi fragment, and I'm happy to share that.
Cool, that would be very welcome!
Jan
Rasmus
[1] https://lore.kernel.org/u-boot/CAO5Uq5TyTMacERo01weTEda-5X4Fx-VUoYFHa=mBYhW-... [2] https://lore.kernel.org/u-boot/94d75c521aed46dbb54a8275be2f529e@kaspersky.co...
On 05.11.21 13:42, Jan Kiszka wrote:
On 05.11.21 11:28, Rasmus Villemoes wrote:
On 05/11/2021 11.16, Jan Kiszka wrote:
Hi all,
in order to use CONFIG_FIT_SIGNATURE and also CONFIG_SPL_FIT_SIGNATURE, a public key needs to be placed into the control FDT. So far, I only found mkimage being able to do that during FIT image signing. That is fairly unhandy and often incompatible with how firmware is built & signed vs. how the lifecycle of the artifacts to be loaded and verified look like. Is there really no other way than mkimage -K?
I'm currently considering to derive a tool that, given a public key (which is easy to hand around, compared to the private key needed for signing), injects them into a FDT. Then I would hook that up as generic feature for U-Boot builds, enriching all control FTDs already during the first build with this when requested.
Am I missing an even simpler approach?
You're not missing an existing upstream simpler approach, but it's certainly an itch that others have had [1] [2]. My latest attempt
https://lore.kernel.org/u-boot/20210928085651.619892-1-rasmus.villemoes@prev...
Looking at this path: I would also need it for SPL, so that SPL can validate the container for the main U-Boot. Seems that is missing here, isn't it?
Jan
does now have an R-b by Simon, so now I'm just waiting for that to actually make it into master. I have the script(s) that will convert a public key to a .dtsi fragment, and I'm happy to share that.
Cool, that would be very welcome!
Jan
Rasmus
[1] https://lore.kernel.org/u-boot/CAO5Uq5TyTMacERo01weTEda-5X4Fx-VUoYFHa=mBYhW-... [2] https://lore.kernel.org/u-boot/94d75c521aed46dbb54a8275be2f529e@kaspersky.co...
Hi,
On Fri, 5 Nov 2021 at 07:04, Jan Kiszka jan.kiszka@siemens.com wrote:
On 05.11.21 13:42, Jan Kiszka wrote:
On 05.11.21 11:28, Rasmus Villemoes wrote:
On 05/11/2021 11.16, Jan Kiszka wrote:
Hi all,
in order to use CONFIG_FIT_SIGNATURE and also CONFIG_SPL_FIT_SIGNATURE, a public key needs to be placed into the control FDT. So far, I only found mkimage being able to do that during FIT image signing. That is fairly unhandy and often incompatible with how firmware is built & signed vs. how the lifecycle of the artifacts to be loaded and verified look like. Is there really no other way than mkimage -K?
I'm currently considering to derive a tool that, given a public key (which is easy to hand around, compared to the private key needed for signing), injects them into a FDT. Then I would hook that up as generic feature for U-Boot builds, enriching all control FTDs already during the first build with this when requested.
Am I missing an even simpler approach?
You're not missing an existing upstream simpler approach, but it's certainly an itch that others have had [1] [2]. My latest attempt
https://lore.kernel.org/u-boot/20210928085651.619892-1-rasmus.villemoes@prev...
Looking at this path: I would also need it for SPL, so that SPL can validate the container for the main U-Boot. Seems that is missing here, isn't it?
Jan
does now have an R-b by Simon, so now I'm just waiting for that to actually make it into master. I have the script(s) that will convert a public key to a .dtsi fragment, and I'm happy to share that.
Cool, that would be very welcome!
What I'd really like is a separate tool. It was sent as attachments but we are waiting for the author to send them as patches on the thread "Introduce CONFIG_DEVICE_TREE_INCLUDES".
BTW, Rasmus, some documentation on this patch would be helpful.
Regards, Simon
Jan
Rasmus
[1] https://lore.kernel.org/u-boot/CAO5Uq5TyTMacERo01weTEda-5X4Fx-VUoYFHa=mBYhW-... [2] https://lore.kernel.org/u-boot/94d75c521aed46dbb54a8275be2f529e@kaspersky.co...
-- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
participants (3)
-
Jan Kiszka -
Rasmus Villemoes -
Simon Glass