RFC: Remote signing support for mkimage

[Daniel Frink]

Hi Peter -

Thanks for the response, sorry for the delay in getting back to you.

To clarify - the proposed interface is fully tooling-agnostic. I am not proposing integration with any specific signing API or library, but rather, a mode where mkimage’s side of the signing is limited to creating the digests that need to be signed, and ingesting the signatures after they have been created.

To go into a bit more detail, here are my thoughts on how this would work from an end-to-end perspective.

Step 1: mkimage --emit-hashes

  *
mkimage builds the FIT as before, computes the digest(s) that would ordinarily be passed to EVP_DigestSignFinal, and instead writes them along with signing metadata to a JSON file. I have attached an example of what the hash and signature files could look like.

Step 2: External signing

  *
This is left to the caller and does not require anything from mkimage. The information given in the hash file should be very straightforward for signers to parse and use with their remote signing service. After completing the signing, the signers will then create a JSON file containing entries corresponding to each entry in the JSON file produced in step 1.

Step 3: mkimage --inject-signatures

  *
mkimage reads the provided JSON signature file and writes each signature into its correct FIT node by looking up the “id” field in the JSON as the FDT node path. Optionally, it validates the signatures if the public key/certificate is provided with the -G option.

A couple more comments:

  *
The proposed exchange format is standard JSON - nothing proprietary. It is just a thin, flexible adapter between mkimage and whatever signing service the caller has available.
  *
My thought is that json-c could be used to handle JSON file creation and parsing. Here are a few reasons I see json-c as a potentially acceptable dependency to add:
     *
mkimage already relies on OpenSSL as an external dependency. json-c, in comparison, is much lighter and much more narrowly scoped.
     *
JSON’s simpler structure makes parsers less error-prone to implement correctly than binary formats like ASN.1
     *
json-c is already widely packaged in many major distros and is actively maintained

Let me know if you have any other questions.

Thanks,
Daniel Frink
Firmware Engineer - PowerVM Security
IBM Rochester, MN
Email: daniel.frink at ibm.com
From: Peter Robinson <pbrobinson at gmail.com>
Date: Thursday, April 23, 2026 at 11:02 AM
To: Daniel Frink <Daniel.Frink at ibm.com>
Cc: u-boot at lists.denx.de <u-boot at lists.denx.de>; George Wilson <gcwilson at us.ibm.com>; Chris Engel <cjengel at us.ibm.com>; NAYNA JAIN <naynjain at ibm.com>
Subject: [EXTERNAL] Re: RFC: Remote signing support for mkimage

Hi Daniel,

> I wanted to check whether a patch I'd like to submit to mkimage to better support remote secure signing servers would be acceptable for upstream.
>
> Currently, we support this capability via a custom PKCS#11 module via an OpenSSL engine. The migration to OpenSSL 3 (and the need to upgrade our libp11 dependency) is going to force major changes on our end, as newer releases of libp11 no longer reliably support signing with our OpenSSL engine/custom PKCS#11 module. The libp11 maintainers have explicitly stated they only support OpenSSL engines on a best-effort basis.
>
> It seems to me that the ideal solution would be support for a 3-step signing flow in mkimage:
>
> 1. mkimage --emit-hashes — emits all hashes that need to be signed
> 2. External signing tooling produces signatures
> 3. mkimage --inject-signatures — signatures for each hash are provided, validated against a provided public key, and injected back into the image
>
> We're aware the OpenSSL provider system is a potential uplift path, but we believe a tooling-agnostic signing interface would be more accessible to organizations with diverse signing infrastructure, avoiding the need to implement and maintain custom OpenSSL plugin code entirely. We'd also prefer not to resort to workarounds such as signing with a throwaway key and manually extracting/re-injecting signatures.
>
> If this direction seems acceptable, or if you're open to the idea but have concerns about the approach, I'd welcome your feedback before investing time in a full patch.

I think the ability to do remote signing functionality would be fine.
It might be useful to go into a bit more details of what you're
thinking here, is there open standards/APIs for this sort of
integration? Most of what I'm aware of, and it's been some time since
I looked, was either using PKCS interfaces or proprietary
APIs/libraries, the later IMO would not be appropriate.

Regards,
Peter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: example-signatures.json
Type: application/json
Size: 1173 bytes
Desc: example-signatures.json
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20260508/5a610a59/attachment.json>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: example-hashes.json
Type: application/json
Size: 441 bytes
Desc: example-hashes.json
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20260508/5a610a59/attachment-0001.json>