[U-Boot] FIT image signing

Simon Glass sjg at chromium.org
Fri Aug 4 08:44:17 UTC 2017


Hi Aaron,

On 25 July 2017 at 20:04, Aaron Williams
<Aaron.Williams at caviumnetworks.com> wrote:
> On Tuesday, July 25, 2017 4:54:15 PM PDT Aaron Williams wrote:
>> Hi all,
>>
>> I am trying to enable support for booting signed FIT images but I'm not sure
>> how I go about setting up the public keys. The documentation under
>> uImage.fit does not seem to cover how to go about setting up the keys for
>> U-Boot to verify the image.
>>
>> I can sign the .fit image without any issues but so far I have not been able
>> to put the keys in the device tree which gets passed to U-Boot.
>>
>> In our case we're using AARCH64 and the device tree is passed to U-Boot from
>> the ATF layer. At our lowest layer we use something called the BDK which
>> performs low-level initialization and builds the proper device tree. The
>> device tree is eventually passed as a parameter to U-Boot when the ATF
>> starts U-Boot.

Does U-Boot SPL run on this platform? If so then perhaps that could
set up the DT?

>>
>> Since the device tree is stored in RAM and is not particularly secure we
>> plan to add a call to the ATF to obtain the public key.
>>
>> I'm thinking the best way to do this would be to have another version of
>> rsa_verify which uses a separate function than rsa_verify_with_keynode so
>> that the properties are obtained elsewhere.

It looks like that function already works without device tree. Do you
mean fit_image_check_sig() and fit_config_check_sig()?

>>
>> In the meantime I am trying to use the device tree but it's not entirely
>> clear what data needs to be placed into the board device tree for this. The
>> documentation under doc/uImage.FIT is clear about what needs to go into the
>> .its files to generate the FIT image and I have no problem with that. There
>> is no documentation discussing how the keys are stored in the device tree
>> or what fields are used there. I did find some reference to it in
>> beaglebone_vboot.txt, however.

This is handled by mkimage. Is it really  not possible to sign the DT
that you use with mkimage? See also signature.txt which means the
fields used by RSA.

Since you are using ATF, how do you know that this is not corrupted?
What signing is done with that? Can you explain the full boot path you
are using?

>>
>> Is mkimage supposed to be able to add these fields to the device tree? If
>> so, I'm not sure how to do that.

Yes. See beaglebone_vboot.txt for an example of how to run mkimage.
You might also find these useful:

https://www.denx.de/wiki/pub/U-Boot/MiniSummitELCE2013/U-Boot_verified_RSA_boot_flow_on_arm_target.pdf

https://lwn.net/Articles/571031/

http://events.linuxfoundation.org/sites/events/files/slides/elce-2014.pdf

https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/42038.pdf

Some of the events have videos which you should be able to find.

>>
>> Also, I came across what appears to be a bug in mkimage when signing images.
>> In tools/image-host.c in fit_image_add_verification_data if
>> fit_image_process_sig or fit_image_process_hash returns -ENOSPC then -1 is
>> returned which causes mkimage to fail. Instead shouldn't -ENOSPC be returned
>> so that mkimage can resize the image and allow it to proceed?

I thought that bug was fixed a long time ago. What version of U-Boot
are you using?

>>
>> Cheers,
>>
>> -Aaron
>
> I found the problem with adding the public key data to our device tree. We
> were not leaving any padding space. That still does not address the issue we
> have about obtaining the keys from a location other than the device tree.

This should happen automatically (see version question above). If not,
please let me know.

>
> -Aaron
>
>
> --
> Aaron Williams
> Senior Software Engineer
> Cavium, Inc.
> (408) 943-7198        (510) 789-8988 (cell)

Regards,
Simon


More information about the U-Boot mailing list