From: Ilias Apalodimas <ilias.apalodimas@linaro.org>
To: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>, u-boot@lists.denx.de
Subject: Re: [PATCH] lib/crypto: Enable more algorithms in cert verification
Date: Wed, 19 Jan 2022 16:54:10 +0200 [thread overview]
Message-ID: <YegmElZ8TSOZuV1t@hades> (raw)
In-Reply-To: <2d0694f3-5c21-62be-b9da-701126f9ad96@gmx.de>
Hi Heinrich,
On Wed, Jan 19, 2022 at 03:22:53PM +0100, Heinrich Schuchardt wrote:
> On 1/18/22 19:12, 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?
>
> You must assume that PK, KEK, db are preexisting or are seeded from a
> file. So the check should be done when loading an image.
I've already replied on this and sent a v2. Can you have a look at that ?
It is happening during loading. The call chain here is
efi_load_pe() ->
efi_image_authenticate() ->
efi_signature_verify()
>
> To be more precise:
>
> An image should not be validated based on an SHA1 signature or SHA1 hash
> but it must be possible to reject an image based on an SHA1 hash.
That's two different things and imho should go into completely
different patchsets.
The v2 I've sent only deals with certs. If you want to kick out sha1 in
general there's efi_signature_lookup_digest() we should go and change.
But the purpose of this patchset is fix rsa4096 encrypted signatures, not
remove the sha1 overall. So can we review the v2 and I'll send a different
patchset for sha1 hashes.
Thanks
/Ilias
>
> Best regards
>
> Heinrich
>
> >
> > 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
> > > > > > > >
> > > > >
> > >
>
prev parent reply other threads:[~2022-01-19 14:54 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
2022-01-19 13:03 ` Ilias Apalodimas
2022-01-19 14:22 ` Heinrich Schuchardt
2022-01-19 14:54 ` Ilias Apalodimas [this message]
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=YegmElZ8TSOZuV1t@hades \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox