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 Best regards Heinrich _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
