[U-Boot] RFC: Secure boot framework

[Simon Glass]

+Tom, Wolfgang, CL, Vadim

Hi Joel,

On Thu, Dec 20, 2012 at 3:54 PM, Fernandes, Joel A <joelagnel at ti.com> wrote:
>
> 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?

It is exynos5250 rev1 - the device is called snow in the source code.
I don't have a full description other than what is on chromium.org,
but you can ask me questions! For FIT, see below for current proposal.

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

Yes, we will update the firmware. This is not for snow (which already
has a verified boot) but for the future. We want to try to implement a
general purpose verified boot in U-Boot.

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

We use a read-only SPI flash, where the root keys are stored. After
manufacture they cannot be changed without opening the case.

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

There is some discussion (lots of docs) at chromium.org. Basically if
we decide that kernel version 2 is compromised, we roll out version 3.
Once a machine has that, it needs to ensure that version 2 will not
run.

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

Yes that can be a detail of the board/architecture.

>
> Thanks,
> Joel
>
> [1] http://www.chromium.org/chromium-os/chromiumos-design-docs/verified-boot-crypto


Here are my thoughts so far:

Adding Signatures to FITs

It seems pretty straightforward to extend the existing FIT scheme to
allow signatures to be attached to each hash. An example would be is
as follows:

/ {
	images {
		kernel at 1 {
		data = /incbin/("...");
		type = "flat_dt";
		arch = "arm";
		os = "linux";
		compression = "none";
		load = <0x111>;
		entry = <0x222>;
		kernel-version = <1>;
		hash at 1 {
		algo = "sha1";
		value = <....>;
		};
	signature at 1 {
		algo = "sha1,rsa2048";
		key-hint = "dev";
		description = “Dev-signed kernel 3.8.0-33, snow FDT”;
		signer = “mkimage”;
		signer-version = “ v2013.01”;
		value = <....>;
	};
…

In this case the kernel hash is signed with a private key. The
resulting ciphertext can be stored in the signature node in the same
was as the hash. We can permit signing images with multiple keys so
that images can be verified either in dev mode (for messing around) or
production mode (for shipping). The dev mode private key would be
widely available, and the production private key would be very very
secret. A kernel signed both ways may end up looking like this:

/ {
	images {
	kernel at 1 {
		...
		hash at 1 {
		algo = "sha1";
		value = <....>;
	signature at 1 {
		algo = "sha1,rsa2048";
		key-hint = "dev";
		value = <2Kb of hex data>;
	};
	signature at 2 {
		algo = "sha1,rsa2048";
		key-hint = "production";
		value = <2Kb of hex data>;
	};
…

We can fairly easily extend the mkimage tool to support signing of
images. The main additions are the cryptographic algorithms,
additional command line options for supplying a key and the additional
scanning steps looking for signature information.

Verifying images

In order to verify a FIT, and therefore perform one step of a verified
boot, a simple algorithm would be as follows:

1. Select a public key to use for verification of images. This could
come from U-Boot’s FDT supplied by CONFIG_OF_CONTROL, using a format
similar to the signature node above.
2. Load the entire FIT into memory
3. Look through the available configurations and decide which images to load

3a. This may involve checking image version numbers
3b. The TPM may be consulted to decide the minimum version we will
accept for each image type (rollback protection)

4. For “sha1,rsa2048” as an example, compute hashes of these images as
specified in the FIT and the signature of each of these hashes using
the supplied public key
5. For each image, verify that the resulting check hash matches with
the computed hash


Hopefully that provided a starting point of what we are thinking. Once
i have some comments I will put together a patch with a README
describing this. We have a lot of the code sitting around but it needs
to be cleaned up and pulled together.

Regards,
Simon