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. > -sughosh > -- François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 [email protected] | Skype: ffozog _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
