All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ilias Apalodimas <ilias.apalodimas@linaro.org>
To: AKASHI Takahiro <takahiro.akashi@linaro.org>,
	 Ilias Apalodimas <ilias.apalodimas@linaro.org>,
	Heinrich Schuchardt <xypron.glpk@gmx.de>,
	u-boot@lists.denx.de
Subject: Re: [RFC PATCH 1/2] efi_loader: fix dual signed image certification
Date: Fri, 11 Feb 2022 08:15:24 +0200	[thread overview]
Message-ID: <CAC_iWjK5MD+EWQr=Z8JtLbLSnChte=ioJ+PDZ5RD93_9JQCSkA@mail.gmail.com> (raw)
In-Reply-To: <20220210080109.GJ12412@laputa>

On Thu, 10 Feb 2022 at 10:01, AKASHI Takahiro
<takahiro.akashi@linaro.org> wrote:
>
> On Thu, Feb 10, 2022 at 09:55:20AM +0200, Ilias Apalodimas wrote:
> > On Thu, Feb 10, 2022 at 04:41:15PM +0900, AKASHI Takahiro wrote:
> > > On Thu, Feb 10, 2022 at 09:33:46AM +0200, Ilias Apalodimas wrote:
> > > > > > > >                   msg = pkcs7_parse_message(auth, auth_size);
> > > >
> > > > [...]
> > > >
> > > > > > > > @@ -717,32 +665,32 @@ static bool efi_image_authenticate(void *efi, size_t efi_size)
> > > > > > > >                    */
> > > > > > > >                   /* try black-list first */
> > > > > > > >                   if (efi_signature_verify_one(regs, msg, dbx)) {
> > > > > > > > +                 ret = false;
> > > > > > > >                           EFI_PRINT("Signature was rejected by \"dbx\"\n");
> > > > > > > > -                 continue;
> > > > > > > > +                 goto out;
> > > > > > >
> > > > > > > If we go to "out" here, we have no chance to verify some cases:
> > > > > > > 1) An image has two signatures, for instance, one signed by SHA1 cert
> > > > > > >     and the other signed by SHA256 cert. A user wants to reject SHA1 cert
> > > > > > >     and put the cert in dbx.
> > > > > >
> > > > > > I am not sure I am following,  what does he gain be rejecting the SHA1
> > > > > > portion only?  Avoid potential collisions?
> > > > >
> > > > > If an image has a SHA1 and a SHA256 signature attached and SHA1 *or*
> > > > > SHA256 is in dbx, we must reject the image. Don't expect a dbx entry for
> > > > > each of the hashes. - But isn't this what your are doing here: for all
> > > > > signatures of the image look for one hit in dbx?
> > > > >
> > > >
> > > > Yes exactly. Any match on dbx of any certificate or sha256 of a certificate
> > > > or a sha256 of the executable will reject the image.
> > >
> > > But we believe that SHA256-based signature is still valid
> > > even if we don't trust SHA1.
> >
> > UEFI spec 2.9 page 1715 describes exaclty what we propose here as a
> > change.  The SHAxxx choise is irrelevant, any potential match should reject
> > the image.
> >
> > >
> > > > Regards
> > > > /Ilias
> > > > > Best regards
> > > > >
> > > > > Heinrich
> > > > >
> > > > > >
> > > > > > >     But this image can and should yet be verified by SHA256 cert.
> > > > > >
> > > > > > Why should it be verified?  My understanding of the EFI spec is that any match
> > > > > > in dbx of any certificate in the signing chain of the signature being verified means
> > > > > > reject the image.
> > > > > >
> > > > > > > 2) A user knows that a given image is safe for some reason even though
> > > > > > >     he or she doesn't trust the certficate which is used for signing
> > > > > > >     the image.
> >
> > Then he should resign his image with a proper certificate.
>
> No, I don't think so. The hash-based verification is for that.

If an image is rejected by a corresponding x509 in dbx or a shaxxx of
the certificate, execution should be denied. I am not really sure what
you are trying to describe here.

Regards
/Ilias

>
> -Takahiro Akashi
>
> > Regards
> > /Ilias
> > >
> > > What do you think of this case?
> > >
> > > -Takahiro Akashi
> > >
> > > > > > > -Takahiro Akashi
> > > > > > >
> > > > > > > >                   }
> > > > > > > >
> > > > > > > >                   if (!efi_signature_check_signers(msg, dbx)) {
> > > > > > > > +                 ret = false;
> > > > > > > >                           EFI_PRINT("Signer(s) in \"dbx\"\n");
> > > > > > > > -                 continue;
> > > > > > > > +                 goto out;
> > > > > > > >                   }
> > > > > > > >
> > > > > > > >                   /* try white-list */
> > > > > > > >                   if (efi_signature_verify(regs, msg, db, dbx)) {
> > > > > > > >                           ret = true;
> > > > > > > > -                 break;
> > > > > > > > +                 continue;
> > > > > > > >                   }
> > > > > > > >
> > > > > > > >                   EFI_PRINT("Signature was not verified by \"db\"\n");
> > > > > > > > + }
> > > > > > > >
> > > > > > > > -         if (efi_signature_lookup_digest(regs, db, false)) {
> > > > > > > > -                 ret = true;
> > > > > > > > -                 break;
> > > > > > > > -         }
> > > > > > > >
> > > > > > > > -         EFI_PRINT("Image's digest was not found in \"db\" or \"dbx\"\n");
> > > > > > > > - }
> > > > > > > > + /* last resort try the image sha256 hash in db */
> > > > > > > > + if (!ret && efi_signature_lookup_digest(regs, db, false))
> > > > > > > > +         ret = true;
> > > > > > > >
> > > > > > > > -err:
> > > > > > > > +out:
> > > > > > > >           efi_sigstore_free(db);
> > > > > > > >           efi_sigstore_free(dbx);
> > > > > > > >           pkcs7_free_message(msg);
> > > > > > > > --
> > > > > > > > 2.32.0
> > > > > > > >
> > > > > >
> > > > > > Thanks
> > > > > > /Ilias
> > > > >

  reply	other threads:[~2022-02-11  6:16 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-04  7:32 [RFC PATCH 1/2] efi_loader: fix dual signed image certification Ilias Apalodimas
2022-02-04  7:32 ` [RFC PATCH 2/2] test/py: efi_secboot: adjust secure boot tests to code changes Ilias Apalodimas
2022-02-10  5:22   ` AKASHI Takahiro
2022-02-10  7:14     ` Ilias Apalodimas
2022-02-10  7:31       ` AKASHI Takahiro
2022-02-10  8:00         ` Ilias Apalodimas
2022-02-10  5:13 ` [RFC PATCH 1/2] efi_loader: fix dual signed image certification AKASHI Takahiro
2022-02-10  7:13   ` Ilias Apalodimas
2022-02-10  7:31     ` Heinrich Schuchardt
2022-02-10  7:33       ` Ilias Apalodimas
2022-02-10  7:41         ` AKASHI Takahiro
2022-02-10  7:55           ` Ilias Apalodimas
2022-02-10  8:01             ` AKASHI Takahiro
2022-02-11  6:15               ` Ilias Apalodimas [this message]
2022-02-10  7:36     ` 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='CAC_iWjK5MD+EWQr=Z8JtLbLSnChte=ioJ+PDZ5RD93_9JQCSkA@mail.gmail.com' \
    --to=ilias.apalodimas@linaro.org \
    --cc=takahiro.akashi@linaro.org \
    --cc=u-boot@lists.denx.de \
    --cc=xypron.glpk@gmx.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.