On Mon, 31 Aug 2020 at 19:00, François Ozog <[email protected]> wrote: > > On Fri, 28 Aug 2020 at 18:03, Sughosh Ganu <[email protected]> wrote: > > > hello Heinrich, > > > > On Fri, 28 Aug 2020 at 20:24, Heinrich Schuchardt <[email protected]> > > wrote: > > > >> On 28.08.20 14:19, Grant Likely wrote: > >> > > >> > > >> > On 28/08/2020 12:57, Sughosh Ganu wrote: > >> >> hi, > >> >> I am currently working on adding support for the capsule authentication > >> >> in the SetImage function of the efi firmware management protocol in > >> >> u-boot. This work is part of adding functionality in u-boot for > >> firmware > >> >> updates using the uefi capsule format. > >> >> > >> >> The capsule authentication is done using a public key stored as a pkcs7 > >> >> certificate. The uefi specification does not have any mention of how > >> >> this certificate needs to be stored. This is unlike the case of the > >> >> certificates used for image authentication when UEFI secure boot > >> feature > >> >> is enabled, where the certificates and hash values are stored as part > >> of > >> >> the authenticated variables like KEK, db, dbx. > >> > > >> > I don't think it makes sense to store the capsule authentication in the > >> > KEK. PK and KEK is about the chain of trust between the platform owner > >> > and one of many OSes that may be run on the platform. In the case of a > >> > firmware update, it is an entirely different chain of trust. i.e. we > >> > don't trust 3rd party OS vendors to also provide replacement firmware > >> > images. > >> > > >> > The capsule update public key should be kept separately. For convenience > >> > you could define another variable to hold that public key, but it would > >> > be worth checking with the TF-A folks. It might make sense for BL31 to > >> > be the holder of that key. > >> > > >> > g. > >> > > >> >> Can we use an authenticated variable like KEK to store the certificate > >> >> used for authentication of the capsule payload. Would it make sense to > >> >> have this mentioned in EBBR, or even the UEFI specification. Please let > >> >> me know your thoughts. Thanks. > >> > >> Takahiro was working with FIT images as the content of the capsules. > >> U-Boot already has RSA signing for FIT images. Isn't that enough? > >> > >> Cf. u-boot/doc/uImage.FIT/signature.txt > > > > > > We do have the logic for verification of the signatures, and I have used > > the same code for capsule authentication, which has been introduced by > > Takahiro for image authentication. My question was about storage of the > > public key certificate -- whether it should be stored as a normal uefi > > variable, or as an authenticated variable. > > > > The list of accepted certificates should be in an authenticated variable > ro avoid injection of an attacker cert. >
Why should it be in a variable to begin with? It is common practice for firmware images to have compiled-in certificates for firmware update, which is all you typically need for production hardware. (For development, you could add a jumper, or simply rely on a SPI flash programmer to flash development images or debrick the hardware) Reusing UEFI secure boot infrastructure for this is not supported by requirements of the use case, but simply because the use cases seem related at first glance, but they are really not. (The platform owner should be in full control of the certificates that define the secure boot policies, but updating the system firmware itself is usually under OEM control, and has limitations related to warranty, support etc) _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
