I have a couple of products whose U-Boot FIT is signed via a proprietary OpenSSL engine which only expects the name of a "slot" to select the key to sign data with.
Currently mkimage fit support expects either a key-dir (-k) or a key-file (-G) as a toggle for signing, however this doesn't apply to our usecase because we use an OpenSSL engine (so no key-file to provide) which doesn't mimic a directory layout like key-dir implies. Moreover, binman really expects private keys (.key extension) to be available in this key-dir directory, which we of course cannot provide. 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. Note that the public key (.crt extension) still needs to be available if one wants to embed it for signature verification (which is probably what one wants to do :) ). One issue though is that since binman resolves key paths absolutely and that I don't believe an OpenSSL engine would happen to have the exact same key_id value than a local absolute path, fit,encrypt and fit,sign-engine cannot cohabit. An issue for the next person who wants an OpenSSL engine AND encrypt the same FIT image, I don't. Signed-off-by: Quentin Schulz <[email protected]> --- Quentin Schulz (3): fit: support signing with only an engine_id tools: binman: mkimage: add support for passing the engine tools: binman: fit: add support for OpenSSL engines tools/binman/btool/mkimage.py | 5 ++++- tools/binman/entries.rst | 22 +++++++++++++++++++--- tools/binman/etype/fit.py | 41 +++++++++++++++++++++++++++++++++++++---- tools/fit_image.c | 3 ++- tools/image-host.c | 4 ++-- 5 files changed, 64 insertions(+), 11 deletions(-) --- base-commit: 0dad93a72ec59b21cedeab365a28fcaa11a58384 change-id: 20251030-binman-engine-e349b02696d0 Best regards, -- Quentin Schulz <[email protected]>
