* U-Boot ECDSA Implementation Question
@ 2021-02-04 22:01 Tim Romanski
2021-02-05 14:35 ` Simon Glass
0 siblings, 1 reply; 6+ messages in thread
From: Tim Romanski @ 2021-02-04 22:01 UTC (permalink / raw
To: u-boot
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* U-Boot ECDSA Implementation Question
2021-02-04 22:01 U-Boot ECDSA Implementation Question Tim Romanski
@ 2021-02-05 14:35 ` Simon Glass
2021-02-05 16:08 ` Alex G.
0 siblings, 1 reply; 6+ messages in thread
From: Simon Glass @ 2021-02-05 14:35 UTC (permalink / raw
To: u-boot
Hi Tim
+Alexandru Gagniuc
On Thu, 4 Feb 2021 at 15:01, Tim Romanski <t-tromanski@microsoft.com> wrote:
>
> 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.
U-Boot's RSA came originally from Android I think and was modified for
use in Chrome OS. However the implementation in U-Boot of the
verification part is quite small - mostly in rsa-verify.c with some
maths in rsa-mod-exp.c and U-Boot has added various new features over
the years. We don't synchronous security patches formally although of
course they are published. I think pulling in something from Linux
makes sense if it is not too large, as the projects are fairly close
in coding style, contributors, etc.
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 you have a nice internship!
Regards,
Simon
^ permalink raw reply [flat|nested] 6+ messages in thread
* U-Boot ECDSA Implementation Question
2021-02-05 14:35 ` Simon Glass
@ 2021-02-05 16:08 ` Alex G.
2021-02-10 19:45 ` [EXTERNAL] " Tim Romanski
0 siblings, 1 reply; 6+ messages in thread
From: Alex G. @ 2021-02-05 16:08 UTC (permalink / raw
To: u-boot
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://github.com/mrnuke/u-boot/commits/patch-mkimage-keyfile-v1
[2]
https://github.com/mrnuke/u-boot/commit/a2ae016f2f80579962d4ab058137c8e1a4f4741f
[3]
https://github.com/mrnuke/u-boot/blob/3f447efcf8ad98d0eea349994810a66b453ac188/doc/uImage.FIT/signature.txt#L488
[4]
https://github.com/mrnuke/u-boot/commit/31caceb0e28959881e96ea49a0b28fd44d13a947
[5] https://github.com/mrnuke/u-boot/commits/patch-stm32-ecdsa-v1
[6]
https://github.com/mrnuke/u-boot/blob/7d7ce8d70287568071a5d24acb6dc74b923fe7e0/include/u-boot/rsa-mod-exp.h#L79
^ permalink raw reply [flat|nested] 6+ messages in thread
* [EXTERNAL] Re: U-Boot ECDSA Implementation Question
2021-02-05 16:08 ` Alex G.
@ 2021-02-10 19:45 ` Tim Romanski
2021-02-22 23:33 ` Alex G.
0 siblings, 1 reply; 6+ messages in thread
From: Tim Romanski @ 2021-02-10 19:45 UTC (permalink / raw
To: u-boot
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. <mr.nuke.me@gmail.com>
Sent: February 5, 2021 11:09 AM
To: Simon Glass <sjg@chromium.org>; Tim Romanski <t-tromanski@microsoft.com>
Cc: u-boot at lists.denx.de; Deskin Miller <deskinm@microsoft.com>; Dylan D'Silva <ddsilva@microsoft.com>
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-v1&data=04%7C01%7Ct-tromanski%40microsoft.com%7C4e326c48dc2f4e89df5d08d8c9f0536f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637481381320581783%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=NulehqeJPXmR%2BLhHzBagWc9Uum1iFS5%2BSVlRu0L9SUU%3D&reserved=0
[2]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmrnuke%2Fu-boot%2Fcommit%2Fa2ae016f2f80579962d4ab058137c8e1a4f4741f&data=04%7C01%7Ct-tromanski%40microsoft.com%7C4e326c48dc2f4e89df5d08d8c9f0536f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637481381320581783%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Sa06A5TDKVxJ7sd1Dj%2FCiztHPQ%2BJBuzVbpK9mMVwMsU%3D&reserved=0
[3]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmrnuke%2Fu-boot%2Fblob%2F3f447efcf8ad98d0eea349994810a66b453ac188%2Fdoc%2FuImage.FIT%2Fsignature.txt%23L488&data=04%7C01%7Ct-tromanski%40microsoft.com%7C4e326c48dc2f4e89df5d08d8c9f0536f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637481381320581783%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ExeKMGFCC9QX6bGAyWztqMZqMqCqGWbhgZkF8odmcKM%3D&reserved=0
[4]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmrnuke%2Fu-boot%2Fcommit%2F31caceb0e28959881e96ea49a0b28fd44d13a947&data=04%7C01%7Ct-tromanski%40microsoft.com%7C4e326c48dc2f4e89df5d08d8c9f0536f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637481381320581783%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=QMhDdKcxviXg%2FhmXIwxpgmUKsc2aezNb3L9kZOgX198%3D&reserved=0
[5] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmrnuke%2Fu-boot%2Fcommits%2Fpatch-stm32-ecdsa-v1&data=04%7C01%7Ct-tromanski%40microsoft.com%7C4e326c48dc2f4e89df5d08d8c9f0536f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637481381320591742%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=bWUtVRDNSmwOIvizaPz8zQh6I0bmurz8vVh10ef%2B5O8%3D&reserved=0
[6]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmrnuke%2Fu-boot%2Fblob%2F7d7ce8d70287568071a5d24acb6dc74b923fe7e0%2Finclude%2Fu-boot%2Frsa-mod-exp.h%23L79&data=04%7C01%7Ct-tromanski%40microsoft.com%7C4e326c48dc2f4e89df5d08d8c9f0536f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637481381320591742%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=8FbEZj6l7vutTknzV4a5%2FnNtoznnQHIjdrP2rJiZEFs%3D&reserved=0
^ permalink raw reply [flat|nested] 6+ messages in thread
* [EXTERNAL] Re: U-Boot ECDSA Implementation Question
2021-02-10 19:45 ` [EXTERNAL] " Tim Romanski
@ 2021-02-22 23:33 ` Alex G.
2021-03-03 18:08 ` Tim Romanski
0 siblings, 1 reply; 6+ messages in thread
From: Alex G. @ 2021-02-22 23:33 UTC (permalink / raw
To: u-boot
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. <mr.nuke.me@gmail.com>
> Sent: February 5, 2021 11:09 AM
> To: Simon Glass <sjg@chromium.org>; Tim Romanski <t-tromanski@microsoft.com>
> Cc: u-boot at lists.denx.de; Deskin Miller <deskinm@microsoft.com>; Dylan D'Silva <ddsilva@microsoft.com>
> 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-v1&data=04%7C01%7Ct-tromanski%40microsoft.com%7C4e326c48dc2f4e89df5d08d8c9f0536f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637481381320581783%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=NulehqeJPXmR%2BLhHzBagWc9Uum1iFS5%2BSVlRu0L9SUU%3D&reserved=0
> [2]
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmrnuke%2Fu-boot%2Fcommit%2Fa2ae016f2f80579962d4ab058137c8e1a4f4741f&data=04%7C01%7Ct-tromanski%40microsoft.com%7C4e326c48dc2f4e89df5d08d8c9f0536f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637481381320581783%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Sa06A5TDKVxJ7sd1Dj%2FCiztHPQ%2BJBuzVbpK9mMVwMsU%3D&reserved=0
> [3]
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmrnuke%2Fu-boot%2Fblob%2F3f447efcf8ad98d0eea349994810a66b453ac188%2Fdoc%2FuImage.FIT%2Fsignature.txt%23L488&data=04%7C01%7Ct-tromanski%40microsoft.com%7C4e326c48dc2f4e89df5d08d8c9f0536f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637481381320581783%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ExeKMGFCC9QX6bGAyWztqMZqMqCqGWbhgZkF8odmcKM%3D&reserved=0
> [4]
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmrnuke%2Fu-boot%2Fcommit%2F31caceb0e28959881e96ea49a0b28fd44d13a947&data=04%7C01%7Ct-tromanski%40microsoft.com%7C4e326c48dc2f4e89df5d08d8c9f0536f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637481381320581783%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=QMhDdKcxviXg%2FhmXIwxpgmUKsc2aezNb3L9kZOgX198%3D&reserved=0
> [5] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmrnuke%2Fu-boot%2Fcommits%2Fpatch-stm32-ecdsa-v1&data=04%7C01%7Ct-tromanski%40microsoft.com%7C4e326c48dc2f4e89df5d08d8c9f0536f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637481381320591742%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=bWUtVRDNSmwOIvizaPz8zQh6I0bmurz8vVh10ef%2B5O8%3D&reserved=0
> [6]
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmrnuke%2Fu-boot%2Fblob%2F7d7ce8d70287568071a5d24acb6dc74b923fe7e0%2Finclude%2Fu-boot%2Frsa-mod-exp.h%23L79&data=04%7C01%7Ct-tromanski%40microsoft.com%7C4e326c48dc2f4e89df5d08d8c9f0536f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637481381320591742%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=8FbEZj6l7vutTknzV4a5%2FnNtoznnQHIjdrP2rJiZEFs%3D&reserved=0
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* [EXTERNAL] Re: U-Boot ECDSA Implementation Question
2021-02-22 23:33 ` Alex G.
@ 2021-03-03 18:08 ` Tim Romanski
0 siblings, 0 replies; 6+ messages in thread
From: Tim Romanski @ 2021-03-03 18:08 UTC (permalink / raw
To: u-boot
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. <mr.nuke.me@gmail.com>
Sent: February 22, 2021 6:33 PM
To: Tim Romanski <t-tromanski@microsoft.com>; Simon Glass <sjg@chromium.org>
Cc: u-boot at lists.denx.de; Deskin Miller <deskinm@microsoft.com>; Dylan D'Silva <ddsilva@microsoft.com>
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. <mr.nuke.me@gmail.com>
> Sent: February 5, 2021 11:09 AM
> To: Simon Glass <sjg@chromium.org>; Tim Romanski
> <t-tromanski@microsoft.com>
> Cc: u-boot at lists.denx.de; Deskin Miller <deskinm@microsoft.com>; Dylan
> D'Silva <ddsilva@microsoft.com>
> 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%2Fgith
> ub.com%2Fmrnuke%2Fu-boot%2Fcommits%2Fpatch-mkimage-keyfile-v1&data
> =04%7C01%7Ct-tromanski%40microsoft.com%7Cdf9b77d80e0a407b118408d8d78a4
> 148%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637496336104405466%7C
> Unknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1h
> aWwiLCJXVCI6Mn0%3D%7C1000&sdata=DaeOfna1Judsb9nMxHis68hqh2bM45ojlh
> kqoorEfTQ%3D&reserved=0
> [2]
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> ub.com%2Fmrnuke%2Fu-boot%2Fcommit%2Fa2ae016f2f80579962d4ab058137c8e1a4
> f4741f&data=04%7C01%7Ct-tromanski%40microsoft.com%7Cdf9b77d80e0a40
> 7b118408d8d78a4148%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637496
> 336104405466%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
> zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=x%2FnhL7GVyi2yL34kU
> Lzn3O5eOQMzkLZUpLolBIrg9wM%3D&reserved=0
> [3]
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> ub.com%2Fmrnuke%2Fu-boot%2Fblob%2F3f447efcf8ad98d0eea349994810a66b453a
> c188%2Fdoc%2FuImage.FIT%2Fsignature.txt%23L488&data=04%7C01%7Ct-tr
> omanski%40microsoft.com%7Cdf9b77d80e0a407b118408d8d78a4148%7C72f988bf8
> 6f141af91ab2d7cd011db47%7C1%7C0%7C637496336104405466%7CUnknown%7CTWFpb
> GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0
> %3D%7C1000&sdata=2TCDph4oYNyhKsjS8gc7MVKnzff42EXcrQC%2Flt5qILw%3D&
> amp;reserved=0
> [4]
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> ub.com%2Fmrnuke%2Fu-boot%2Fcommit%2F31caceb0e28959881e96ea49a0b28fd44d
> 13a947&data=04%7C01%7Ct-tromanski%40microsoft.com%7Cdf9b77d80e0a40
> 7b118408d8d78a4148%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637496
> 336104405466%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
> zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=bICF7YOUPu4Hnhi0XlQ
> BKnktnGAqJvj1auE3GUrRb44%3D&reserved=0
> [5]
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> ub.com%2Fmrnuke%2Fu-boot%2Fcommits%2Fpatch-stm32-ecdsa-v1&data=04%
> 7C01%7Ct-tromanski%40microsoft.com%7Cdf9b77d80e0a407b118408d8d78a4148%
> 7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637496336104405466%7CUnkn
> own%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi
> LCJXVCI6Mn0%3D%7C1000&sdata=PCskH6TTPETw3Hzfreytuaf33xRaeRn4WpHf4n
> 9wn9k%3D&reserved=0
> [6]
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> ub.com%2Fmrnuke%2Fu-boot%2Fblob%2F7d7ce8d70287568071a5d24acb6dc74b923f
> e7e0%2Finclude%2Fu-boot%2Frsa-mod-exp.h%23L79&data=04%7C01%7Ct-tro
> manski%40microsoft.com%7Cdf9b77d80e0a407b118408d8d78a4148%7C72f988bf86
> f141af91ab2d7cd011db47%7C1%7C0%7C637496336104415461%7CUnknown%7CTWFpbG
> Zsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%
> 3D%7C1000&sdata=WrQeFYIFOA3DWuztq7%2BbLUwWCQmYpnFRdc80Tyg%2FoIs%3D
> &reserved=0
>
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-03-03 18:08 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-02-04 22:01 U-Boot ECDSA Implementation Question Tim Romanski
2021-02-05 14:35 ` Simon Glass
2021-02-05 16:08 ` Alex G.
2021-02-10 19:45 ` [EXTERNAL] " Tim Romanski
2021-02-22 23:33 ` Alex G.
2021-03-03 18:08 ` Tim Romanski
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.