Integrity check of a binary firmware file with hash function

Question

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?

Answer 1

This appears to be an example of an xy problem.

The goal is to ensure that the firmware is not modified. The standard solution to this problem is to use a digital signature. To quote content from the previous link:

A (digital) signature is created with a private key, and verified with the corresponding public key of an asymmetric key-pair. Only the holder of the private key can create this signature, and normally anyone knowing the public key can verify it.

With a digital signature, your company (and only your company) can create a signature for the firmware that anyone can verify. If the firmware is modified, then the signature you created will not pass the verification routine.

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…

This is not really an "easy" way to verify - most users will not be able/willing to read the binary via JTAG.

Even if they are willing to do so, there is still a possible attack vector: Users might only check if $n$ characters of the two hashes are a match, and then naturally assume that all of the rest will be too. An adversary would in this case only have to produce a partial collision, which could be a much easier task.

It is best to refrain from relying on manual verification.

You can store in the device your public verification key and store the signature next to the firmware. When your device is started, it should be designed to automatically verify the signature before continuing to use the firmware. If the signature does not verify, then operation should be aborted.

RSA is popular* for signatures because verification can be very fast (relatively speaking). Creating a signature is not terribly fast, but since it only needs to be done rarely, it does not really matter how long it takes.

You can use a program such as SSL to create a digital signature, which can be done on any computer.

The verification routine will have to run on your device, so your developer(s) will have to incorporate that functionality in somehow. It may be possible to re-use part of an existing library rather than writing the verification routine from scratch. I would recommend using/porting the code from bearssl if at all possible.

Ideally, your company would contract this portion of development out to an experienced cryptography engineer. If it's possible, it's worth it to have to make sure that it is done correctly.

*In approximately a decade you may have/want to update the signature scheme you use due to quantum computing and NIST's post-quantum cryptography competition.

Answer 2

Definitely MD5 and SHA-1 should not be used.

The security strength recommended by NIST is at least 112-bit (see NIST SP 800-57). 112-bits is estimated to be secure until 2030. If you are looking for something lasts beyond 2030, you should consider 128-bit security or higher.

The security strength of a hash function is its hash size divided by 2 (because of birthday attack). Thus SHA3-224 provides 112-bit security, and SHA3-256 provides 128-bit security and so on.