I need to provide a mechanism that it is possible to verify the integrity of a firmware image flashed on an embedded system. The procedure should be, that if someone has doubt on the firmware’s integrity, he can read the binary image via a debug port (JTAG) and then compare it against a public available hash code.
The request came from the fact, that the product is used in a custody transfer application and must be therefore protected against tampering (only tampering detecting is enough). There should be an easy way to verify the firmware, like by comparing the hash code, printed in the manual and compare it against the calculated one, loaded from the individual device…
My first approach would be to take for this the commonly used MD5 hash function, also to make it much handier for the customer (only 16 byte or respectively 32 hexadecimal characters). But then I was remembering on some news of the last years about collisions and that MD5 or even SHA-1 are (at least almost) broken. So, I wanted to choose the latest hash algorithm with the best reputation for best future viability and therefore I tended to SHA3-224 (which implicates 28 bytes or 56 hexadecimal characters).
Some colleagues in my company said to me, MD5 should be more than sufficient to cover our needs. But I don`t think this is correct, since we have a 128 KiB Firmware image, with only about 100 KiB are used the other 28 KiB can contain "random data". Therefore, I would say, this is more than enough to create at least one single collision with the identical programmatically functionality.
Is SHA3-224 an overkill for this purpose or is it reasonable in terms of future viability?