All of lore.kernel.org
 help / color / mirror / Atom feed
From: AKASHI Takahiro <takahiro.akashi@linaro.org>
To: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>, u-boot@lists.denx.de
Subject: Re: [PATCH] lib/crypto: Enable more algorithms in cert verification
Date: Wed, 19 Jan 2022 21:36:10 +0900	[thread overview]
Message-ID: <20220119123610.GC61490@laputa> (raw)
In-Reply-To: <CAC_iWjKN=Ue20qfiK8xc+J-uyx-w-jndcjNhsaaWAMfB07T63g@mail.gmail.com>

On Wed, Jan 19, 2022 at 09:07:04AM +0200, Ilias Apalodimas wrote:
> Hi Akashi-san,
> 
> 
> On Wed, 19 Jan 2022 at 06:47, AKASHI Takahiro
> <takahiro.akashi@linaro.org> wrote:
> >
> > On Tue, Jan 18, 2022 at 08:12:22PM +0200, Ilias Apalodimas wrote:
> > > Hi Heinrich,
> > >
> > > On Tue, 18 Jan 2022 at 18:22, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
> > > >
> > > > On 1/18/22 15:03, Ilias Apalodimas wrote:
> > > > > Hi Heinrich,
> > > > >
> > > > >>>>> -         info.checksum = image_get_checksum_algo("sha256,rsa2048");
> > > > >
> > > > > [...]
> > > > >
> > > > >>>>> -         info.name = "sha256,rsa2048";
> > > > >>>>> - } else {
> > > > >>>>> -         pr_warn("unknown msg digest algo: %s\n", sig->hash_algo);
> > > > >>>>> + if (strcmp(sig->pkey_algo, "rsa")) {
> > > > >>>>> +         pr_err("Encryption is not RSA: %s\n", sig->pkey_algo);
> > > > >>>>>                   return -ENOPKG;
> > > > >>>>>           }
> > > > >>>>> + ret = snprintf(algo, sizeof(algo), "%s,%s%d", sig->hash_algo,
> > > > >>>>> +                sig->pkey_algo, sig->s_size * 8);
> > > > >>
> > > > >> How do we ensure that the unsafe SHA1 algorithm is not used?
> > > > >
> > > > > We don't,  but the current code allows it as well.  Should we enforce this
> > > > > from U-Boot  though?  The spec doesn't forbid it as far as I remember
> > > >
> > > > Collisions for SHA1 have been first created successfully in 2017.
> > > >
> > > > It is feasible to create two different EFI binaries with the same SHA1.
> > > > One will be reviewed and signed. After copying the signature to the
> > > > other one it will happily boot on U-Boot. Ouch. This is exactly what
> > > > signatures are meant to avoid.
> > > >
> > > > We must not accept SHA1 for signatures.
> > >
> > > Right, but is this the right place to do it? This is function to
> > > verify signatures.  Isn't it better to keep this as is and then
> > > explicitly deny adding sha1 hashed keys into db?
> >
> > If you don't want to trust SHA1, just disable it with !CONFIG_SHA1.
> 
> No that's not doable.  Things like EFI_TCG2 protocol needs that since
> we use a sha1 in the tcg eventlog.

I simply wonder why you can trust SHA1 in PCR/event log while you don't
trust it in secure boot.

-Takahiro Akashi

> I've looked at the code a bit more
> and not adding in db looks either bad or hard to reason about, since
> we do have different storage backends(i.e efi variables in RPMB via
> standaloneMM).  So one way to do this without affecting the generic
> crypto code is
> 
> bool efi_signature_verify(struct efi_image_regions *regs,
>                 if (ret < 0 || !signer)
>                         goto out;
> 
> +               if (!strcmp(signer->sig->hash_algo, "sha1")) {
> +                       pr_err("SHA1 support is disabled for EFI\n");
> +                       goto out;
> +               }
> +
>                 if (sinfo->blacklisted)
>                         goto out;
> 
> Cheers
> /Ilias
> 
> > -Takahiro Akashi
> >
> > > Cheers
> > > /Ilias
> > > >
> > > > Best regards
> > > >
> > > > Heinrich
> > > >
> > > > >
> > > > > Regards
> > > > > /Ilias
> > > > >>
> > > > >> Best regards
> > > > >>
> > > > >> Heinrich
> > > > >>
> > > > >>>>
> > > > >>>> I'm not sure that this naming rule, in particular the latter part, will
> > > > >>>> always hold in the future while all the existing algo's observe it.
> > > > >>>> (Maybe we need some note somewhere?)
> > > > >>>
> > > > >>> The if a few lines below will shield us and return -EINVAL.  How about
> > > > >>> adding an error message there?
> > > > >>>
> > > > >>> Cheers
> > > > >>> /Ilias
> > > > >>>>
> > > > >>>> -Takahiro Akashi
> > > > >>>>
> > > > >>>>> +
> > > > >>>>> + if (ret >= sizeof(algo))
> > > > >>>>> +         return -EINVAL;
> > > > >>>>> +
> > > > >>>>> + info.checksum = image_get_checksum_algo((const char *)algo);
> > > > >>>>> + info.name = (const char *)algo;
> > > > >>>>>           info.crypto = image_get_crypto_algo(info.name);
> > > > >>>>> - if (IS_ERR(info.checksum) || IS_ERR(info.crypto))
> > > > >>>>> + if (!info.checksum || !info.crypto)
> > > > >>>>>                   return -ENOPKG;
> > > > >>>>>
> > > > >>>>>           info.key = pkey->key;
> > > > >>>>> --
> > > > >>>>> 2.30.2
> > > > >>>>>
> > > > >>
> > > >

  reply	other threads:[~2022-01-19 12:36 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-18 11:12 [PATCH] lib/crypto: Enable more algorithms in cert verification Ilias Apalodimas
2022-01-18 12:38 ` AKASHI Takahiro
2022-01-18 12:50   ` Ilias Apalodimas
2022-01-18 13:41     ` Heinrich Schuchardt
2022-01-18 14:03       ` Ilias Apalodimas
2022-01-18 16:22         ` Heinrich Schuchardt
2022-01-18 18:12           ` Ilias Apalodimas
2022-01-19  4:47             ` AKASHI Takahiro
2022-01-19  7:07               ` Ilias Apalodimas
2022-01-19 12:36                 ` AKASHI Takahiro [this message]
2022-01-19 13:03                   ` Ilias Apalodimas
2022-01-19 14:22             ` Heinrich Schuchardt
2022-01-19 14:54               ` Ilias Apalodimas

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=20220119123610.GC61490@laputa \
    --to=takahiro.akashi@linaro.org \
    --cc=ilias.apalodimas@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.