Thank all of you who commented on my question.
@Laszlo, I agree to the criteria that you mentioned. good user base is a crucial factor for security code.
@Paolo, I have had no idea about license term issues. You're right.
@Heinrich, thank you for pointing out gnutls. I'm stilling looking into the code, but my first impression is that it is not well optimized for *smaller* system.
@Sughosh, as Paolo mentioned, LibreSSL may have a similar license issue: The license term seems to be a variant of 3-clause BSD, and some file header says, * The licence and distribution terms for any publically available version or * derivative of this code cannot be changed. i.e. this code cannot simply be * copied and put under another distribution licence * [including the GNU Public Licence.]
Thanks, -Takahiro Akashi
On Fri, Apr 26, 2019 at 11:05:27AM +0200, 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? :)
Thanks,
Alex
Thanks, -Takahiro Akashi
Thanks, -Takahiro Akashi
----- Forwarded message from Simon Glass sjg@chromium.org -----
Date: Thu, 7 Mar 2019 19:56:10 -0700 From: Simon Glass sjg@chromium.org To: "AKASHI, Takahiro" takahiro.akashi@linaro.org Subject: Re: RSA in U-Boot
Hi Takahiro,
On Thu, 7 Mar 2019 at 17:27, AKASHI, Takahiro takahiro.akashi@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:
- 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 -----