[U-Boot] RSA in U-Boot

Alexander Graf agraf at csgraf.de
Fri Apr 26 09:05:27 UTC 2019


On 25.04.19 04:12, AKASHI, Takahiro wrote:
> Update and reminder.
>
> On Mon, Mar 18, 2019 at 11:17:14AM +0900, AKASHI, Takahiro wrote:
>> Hi,
>>
>> I'd like to discuss this topic in public.
>> I will appreciate your comments here.
>> # FYI, I now started to experimentally port linux's pkcs7/x509
>> # parser.
> I've done porting linux's pkcs7/x509 parsers and they work well
> with my UEFI secure boot patch, but I'm still looking for other options
> as well.
>
> * openssl
>   Most of existing components linked to UEFI secure boot, including
>   EDK2, shim and grub, reply on this library. Why not for U-Boot?
>   The size of U-Boot UEFI code in U-Boot is already quite big, and
>   so the size of openssl won't be a big issue.
> * mbedTLS
>   which is maintained by ARM and used with Zephyr, I guess it should
>   have small footprint. But it currently lacks pkcs7 parser.
>
> Any thoughts?


Paolo, Laszlo, Ard, if you could write a new secure boot implementation
today, which of the options above would you pick and why so? :)


Thanks,

Alex


>
> Thanks,
> -Takahiro Akashi
>
>
>> Thanks,
>> -Takahiro Akashi
>>
>> ----- Forwarded message from Simon Glass <sjg at chromium.org> -----
>>
>> Date: Thu, 7 Mar 2019 19:56:10 -0700
>> From: Simon Glass <sjg at chromium.org>
>> To: "AKASHI, Takahiro" <takahiro.akashi at linaro.org>
>> Subject: Re: RSA in U-Boot
>>
>> Hi Takahiro,
>>
>> On Thu, 7 Mar 2019 at 17:27, AKASHI, Takahiro
>> <takahiro.akashi at linaro.org> wrote:
>>> Hi Simon,
>>>
>>> Before I start discussions publicly, I'd like to hear
>>> your opinion first.
>> I do think it is better to discuss this in public since there will be
>> other opinions.
>>
>>> I'm now working on implementing "secure boot"
>>> for UEFI U-Boot.
>>>
>>> As you might know, there are a couple of features
>>> required to achieve "secure boot":
>>> (I won't discuss about secure storage here though.)
>>> - x509 certificate decoder
>>> - pkcs7 decoder (for PE file's signature)
>>> - RSA verification
>>> - (hash digest, sha256)
>>>
>>> The original code, which was written by some other guy,
>>> Patrick, uses BearSSL for x509 and RSA and
>>> I'm now wondering what is the best solution.
>>> Obviously, I can think of several options here:
>>> 1. use BearSSL
>>>   1.a just import minimum set of files akin lib/libfdt
>>>   1.b link whole BearSSL as a library, merging the code
>>>         as git submodule
>>> 2. use openssl
>>> 3. import linux kernel code, particularly x509 & pkcs7 parser
>>> 4. write our own code
>>>
>>> I suppose that you weighed similar choices when you implemented
>>> "FIT image signing".
>>> Can you share your opinion with me?
>> I think if you can do 3 then it keeps U-Boot self-contained and
>> perhaps provides for simple code. That said, if the amount of code is
>> large and has an upstream there is clear precident for 1a, as you say.
>>
>> I am not sure about 4. If it is a relatively small amount of code,
>> then maybe, but surely it makes sense to use the linux code where
>> possible. That is what I did with the U-Boot livetree code.
>>
>> 1b sounds painful to me.
>>
>>> Regarding your lib/rsa code, you intentionally avoided to
>>> add formula of inverse-mod and power-mod of R. Do you still
>>> believe that the assumption is appropriate?
>>> (BearSSL implements its own montgomery.
>> If you look at a talk I gave on this, you can see that one of the
>> goals was to implement it efficiently, with minimal extra code at
>> run-time, and minimal memory usage. So unpacking complex key
>> structures did not seem like a good idea. From memory you can do
>> verified boot in about 7KB of extra code in U-Boot and it runs in a
>> small number of milliseconds.
>>
>> UEFI is obviously pretty big, so perhaps efficiency concerns are less
>> important. More important probably is wide compatibility, supporting
>> all possible options, etc.
>>
>> I hope this is helpful.
>>
>> Regards,
>> Simon
>>
>> ----- End forwarded message -----


More information about the U-Boot mailing list