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 <[email protected]> ----- >>> >>> Date: Thu, 7 Mar 2019 19:56:10 -0700 >>> From: Simon Glass <[email protected]> >>> To: "AKASHI, Takahiro" <[email protected]> >>> Subject: Re: RSA in U-Boot >>> >>> Hi Takahiro, >>> >>> On Thu, 7 Mar 2019 at 17:27, AKASHI, Takahiro >>> <[email protected]> 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 ----- _______________________________________________ U-Boot mailing list [email protected] https://lists.denx.de/listinfo/u-boot
