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