[PATCH 0/2] RFC: add fdt_add_pubkey tool

[Jan Kiszka]

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.

Jan

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