Code signing of embedded firmware: Is a CRC enough when the firmware is encrypted?

user_5234015 0
Viewed 1147

I'm writing a firmware for an embedded system (microcontroller). The firmware can be updated by a bootloader (also written by me).

Now there is a requirement to take measures to prevent manipulation of the firmware, so the system must only execute a downloaded firmware if it has some sort of a valid signature.

The firmware file comes encrypted. It is decrypted by the bootloader (in the microcontroller) and then programmed into the flash memory.

Since the firmware comes encrypted, in my opinion a simple CRC check on the flash content should be sufficient to prove the firmware validity. But I'm no expert for cyber security, so... do I need more?

I presume that the encryption is strong enough and that the flash memory cannot be read out.

embedded firmware code-signing encryption
1 Answers

Since the firmware comes encrypted, in my opinion a simple CRC check on the flash content should be sufficient to prove the firmware validity. But I'm no expert for cyber security, so... do I need more?

If you chose a sound cryptography method, and guard your encryption keys properly, and you also guarantee that the firmware cannot be read-out after it has been transferred, and the bootloader rejects the firmware if it cannot successfully decrypt it, then you already guarantee firmware validity. Unless one of the above assumptions is violated, only the person who owns the keys to encrypt the firmware can ever produce a firmware that will be accepted by the bootloader.

As others have pointed out, CRC is not used to protect against intentional modification as you could just append trash-data to any file to produce the desired CRC. However I'd still recommend to have a CRC on at least two stages of your firmware-upgrade process:

  • CRC the encrypted data during transmission, preferably on each transmitted packet so you can re-transmit single packets without restarting the whole process (i.e. CRC over 256-byte chunks of the encrypted data)
  • Second over the flash area occupied by the firmware (minus bootloader) against a CRC of the decrypted firmware that is generated by the bootloader after successful decryption (or a static, fixed CRC, some µC-IDEs support this built-in), to make sure no flash-write-errors occured. It's common practice to safe this CRC-value to some flash area that is not part of the CRC, so that the bootloader can verify the application's integrity on every device reset.
user_62291730
Related