[U-Boot] RFC: Secure boot framework
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?
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.
Let me know your suggestions, thanks.
Regards, Joel
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.
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.
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@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
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...
+Tom, Wolfgang, CL, Vadim
Hi Joel,
On Thu, Dec 20, 2012 at 3:54 PM, Fernandes, Joel A joelagnel@ti.com wrote:
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?
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:
- 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?
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.
- 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?
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.
- 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.
Yes that can be a detail of the board/architecture.
Thanks, Joel
[1] http://www.chromium.org/chromium-os/chromiumos-design-docs/verified-boot-cry...
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@1 { data = /incbin/("..."); type = "flat_dt"; arch = "arm"; os = "linux"; compression = "none"; load = <0x111>; entry = <0x222>; kernel-version = <1>; hash@1 { algo = "sha1"; value = <....>; }; signature@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@1 { ... hash@1 { algo = "sha1"; value = <....>; signature@1 { algo = "sha1,rsa2048"; key-hint = "dev"; value = <2Kb of hex data>; }; signature@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
participants (2)
-
Fernandes, Joel A -
Simon Glass