Re: Storage of public key certificates for capsule authentication

On 31/08/2020 17:00, François Ozog wrote:

On Fri, 28 Aug 2020 at 18:03, Sughosh Ganu <sughosh.ganu@linaro.org mailto:sughosh.ganu@linaro.org> wrote:

hello Heinrich,

On Fri, 28 Aug 2020 at 20:24, Heinrich Schuchardt
<xypron.glpk@gmx.de <mailto:xypron.glpk@gmx.de>> 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

An authenticated variable probably isn't right because that authenticated variables are signed against the PK; but it doesn't make sense for the PK to be in the firmware chain of trust because the PK doesn't get to control what firmware can run.

Key for firmware updates needs to be communicated up from BL2 or equivalent.

g. 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.