[PATCH v4 2/3] tools: binman: add 'fit, encrypt' property to pass keys directory to mkimage

[Simon Glass]

On Mon, 25 Nov 2024 at 10:47, Paul HENRYS
<paul.henrys_ext at softathome.com> wrote:
>
> mkimage can be used for both signing the FIT or encrypt its content and the
> option '-k' can be used to pass a directory where both signing and encryption
> keys can be retrieved. Adding 'fit,encrypt' property to the 'fit' node, leads to
> try to find keys directory among binman include directories.
> _get_priv_keys_dir() is renamed as _get_keys_dir() and adapted to support both
> signing and encryption nodes in the FIT.
>
> Signed-off-by: Paul HENRYS <paul.henrys_ext at softathome.com>
> ---
> Changes for v4:
> - Add 'fit,encrypt' property to enable encryption in FIT
> - Remove the previous implementation to have a common property to pass the keys
>   directory to mkimage for both signing and encrypting the FIT
> - Update the entries.rst file
>
> Reacting to Alexander's message pointing at Simon's previous message in August, speaking about entryargs. At my level, it doesn't really matter whether a specific directory is specified or if it comes from one of the binman input directories and Alexander's implementation, that retrieves the signing keys from one of the binman input directory is handy for that.
> On my side, it would sufficient to retrieve the ciphering keys from one of binman input directories, like for the signing keys but with the current implementation, I would need to add the property 'fit,sign' which is a bit counterintuitive. 'fit-keys-directory' might also not be right, it could be something like 'fit,keys'. What I meant is that afaiu, 'fit,sign' is not a property that will enable the signature but provides the keys directories to mkimage. Signing the FIT data is based on the presence of 'signature' nodes in the ITS. The same is true for the encryption with mkimage but with 'cipher' nodes.
>
> Regarding the other entryargs for signing with binman, this is another way of signing any piece of data (file, binary blob...) which globally signs the data and prepends a header. When using the FIT embedded signature, that does not sign all FIT metadata, I guess it's better to keep it in mkimage, which is the tool generating the FIT.
>
> I am pushing here a v4, where I add a property 'fit,encrypt' that does the same than 'fit,sign', passing the option '-k' to mkimage. That might help our discussions because I am a bit confuse at the moment on the approach to be taken. Thx for your help.
>
>
>  tools/binman/btool/mkimage.py |  8 ++++----
>  tools/binman/entries.rst      |  7 +++++++
>  tools/binman/etype/fit.py     | 25 ++++++++++++++++++-------
>  3 files changed, 29 insertions(+), 11 deletions(-)

Reviewed-by: Simon Glass <sjg at chromium.org>