Re: [EXTERNAL] Re: [PATCH v2 6/6] test: dm: Add test for ECDSA UCLASS support
Update on ECDSA verification progress, I've forked Alex's repo and have
included my changes in the 'ecdsa-vrf-1' branch [1]. This includes the
isolated OpenSSL code for verification, and I split up the
lib/ecdsa/ecdsa-libcrypto.c file into lib/ecdsa/ecdsa-sign.c and
lib/ecdsa/ecdsa-verify.c. I've also included unit tests under
test/py/tests/test_vboot_ecdsa.py, which test ECDSA with the sha1 and
sha256 digest algos. There are some outstanding changes to be made
before it's ready for review, mainly cleaning up the OpenSSL code as it
has redundant code still included though it works without any additional
dependencies, and better integration with U-Boot's build system.
Currently I've added a new Kconfig setting to turn on ECDSA
signing/verification called "CONFIG_FIT_SIGNATURE_ECDSA" in
common/Kconfig.boot which sets config options "CONFIG_ECDSA" and
"CONFIG_ECDSA_VERIFY". This is done mainly to replicate how the RSA
config was setup, though creating "CONFIG_FIT_SIGNATURE_ECDSA" separate
from "CONFIG_FIT_SIGNATURE" feels messy, there's probably a better approach.
Today is also my last day at my internship. Deskin, a team member of
mine at Microsoft who was keeping an eye on the project, will be the
main point of contact from here (desk...@linux.microsoft.com) though I
can also be reached at timroman...@gmail.com (CC'd) and will be
responsive if there are any questions.
All the best,
Tim
[1] timr11/u-boot: u-boot + elliptic curve verification (github.com)
<https://github.com/timr11/u-boot>
On 2021-04-08 12:56 p.m., Tim Romanski wrote:
Ok, will do. I'm writing the verification code, I noticed you're
passing the public key into the fdt using fdt_add_bignum, which
converts the x and y values into big endian integer arrays. Do you
have a method to read these values from the fdt and convert them back
into bignums, or is that TODO? I can get that done if it's not yet
implemented.
All the best,
Tim
On 2021-04-07 4:03 p.m., Alex G. wrote:
On 4/7/21 12:29 PM, Tim Romanski wrote:
Question for Alex, I see your repo has a few branches related to
ECDSA (patch-ecdsa-v[1-5], patch-mkimage-keyfile-v{1,2}). You sent
me a link to 'patch-ecdsa-v1' in a previous email, is that the one
that's being upstreamed? Should I be working off a different branch
or is that one ok?
I'm up to v6 on the patch submission. The differences are not that
big, but I recommend sticking to the latest.
Alex
Re: [EXTERNAL] Re: [PATCH v2 6/6] test: dm: Add test for ECDSA UCLASS support
Ok, will do. I'm writing the verification code, I noticed you're passing
the public key into the fdt using fdt_add_bignum, which converts the x
and y values into big endian integer arrays. Do you have a method to
read these values from the fdt and convert them back into bignums, or is
that TODO? I can get that done if it's not yet implemented.
All the best,
Tim
On 2021-04-07 4:03 p.m., Alex G. wrote:
On 4/7/21 12:29 PM, Tim Romanski wrote:
Question for Alex, I see your repo has a few branches related to
ECDSA (patch-ecdsa-v[1-5], patch-mkimage-keyfile-v{1,2}). You sent me
a link to 'patch-ecdsa-v1' in a previous email, is that the one
that's being upstreamed? Should I be working off a different branch
or is that one ok?
I'm up to v6 on the patch submission. The differences are not that
big, but I recommend sticking to the latest.
Alex
Re: [EXTERNAL] Re: [PATCH v2 6/6] test: dm: Add test for ECDSA UCLASS support
Update on current progress on U-Boot ECDSA verification: I've isolated
the OpenSSL code required to verify a signature signed with the
nistp256v1 curve, and I've written a small test program to show that the
code works without any external dependencies [1]. Currently fitting the
code into Alex's fork of U-Boot.
Question for Alex, I see your repo has a few branches related to ECDSA
(patch-ecdsa-v[1-5], patch-mkimage-keyfile-v{1,2}). You sent me a link
to 'patch-ecdsa-v1' in a previous email, is that the one that's being
upstreamed? Should I be working off a different branch or is that one ok?
Tim
[1] https://github.com/timr11/openssl-ecdsa-verify
On 2021-03-30 2:27 p.m., Tim Romanski wrote:
On 3/30/21 2:17PM, Alexandru Gagniuc wrote:
I don't have any updates from Tim that you don't. I assume he's still silently
hacking at it.
Yep, I'm working on a software implementation of ECDSA. Currently have the
OpenSSL implementation for the nistp256 curve isolated, debugging a test
program that verifies a signature on data that was randomly generated, then
will need to clean up unnecessary code and fit it into U-Boot.
CC'd my @linux.microsoft.com email, I prefer to use that one from now on.
All the best,
Tim
-Original Message-
From: Alex G.
Sent: March 29, 2021 2:43 PM
To: Simon Glass
Cc: U-Boot Mailing List ; Tom Rini ; Tim
Romanski
Subject: [EXTERNAL] Re: [PATCH v2 6/6] test: dm: Add test for ECDSA UCLASS
support
+ Tim
On 3/29/21 2:43 AM, Simon Glass wrote:
Hi Alexandru,
On Tue, 16 Mar 2021 at 13:24, Alexandru Gagniuc wrote:
This test verifies that ECDSA_UCLASS is implemented, and that
ecdsa_verify() works as expected. The definition of "expected" is
"does not find a device, and returns -ENODEV".
The lack of a hardware-independent ECDSA implementation prevents us
from having one in the sandbox, for now.
Yes we do need a software impl at some point. Any update on that?
I don't have any updates from Tim that you don't. I assume he's still silently
hacking at it.
Alex
RE: [EXTERNAL] Re: [PATCH v2 6/6] test: dm: Add test for ECDSA UCLASS support
On 3/30/21 2:17PM, Alexandru Gagniuc wrote: > I don't have any updates from Tim that you don't. I assume he's still > silently hacking at it. Yep, I'm working on a software implementation of ECDSA. Currently have the OpenSSL implementation for the nistp256 curve isolated, debugging a test program that verifies a signature on data that was randomly generated, then will need to clean up unnecessary code and fit it into U-Boot. CC'd my @linux.microsoft.com email, I prefer to use that one from now on. All the best, Tim -Original Message- From: Alex G. Sent: March 29, 2021 2:43 PM To: Simon Glass Cc: U-Boot Mailing List ; Tom Rini ; Tim Romanski Subject: [EXTERNAL] Re: [PATCH v2 6/6] test: dm: Add test for ECDSA UCLASS support + Tim On 3/29/21 2:43 AM, Simon Glass wrote: > Hi Alexandru, > > On Tue, 16 Mar 2021 at 13:24, Alexandru Gagniuc wrote: >> >> This test verifies that ECDSA_UCLASS is implemented, and that >> ecdsa_verify() works as expected. The definition of "expected" is >> "does not find a device, and returns -ENODEV". >> >> The lack of a hardware-independent ECDSA implementation prevents us >> from having one in the sandbox, for now. > > Yes we do need a software impl at some point. Any update on that? I don't have any updates from Tim that you don't. I assume he's still silently hacking at it. Alex
RE: [EXTERNAL] Re: U-Boot ECDSA Implementation Question
On 2/22/21 6:33 PM, Alex G. wrote: > Verification on the target would be great. My implementation is > platform-specific. It would make sense to also have a software implementation > of ECDSA (as we do for RSA). Once that is in place, it opens the gates for > unit-testing. Currently, we're only testing the host signing part, but it > would be awesome to have a test for ECDSA_UCLASS. That sounds good! It aligns with our though process on the topic too. > I think getting started on a software implementation of ECDSA_UCLASS would be > most beneficial. Is that something you'd like to take on? Yessir, happy to get that started! I've been looking at the Linux and OpenSSL implementations, turns out Linux's ECRDSA is slightly different than what OpenSSL uses so I'm going ahead with isolating the OpenSSL ECDSA implementation right now and will fit it into a UCLASS after. My intuition is this will align the best with your implementation, though if you have different thoughts please let me know. CC'd our @linux.microsoft.com emails, will be using those from now on. All the best, Tim -Original Message- From: Alex G. Sent: February 22, 2021 6:33 PM To: Tim Romanski ; Simon Glass Cc: u-boot@lists.denx.de; Deskin Miller ; Dylan D'Silva Subject: Re: [EXTERNAL] Re: U-Boot ECDSA Implementation Question On 2/10/21 1:45 PM, Tim Romanski wrote: > Hi Alex, > > Thanks for the context! What are your plans for upstreaming your ECDSA > signing implementation? I expect that the ECDSA signing series will get merged soon. > I've currently dedicated the next four weeks to getting signing+verification > implemented, so if you'd like a helping hand either with any leftover signing > work or to get verification started I'm happy to collaborate. Verification on the target would be great. My implementation is platform-specific. It would make sense to also have a software implementation of ECDSA (as we do for RSA). Once that is in place, it opens the gates for unit-testing. Currently, we're only testing the host signing part, but it would be awesome to have a test for ECDSA_UCLASS. I think getting started on a software implementation of ECDSA_UCLASS would be most beneficial. Is that something you'd like to take on? Alex > > All the best, > Tim > > -Original Message- > From: Alex G. > Sent: February 5, 2021 11:09 AM > To: Simon Glass ; Tim Romanski > > Cc: u-boot@lists.denx.de; Deskin Miller ; Dylan > D'Silva > Subject: [EXTERNAL] Re: U-Boot ECDSA Implementation Question > > Hi Tim, > > On 2/5/21 8:35 AM, Simon Glass wrote: >>> I'm a current intern at Microsoft, and one of my priorities is to enable >>> ECDSA for U-Boot image signing/verification. Simon mentioned someone is >>> already working on ECC, it would be great to get synced up with related >>> progress. For signing, I will likely replicate the existing approach of >>> using the openssl library. I'm aware that signing happens on a host machine >>> and verification happens during boot, which implies verification should >>> have a custom implementation to avoid the openssl overhead in the U-Boot >>> binary. My thoughts are to copy an ECC verification implementation from a >>> well-tested widely-used open source project. I was wondering, is U-Boot's >>> current RSA verification copied from another project? If so, how are >>> security patches between the two copies of code usually handled? I'm >>> thinking of deriving from the ECDSA implementation currently in the Linux >>> kernel, though I'd also appreciate suggestions if there's a better/more >>> widely tested & used implementation. >> > > [snip] >> >> Alexandru Gagniuc, on cc, has been looking at implementing the >> signing side of this recently and has sent some patches that you >> could look at. > > I hope I can save you some effort on the signing side. Generally, you > have two types of signed images. The first is the signed bootloader > (BL2 or FSBL in ARM terms). The other one is the signed Flattened > Image Tree > (FIT) that we use in u-boot. The first one is vendor-specific, so you'd > usually use vendor tools or write your own. We use mkimage to deal with the > latter. > > I've implemented the signing part [1] for mkimage. mkimage has the ability to > use hardware signing via the PKCS11 engine of openssl, which I did not > implement. You can read more about it here [3]. > > The verification part is still being defined [4][5]. The idea is to define a > UCLASS which abstracts the underlying implementation. For RSA, it's defined > here [6]. > > My goal with ECDSA verification was to use the ROM API of the STM32MP1. > This m
RE: [EXTERNAL] Re: U-Boot ECDSA Implementation Question
Hi Alex, Thanks for the context! What are your plans for upstreaming your ECDSA signing implementation? I've currently dedicated the next four weeks to getting signing+verification implemented, so if you'd like a helping hand either with any leftover signing work or to get verification started I'm happy to collaborate. All the best, Tim -Original Message- From: Alex G. Sent: February 5, 2021 11:09 AM To: Simon Glass ; Tim Romanski Cc: u-boot@lists.denx.de; Deskin Miller ; Dylan D'Silva Subject: [EXTERNAL] Re: U-Boot ECDSA Implementation Question Hi Tim, On 2/5/21 8:35 AM, Simon Glass wrote: >> I'm a current intern at Microsoft, and one of my priorities is to enable >> ECDSA for U-Boot image signing/verification. Simon mentioned someone is >> already working on ECC, it would be great to get synced up with related >> progress. For signing, I will likely replicate the existing approach of >> using the openssl library. I'm aware that signing happens on a host machine >> and verification happens during boot, which implies verification should have >> a custom implementation to avoid the openssl overhead in the U-Boot binary. >> My thoughts are to copy an ECC verification implementation from a >> well-tested widely-used open source project. I was wondering, is U-Boot's >> current RSA verification copied from another project? If so, how are >> security patches between the two copies of code usually handled? I'm >> thinking of deriving from the ECDSA implementation currently in the Linux >> kernel, though I'd also appreciate suggestions if there's a better/more >> widely tested & used implementation. > [snip] > > Alexandru Gagniuc, on cc, has been looking at implementing the signing > side of this recently and has sent some patches that you could look > at. I hope I can save you some effort on the signing side. Generally, you have two types of signed images. The first is the signed bootloader (BL2 or FSBL in ARM terms). The other one is the signed Flattened Image Tree (FIT) that we use in u-boot. The first one is vendor-specific, so you'd usually use vendor tools or write your own. We use mkimage to deal with the latter. I've implemented the signing part [1] for mkimage. mkimage has the ability to use hardware signing via the PKCS11 engine of openssl, which I did not implement. You can read more about it here [3]. The verification part is still being defined [4][5]. The idea is to define a UCLASS which abstracts the underlying implementation. For RSA, it's defined here [6]. My goal with ECDSA verification was to use the ROM API of the STM32MP1. This meant I don't have to write a software implementation of ECDSA. This would be useful in two ways. It would enable ECDSA verification on devices that don't support it in hardware, and would also allow us to add some unit tests for ECDSA. I suspect what you could do from here, is try to build my branch with ECDSA signing, play around with mkimage, and let us know how we can point you to the correct documentation. There's a lot of it in doc/, but it's not always easy to find. Alex [1] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmrnuke%2Fu-boot%2Fcommits%2Fpatch-mkimage-keyfile-v1data=04%7C01%7Ct-tromanski%40microsoft.com%7C4e326c48dc2f4e89df5d08d8c9f0536f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637481381320581783%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=NulehqeJPXmR%2BLhHzBagWc9Uum1iFS5%2BSVlRu0L9SUU%3Dreserved=0 [2] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmrnuke%2Fu-boot%2Fcommit%2Fa2ae016f2f80579962d4ab058137c8e1a4f4741fdata=04%7C01%7Ct-tromanski%40microsoft.com%7C4e326c48dc2f4e89df5d08d8c9f0536f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637481381320581783%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=Sa06A5TDKVxJ7sd1Dj%2FCiztHPQ%2BJBuzVbpK9mMVwMsU%3Dreserved=0 [3] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmrnuke%2Fu-boot%2Fblob%2F3f447efcf8ad98d0eea349994810a66b453ac188%2Fdoc%2FuImage.FIT%2Fsignature.txt%23L488data=04%7C01%7Ct-tromanski%40microsoft.com%7C4e326c48dc2f4e89df5d08d8c9f0536f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637481381320581783%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=ExeKMGFCC9QX6bGAyWztqMZqMqCqGWbhgZkF8odmcKM%3Dreserved=0 [4] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmrnuke%2Fu-boot%2Fcommit%2F31caceb0e28959881e96ea49a0b28fd44d13a947data=04%7C01%7Ct-tromanski%40microsoft.com%7C4e326c48dc2f4e89df5d08d8c9f0536f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637481381320581783%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiL
U-Boot ECDSA Implementation Question
Hello, I'm a current intern at Microsoft, and one of my priorities is to enable ECDSA for U-Boot image signing/verification. Simon mentioned someone is already working on ECC, it would be great to get synced up with related progress. For signing, I will likely replicate the existing approach of using the openssl library. I'm aware that signing happens on a host machine and verification happens during boot, which implies verification should have a custom implementation to avoid the openssl overhead in the U-Boot binary. My thoughts are to copy an ECC verification implementation from a well-tested widely-used open source project. I was wondering, is U-Boot's current RSA verification copied from another project? If so, how are security patches between the two copies of code usually handled? I'm thinking of deriving from the ECDSA implementation currently in the Linux kernel, though I'd also appreciate suggestions if there's a better/more widely tested & used implementation. All the best, Tim
