AW: AW: secure boot, mkimage with external signing server
Rosenschild, Klaus
Klaus.Rosenschild at hilti.com
Thu Jan 23 10:00:55 CET 2025
Wow, the hint to use "tools/key2dtsi.py" saves my day.
Now, I think I have all I need to create a FIT image to test the approach.
Thanks a lot
Klaus
________________________________
Von: Rasmus Villemoes
Gesendet: Donnerstag, 23. Januar 2025 00:27
Bis: Rosenschild, Klaus
Cc: u-boot at lists.denx.de
Betreff: Re: AW: secure boot, mkimage with external signing server
CAUTION: This email originated from outside of Hilti. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
On Wed, Jan 22 2025, "Rosenschild, Klaus" <Klaus.Rosenschild at hilti.com> wrote:
> Hi Rasmus,
> thank you for pointing to this solution.
> I think this is the best way to do this.
>
> However, our signing server is very well protected and making changes there is a long and complex process.
> Right now, it only provides the following two functions:
>
> 1.
> generation of a signature of a sha256 hash using the private key
> 2.
> providing the public key, the pure key, not the certificate
>
> I found a workaround to determine the hash that mkimage uses to create the signature of the configuration without re-implementing the internal algorithm that mkimage uses:
>
> 1.
> create a temporary rsa private and public key
> 2.
> run mkimage to create a FIT image with signature: mkimage -k keys-f fitImage-sign-orig.its -r fitImage-sign
> 3.
> extract the signature from the FIT image
> 4.
> re-generate the hash from the signature and the public key: openssl pkeyutl -verifyrecover -in signFile.hash.sign.bin -pubin -inkey ../keys/build.pub -asn1parse
> 5.
> now, I can send the hash to the signing server, get the correct signature back and re-enter it into the FIT image (e.g. via python libfdt)
>
Urgh, it shouldn't be that complicated, and I would consider it quite
reasonable if mkimage could be instructed to emit the hash it actually
signs along with the signature.
But, I do think you should be able to create a pkcs#11 module which
simply takes that sha256 as input from the higher layers and does
whatever it needs to do to talk to the server, getting the signature
back.
> However, there is now another problem. I also need to put the public key into the device tree file. So, I have to run a slightly different mkimage command (with -K option):
> mkimage -k keys -f fitImage-sign-orig.its -r -K bcm2711-rpi-4-b.dtb fitImage-sign
>
> However, the -K options requires a certificate and not just the
> public.
Yeah, that is a fundamental design flaw of mkimage; one shouldn't need
to sign any image in order to get the public key data embedded in
u-boot's control dtb.
Fortunately, you can ignore what most tutorials tell you about that -K
option. There is a simple script in the u-boot repo, tools/key2dtsi.py,
which you can apply to just the public key, and you get a .dtsi fragment
that you can include when you build u-boot's control dtb. Either you can
use the CONFIG_DEVICE_TREE_INCLUDES mechanism for making sure that .dtsi
gets picked up during build, or you can simply copy-paste the contents
into your board's .dts file.
Rasmus
More information about the U-Boot
mailing list