* secure boot, mkimage with external signing server [not found] ` <VI1PR07MB9972E22550B1514AD604D399F7192@VI1PR07MB9972.eurprd07.prod.outlook.com> @ 2025-01-20 17:43 ` Rosenschild, Klaus 2025-01-21 9:28 ` Rasmus Villemoes 0 siblings, 1 reply; 7+ messages in thread From: Rosenschild, Klaus @ 2025-01-20 17:43 UTC (permalink / raw) To: u-boot@lists.denx.de [-- 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 --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: secure boot, mkimage with external signing server 2025-01-20 17:43 ` secure boot, mkimage with external signing server Rosenschild, Klaus @ 2025-01-21 9:28 ` Rasmus Villemoes 2025-01-21 17:47 ` AW: " Rosenschild, Klaus 2025-01-22 21:13 ` Rosenschild, Klaus 0 siblings, 2 replies; 7+ messages in thread From: Rasmus Villemoes @ 2025-01-21 9:28 UTC (permalink / raw) To: Rosenschild, Klaus; +Cc: u-boot@lists.denx.de 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* AW: secure boot, mkimage with external signing server 2025-01-21 9:28 ` Rasmus Villemoes @ 2025-01-21 17:47 ` Rosenschild, Klaus 2025-01-22 21:13 ` Rosenschild, Klaus 1 sibling, 0 replies; 7+ messages in thread From: Rosenschild, Klaus @ 2025-01-21 17:47 UTC (permalink / raw) To: Rasmus Villemoes; +Cc: u-boot@lists.denx.de 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* AW: secure boot, mkimage with external signing server 2025-01-21 9:28 ` Rasmus Villemoes 2025-01-21 17:47 ` AW: " Rosenschild, Klaus @ 2025-01-22 21:13 ` Rosenschild, Klaus 2025-01-22 23:27 ` Rasmus Villemoes 1 sibling, 1 reply; 7+ messages in thread From: Rosenschild, Klaus @ 2025-01-22 21:13 UTC (permalink / raw) To: Rasmus Villemoes; +Cc: u-boot@lists.denx.de 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: AW: secure boot, mkimage with external signing server 2025-01-22 21:13 ` Rosenschild, Klaus @ 2025-01-22 23:27 ` Rasmus Villemoes 2025-01-23 9:00 ` AW: " Rosenschild, Klaus 2025-01-25 17:11 ` Simon Glass 0 siblings, 2 replies; 7+ messages in thread From: Rasmus Villemoes @ 2025-01-22 23:27 UTC (permalink / raw) To: Rosenschild, Klaus; +Cc: u-boot@lists.denx.de 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* AW: AW: secure boot, mkimage with external signing server 2025-01-22 23:27 ` Rasmus Villemoes @ 2025-01-23 9:00 ` Rosenschild, Klaus 2025-01-25 17:11 ` Simon Glass 1 sibling, 0 replies; 7+ messages in thread From: Rosenschild, Klaus @ 2025-01-23 9:00 UTC (permalink / raw) To: Rasmus Villemoes; +Cc: u-boot@lists.denx.de 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: AW: secure boot, mkimage with external signing server 2025-01-22 23:27 ` Rasmus Villemoes 2025-01-23 9:00 ` AW: " Rosenschild, Klaus @ 2025-01-25 17:11 ` Simon Glass 1 sibling, 0 replies; 7+ messages in thread From: Simon Glass @ 2025-01-25 17:11 UTC (permalink / raw) To: Rasmus Villemoes; +Cc: Rosenschild, Klaus, u-boot@lists.denx.de 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2025-01-25 17:11 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <VI1PR07MB9972394B8A364AC9A18495F6F7192@VI1PR07MB9972.eurprd07.prod.outlook.com>
[not found] ` <VI1PR07MB9972E22550B1514AD604D399F7192@VI1PR07MB9972.eurprd07.prod.outlook.com>
2025-01-20 17:43 ` secure boot, mkimage with external signing server Rosenschild, Klaus
2025-01-21 9:28 ` Rasmus Villemoes
2025-01-21 17:47 ` AW: " Rosenschild, Klaus
2025-01-22 21:13 ` Rosenschild, Klaus
2025-01-22 23:27 ` Rasmus Villemoes
2025-01-23 9:00 ` AW: " Rosenschild, Klaus
2025-01-25 17:11 ` Simon Glass
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox