On Mon, 31 Aug 2020 at 17:16, Ard Biesheuvel <[email protected]> wrote:
> On Fri, 28 Aug 2020 at 19: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. > > > > I agree with Grant here. The scopes of signed capsule update and UEFI > secure boot are entirely disjoint, and so there is no reason for the > sets of certificates to overlap either, especially because the scope > of signed capsule update is much narrower (i.e., any OS loader from > any OS vendor could potentially be installed on a given system, > whereas only a single entity publishes firmware updates for it) > I'd like to see people's view on who signs what, in the following use case: - Car vendor A builds a car with tier1-1 and tier1-2 boards provided by silicon1 and silicon2. - TF-A, OP-TEE, SCMI-TA, U-Boot are provided by silicon1 for board1 and silicon2 for board2 - board1 is an android auto board and has a DRM TA on board1 provided by Netflix - board2 is an AGL board provided by tier1-2 Is the following correct? PK only cert should be issued by silicon1 and silicon2. KEK in board1 shall contain silicon1, android, Netflix certs KEK in board2 shall contain silicon2, tier1-2 certs DB shall contain the signatures of relevant images on each board. Shouldn't car vendor A have a way to insert itself in the chain of trust? -- 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
