secure boot, mkimage with external signing server
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.commailto:klaus.rosenschild@hilti.com
www.hilti.dehttp://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
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
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
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
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:
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:
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
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:
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:
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
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:
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:
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
participants (3)
-
Rasmus Villemoes -
Rosenschild, Klaus -
Simon Glass