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