[PATCH v4 1/3] aes: Allow to store randomly generated IV in the FIT

When the initialisation vector is randomly generated, its value shall be stored in the FIT together with the encrypted data. The changes allow to store the IV in the FIT also in the case where the key is not stored in the DTB but retrieved somewhere else at runtime.
Signed-off-by: Paul HENRYS paul.henrys_ext@softathome.com --- Changes for v4: - Add a function comment for add_cipher_data()
include/image.h | 15 +++++++++++++++ lib/aes/aes-encrypt.c | 7 +++++++ tools/image-host.c | 2 +- 3 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/include/image.h b/include/image.h index c52fced9b4..b9aef33826 100644 --- a/include/image.h +++ b/include/image.h @@ -1788,6 +1788,21 @@ struct cipher_algo { const unsigned char *data, int data_len, unsigned char **cipher, int *cipher_len);
+ /** + * add_cipher_data() - Add cipher data to the FIT and device tree + * + * This is used to add the ciphered data to the FIT and other cipher + * related information (key and initialization vector) to a device tree. + * + * @info: Pointer to image cipher information. + * @keydest: Pointer to a device tree where the key and IV can be + * stored. keydest can be NULL when the key is retrieved at + * runtime by another mean. + * @fit: Pointer to the FIT image. + * @node_noffset: Offset where the cipher information are stored in the + * FIT. + * return: 0 on success, a negative error code otherwise. + */ int (*add_cipher_data)(struct image_cipher_info *info, void *keydest, void *fit, int node_noffset);
diff --git a/lib/aes/aes-encrypt.c b/lib/aes/aes-encrypt.c index e74e35eaa2..90e1407b4f 100644 --- a/lib/aes/aes-encrypt.c +++ b/lib/aes/aes-encrypt.c @@ -84,6 +84,13 @@ int image_aes_add_cipher_data(struct image_cipher_info *info, void *keydest, char name[128]; int ret = 0;
+ if (!keydest && !info->ivname) { + /* At least, store the IV in the FIT image */ + ret = fdt_setprop(fit, node_noffset, "iv", + info->iv, info->cipher->iv_len); + goto done; + } + /* Either create or overwrite the named cipher node */ parent = fdt_subnode_offset(keydest, 0, FIT_CIPHER_NODENAME); if (parent == -FDT_ERR_NOTFOUND) { diff --git a/tools/image-host.c b/tools/image-host.c index 5e01b853c5..16389bd488 100644 --- a/tools/image-host.c +++ b/tools/image-host.c @@ -535,7 +535,7 @@ fit_image_process_cipher(const char *keydir, void *keydest, void *fit, * size values * And, if needed, write the iv in the FIT file */ - if (keydest) { + if (keydest || (!keydest && !info.ivname)) { ret = info.cipher->add_cipher_data(&info, keydest, fit, node_noffset); if (ret) { fprintf(stderr,

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@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(-)
diff --git a/tools/binman/btool/mkimage.py b/tools/binman/btool/mkimage.py index 78d3301bc1..3f84220fb1 100644 --- a/tools/binman/btool/mkimage.py +++ b/tools/binman/btool/mkimage.py @@ -22,7 +22,7 @@ class Bintoolmkimage(bintool.Bintool):
# pylint: disable=R0913 def run(self, reset_timestamp=False, output_fname=None, external=False, - pad=None, align=None, priv_keys_dir=None): + pad=None, align=None, keys_dir=None): """Run mkimage
Args: @@ -34,7 +34,7 @@ class Bintoolmkimage(bintool.Bintool): other things to be easily added later, if required, such as signatures align: Bytes to use for alignment of the FIT and its external data - priv_keys_dir: Path to directory containing private keys + keys_dir: Path to directory containing private and encryption keys version: True to get the mkimage version """ args = [] @@ -46,8 +46,8 @@ class Bintoolmkimage(bintool.Bintool): args += ['-B', f'{align:x}'] if reset_timestamp: args.append('-t') - if priv_keys_dir: - args += ['-k', f'{priv_keys_dir}'] + if keys_dir: + args += ['-k', f'{keys_dir}'] if output_fname: args += ['-F', output_fname] return self.run_cmd(*args) diff --git a/tools/binman/entries.rst b/tools/binman/entries.rst index e918162fb4..53024acad4 100644 --- a/tools/binman/entries.rst +++ b/tools/binman/entries.rst @@ -871,6 +871,13 @@ The top-level 'fit' node supports the following special properties: -k flag. All the keys required for signing FIT must be available at time of signing and must be located in single include directory.
+ fit,encrypt + Enable data encryption in FIT images via mkimage. If the property + is found, the keys path is detected among binman include + directories and passed to mkimage via -k flag. All the keys + required for encrypting the FIT must be available at the time of + encrypting and must be located in a single include directory. + Substitutions ~~~~~~~~~~~~~
diff --git a/tools/binman/etype/fit.py b/tools/binman/etype/fit.py index b5afbda41b..70be9bea47 100644 --- a/tools/binman/etype/fit.py +++ b/tools/binman/etype/fit.py @@ -110,6 +110,13 @@ class Entry_fit(Entry_section): available at time of signing and must be located in single include directory.
+ fit,encrypt + Enable data encryption in FIT images via mkimage. If the property + is found, the keys path is detected among binman include + directories and passed to mkimage via -k flag. All the keys + required for encrypting the FIT must be available at the time of + encrypting and must be located in a single include directory. + Substitutions ~~~~~~~~~~~~~
@@ -518,14 +525,14 @@ class Entry_fit(Entry_section): # are removed from self._entries later. self._priv_entries = dict(self._entries)
- def _get_priv_keys_dir(self, data): - """Detect private keys path among binman include directories + def _get_keys_dir(self, data): + """Detect private and encryption keys path among binman include directories
Args: data: FIT image in binary format
Returns: - str: Single path containing all private keys found or None + str: Single path containing all keys found or None
Raises: ValueError: Filename 'rsa2048.key' not found in input path @@ -533,11 +540,14 @@ class Entry_fit(Entry_section): """ def _find_keys_dir(node): for subnode in node.subnodes: - if subnode.name.startswith('signature'): + if (subnode.name.startswith('signature') or + subnode.name.startswith('cipher')): if subnode.props.get('key-name-hint') is None: continue hint = subnode.props['key-name-hint'].value - name = tools.get_input_filename(f"{hint}.key") + name = tools.get_input_filename( + f"{hint}.key" if subnode.name.startswith('signature') + else f"{hint}.bin") path = os.path.dirname(name) if path not in paths: paths.append(path) @@ -587,8 +597,9 @@ class Entry_fit(Entry_section): align = self._fit_props.get('fit,align') if align is not None: args.update({'align': fdt_util.fdt32_to_cpu(align.value)}) - if self._fit_props.get('fit,sign') is not None: - args.update({'priv_keys_dir': self._get_priv_keys_dir(data)}) + if (self._fit_props.get('fit,sign') is not None or + self._fit_props.get('fit,encrypt') is not None): + args.update({'keys_dir': self._get_keys_dir(data)}) if self.mkimage.run(reset_timestamp=True, output_fname=output_fname, **args) is None: if not self.GetAllowMissing():

On Mon, 25 Nov 2024 at 10:47, Paul HENRYS paul.henrys_ext@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@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@chromium.org

Test the property 'fit,encrypt' to encrypt FIT data.
Signed-off-by: Paul HENRYS paul.henrys_ext@softathome.com --- Changes for v4: - Update the tests to use 'fit,encrypt'
tools/binman/ftest.py | 45 +++++++++++++++ tools/binman/test/343_fit_encrypt_data.dts | 53 ++++++++++++++++++ .../test/344_fit_encrypt_data_no_key.dts | 53 ++++++++++++++++++ tools/binman/test/aes256.bin | Bin 0 -> 32 bytes 4 files changed, 151 insertions(+) create mode 100644 tools/binman/test/343_fit_encrypt_data.dts create mode 100644 tools/binman/test/344_fit_encrypt_data_no_key.dts create mode 100644 tools/binman/test/aes256.bin
diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py index 156567ace7..92c6e59285 100644 --- a/tools/binman/ftest.py +++ b/tools/binman/ftest.py @@ -7900,5 +7900,50 @@ fdt fdtmap Extract the devicetree blob from the fdtmap extra_indirs=[test_subdir])[0]
+ def testSimpleFitEncryptedData(self): + """Test an image with a FIT containing data to be encrypted""" + data = tools.read_file(self.TestFile("aes256.bin")) + self._MakeInputFile("keys/aes256.bin", data) + + keys_subdir = os.path.join(self._indir, "keys") + data = self._DoReadFileDtb( + '343_fit_encrypt_data.dts', + extra_indirs=[keys_subdir])[0] + + fit = fdt.Fdt.FromData(data) + fit.Scan() + + # Extract the encrypted data and the Initialization Vector from the FIT + node = fit.GetNode('/images/u-boot') + subnode = fit.GetNode('/images/u-boot/cipher') + data_size_unciphered = int.from_bytes(fit.GetProps(node)['data-size-unciphered'].bytes, + byteorder='big') + self.assertEqual(data_size_unciphered, len(U_BOOT_NODTB_DATA)) + + # Retrieve the key name from the FIT removing any null byte + key_name = fit.GetProps(subnode)['key-name-hint'].bytes.replace(b'\x00', b'') + with open(self.TestFile(key_name.decode('ascii') + '.bin'), 'rb') as file: + key = file.read() + iv = fit.GetProps(subnode)['iv'].bytes.hex() + enc_data = fit.GetProps(node)['data'].bytes + outdir = tools.get_output_dir() + enc_data_file = os.path.join(outdir, 'encrypted_data.bin') + tools.write_file(enc_data_file, enc_data) + data_file = os.path.join(outdir, 'data.bin') + + # Decrypt the encrypted data from the FIT and compare the data + tools.run('openssl', 'enc', '-aes-256-cbc', '-nosalt', '-d', '-in', + enc_data_file, '-out', data_file, '-K', key.hex(), '-iv', iv) + with open(data_file, 'r') as file: + dec_data = file.read() + self.assertEqual(U_BOOT_NODTB_DATA, dec_data.encode('ascii')) + + def testSimpleFitEncryptedDataMissingKey(self): + """Test an image with a FIT containing data to be encrypted but with a missing key""" + with self.assertRaises(ValueError) as e: + self._DoReadFile('344_fit_encrypt_data_no_key.dts') + + self.assertIn("Filename 'aes256.bin' not found in input path", str(e.exception)) + if __name__ == "__main__": unittest.main() diff --git a/tools/binman/test/343_fit_encrypt_data.dts b/tools/binman/test/343_fit_encrypt_data.dts new file mode 100644 index 0000000000..d70de3426c --- /dev/null +++ b/tools/binman/test/343_fit_encrypt_data.dts @@ -0,0 +1,53 @@ +// SPDX-License-Identifier: GPL-2.0+ + +/dts-v1/; + +/ { + #address-cells = <1>; + #size-cells = <1>; + + binman { + fit { + fit,encrypt; + description = "Test a FIT with encrypted data"; + #address-cells = <1>; + + images { + u-boot { + description = "U-Boot"; + type = "firmware"; + arch = "arm64"; + os = "U-Boot"; + compression = "none"; + load = <00000000>; + entry = <00000000>; + cipher { + algo = "aes256"; + key-name-hint = "aes256"; + }; + u-boot-nodtb { + }; + }; + fdt-1 { + description = "Flattened Device Tree blob"; + type = "flat_dt"; + arch = "arm64"; + compression = "none"; + cipher { + algo = "aes256"; + key-name-hint = "aes256"; + }; + }; + }; + + configurations { + default = "conf-1"; + conf-1 { + description = "Boot U-Boot with FDT blob"; + firmware = "u-boot"; + fdt = "fdt-1"; + }; + }; + }; + }; +}; diff --git a/tools/binman/test/344_fit_encrypt_data_no_key.dts b/tools/binman/test/344_fit_encrypt_data_no_key.dts new file mode 100644 index 0000000000..d70de3426c --- /dev/null +++ b/tools/binman/test/344_fit_encrypt_data_no_key.dts @@ -0,0 +1,53 @@ +// SPDX-License-Identifier: GPL-2.0+ + +/dts-v1/; + +/ { + #address-cells = <1>; + #size-cells = <1>; + + binman { + fit { + fit,encrypt; + description = "Test a FIT with encrypted data"; + #address-cells = <1>; + + images { + u-boot { + description = "U-Boot"; + type = "firmware"; + arch = "arm64"; + os = "U-Boot"; + compression = "none"; + load = <00000000>; + entry = <00000000>; + cipher { + algo = "aes256"; + key-name-hint = "aes256"; + }; + u-boot-nodtb { + }; + }; + fdt-1 { + description = "Flattened Device Tree blob"; + type = "flat_dt"; + arch = "arm64"; + compression = "none"; + cipher { + algo = "aes256"; + key-name-hint = "aes256"; + }; + }; + }; + + configurations { + default = "conf-1"; + conf-1 { + description = "Boot U-Boot with FDT blob"; + firmware = "u-boot"; + fdt = "fdt-1"; + }; + }; + }; + }; +}; diff --git a/tools/binman/test/aes256.bin b/tools/binman/test/aes256.bin new file mode 100644 index 0000000000000000000000000000000000000000..09b8bf6254ada5c084039f32916bc7d30233bb2c GIT binary patch literal 32 ncmXpsGBz<aGq<obNK8sjNli=7$jr*l$<50zC@d;2DJ=s4pC}7U
literal 0 HcmV?d00001

On Mon, 25 Nov 2024 at 10:47, Paul HENRYS paul.henrys_ext@softathome.com wrote:
Test the property 'fit,encrypt' to encrypt FIT data.
Signed-off-by: Paul HENRYS paul.henrys_ext@softathome.com
Changes for v4:
- Update the tests to use 'fit,encrypt'
tools/binman/ftest.py | 45 +++++++++++++++ tools/binman/test/343_fit_encrypt_data.dts | 53 ++++++++++++++++++ .../test/344_fit_encrypt_data_no_key.dts | 53 ++++++++++++++++++ tools/binman/test/aes256.bin | Bin 0 -> 32 bytes 4 files changed, 151 insertions(+) create mode 100644 tools/binman/test/343_fit_encrypt_data.dts create mode 100644 tools/binman/test/344_fit_encrypt_data_no_key.dts create mode 100644 tools/binman/test/aes256.bin
Reviewed-by: Simon Glass sjg@chromium.org
BTW you could use tools.read_file() as well

On Mon, Nov 25, 2024 at 06:47:17PM +0100, Paul HENRYS wrote:
Test the property 'fit,encrypt' to encrypt FIT data.
Signed-off-by: Paul HENRYS paul.henrys_ext@softathome.com Reviewed-by: Simon Glass sjg@chromium.org
Changes for v4:
- Update the tests to use 'fit,encrypt'
tools/binman/ftest.py | 45 +++++++++++++++ tools/binman/test/343_fit_encrypt_data.dts | 53 ++++++++++++++++++ .../test/344_fit_encrypt_data_no_key.dts | 53 ++++++++++++++++++ tools/binman/test/aes256.bin | Bin 0 -> 32 bytes 4 files changed, 151 insertions(+) create mode 100644 tools/binman/test/343_fit_encrypt_data.dts create mode 100644 tools/binman/test/344_fit_encrypt_data_no_key.dts create mode 100644 tools/binman/test/aes256.bin
This fails in CI: https://source.denx.de/u-boot/u-boot/-/jobs/980030 or https://dev.azure.com/u-boot/u-boot/_build/results?buildId=10169&view=lo... Please see https://docs.u-boot.org/en/latest/develop/ci_testing.html for how to trigger Azure yourself to resolve these, thanks!

Hello Tom,
The issue comes from the key that is reported missing (or zero size):
ValueError: Error 1 running 'mkimage -t -k /tmp/binmant.nvd038o5/keys -F /tmp/binman.is3n51x5/fit.fit': File /tmp/binmant.nvd038o5/keys/aes256.bin don't have the expected size (size=0, expected=32)
The issue is that the "binary" file fails to be provided in patchwork. I send the following mail about this on 05/08/24:
Hi Simon,
Sorry for the late reply as I missed your message blocked in quarantine. It looks like when I push a patch with binary data, patchworks does not seem to get it right. Nonetheless, using git send-email, a copy is also sent to me and I do get the patch right. I put you in CC this time so you should also have received a copy of the patches. Could you take a look you get the patch "[v2,3/3] tools: binman: Add tests for FIT with data encrypted by mkimage" with the binary data?
The end of the patch with the binary data should be as such:
diff --git a/tools/binman/test/aes256.bin b/tools/binman/test/aes256.bin new file mode 100644 index 0000000000000000000000000000000000000000..09b8bf6254ada5c084039f32916bc7d30233bb2c GIT binary patch literal 32 ncmXpsGBz<aGq<obNK8sjNli=7$jr*l$<50zC@d;2DJ=s4pC}7U
literal 0 HcmV?d00001
FYI, I also added the requested changes.
Best regards, Paul
Best regards, Paul
________________________________________ From: Tom Rini Sent: Thursday, December 19, 2024 01:51 To: Paul HENRYS (EXT) Cc: u-boot@lists.denx.de; paul.henrysd+nodisclaimer@gmail.com; sjg@chromium.org; al.kochet@gmail.com Subject: Re: [PATCH v4 3/3] tools: binman: Add tests for FIT with data encrypted by mkimage
On Mon, Nov 25, 2024 at 06:47:17PM +0100, Paul HENRYS wrote:
Test the property 'fit,encrypt' to encrypt FIT data.
Signed-off-by: Paul HENRYS paul.henrys_ext@softathome.com
Reviewed-by: Simon Glass sjg@chromium.org
Changes for v4:
- Update the tests to use 'fit,encrypt'
tools/binman/ftest.py | 45 +++++++++++++++
tools/binman/test/343_fit_encrypt_data.dts | 53 ++++++++++++++++++
.../test/344_fit_encrypt_data_no_key.dts | 53 ++++++++++++++++++
tools/binman/test/aes256.bin | Bin 0 -> 32 bytes
4 files changed, 151 insertions(+)
create mode 100644 tools/binman/test/343_fit_encrypt_data.dts
create mode 100644 tools/binman/test/344_fit_encrypt_data_no_key.dts
create mode 100644 tools/binman/test/aes256.bin
This fails in CI:
https://source.denx.de/u-boot/u-boot/-/jobs/980030
or
https://dev.azure.com/u-boot/u-boot/_build/results?buildId=10169&view=lo...
Please see https://docs.u-boot.org/en/latest/develop/ci_testing.html%C2%A0for
how to trigger Azure yourself to resolve these, thanks!
--
Tom

On Thu, Dec 19, 2024 at 09:51:16AM +0000, Paul HENRYS (EXT) wrote:
Hello Tom,
The issue comes from the key that is reported missing (or zero size):
ValueError: Error 1 running 'mkimage -t -k /tmp/binmant.nvd038o5/keys -F /tmp/binman.is3n51x5/fit.fit': File /tmp/binmant.nvd038o5/keys/aes256.bin don't have the expected size (size=0, expected=32)
The issue is that the "binary" file fails to be provided in patchwork. I send the following mail about this on 05/08/24:
I will try again. But please note that "lore.kernel.org" also is missing things, seemingly, because I started this out with b4 grabbing the patches there, and then tried patchwork which did give me tools/binman/test/aes256.bin but not the key file (and was a bit tricky because of .gitignore). Thanks for explaining.
Hi Simon,
Sorry for the late reply as I missed your message blocked in quarantine. It looks like when I push a patch with binary data, patchworks does not seem to get it right. Nonetheless, using git send-email, a copy is also sent to me and I do get the patch right. I put you in CC this time so you should also have received a copy of the patches. Could you take a look you get the patch "[v2,3/3] tools: binman: Add tests for FIT with data encrypted by mkimage" with the binary data?
The end of the patch with the binary data should be as such:
diff --git a/tools/binman/test/aes256.bin b/tools/binman/test/aes256.bin new file mode 100644 index 0000000000000000000000000000000000000000..09b8bf6254ada5c084039f32916bc7d30233bb2c GIT binary patch literal 32 ncmXpsGBz<aGq<obNK8sjNli=7$jr*l$<50zC@d;2DJ=s4pC}7U
literal 0 HcmV?d00001
FYI, I also added the requested changes.
Best regards, Paul
Best regards, Paul
From: Tom Rini Sent: Thursday, December 19, 2024 01:51 To: Paul HENRYS (EXT) Cc: u-boot@lists.denx.de; paul.henrysd+nodisclaimer@gmail.com; sjg@chromium.org; al.kochet@gmail.com Subject: Re: [PATCH v4 3/3] tools: binman: Add tests for FIT with data encrypted by mkimage
On Mon, Nov 25, 2024 at 06:47:17PM +0100, Paul HENRYS wrote:
Test the property 'fit,encrypt' to encrypt FIT data.
Signed-off-by: Paul HENRYS paul.henrys_ext@softathome.com
Reviewed-by: Simon Glass sjg@chromium.org
Changes for v4:
- Update the tests to use 'fit,encrypt'
tools/binman/ftest.py | 45 +++++++++++++++
tools/binman/test/343_fit_encrypt_data.dts | 53 ++++++++++++++++++
.../test/344_fit_encrypt_data_no_key.dts | 53 ++++++++++++++++++
tools/binman/test/aes256.bin | Bin 0 -> 32 bytes
4 files changed, 151 insertions(+)
create mode 100644 tools/binman/test/343_fit_encrypt_data.dts
create mode 100644 tools/binman/test/344_fit_encrypt_data_no_key.dts
create mode 100644 tools/binman/test/aes256.bin
This fails in CI:
https://source.denx.de/u-boot/u-boot/-/jobs/980030
or
https://dev.azure.com/u-boot/u-boot/_build/results?buildId=10169&view=lo...
Please see https://docs.u-boot.org/en/latest/develop/ci_testing.html%C2%A0for
how to trigger Azure yourself to resolve these, thanks!
--
Tom

On Thu, Dec 19, 2024 at 09:51:16AM +0000, Paul HENRYS (EXT) wrote:
Hello Tom,
The issue comes from the key that is reported missing (or zero size):
ValueError: Error 1 running 'mkimage -t -k /tmp/binmant.nvd038o5/keys -F /tmp/binman.is3n51x5/fit.fit': File /tmp/binmant.nvd038o5/keys/aes256.bin don't have the expected size (size=0, expected=32)
The issue is that the "binary" file fails to be provided in patchwork. I send the following mail about this on 05/08/24:
Indeed, I thought I had fixed that up, but didn't do it correctly, thanks!
Hi Simon,
Sorry for the late reply as I missed your message blocked in quarantine. It looks like when I push a patch with binary data, patchworks does not seem to get it right. Nonetheless, using git send-email, a copy is also sent to me and I do get the patch right. I put you in CC this time so you should also have received a copy of the patches. Could you take a look you get the patch "[v2,3/3] tools: binman: Add tests for FIT with data encrypted by mkimage" with the binary data?
The end of the patch with the binary data should be as such:
diff --git a/tools/binman/test/aes256.bin b/tools/binman/test/aes256.bin new file mode 100644 index 0000000000000000000000000000000000000000..09b8bf6254ada5c084039f32916bc7d30233bb2c GIT binary patch literal 32 ncmXpsGBz<aGq<obNK8sjNli=7$jr*l$<50zC@d;2DJ=s4pC}7U
literal 0 HcmV?d00001
FYI, I also added the requested changes.
Best regards, Paul
Best regards, Paul
From: Tom Rini Sent: Thursday, December 19, 2024 01:51 To: Paul HENRYS (EXT) Cc: u-boot@lists.denx.de; paul.henrysd+nodisclaimer@gmail.com; sjg@chromium.org; al.kochet@gmail.com Subject: Re: [PATCH v4 3/3] tools: binman: Add tests for FIT with data encrypted by mkimage
On Mon, Nov 25, 2024 at 06:47:17PM +0100, Paul HENRYS wrote:
Test the property 'fit,encrypt' to encrypt FIT data.
Signed-off-by: Paul HENRYS paul.henrys_ext@softathome.com
Reviewed-by: Simon Glass sjg@chromium.org
Changes for v4:
- Update the tests to use 'fit,encrypt'
tools/binman/ftest.py | 45 +++++++++++++++
tools/binman/test/343_fit_encrypt_data.dts | 53 ++++++++++++++++++
.../test/344_fit_encrypt_data_no_key.dts | 53 ++++++++++++++++++
tools/binman/test/aes256.bin | Bin 0 -> 32 bytes
4 files changed, 151 insertions(+)
create mode 100644 tools/binman/test/343_fit_encrypt_data.dts
create mode 100644 tools/binman/test/344_fit_encrypt_data_no_key.dts
create mode 100644 tools/binman/test/aes256.bin
This fails in CI:
https://source.denx.de/u-boot/u-boot/-/jobs/980030
or
https://dev.azure.com/u-boot/u-boot/_build/results?buildId=10169&view=lo...
Please see https://docs.u-boot.org/en/latest/develop/ci_testing.html%C2%A0for
how to trigger Azure yourself to resolve these, thanks!
--
Tom

On Mon, 25 Nov 2024 at 10:47, Paul HENRYS paul.henrys_ext@softathome.com wrote:
When the initialisation vector is randomly generated, its value shall be stored in the FIT together with the encrypted data. The changes allow to store the IV in the FIT also in the case where the key is not stored in the DTB but retrieved somewhere else at runtime.
Signed-off-by: Paul HENRYS paul.henrys_ext@softathome.com
Changes for v4:
- Add a function comment for add_cipher_data()
include/image.h | 15 +++++++++++++++ lib/aes/aes-encrypt.c | 7 +++++++ tools/image-host.c | 2 +- 3 files changed, 23 insertions(+), 1 deletion(-)
Reviewed-by: Simon Glass sjg@chromium.org

On Mon, 25 Nov 2024 18:47:15 +0100, Paul HENRYS wrote:
When the initialisation vector is randomly generated, its value shall be stored in the FIT together with the encrypted data. The changes allow to store the IV in the FIT also in the case where the key is not stored in the DTB but retrieved somewhere else at runtime.
Applied to u-boot/next, thanks!
participants (4)
-
Paul HENRYS
-
Paul HENRYS (EXT)
-
Simon Glass
-
Tom Rini