RFC: Remote signing support for mkimage

Daniel Frink Daniel.Frink at ibm.com
Thu Mar 19 18:38:49 CET 2026


Hi,

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.

Thanks,

Daniel Frink
Firmware Engineer - PowerVM Security
IBM Rochester, MN
Email: daniel.frink at ibm.com


More information about the U-Boot mailing list