# Encrypting firmware with AES and no IV [closed]

I have an embedded device with a AES CBC engine on it that is used to ensure the integrity of the firmware. I know that CBC mode requires unique IVs to be any good, but I'm unsure if it makes a large difference in this scenario. The AES key is stored in hardware on chip, and before firmware is loaded, it's decrypted with the key using decrypt hardware also on the chip. If I understand this correctly, that would mean that the same key encrypting the same plaintext will always result in the same ciphertext, meaning it's deterministic. Assuming the attacker can obtain the encrypted firmware (but not the key, so he can't encrypt anything with the key), does the fact that no IV is used really make a difference?

-

## closed as unclear what you're asking by figlesquidge, e-sushi, DrLecter, rath, AFSFeb 17 at 11:13

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question.If this question can be reworded to fit the rules in the help center, please edit the question.

The title says "Encrypting firmware". The question is about AES CBC "used to ensure the integrity of the firmware". These are radically different goals, please clarify. An IV or substitute is useful for the first, not the second. –  fgrieu Feb 14 at 17:13

Let me see if I have this right (and please correct me if I misunderstand; my conclusions depend on the details of this); you distribute images for your firmware device; these images are encrypted with a secret AES key (using AES in CBC mode); the device decrypts the image, and then runs that decrypted image. The sole check to make sure that the image wasn't tampered with is the hope that a modified image would not decrypt to anything intelligible.

If the above is all true (and personally, I hope that I'm wrong and you're doing more than this), then you have bigger problems than having a fixed IV.

The problem is that you're assuming that an attacker cannot modify the image to make changes that he picked out; the problem with CBC mode is that, to a surprising extent, he can. Here's one way he can do this: suppose you have a constant initializer in your image, as follows:

static int important_variable = 3;

Suppose further that the attacker decides that he'd get an advantage if that important_variable was initialized to 5. What the attacker could do is find where the constant 3 appears in the image, and (here's the tricky bit) exclusive-or the previous block in the ciphertext by 6. To see what this does, let us review how CBC mode decryption works:

$$P_i = C_{i-1} \oplus D_k( C_i )$$

(where $C_{i-1}$, $C_i$ are the ciphertext blocks, and $P_i$ is the decrypted blocks.

Now, the attacker has no idea what the key $k$ is, however he doesn't care, he knows that $3 = C_{i-1} \oplus D_k(C_i)$. By adjusting $C_{i-1}$ into $C'_{i-1} = C_{i-1} \oplus 6$, and making no changes to $C_i$, the modified ciphertext will decrypt there into $P'_i = C'_{i-1} \oplus D_k(C_i) = C_{i-1} \oplus 6 \oplus D_k(C_i) = 6 \oplus 3 = 5$, hence making the change he desired.

The sole disadvange (as far the attacker is concerned)? The previous block $P_{i-1}$ will decrypt to something unpredictable (because he has no idea what $D_k(C'_{i-1})$ evaluates to), however that block might not be important.

The bottom line: if you care about integrity (as opposed to secrecy), you need to use a cryptographical primitive that gives integrity guarantees (such as a Message Authentication Code or a signature).

-
This. Encryption is entirely orthogonal to authentication. If you are using AES-CBC to ensure your firmware hasn't been tampered with, you are using a very inappropriate tool for the job. –  Stephen Touset Feb 14 at 21:35