Hi Simon,
Thanks for your reply.
On Tue, Dec 18, 2012 at 1:37 AM, Simon Glass sjg@chromium.org wrote:
Hi Joel,
On Mon, Dec 17, 2012 at 9:11 PM, Fernandes, Joel A joelagnel@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:
- 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:
- 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.
- 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.
- Support checking of version information against a TPM rollback counter
I have no idea about TPM rollback, can you point to docs for that?
- Work this into the bootm code
- 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-cry...