[PATCH 0/2] RFC: add fdt_add_pubkey tool

[Jan Kiszka]

On 10.11.21 18:29, François Ozog wrote:
> 
> Hi Jan
> 
> Le mer. 10 nov. 2021 à 17:48, Jan Kiszka <jan.kiszka at siemens.com
> <mailto:jan.kiszka at siemens.com>> a écrit :
> 
>     On 10.11.21 17:31, Simon Glass wrote:
>     > Hi Jan,
>     >
>     > On Tue, 9 Nov 2021 at 23:44, Jan Kiszka <jan.kiszka at siemens.com
>     <mailto:jan.kiszka at siemens.com>> wrote:
>     >>
>     >> On 10.11.21 01:58, Simon Glass wrote:
>     >>> Hi Jan,
>     >>>
>     >>> On Tue, 9 Nov 2021 at 03:07, Jan Kiszka <jan.kiszka at siemens.com
>     <mailto:jan.kiszka at siemens.com>> wrote:
>     >>>>
>     >>>> On 09.11.21 10:37, Roman Kopytin wrote:
>     >>>>> Can we have discussion with code lines? For me it is not very
>     clear, because it isn't my code.
>     >>>>>
>     >>>>
>     >>>> Please do not top-post.
>     >>>>
>     >>>>> -----Original Message-----
>     >>>>> From: Jan Kiszka <jan.kiszka at siemens.com
>     <mailto:jan.kiszka at siemens.com>>
>     >>>>> Sent: Tuesday, November 9, 2021 12:17 PM
>     >>>>> To: Roman Kopytin <Roman.Kopytin at kaspersky.com
>     <mailto:Roman.Kopytin at kaspersky.com>>; u-boot at lists.denx.de
>     <mailto:u-boot at lists.denx.de>; Rasmus Villemoes
>     <rasmus.villemoes at prevas.dk <mailto:rasmus.villemoes at prevas.dk>>
>     >>>>> Subject: Re: [PATCH 0/2] RFC: add fdt_add_pubkey tool
>     >>>>>
>     >>>>> On 08.11.21 16:28, Roman Kopytin wrote:
>     >>>>>> In order to reduce the coupling between building the kernel and
>     >>>>>> U-Boot, I'd like a tool that can add a public key to U-Boot's dtb
>     >>>>>> without simultaneously signing a FIT image. That tool doesn't
>     seem to
>     >>>>>> exist, so I stole the necessary pieces from mkimage et al and
>     put it
>     >>>>>> in a single .c file.
>     >>>>>>
>     >>>>>> I'm still working on the details of my proposed "require just
>     k out
>     >>>>>> these n required keys" and how it should be implemented, but
>     it will
>     >>>>>> probably involve teaching this tool a bunch of new options. These
>     >>>>>> patches are not necessarily ready for inclusion (unless
>     someone else
>     >>>>>> finds fdt_add_pubkey useful as is), but I thought I might as
>     well send
>     >>>>>> it out for early comments.
>     >>>>>
>     >>>>> I'd also like to see the usage of this hooked into the build
>     process.
>     >>>>>
>     >>>>> And to my understanding of [1], that approach will provide a
>     feature that permits hooking with the build but would expect the key
>     as dtsi fragment. Can we consolidate the approaches?
>     >>>>>
>     >>>>> My current vision of a user interface would be a Kconfig
>     option that takes a list of key files to be injected. Maybe make
>     that three lists, one for "required=image", one for "required=conf",
>     and one for optional keys (if that has a use case in practice, no idea).
>     >>>>>
>     >>>>> Jan
>     >>>>>
>     >>>>> [1]
>     >>>>>
>     https://lore.kernel.org/u-boot/20210928085651.619892-1-rasmus.villemoes@prevas.dk/
>     <https://lore.kernel.org/u-boot/20210928085651.619892-1-rasmus.villemoes@prevas.dk/>
>     >>>>>
>     >>>>> --
>     >>>>> Siemens AG, T RDA IOT
>     >>>>> Corporate Competence Center Embedded Linux
>     >>>>>
>     >>>>
>     >>>> For what would you like to have code? The kconfig addition?
>     >>>>
>     >>>> diff --git a/common/Kconfig.boot b/common/Kconfig.boot
>     >>>> index d3a12be228..a9ed4d4ec4 100644
>     >>>> --- a/common/Kconfig.boot
>     >>>> +++ b/common/Kconfig.boot
>     >>>> @@ -279,6 +279,14 @@ config SPL_FIT_GENERATOR
>     >>>>
>     >>>>  endif # SPL
>     >>>>
>     >>>> +config FIT_SIGNATURE_PUB_KEYS
>     >>>> +       string "Public keys to use for FIT image verification"
>     >>>> +       depends on FIT_SIGNATURE || SPL_FIT_SIGNATURE
>     >>>> +       help
>     >>>> +         Public keys, or certificate files to extract them
>     from, that shall
>     >>>> +         be used to verify signed FIT images. The keys will be
>     embedded into
>     >>>> +         the control device tree of U-Boot.
>     >>>> +
>     >>>>  endif # FIT
>     >>>>
>     >>>>  config LEGACY_IMAGE_FORMAT
>     >>>>
>     >>>>
>     >>>> But note that we are in a design discussion here, and I'm at least
>     >>>> reluctant to code up n-versions without having some common idea
>     where
>     >>>> things should move.
>     >>>
>     >>> I'm not sure we want this built into U-Boot. I see signing of a
>     >>> firmware image as a final step, with the keys being added then, e.g.
>     >>> by binman.
>     >>
>     >> This is not signing, this in embedding public key information
>     into build
>     >> artifacts before they can be signed. As pointed out in my other
>     thread,
>     >> not having an embedding feature is a major drawback of the current
>     >> workflow. It easily forces you to rebuild existing build flows in
>     >> out-of-tree scripts.
>     >
>     > The public key is not needed for signing to work, right? I don't
>     > understand what you are getting at here. If you want to add the public
>     > key to the image before it is signed, that's fine. I just don't
>     > understand why you want to do that. Why not have the signer do
>     > everything?
> 
>     A) Because sensitive signing environments will not run arbitrary logic.
>        They will hand out the public key, but they may not give you the
>        chance to run mkimage with the private key, like you would do during
>        development.
> 
> thanks for bringing this very important topic on the list. In this case
> nobody may have the private key handy as it sits hidden inside an HSM:
> correct ?

I have no insides where/how it is stored in our case, ie. our trust
center that is managing keys and issuing certificates. In any case,
private keys are definitely not in the hands of the build environments
or product engineers then - even if those have to be trusted as well,
just for different aspects.

Jan

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