zephyr: west sign: imgtool: zephyr.signed.hex and zephyr.signed.bin do not have the same contents

Describe the bug

When creating signed images, the generated files zephyr.signed.hex and zephyr.signed.bin do not have the same logical contents.

west sign works by running two independent calls to imgtool, once to create the .hex, and again to create the .bin. Unfortunately even running imgtool with the exact same arguments twice does not result in the same binary.

Both files are valid, they are just different due to the different generated values of the IMAGE_TLV_RSA2048_PSS.

To Reproduce

yat033@GRAY-PH zephyr % imgtool sign --version 0.0.0+0 --align 4 --header-size 512 --slot-size 0x60000 --key ~/code/zephyr/bootloader/mcuboot/root-rsa-2048.pem app.hex signed.hex && md5 signed.hex
MD5 (signed.hex) = 6b2ce8658c234cc0008009490d0c012b
yat033@GRAY-PH zephyr % imgtool sign --version 0.0.0+0 --align 4 --header-size 512 --slot-size 0x60000 --key ~/code/zephyr/bootloader/mcuboot/root-rsa-2048.pem app.hex signed.hex && md5 signed.hex
MD5 (signed.hex) = 4ad4834a9de8123134a7cc8a5c4e3e39

Expected behavior

I would expect zephyr.signed.bin and zephyr.signed.hex to have the same contents, differing only in the file format.

Impact

The actual binary on the device depends on which file format was flashed.

Additional context

Given this behaviour is in imgtool, the only solution I see is running imgtool once and then converting the .hex to a .bin

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Comments: 18 (2 by maintainers)

Most upvoted comments

I’ll leave a few comments before closing the issue. Feel free to open if needed. To summarize, several signature and encryption algorithms used by imgtool/mcuboot are non-deterministic. There are situations where west is used to build both a .bin and a .hex file, and because each is a separate invocation of imgtool, the output ends up different.

My question is, what are the situations where there is a need to generate both a .hex and a .bin file? Shouldn’t one be the preferred output type for a given build configuration. If this is really important, it might be worthwhile changing west to generate just a hex file, and build a .bin from that, but I’m not sure how well that would fit with the given architecture.

As an aside, if you really want deterministic signatures, Ed25519 should be deterministic. RSA-PSS uses a random value to increase the security properties of the signature. A random value is fundamental to how ECDSA works. Another option would be to add support for rfc6979 to imgtool. The resulting signatures are compatible with existing ECDSA verification, but the signatures are deterministic. Note that there are security implications of deterministic ECDSA, even though there are also benefits.

@stephanosio, @carlescufi, no this is not a mcuboot issue. It is due to how a hex and bin are generated by west. By calling imgtool twice the signature being non-deterministic is different for the hex and the bin. If west would create the bin from the hex this would not be the case. I would not call this a bug, it is a property of the system. Whether or nor a build system should generate “identical” files in hex or bin format I have no opinion on.