I want to encrypt a system firmware, and future firmware updates will use the same encryption system. Because this firmware isn't fully from scratch but rather is based on an existing framework, it is highly likely that parts of the original firmware code are known, in other words, that long sequences of the message to encrypt would be known to any attacker (some of which are known to be full 1 and full 0s)

Considering this, can I merely use, say, AES, that preserves the sequence of the 128 bit blocks ? Or must I use a specific encryption tailored to such a use case ? I don't know if it's still robust against an attacker that has unencrypted/crypted block pairs, and I'm having trouble finding information on that use case.

I would guess that it is, but I'd rather verify. Thanks.

  • 2
    $\begingroup$ It really depends on your security goals and how you implement the encryption. Do you want to detect modified firmware and refuse to execute it, or prevent the firmware from being readable? What mode of operation are you using AES in? Where does the key come from? What is doing the decrypting? How are you verifying integrity? The simple question as to whether or not AES is vulnerable to a known plaintext attack (an attack that is made possible when you have plaintext/ciphertext pairs), the answer is no. $\endgroup$
    – forest
    Commented Mar 20, 2022 at 23:03
  • $\begingroup$ And, how do you keep the encryption key? You have a long way to go. Even Xilinx had mistakes $\endgroup$
    – kelalaka
    Commented Mar 21, 2022 at 0:00
  • $\begingroup$ @forest I'm in the annoying position of having to use a non-secure external flash for that device, yet still care about the firmware not being analyzed. So the key... has to be in the flash too (itself encrypted in some ways). So it's really about making it as hard as possible to analyze rather than impossible. I guess there are two separate problems: making it so firmware updates can't be analyzed on their own and making it as difficult as possible to analyze the firmware/clone the device once you reach the flash. Thanks for your answer, I didn't know it was called a plain text attack. $\endgroup$ Commented Mar 22, 2022 at 11:01
  • $\begingroup$ For firmware update integrity checks, my first thought is to embed some CRC inside the firmware updates pre-encryption. Are there concerns to be had about this ? $\endgroup$ Commented Mar 22, 2022 at 11:05
  • $\begingroup$ @JulienBERNARD What you're describing is simply impossible. If the key is stored along with the firmware, it can be analyzed, usually quite easily, no matter how much you attempt to obfuscate the key. As for integrity checks, a CRC is fine if you just want to detect accidental corruption. If you don't have hardware which supports verification (i.e. the system will refuse to execute the code if it doesn't have a valid signature, with the public key being burnt into the CPU itself), you can't verify it either. $\endgroup$
    – forest
    Commented Mar 22, 2022 at 19:53

1 Answer 1


Regardless of the symmetric encryption schema (3DES, AES,...), I suggest you to use an Encryption Mode that can hide data patterns. If you use CBC as encryption mode your cipher text will be randomized by using a random IV (Initialization Vector). Then you can pass the IV to the receiver in plaintext.

  • $\begingroup$ This really isn't a good answer because it doesn't address the hardware-specific concerns, and is a bit misleading anyway (using an IND-CPA construction isn't a solution to OP's problem). $\endgroup$
    – forest
    Commented Mar 21, 2022 at 22:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.