[U-Boot] RFC: Secure boot framework

[Simon Glass]

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.


> 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.

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
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
4. Support checking of version information against a TPM rollback counter
5. Work this into the bootm code
6. Add RSA2048/4096

This would provide the pieces for verified boot, if not a full
implementation. It should then be possible to do verified boot with a
U-Boot script. If we get this far then it will provide a good basis for
more advanced efforts.

Regards,
Simon


> Let me know your suggestions, thanks.
>
> Regards,
> Joel
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>