On Mon, 31 Aug 2020 at 19:30, François Ozog <[email protected]> wrote:
> > > 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? > > So you are assuming that the fact that some parts of the firmware image are provided by different parties implies that each of those parties can control when/how those pieces get updated? Do you seriously think that, e.g., Toyota will happily let Netflix issue updates for firmware pieces that are stored on the same NOR flash as the system firmware? In your example, *only* the car vendor controls which pieces get updated. The fact that some pieces of code have signatures that controls when/where they are permitted to execute is completely orthonogonal, and conflating these things does not make the picture any clearer. In general, firmware updates need to be authenticated to the agent that has control over the NOR flash contents, and nothing else. All this effort involving multiple signing domains, and overloading 'container' signatures as 'trusted code' signatures is a move in the wrong direction imho. _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
