All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heinrich Schuchardt <xypron.glpk@gmx.de>
To: u-boot@lists.denx.de
Subject: [PATCH v2 10/17] efi_loader: image_loader: verification for all signatures should pass
Date: Tue, 9 Jun 2020 09:14:18 +0200	[thread overview]
Message-ID: <3a30c76f-6813-fe85-379b-0b19ae99850f@gmx.de> (raw)
In-Reply-To: <20200609050947.17861-11-takahiro.akashi@linaro.org>

On 09.06.20 07:09, AKASHI Takahiro wrote:
> A signed image may have multiple signatures in
>   - each WIN_CERTIFICATE in authenticode, and/or
>   - each SignerInfo in pkcs7 SignedData (of WIN_CERTIFICATE)
>
> In the initial implementation of efi_image_authenticate(), the criteria
> of verification check for multiple signatures case is a bit ambiguous
> and it may cause inconsistent result.
>
> With this patch, we will make sure that verification check in
> efi_image_authenticate() should pass against all the signatures.
> The only exception would be
>   - the case where a digest algorithm used in signature is not supported by
>     U-Boot, or
>   - the case where parsing some portion of authenticode has failed
> In those cases, we don't know how the signature be handled and should
> just ignore them.
>
> Please note that, due to this change, efi_signature_verify_with_sigdb()'s
> function prototype will be modified, taking "dbx" as well as "db"
> instead of outputing a "certificate." If "dbx" is null, the behavior would
> be the exact same as before.
> The function's name will be changed to efi_signature_verify() once
> current efi_signature_verify() has gone due to further improvement
> in intermediate certificates support.


Something has been signed by a person you know and additionally by
somebody you do not know. Why would the extra signature make it less
trustworthy?

Is this really what the UEFI spec mandates?

Imagine you have an old device that needs to be updated. It only has
some old db entries.

As certificates expire the upstream maintainer has created a new signing
certificate and signs the firmware with an old and a new certificate.

Or imagine that new firmware is simply cross-signed by another party.

With your rule the firmware cannot be updated.

I think it is sufficient that at least one entry matches db and none
matches dbx.

Best regards

Heinrich

>
> Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>

  reply	other threads:[~2020-06-09  7:14 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-09  5:09 [PATCH v2 00/17] efi_loader: rework/improve UEFI secure boot code AKASHI Takahiro
2020-06-09  5:09 ` [PATCH v2 01/17] efi_loader: change efi objects initialization order AKASHI Takahiro
2020-07-03 10:29   ` Heinrich Schuchardt
2020-06-09  5:09 ` [PATCH v2 02/17] Revert "test: stabilize test_efi_secboot" AKASHI Takahiro
2020-07-03 10:30   ` Heinrich Schuchardt
2020-06-09  5:09 ` [PATCH v2 03/17] efi_loader: signature: replace debug to EFI_PRINT AKASHI Takahiro
2020-07-03 10:30   ` Heinrich Schuchardt
2020-06-09  5:09 ` [PATCH v2 04/17] efi_loader: variable: " AKASHI Takahiro
2020-06-09  5:09 ` [PATCH v2 05/17] efi_loader: image_loader: " AKASHI Takahiro
2020-07-03 10:38   ` Heinrich Schuchardt
2020-06-09  5:09 ` [PATCH v2 06/17] efi_loader: image_loader: add a check against certificate type of authenticode AKASHI Takahiro
2020-07-03 10:56   ` Heinrich Schuchardt
2020-07-08  1:08     ` AKASHI Takahiro
2020-06-09  5:09 ` [PATCH v2 07/17] efi_loader: image_loader: retrieve authenticode only if it exists AKASHI Takahiro
2020-06-09  5:09 ` [PATCH v2 08/17] efi_loader: signature: fix a size check against revocation list AKASHI Takahiro
2020-07-03 11:00   ` Heinrich Schuchardt
2020-07-08  1:12     ` AKASHI Takahiro
2020-07-08  1:30       ` AKASHI Takahiro
2020-06-09  5:09 ` [PATCH v2 09/17] efi_loader: signature: make efi_hash_regions more generic AKASHI Takahiro
2020-07-03 11:08   ` Heinrich Schuchardt
2020-07-08  1:22     ` AKASHI Takahiro
2020-06-09  5:09 ` [PATCH v2 10/17] efi_loader: image_loader: verification for all signatures should pass AKASHI Takahiro
2020-06-09  7:14   ` Heinrich Schuchardt [this message]
2020-06-09  5:09 ` [PATCH v2 11/17] efi_loader: image_loader: add digest-based verification for signed image AKASHI Takahiro
2020-06-09  5:09 ` [PATCH v2 12/17] test/py: efi_secboot: remove all "re.search" AKASHI Takahiro
2020-07-03 15:52   ` Heinrich Schuchardt
2020-06-09  5:09 ` [PATCH v2 13/17] test/py: efi_secboot: fix test case 1g of test_authvar AKASHI Takahiro
2020-07-03 16:08   ` Heinrich Schuchardt
2020-06-09  5:09 ` [PATCH v2 14/17] test/py: efi_secboot: split "signed image" test case-1 into two cases AKASHI Takahiro
2020-07-03 16:14   ` Heinrich Schuchardt
2020-06-09  5:09 ` [PATCH v2 15/17] test/py: efi_secboot: add a test against certificate revocation AKASHI Takahiro
2020-06-09  5:09 ` [PATCH v2 16/17] test/py: efi_secboot: add a test for multiple signatures AKASHI Takahiro
2020-06-09  5:09 ` [PATCH v2 17/17] test/py: efi_secboot: add a test for verifying with digest of signed image AKASHI Takahiro

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3a30c76f-6813-fe85-379b-0b19ae99850f@gmx.de \
    --to=xypron.glpk@gmx.de \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.