Edit: I have found a scheme that fits my limits (little memory, only AES is available): AES-CMAC described in RFC 4493 (just remember to use different key for encryption and MAC ;) .

I am working on a limited, embedded system that has to be field-upgradable. I want to protect the firmware against copying/reverse-engineering and modification (it will be transferred over plain HTTP).

First parts is easy - I use AES-128-CBC. Keys are burned in the bootloader. Microcontroller memory is locked.

The second part is my problem. My system is too limited to do a "heavyweight" (eg. RSA) signature verification.

I have an idea to distribute the firmware as AES(firmware+hash(firmware)). My device will first decrypt the whole image, calculate hash of the decrypted part and compare it with the original hash appended at the end).

I know that encryption alone is not authentication, but I can't imagine a successful attach against something "inside" AES that will give the right (encrypted) hash at the end.


  1. Is my scheme secure?
  2. Can the hash be "weak" and still make the whole scheme secure? (eg. MD5? I know it is "broken", but I think it is still hard to meddle with it inside an encrypted image).
  • 1
    "I want to protect the firmware against copying/reverse-engineering and modification" Why bother? Don't you already distribute the hardware? Sounds like a captive audience already. Don't use hiding your implementation as a substitute for an actually secure implementation. Commented Jun 2, 2016 at 16:44
  • i don't get it; what stops me from flashing with my own firmware that i've appended my own hash on?
    – dandavis
    Commented Jun 2, 2016 at 18:41
  • Nothing stops you from erasing the MCU completely and burning your own firmware without any hashes, but then you don't have the stock features, connectivity etc.
    – filo
    Commented Jun 3, 2016 at 5:51
  • In some countries there is even a legal right to reverse engineer for the purposes of compatibility. As you pointed out one can always crack the case and hook up JTAG or similar direct to the micro-controller and override any such security. One can also then do things like dump active memory including the processes currently loaded.
    – ewanm89
    Commented Jun 12, 2016 at 12:39
  • And the key for your AES is stored where? In a file on the device? I hope it's unique per device, or you've gained very little if anything from the encryption.
    – Ben
    Commented Jun 12, 2016 at 15:13

1 Answer 1


No, it is not secure.

First of all, you're suggesting a MAC-then-encrypt, which is known to be vulnerable to "chosen ciphertext" attacks (i.e. an attacker can take a valid message, modify it, and observe the result to gain information about the plaintext).

Secondly, you're suggesting the use of a hash rather than a MAC or even better a digital signature. A hash is not designed to verify the sender of information, only that the information has not been modified since being sent. A MAC can verify that the message came from the sender. A digital signature can verify that the sender is who it claims to be. You want a digital signature.

Finally, you're relying on symmetric encryption, a.k.a. "shared key" encryption. How is that key determined? You mentioned not wanting to do RSA (an example of asymmetric/public key encryption) which means you probably plan to keep the encryption key on your device, or hand it out to those who purchase/maintain the device. This means that the key is discoverable. Since this is a symmetric key, this furthermore means that once discovered the key can be used to create messages that appear valid using your scheme. There are certainly hardware modules that can help make it MUCH more difficult and expensive to extract the key (maybe even impossible) but the key may still be stolen from YOU, in which case you will need a way to change the key, and update all devices previously using that key, if you want to maintain security in such an event.

Why exactly do you think your device is not capable of using standard technology like public key cryptography? You really should just use proven methods instead of rolling your own.

  • 1
    I understand that my scheme is insecure by definition and my bootloader is an oracle, though I can't still think of a successful attack if each verification attempt takes 2-3 seconds. It would take ages to get a right hit.
    – filo
    Commented Jun 3, 2016 at 5:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .