Hi Simon, Thanks for your reply.
On Tue, Dec 18, 2012 at 1:37 AM, Simon Glass <[email protected]> wrote: > Hi Joel, > > On Mon, Dec 17, 2012 at 9:11 PM, Fernandes, Joel A <[email protected]> wrote: > >> Hi, >> >> Can anyone comment on what has been discussed about a framework for secure >> boot and authentication, if there has been such a discussion, in the >> community? >> >> I have some U-boot code that is based off of a slightly older U-boot which >> does authentication and/or decryption. The main code that does the >> cryptography is in the ROM of the SoC. However, I'm sure there will be >> other U-boot developers requiring the crypto algorithms itself to be >> supported. >> >> My questions are : >> (1) Would a general framework for performing authentication and/or >> decryption of signed and/or encrypted images be useful for U-boot? These >> operations seem to make a lot of sense for a bootloader. > > >> (2) Does such a framework make sense for any of your usecase(s)? >> >> (3) Has there been any work or discussions of coming up with such a >> framework for U-boot? >> > > We have created a secure boot system on top of U-Boot - it is in the > Chromium tree if you want to take a look. Three ChromeOS devices have > shipped with this so far. However it is not really suitable for generic > upstream use, so... > > There have been some discussions lately on the list about using the FIT > format to hold an image which can then be verified using a public key. We > have put together a possible design for this and I am working on this as I > make time. Which Processor and silicon revision is this? Can you point to a security hardware specification so that I could take a quick look at the architecture you have in mind? Is it [1]? Also, is it possible to share the design for modification to FIT you have put together so far? >> I imagine a framework like this will atleast consist of: >> >> 1. General purposes cryptographic functions in a library (which we might >> not need for our case), some light weight crypto library. >> 2. Hooks for board/Soc-specific functions that call into the general >> crypto lib and do any other board/SoC-specific stuff. >> 3. General commands (in a cmd_crpto.c) that calls into the callbacks >> mentioned in 2. for encryption and verification of an image already in >> memory. (making it commands can allow us to leave bootm alone and do the >> inplace decryption/verification independently - however for SPL, we don't >> need the commands and call into 2. directly). >> 4. Abstract any other change(s) to common boot code in a common place. >> > > Yes that seems reasonable. Thanks. > A very basic hashing framework recently went into U-Boot, and this can be > used to plumb in SOC hashing acceleration code. I suspect we will do the > same with RSA, supporting a few different key lengths and associated > padding. > > My plan at present is roughly (and in short order) to: > > 1. Define how signatures are represented in FIT Just wondering what architecture / silicon are you using from the ChromiumOS, I guess its the Samsun Exynos? Anyway, isn't the representation of the signature and the other structure of the image fixed by your ROM or hardware specification? For example, to load U-boot SPL, doesn't your ROM or firmware expect the image signatures/certificates etc to be in a certain format? Then how can you use FIT for the purpose of verification/authentication? I agree FIT can be possibly modified enough to support this, but what about the first-stage loading of U-boot SPL. Does your ROM or architecture understand FIT? I agree second-state bootloader loading and then kernel can use FIT but I'm not clear on how you do verified-boot for U-boot SPL for example. Representing U-boot SPL as FIT is not possible right. Just a note, we run U-boot SPL from internal SRAM and not a programmable ROM. > 2. Enhance mkimage to sign an image or a configuration (consisting of image > +fdt, for example) > 3. Enhance FIT command to verify an image given a public key Yeah, this sound like a good plan. > 4. Support checking of version information against a TPM rollback counter I have no idea about TPM rollback, can you point to docs for that? > 5. Work this into the bootm code > 6. Add RSA2048/4096 cool , ok. For us right now we have ROM API that does all boot-time crypto (using hw acceleration where possible), but I guess those details can be abstracted for different secure boot architectures, and folks who need a pure software implementation can use it. Thanks, Joel [1] http://www.chromium.org/chromium-os/chromiumos-design-docs/verified-boot-crypto _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
