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. -sughosh
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
