[U-Boot] FIT image signing

[U-Boot] FIT image signing

[Aaron Williams]

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.

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.

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.

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

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?

Cheers,

-Aaron

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

[U-Boot] FIT image signing

[Aaron Williams]

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.
> 
> 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.
> 
> 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.
> 
> Is mkimage supposed to be able to add these fields to the device tree? If
> so, I'm not sure how to do that.
> 
> 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?
> 
> 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.

-Aaron


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

[U-Boot] FIT image signing

[Simon Glass]

Hi Aaron,

On 25 July 2017 at 20:04, Aaron Williams
<Aaron.Williams@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