AW: secure boot, mkimage with external signing server

Simon Glass sjg at chromium.org
Sat Jan 25 18:11:25 CET 2025


Hi Rasmus,

On Wed, 22 Jan 2025 at 16:27, Rasmus Villemoes <ravi at prevas.dk> wrote:
>
> 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.

Yes that sounds useful.

>
> 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

Note also that you don't need the original source. You can use the -F option.

> >
> > 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.

It would be nice to have a way to generate an instructions file, which
contains the hash to be signed, then a way to read the result file,
loading the private/public keys in as needed. In other words, split
the operations of mkgimag into two.

>
> 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

Regards,
Simon


More information about the U-Boot mailing list