Injecting public keys into FTDs for FIT verification

Injecting public keys into FTDs for FIT verification

[Jan Kiszka]

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

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Re: Injecting public keys into FTDs for FIT verification

[Rasmus Villemoes]

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@prevas.dk/

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-RvmVSQ@mail.gmail.com/
[2]
https://lore.kernel.org/u-boot/94d75c521aed46dbb54a8275be2f529e@kaspersky.com/

Re: Injecting public keys into FTDs for FIT verification

[Jan Kiszka]

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@prevas.dk/
> 
> 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-RvmVSQ@mail.gmail.com/
> [2]
> https://lore.kernel.org/u-boot/94d75c521aed46dbb54a8275be2f529e@kaspersky.com/
> 

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Re: Injecting public keys into FTDs for FIT verification

[Jan Kiszka]

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@prevas.dk/
>>

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-RvmVSQ@mail.gmail.com/
>> [2]
>> https://lore.kernel.org/u-boot/94d75c521aed46dbb54a8275be2f529e@kaspersky.com/
>>
> 

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Re: Injecting public keys into FTDs for FIT verification

[Simon Glass]

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@prevas.dk/
> >>
>
> 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-RvmVSQ@mail.gmail.com/
> >> [2]
> >> https://lore.kernel.org/u-boot/94d75c521aed46dbb54a8275be2f529e@kaspersky.com/
> >>
> >
>
> --
> Siemens AG, T RDA IOT
> Corporate Competence Center Embedded Linux