[U-Boot] RSA in U-Boot

[Laszlo Ersek]

On 04/26/19 11:05, Alexander Graf wrote:
> 
> 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? :)

Difficult question. Ideally you'd want a library where three aspects met:

- widely used (so that there is a diverse community that's interested in
vulnerabilities, and fixing them too)

- easy to cross-compile for your free-standing environment (optimally
the upstream project would support being cross-compiled and packaged
stand-alone, for that free-standing environment)

- cares about API stability

OpenSSL is very widely used...
...and that's where we can stop in the list :)

Rolling your own covers #2 and #3, but lack of #1 makes security people
very nervous. (Rightfully so, I believe.)

Ultimately I think security expertise is the scarcest resource, so I'd
go with #1 -- I'd pick whichever project comes with the largest user
base and most scrutiny.

Thanks
Laszlo

>>> ----- 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 -----