[U-Boot] RFC: Secure boot framework

[Fernandes, Joel A]

Hi Simon,

Thanks for your reply.

On Tue, Dec 18, 2012 at 1:37 AM, Simon Glass <sjg at chromium.org> wrote:
> Hi Joel,
>
> On Mon, Dec 17, 2012 at 9:11 PM, Fernandes, Joel A <joelagnel at ti.com> 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