[PATCH 0/2] RFC: add fdt_add_pubkey tool

[François Ozog]

Hi Jan,

On Tue, 9 Nov 2021 at 15:00, Jan Kiszka <jan.kiszka at siemens.com> wrote:

> On 09.11.21 14:16, François Ozog wrote:
> > Hi Jan
> >
> > On Tue, 9 Nov 2021 at 13:58, Jan Kiszka <jan.kiszka at siemens.com
> > <mailto:jan.kiszka at siemens.com>> wrote:
> >
> >     On 09.11.21 13:43, François Ozog wrote:
> >     > Hi
> >     >
> >     > as we are in design discussions, I would promote the idea of not
> >     pushing
> >     > non hardware related things in the DTB that is passed to the
> kernel.
> >
> >     This was never proposed. The public keys go into the *control* FDTs.
> >
> > great ;-)
> >
> >     > Is your use case to allow U-Boot to verify the kernel's signature ?
> >     > Why not putting it into an environment variable?
> >
> >     This is both about validating OS FIT containers as well as SPL
> checking
> >     U-Boot proper before continuing the boot there. The former case can
> be
> >     replaced with UEFI logic and likely taking the key from TEE (we do
> that
> >     as well in first prototypes), but the latter can't (yet).
> >
> >     >
> >     > If your use case is on Arm or RISC-V, both environments are working
> >     > heavily to make https://arm-software.github.io/ebbr/
> >     <https://arm-software.github.io/ebbr/>
> >     > <https://arm-software.github.io/ebbr/
> >     <https://arm-software.github.io/ebbr/>> standard available on a
> large
> >     > number of boards.
> >     > This offers UEFI interface and SecureBoot (and later MeasuredBoot)
> >     > services. For Arm boards just check for SystemReady compliance.
> >     > In this context, traditional UEFI secure variables are used to
> >     deal with
> >     > certificates and hashes: PK, KEK, db...
> >     > You can obviously do differently but you will be on your own to
> extend
> >     > the chain of trust to IMA, secure containers (rooted down to hRoT)
> and
> >     > other security facilities in the Linux side.
> >     > Could you describe your use case in more details?
> >
> >     doc/uImage.FIT/signature.txt ;)
> >
> >     More concrete: We are currently massaging board/siemens/iot2050 to
> close
> >     its static chain of trust between SPL and U-Boot main, using software
> >     means (vendor means do not work because FSBL key != TF-A/TEE/U-Boot
> >     key).
> >
> > And will the chain of trust be continuous or with a very brief breakage
> > with this approach?
> > I other words, can you enroll the  TF-A/TEE/U-Boot key so that it can be
> > trusted by FSBL key?
>
> The chain will be continuous. Both FSBL and TF-A/TEE/SPL will be
> OTP-anchored (but deployed at different times / by different
> authorities), FSBL will validate based on OTP, SPL should do that based
> on control FDT key. Therefore, we need embedding into the SPL FDT in
> this case.
>
> If the user decides to continue "classically" by loading the OS from a
> signed FIT image, also U-Boot proper needs the public key in its control
> FDT.
>
> That's just one (likely more special) scenario, but I bet there are
> plenty others on other SOCs / systems.
>
> Get it. Thanks for detailing the case, its very useful for me.

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


-- 
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog at linaro.org | Skype: ffozog