From: Alex G. <mr.nuke.me@gmail.com>
To: u-boot@lists.denx.de
Subject: [PATCH v4 0/6] Add support for ECDSA image signing (with test)
Date: Thu, 28 Jan 2021 11:54:40 -0600 [thread overview]
Message-ID: <2e3dd238-cd2b-6fb0-fd46-00a3f5640334@gmail.com> (raw)
In-Reply-To: <68d2a315-94a0-c73f-1c57-023d0ddacf3b@foss.st.com>
On 1/28/21 10:40 AM, Patrick DELAUNAY wrote:
> Hi Alexandru,
Hi Patrick
> I found in doc/uImage.FIT/signature.txt the description
>
> ??? - key-name-hint: Name of key to use for signing. The keys will
> normally be in a single directory (parameter -k to mkimage).
[snip]
You are correct that the ECDSA path does not use the "key-name-hint".
And this deviates from what RSA does. This is intentional.
[snip]> so today the RSA features seens more compete based on openssl (with
> ENGINE and pkcs11 support for exmaple)
>
> and keydir / keyname seens clear enought...
The the common case with image signing is that one wants to sign an
image with a key. keyname comes from the console, and keydir comes from
the FIT image, which contradicts this simplicity.
Another issue is incorporating this into a bigger build system like
yocto. Now mkimage would impose a specific directory structure for
signing keys. This would not be ideal.
> PS: I think the engine part could be shared between RSA and EDCSA part.
I don't see the benefit of using the engine, and it seems highly
libcrypto specific. It would be a lot more code, with no useful
functionality -- we can ecdsa sign with the simpler code.
[snip]
> This new option -K with full path will be permanent added to mkimage
>
> or it is a temporarily solution (for initial ECDSA implementation).
>
>
> If it is permanent it should be also supported in RSA mode ?
>
> ??? => for example: -K allow to override the "key-name-hint" value
Yes and no. It is temporary in that we'd like to update the RSA path to
be consistent with the ECDSA path. It's permanent in that we want to
have the -'k' option to specify the key filename instead of the key dir.
At least that's my understanding given the previous discussion with Simon.
[snip]
> Sorry to open debate.
> I propose to change the test with previous proposal.
>
[snip]
> with test/py/tests/vboot/sign-images-sha256.its
> ?? ?fdt at 1 {
> ....
> ?? ??? ?signature at 1 {
> ??????????????????????????????? algo = "sha1,rsa2048";
> -??????????????????????????????? key-name-hint = "dev";
> +?????????????????????????????? key-name-hint = "ecdsa-test-key.pem";
This would go against us wanting to decouple the key filename from the
key name. Consider haing several keys:
dev-key-frobnozzle.pem
prov-key-frobnozzle-r1.pem
prov-key-frobnozzle-r2.pem
prov-key-frobnozzle-r3-after-hack-mitigation.pem
One might not want to expose those key names in the .its. The issue is,
when the fit-image is created, the key filename must be known. But when
the signing happens on a separate machine, the filename really isn't known.
So we should really use the "key-name-hint" as a hint rather than a
filename or part of a filename.
Alex
next prev parent reply other threads:[~2021-01-28 17:54 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-08 19:17 [PATCH v4 0/6] Add support for ECDSA image signing (with test) Alexandru Gagniuc
2021-01-08 19:17 ` [PATCH v4 1/6] lib: Rename rsa-checksum.c to hash-checksum.c Alexandru Gagniuc
2021-01-27 19:02 ` Patrick DELAUNAY
2021-01-08 19:17 ` [PATCH v4 2/6] lib/rsa: Make fdt_add_bignum() available outside of RSA code Alexandru Gagniuc
2021-01-27 19:10 ` Patrick DELAUNAY
2021-01-28 0:57 ` Tom Rini
2021-01-08 19:17 ` [PATCH v4 3/6] lib: Add support for ECDSA image signing Alexandru Gagniuc
2021-01-08 19:17 ` [PATCH v4 4/6] doc: signature.txt: Document devicetree format for ECDSA keys Alexandru Gagniuc
2021-01-08 19:17 ` [PATCH v4 5/6] test/py: Add pycryptodomex to list of required pakages Alexandru Gagniuc
2021-01-08 19:17 ` [PATCH v4 6/6] test/py: ecdsa: Add test for mkimage ECDSA signing Alexandru Gagniuc
2021-01-28 16:40 ` [PATCH v4 0/6] Add support for ECDSA image signing (with test) Patrick DELAUNAY
2021-01-28 17:54 ` Alex G. [this message]
2021-02-01 20:44 ` Simon Glass
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=2e3dd238-cd2b-6fb0-fd46-00a3f5640334@gmail.com \
--to=mr.nuke.me@gmail.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox