On 11/19/25 4:06 PM, Wolfgang Wallner wrote:
Hi Quentin,
From: Quentin Schulz <[email protected]>
Hi Wolfgang,
[...]
This description is quite convoluted. I would propose to describe it as a list,
I'm very good at writing convoluted paragraphs, so thanks for suggesting
something more readable :)
something like the following:
When `fit,engine` is set to `pkcs11`, the following cases are distinguished
regarding the value of `fit,engine-keydir`:
- If `fit,engine-keydir` is not present, value of `key-name-hint` is
prefixed
with `pkcs11:object=`, and then passed as-is to the OpenSSL engine API.
PKCS#11 id: `pkcs11:object=<key-name-hint>`
I have no experience with PKCS#11, but shouldn't that rather be a
"PKCS#11 URI" instead if " PKCS#11 id"?
Yes, of course, my formulation was sloppy here. Please use the term URI.
I'm now wondering if I'm not just going too far into explaining what
happens to fit,engine-keydir. It is after all passed verbatim as -k
argument to mkimage. The special cases for pkcs11 are all internal to
mkimage so I'm not sure if fit,engine-keydir is the best place to
document that? That could drastically simplify the documentation for the
fit entry in binman.
[...]
I was wondering if you had experience with using id= in the pkcs11 URI?
Thanks for pointing that out, I have now additionally tested with
'id=%01%02%03':
fit,sign;
fit,engine = "pkcs11";
fit,engine-keydir = "pkcs11:id=<id-of-my-key>";
key-name-hint = "MyTestKey";
Any chance I can get some softhsm2-util command to generate that object
with that id :) I wasn't able to last time I tried with id=999999 or
id=%999999 (since that's what I set the id of the key when importing) in
the test :/ Possibly PEBKAC though :)
There is one other aspect of the current solution that I'm not sure about:
* key-name-hint is an attribute per signature
* fit,engine-keydir is an attribute once per FIT description
I don't know wheter this is a use case for anyone, but I think if one would
like to have multiple signature nodes in a FIT description (e.g. multiple
configurations) and would like to have them signed with different keys, then
it would only be possible to do that via the key-name-hint, and thus only
via "object=xxx", but not via "id=xxx".
As far as I know (but happy to be proven otherwise), this is not
possible with mkimage right now. But note that I too was bothered while
looking at what was possible with mkimage. In the end, I don't need it
but I could see it being useful. On Rockchip, we typically only need to
sign one FIT: U-Boot proper, and everything is validated by SPL before
loading TF-A (bl31), TEE (bl32) and U-Boot proper before jumping into
BL31 so there really isn't a use case here. The kernel FIT which could
be verified by U-Boot proper before booting is anyway a different FIT so
can have a different engine or engine-keydir.
I think we would need to use a per-signature-node Device Tree property
to specify which engine (if any) to use and which arguments to pass with
the engine as well (still per-signature-node; not using the -k argument
anymore for that). This is something that needs to be supported in
mkimage though, with possible additions to the FIT spec (though it is
arguable). This would allow to use a different engine (or not even using
an engine) for encryption vs signing, which we currently cannot do.
Cheers,
Quentin
