secure boot, mkimage with external signing server

secure boot, mkimage with external signing server

[Rosenschild, Klaus]

[-- Attachment #1: Type: text/plain, Size: 2748 bytes --]

Hello,
I have a question regarding the signing of a FIT image using mkimage. I already contacted DENX, they referred me to this mailing list.

mkimage supports the creation of a signed FIT image. To do this, we need to have an appropriate .its file and pass the private key as a parameter to the mkimage command:
mkimage -f fitImage-sign.its -k keys/  fitImage-signed

However, this approach does not work in our setup, as we do not have access to the private key.
The private key resides on an HSM (Hardware security module) that is not directly accessible for us. We can invoke signing related functions via an external signing server that takes a sha256 hash as input and returns the signed hash.
Then we need to add the signed hash to the FIT image.

The replacement of a signature in a FIT image can be easily done using the FDT library.
However, getting the sha256 hash that mkimage uses for the signing does not seems to be possible. I tried to reverse engineer the code, but it looks like that there are a lot of low level byte operations on the FIT image.
Now my questions:
Is there a way to get the SHA256 used for the signing somehow from the mkimage or via a different way?
Is there somewhere a documentation how this hash is generated from the unsigned FIT image ?

Any help is very much appreciated.

Some more details below

Our system runs on a raspberry pi CM 4 module. We use Yocto scarthgap to build the SW images.
The raspberry bootloader loads the U-boot which then boots the further system using a fit image.
We need to support secure boot for this platform. As part of it, we need to have a signed fit image.
Currently, we achieve this using the mkimage tool with the -k option to pass the private key. Via this procedure we are able to execute the secure boot successfully.
However, our organization requires to use a dedicated signing server that implements an organization wide security infrastructure.
It requires a hash (sha256) as input and returns a signature that is generated using the private key inside the signing server.
Our challenges are now:

  1.  Get the hashes that mkimage uses as a base for the signatures
  2.  Manipulate the fit image to include the configuration signatures
The attachments may provide further details.

Thank you very much and Regards

Klaus Rosenschild
IoT solution architect
OP BU Tool Services

Hilti Entwicklungsgesellschaft mbH
Hiltistraße 6 | 86916 Kaufering

E klaus.rosenschild@hilti.com<mailto:klaus.rosenschild@hilti.com>

www.hilti.de<http://www.hilti.de/>

Hilti Entwicklungsgesellschaft mbH
Geschäftsführer: Dr. Olaf Schadoffsky
Sitz der Gesellschaft: D-86916 Kaufering, Hiltistraße 6
Amtsgericht Augsburg HRB 16295


[-- Attachment #2: mkimage-log.txt --]
[-- Type: text/plain, Size: 8988 bytes --]

rosekla@K122842H1:~/signing/playground/uboot$ ls
bcm2711-rpi-4-b.dtb  fitImage.its                                             keys
fitImage-sign.its    hilti-locker-initramfs-raspberrypi-cm4-digisens.cpio.gz  linux.bin
rosekla@K122842H1:~/signing/playground/uboot$ cat fitImage.its
/dts-v1/;

/ {
        description = "Kernel fitImage for Poky (Yocto Project Reference Distro)/6.6.22+git/raspberrypi-cm4-digisens";
        #address-cells = <1>;

        images {
                kernel-1 {
                        description = "Linux kernel";
                        data = /incbin/("linux.bin");
                        type = "kernel";
                        arch = "arm64";
                        os = "linux";
                        compression = "none";
                        load = <0x00008000>;
                        entry = <0x00008000>;
                        hash-1 {
                                algo = "sha256";
                        };
                };
                fdt-bcm2711-rpi-4-b.dtb {
                        description = "Flattened Device Tree blob";
                        data = /incbin/("bcm2711-rpi-4-b.dtb");
                        type = "flat_dt";
                        arch = "arm64";
                        compression = "none";

                        hash-1 {
                                algo = "sha256";
                        };
                };
                ramdisk-1 {
                        description = "hilti-locker-initramfs";
                        data = /incbin/("hilti-locker-initramfs-raspberrypi-cm4-digisens.cpio.gz");
                        type = "ramdisk";
                        arch = "arm64";
                        os = "linux";
                        compression = "none";


                        hash-1 {
                                algo = "sha256";
                        };
                };
        };

        configurations {
                default = "conf-bcm2711-rpi-4-b.dtb";
                conf-bcm2711-rpi-4-b.dtb {
                        description = "1 Linux kernel, FDT blob, ramdisk";

                        kernel = "kernel-1";
                        fdt = "fdt-bcm2711-rpi-4-b.dtb";
                        ramdisk = "ramdisk-1";


                };
        };
};
rosekla@K122842H1:~/signing/playground/uboot$ cat fitImage-sign.its
/dts-v1/;

/ {
        description = "Kernel fitImage for Poky (Yocto Project Reference Distro)/6.6.22+git/raspberrypi-cm4-digisens";
        #address-cells = <1>;

        images {
                kernel-1 {
                        description = "Linux kernel";
                        data = /incbin/("linux.bin");
                        type = "kernel";
                        arch = "arm64";
                        os = "linux";
                        compression = "none";
                        load = <0x00008000>;
                        entry = <0x00008000>;
                        hash-1 {
                                algo = "sha256";
                        };
                };
                fdt-bcm2711-rpi-4-b.dtb {
                        description = "Flattened Device Tree blob";
                        data = /incbin/("bcm2711-rpi-4-b.dtb");
                        type = "flat_dt";
                        arch = "arm64";
                        compression = "none";

                        hash-1 {
                                algo = "sha256";
                        };
                };
                ramdisk-1 {
                        description = "hilti-locker-initramfs";
                        data = /incbin/("hilti-locker-initramfs-raspberrypi-cm4-digisens.cpio.gz");
                        type = "ramdisk";
                        arch = "arm64";
                        os = "linux";
                        compression = "none";


                        hash-1 {
                                algo = "sha256";
                        };
                };
        };

        configurations {
                default = "conf-bcm2711-rpi-4-b.dtb";
                conf-bcm2711-rpi-4-b.dtb {
                        description = "1 Linux kernel, FDT blob, ramdisk";

                        kernel = "kernel-1";
                        fdt = "fdt-bcm2711-rpi-4-b.dtb";
                        ramdisk = "ramdisk-1";


                        signature {
                                algo = "sha256,rsa2048";
                                key-name-hint = "build";
                                sign-images = "kernel", "fdt", "ramdisk";
                                require-hash = "true";
                                padding = "pkcs-1.5";
                                sig-type = "x509";
                        };
                };
        };
};
rosekla@K122842H1:~/signing/playground/uboot$ mkimage -f fitImage.its  fitImage
FIT description: Kernel fitImage for Poky (Yocto Project Reference Distro)/6.6.22+git/raspberrypi-cm4-digisens
Created:         Wed Jan 15 15:52:49 2025
 Image 0 (kernel-1)
  Description:  Linux kernel
  Created:      Wed Jan 15 15:52:49 2025
  Type:         Kernel Image
  Compression:  uncompressed
  Data Size:    27406848 Bytes = 26764.50 KiB = 26.14 MiB
  Architecture: AArch64
  OS:           Linux
  Load Address: 0x00008000
  Entry Point:  0x00008000
  Hash algo:    sha256
  Hash value:   8fd7fa36fe73eb8f9a43e64e1be6d6d7f4225056985699692076feb2e6da358e
 Image 1 (fdt-bcm2711-rpi-4-b.dtb)
  Description:  Flattened Device Tree blob
  Created:      Wed Jan 15 15:52:49 2025
  Type:         Flat Device Tree
  Compression:  uncompressed
  Data Size:    54809 Bytes = 53.52 KiB = 0.05 MiB
  Architecture: AArch64
  Hash algo:    sha256
  Hash value:   b7a32c0939c4d51b9ab87c6d3d68388887c828f258bfa3fa48c8290a635fadd4
 Image 2 (ramdisk-1)
  Description:  hilti-locker-initramfs
  Created:      Wed Jan 15 15:52:49 2025
  Type:         RAMDisk Image
  Compression:  uncompressed
  Data Size:    41491844 Bytes = 40519.38 KiB = 39.57 MiB
  Architecture: AArch64
  OS:           Linux
  Load Address: unavailable
  Entry Point:  unavailable
  Hash algo:    sha256
  Hash value:   b4c834417c8a845907cc19a415fa69f4e23b442f03f1ea56f5b431b7fa2047fa
 Default Configuration: 'conf-bcm2711-rpi-4-b.dtb'
 Configuration 0 (conf-bcm2711-rpi-4-b.dtb)
  Description:  1 Linux kernel, FDT blob, ramdisk
  Kernel:       kernel-1
  Init Ramdisk: ramdisk-1
  FDT:          fdt-bcm2711-rpi-4-b.dtb
rosekla@K122842H1:~/signing/playground/uboot$ mkimage -f fitImage-sign.its -k keys/  fitImage-signed
FIT description: Kernel fitImage for Poky (Yocto Project Reference Distro)/6.6.22+git/raspberrypi-cm4-digisens
Created:         Wed Jan 15 15:52:58 2025
 Image 0 (kernel-1)
  Description:  Linux kernel
  Created:      Wed Jan 15 15:52:58 2025
  Type:         Kernel Image
  Compression:  uncompressed
  Data Size:    27406848 Bytes = 26764.50 KiB = 26.14 MiB
  Architecture: AArch64
  OS:           Linux
  Load Address: 0x00008000
  Entry Point:  0x00008000
  Hash algo:    sha256
  Hash value:   8fd7fa36fe73eb8f9a43e64e1be6d6d7f4225056985699692076feb2e6da358e
 Image 1 (fdt-bcm2711-rpi-4-b.dtb)
  Description:  Flattened Device Tree blob
  Created:      Wed Jan 15 15:52:58 2025
  Type:         Flat Device Tree
  Compression:  uncompressed
  Data Size:    54809 Bytes = 53.52 KiB = 0.05 MiB
  Architecture: AArch64
  Hash algo:    sha256
  Hash value:   b7a32c0939c4d51b9ab87c6d3d68388887c828f258bfa3fa48c8290a635fadd4
 Image 2 (ramdisk-1)
  Description:  hilti-locker-initramfs
  Created:      Wed Jan 15 15:52:58 2025
  Type:         RAMDisk Image
  Compression:  uncompressed
  Data Size:    41491844 Bytes = 40519.38 KiB = 39.57 MiB
  Architecture: AArch64
  OS:           Linux
  Load Address: unavailable
  Entry Point:  unavailable
  Hash algo:    sha256
  Hash value:   b4c834417c8a845907cc19a415fa69f4e23b442f03f1ea56f5b431b7fa2047fa
 Default Configuration: 'conf-bcm2711-rpi-4-b.dtb'
 Configuration 0 (conf-bcm2711-rpi-4-b.dtb)
  Description:  1 Linux kernel, FDT blob, ramdisk
  Kernel:       kernel-1
  Init Ramdisk: ramdisk-1
  FDT:          fdt-bcm2711-rpi-4-b.dtb
  Sign algo:    sha256,rsa2048:build
  Sign padding: pkcs-1.5
  Sign value:   9c75ff865d195d6d529cc00a85ee27a6a7cdd6dc8ccc78d873f0e3346f3b26fefc1bb60319c14886f64329f77aeea7b261fcf5b2be5cdbe558cd4638b734bc21aec71d2b6b18f2d0cdc8cc02d1bec125295c5dff5d2da0dac0618e3dcbb46e983b4c4b0aa83c8698d48b66e127513458efd6e2e59cacd60207e86cf37c5215611de933abc740ddb226c65faac78622591e8d5bae06e38689646dee0a26fbe86640301c002f952307d189dcf8bb08fc63a9d433a1b075d3c855461bbce06c19fc27cd4a6ed3fbe1dccfe46d56c0a0181d5a4f23687a63e2697d79eb58b0cb3d8d16f2c9788bea51870cceb710206ed48dce0288028f7f873e07e29e5419e272b0
  Timestamp:    Wed Jan 15 15:52:58 2025

[-- Attachment #3: build-procedure.jpg --]
[-- Type: image/jpeg, Size: 27694 bytes --]

Re: secure boot, mkimage with external signing server

[Rasmus Villemoes]

On Mon, Jan 20 2025, "Rosenschild, Klaus" <Klaus.Rosenschild@hilti.com> wrote:

> Hello,
> I have a question regarding the signing of a FIT image using mkimage. I already contacted DENX, they referred me to this mailing list.
>
> mkimage supports the creation of a signed FIT image. To do this, we need to have an appropriate .its file and pass the private key as a parameter to the mkimage command:
> mkimage -f fitImage-sign.its -k keys/  fitImage-signed
>
> However, this approach does not work in our setup, as we do not have access to the private key.
> The private key resides on an HSM (Hardware security module) that is not directly accessible for us. We can invoke signing related functions via an external signing server that takes a sha256 hash as input and returns the signed hash.
> Then we need to add the signed hash to the FIT image.
>

You may want to look into using an openssl pkcs11 module interfacing
with that HSM. Then use appropriate openssl configuration (set
OPENSSL_CONF env variable) and pass "-N pkcs11" and "-G <some pkcs11
URI>" to mkimage. This is something we've done in a number of cases with
a Yubi HSM.

Rasmus

AW: secure boot, mkimage with external signing server

[Rosenschild, Klaus]

Hi Rasmus,
thank you for pointing to this option. We will also check on this option.

Best Regards
Klaus
________________________________
Von: Rasmus Villemoes <ravi@prevas.dk>
Gesendet: Dienstag, 21. Januar 2025 10:28
An: Rosenschild, Klaus <Klaus.Rosenschild@hilti.com>
Cc: u-boot@lists.denx.de <u-boot@lists.denx.de>
Betreff: Re: 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 Mon, Jan 20 2025, "Rosenschild, Klaus" <Klaus.Rosenschild@hilti.com> wrote:

> Hello,
> I have a question regarding the signing of a FIT image using mkimage. I already contacted DENX, they referred me to this mailing list.
>
> mkimage supports the creation of a signed FIT image. To do this, we need to have an appropriate .its file and pass the private key as a parameter to the mkimage command:
> mkimage -f fitImage-sign.its -k keys/  fitImage-signed
>
> However, this approach does not work in our setup, as we do not have access to the private key.
> The private key resides on an HSM (Hardware security module) that is not directly accessible for us. We can invoke signing related functions via an external signing server that takes a sha256 hash as input and returns the signed hash.
> Then we need to add the signed hash to the FIT image.
>

You may want to look into using an openssl pkcs11 module interfacing
with that HSM. Then use appropriate openssl configuration (set
OPENSSL_CONF env variable) and pass "-N pkcs11" and "-G <some pkcs11
URI>" to mkimage. This is something we've done in a number of cases with
a Yubi HSM.

Rasmus

AW: secure boot, mkimage with external signing server

[Rosenschild, Klaus]

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)

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. But as described above, I only have the public key. For the certificate, I also need to have private key of the signing server (which I do not have).
I also do not see the security gain that a certificate would bring here.

So, my question is. Is there a way to make mkimage access the public key rather than the certification (dumping fdt does not look like it stores certificate data).
Is there is simple way to replace the public key in a device tree file?

Any help is very much appreciated. Thanks a lot in advance.

Best Regards
Klaus



________________________________
Von: Rasmus Villemoes
Gesendet: Dienstag, 21. Januar 2025 10:28
Bis: Rosenschild, Klaus
Cc: u-boot@lists.denx.de
Betreff: Re: 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 Mon, Jan 20 2025, "Rosenschild, Klaus" <Klaus.Rosenschild@hilti.com> wrote:

> Hello,
> I have a question regarding the signing of a FIT image using mkimage. I already contacted DENX, they referred me to this mailing list.
>
> mkimage supports the creation of a signed FIT image. To do this, we need to have an appropriate .its file and pass the private key as a parameter to the mkimage command:
> mkimage -f fitImage-sign.its -k keys/  fitImage-signed
>
> However, this approach does not work in our setup, as we do not have access to the private key.
> The private key resides on an HSM (Hardware security module) that is not directly accessible for us. We can invoke signing related functions via an external signing server that takes a sha256 hash as input and returns the signed hash.
> Then we need to add the signed hash to the FIT image.
>

You may want to look into using an openssl pkcs11 module interfacing
with that HSM. Then use appropriate openssl configuration (set
OPENSSL_CONF env variable) and pass "-N pkcs11" and "-G <some pkcs11
URI>" to mkimage. This is something we've done in a number of cases with
a Yubi HSM.

Rasmus

Re: AW: secure boot, mkimage with external signing server

[Rasmus Villemoes]

On Wed, Jan 22 2025, "Rosenschild, Klaus" <Klaus.Rosenschild@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

AW: AW: secure boot, mkimage with external signing server

[Rosenschild, Klaus]

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

Re: AW: secure boot, mkimage with external signing server

[Simon Glass]

Hi Rasmus,

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