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.
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
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.
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
hello Heinrich,
On Fri, 28 Aug 2020 at 20:24, Heinrich Schuchardt 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.
-sughosh
On Fri, 28 Aug 2020 at 19:03, Sughosh Ganu sughosh.ganu@linaro.org wrote:
hello Heinrich,
On Fri, 28 Aug 2020 at 20:24, Heinrich Schuchardt 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.
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)
On Mon, 31 Aug 2020 at 17:16, Ard Biesheuvel ardb@kernel.org wrote:
On Fri, 28 Aug 2020 at 19:03, Sughosh Ganu sughosh.ganu@linaro.org wrote:
hello Heinrich,
On Fri, 28 Aug 2020 at 20:24, Heinrich Schuchardt 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.
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?
On Mon, 31 Aug 2020 at 19:30, François Ozog francois.ozog@linaro.org wrote:
On Mon, 31 Aug 2020 at 17:16, Ard Biesheuvel ardb@kernel.org wrote:
On Fri, 28 Aug 2020 at 19:03, Sughosh Ganu sughosh.ganu@linaro.org wrote:
hello Heinrich,
On Fri, 28 Aug 2020 at 20:24, Heinrich Schuchardt 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.
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.
On Mon, 31 Aug 2020 at 19:07, Ard Biesheuvel ardb@kernel.org wrote:
On Mon, 31 Aug 2020 at 19:30, François Ozog francois.ozog@linaro.org wrote:
On Mon, 31 Aug 2020 at 17:16, Ard Biesheuvel ardb@kernel.org wrote:
On Fri, 28 Aug 2020 at 19:03, Sughosh Ganu sughosh.ganu@linaro.org wrote:
hello Heinrich,
On Fri, 28 Aug 2020 at 20:24, Heinrich Schuchardt 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.
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?
Netflix is one example. Insurance companies may want to have recorder code
that car mechanics can't disengage because of liability. It's certainly overarching based on current best practices.
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.
At least, I'd like we make clear the trust model before we rule implementation. Based on the above use case and typical practice, what shall be in the PK, KEK and DBs (and other variables if needed)?
On Mon, 31 Aug 2020 at 20:14, François Ozog francois.ozog@linaro.org wrote:
On Mon, 31 Aug 2020 at 19:07, Ard Biesheuvel ardb@kernel.org wrote:
On Mon, 31 Aug 2020 at 19:30, François Ozog francois.ozog@linaro.org wrote:
On Mon, 31 Aug 2020 at 17:16, Ard Biesheuvel ardb@kernel.org wrote:
On Fri, 28 Aug 2020 at 19:03, Sughosh Ganu sughosh.ganu@linaro.org wrote:
hello Heinrich,
On Fri, 28 Aug 2020 at 20:24, Heinrich Schuchardt <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.
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?
Netflix is one example. Insurance companies may want to have recorder
code that car mechanics can't disengage because of liability. It's certainly overarching based on current best practices.
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.
At least, I'd like we make clear the trust model before we rule implementation. Based on the above use case and typical practice, what shall be in the PK, KEK and DBs
(and other variables if needed)?
None. PK is the root of the chain of trust for OS images, which is disjoint from the chain of trust for system firmware.
Why should we use UEFI variables for this in the first place? UEFI variables are an abstraction that permit generic UEFI clients to manipulate the boot environment. No such mechanism is needed for authenticating firmware updates, and I don't see why a OS<->firmware interoperability standard should care about such internal implementation details.
On 31/08/2020 18:19, Ard Biesheuvel wrote:
On Mon, 31 Aug 2020 at 20:14, François Ozog <francois.ozog@linaro.org mailto:francois.ozog@linaro.org> wrote:
On Mon, 31 Aug 2020 at 19:07, Ard Biesheuvel <ardb@kernel.org <mailto:ardb@kernel.org>> wrote: On Mon, 31 Aug 2020 at 19:30, François Ozog <francois.ozog@linaro.org <mailto:francois.ozog@linaro.org>> wrote: On Mon, 31 Aug 2020 at 17:16, Ard Biesheuvel <ardb@kernel.org <mailto:ardb@kernel.org>> wrote: On Fri, 28 Aug 2020 at 19: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. > 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? Netflix is one example. Insurance companies may want to have recorder code that car mechanics can't disengage because of liability. It's certainly overarching based on current best practices. 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. At least, I'd like we make clear the trust model before we rule implementation. Based on the above use case and typical practice, what shall be in the PK, KEK and DBs (and other variables if needed)?None. PK is the root of the chain of trust for OS images, which is disjoint from the chain of trust for system firmware.
Why should we use UEFI variables for this in the first place? UEFI variables are an abstraction that permit generic UEFI clients to manipulate the boot environment. No such mechanism is needed for authenticating firmware updates, and I don't see why a OS<->firmware interoperability standard should care about such internal implementation details.
I completely agree. The firmware signing chain is 100% unrelated to the OS chain of trust (PK,KEK,DB,DBX). Firmware signing chain does not need to be exposed to the OS.
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.
On Mon, Aug 31, 2020 at 08:07:08PM +0300, Ard Biesheuvel wrote:
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?
Moreover many of the parties that supply code want to *avoid* issuing certificates on the approximate basis that if you don't know a key you can never be legally responsible for having leaked it.
In other words several actors within the supply chain (almost certainly including silicon1 and silicon2) will be actively seeking to avoid certifying anything!
Daniel.
On Fri, 28 Aug 2020 at 18:03, Sughosh Ganu sughosh.ganu@linaro.org wrote:
hello Heinrich,
On Fri, 28 Aug 2020 at 20:24, Heinrich Schuchardt 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.
-sughosh
On Mon, 31 Aug 2020 at 19:00, François Ozog francois.ozog@linaro.org wrote:
On Fri, 28 Aug 2020 at 18:03, Sughosh Ganu sughosh.ganu@linaro.org wrote:
hello Heinrich,
On Fri, 28 Aug 2020 at 20:24, Heinrich Schuchardt 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.
Why should it be in a variable to begin with? It is common practice for firmware images to have compiled-in certificates for firmware update, which is all you typically need for production hardware. (For development, you could add a jumper, or simply rely on a SPI flash programmer to flash development images or debrick the hardware)
Reusing UEFI secure boot infrastructure for this is not supported by requirements of the use case, but simply because the use cases seem related at first glance, but they are really not. (The platform owner should be in full control of the certificates that define the secure boot policies, but updating the system firmware itself is usually under OEM control, and has limitations related to warranty, support etc)
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.
boot-architecture@lists.linaro.org
-
Ard Biesheuvel -
Daniel Thompson -
François Ozog -
Grant Likely -
Heinrich Schuchardt -
Sughosh Ganu