[PATCH 0/3] fit: allow signing with only an engine_id

[Wolfgang Wallner]

 Hi Quentin,

> On 11/11/25 11:10 AM, Wolfgang Wallner wrote:
> > Hi Quentin,
> >
> >> This series allows to sign a FIT image with mkimage (and binman) with
> >> only an OpenSSL engine and no key-dir. mkimage will read the
> >> key-name-hint property and pass that verbatim to the OpenSSL engine API
> >> via the key_id argument.
> >
> > Thanks for implementing this!
> > I was already looking for a way to implement this myself when I saw your
> > implementation on the mailing list.
> >
> > I have tested your patch series in our environment with our PKI provider.
> > Our PKI provider supports the OpenSSL engine API with a PKCS#11 library.
> >
> > Signing and verification with your patch series works fine in our use case.
> >
> > I only stumbled over a small issue, but that has nothing to with your patch
> > series:
> > Initially I used the same key-name-hint in the FIT description for
> > U-Boot proper (which is then used by mkimage for signing) and in the
> > description for U-Boot SPL (within an u-boot-spl-pubkey-dtb entry).
> > In my case key-name-hint contains a colon and several equation signs, it looks
> > something like this:
> >
> >      key-name-hint = "pkcs11:model=xxx;manufacturer=xxx;serial=1234;token=xxx;id=xxx;object=xxx";
> >
> > But when I do this, I cannot decompile the final SPL devicetree any more.
> > Decompiling with dtc gives me a "Bad character '=' in node name" error then.
> 
> The issue is probably that we use the key-name-hint for the key node in
> SPL DTB, c.f.
> https://urldefense.com/v3/__https://elixir.bootlin.com/u-boot/v2025.10/source/lib/rsa/rsa-sign.c*L677__;Iw!!NLW3fF9v!NY3fN9fyh10vF5rVo7-QzKVDnswgoETJaGRb-wCmd8mCjtUXscKGXP7DjqRDJt79NEjixr6ATvMFWfY0vppIHVJNggm5SpqGOpnVHenp$

Yes, that is the line that includes the value of key-name-hint into the node
name.

> We could sanitize the keyname to make sure it's an appropriate name for
> a DT node. According to the standard, allowed characters are
> 
> [0-9][a-z][A-Z],._+-
> 
> and the node name shall start with a letter. We could iterate over the
> string and replace any unsupported character.
> 
> We shall do the same for when we try to find this key node,
> https://urldefense.com/v3/__https://elixir.bootlin.com/u-boot/v2025.10/source/boot/image-fit-sig.c*L87__;Iw!!NLW3fF9v!NY3fN9fyh10vF5rVo7-QzKVDnswgoETJaGRb-wCmd8mCjtUXscKGXP7DjqRDJt79NEjixr6ATvMFWfY0vppIHVJNggm5SpqGOopSJNvU$
> and/or
> https://urldefense.com/v3/__https://elixir.bootlin.com/u-boot/v2025.10/source/lib/rsa/rsa-verify.c*L538__;Iw!!NLW3fF9v!NY3fN9fyh10vF5rVo7-QzKVDnswgoETJaGRb-wCmd8mCjtUXscKGXP7DjqRDJt79NEjixr6ATvMFWfY0vppIHVJNggm5SpqGOr9w2Pt_$ .

For me this make sense, but Security is not my main area, it would be good to
get more feedback from the U-Boot community on such an approach.

> > As a workaround, I use a different key-name-hint in the SPL description now.
> > But as mentioned above, this is just something I found while testing your
> > patches, nothing caused by them.
> >
> 
> Can you show us a snippet of how this looks like?

Yes. But I'm not sure what exactly you are asking for.
Please tell me what you are interested in, and I will provide it.

> Because as far as I
> could tell, the key-name-hint in the SPL pubkey DTB must match the
> key-name-hint used for each signature node in the U-Boot proper FIT
> image.

With the workaround I use (full key-name-hint for U-Boot FIT, but simple
key-name-hint for SPL) the search for a key in rsa_verify_hash() will fail
at first, and then the loop iterates over all keys (in my current test case
the is just key), and the verification then works with the one key that is
found.

> But I assume the key-name-hint for you is used to pass parameters
> to the engine, so you cannot really NOT have it named this way?

Yes, exactly.

mkimage would support to pass in this information via the key-directory
parameter (-k or --key-dir). But this has two drawbacks:

1) It feels like a hack to pass key information via a parameter that is
supposed to be a directory
2) It is currently not implemented in binman.
 
> Maybe we should split the double meaning of key-name-hint which is both
> for identifying the signature to use and how to sign into two separate
> properties.

Yes, I think that would make sense.

How about the following?
   key-name-hint      for a short human readable name
   key-specification  for a full description for which key to use
   
In my case 'key-specification' would then be the long PKCS#11-string which
uniquely identifies the key within the PKI.

It might make sense to also add such a parameter to mkimage, as it does not
really fit the description of a key directory as mentioned above, even if it
works in the current implementation.

> > This series is useful for us, and I'm happy to assist with further testing and
> > review. I'm not sure if I can help with creating tests, but I will have a look
> > at the things Simon listed.
> >
> 
> I'll look into mocking the calls to mkimage for testing the binman part
> correctly calls mkimage but I think we should also think about adding
> test for (engine) signing with mkimage (and maybe even verify that the
> generated images work with sandbox for example).
> 
> I would also very much like to have a way to sign Rockchip images with
> the default binman instructions in rockchip-u-boot.dtsi, but this is
> currently not possible for multiple reasons.
> 
> 1) we misuse/abuse SPL_FIT_SIGNATURE without an actual signature/pubkey,
> only for verifying hashes. We should sign the image and add the pubkey
> if SPL_FIT_SIGNATURE is enabled, and fail if it cannot find a key, but
> we cannot do that because it would break current users. We would need to
> split the "check hash" from "verify hash with signature" functionality
> behind another Kconfig symbol for that. I don't think it cannot be done,
> but we need to be careful to avoid forgetting about checking hashes when
> signature is enabled.

Is this behavior specific for the rockchip code, or in the generic part?

> 2) Make most of the signing configurable through environment variables.
> key-name-hint, whether to use an engine and if so which one, the
> checksum algorithm in algo property, the crypto used (RSA/ECDSA) and its
> key size or whatever other parameter passed to the algo property, the
> padding type (PSS/PKCS) and salt length.

How would it work with environment variables?
There could be multiple signature nodes with different key-name-hints in a
FIT description, would you then assume to have different environment variables
for each?

> I believe we shouldn't make
> those part of the hardcoded binman configuration in DT or from defconfig
> because there is no reason to patch the tree (DT or defconfig) to change
> signatures for essentially the same binaries. We could have environment
> variables used in the binman node in DT though (but for that to work, we
> need to pass environment variables to dtc via flags, or create Kconfig
> symbols generated from env variables). This means many environment
> variables to document and test. Not sure the project wants to go that
> direction though. I would also want this to be something followed by all
> architectures, not simply Rockchip, otherwise enabling SPL_FIT_SIGNATURE
> simply isn't doing what it says it's doing (I can boot unsigned images
> without any issue from current master, which kinda breaks what
> SPL_FIT_SIGNATURE seems to be hinting at "Enable signature verification
> of FIT firmware within SPL").
> 
> I'm planning on sending a mail in the next few weeks to ask what would
> be acceptable for 2) but I am not sure this will go anywhere to be honest.
> I think implementing a new feature for checking hashes without signing
> (1)) makes sense and is unrelated to/not a blocker for 2).

regards, Wolfgang