# IV vector is not random. Is it critical?

Reading the spec of one of the IoT protocols, I found that IV for it one isn't actually random, it consist of $n$ bytes that represents manufacter-specific string; the same for all devices plus 6 bytes of invocation counter. This counter increments every time when the AES cryptography function is called.

Is a non-random IV critical for security? As far as I remeber, such schemes are theoretically vulnurable to chosen plaintext attack?

UPDATE: AES GCM is used

• Which mode of operation are they using? – CodesInChaos Apr 8 '18 at 7:54
• I'm voting to put this question on hold until it is clarified. Without additional information (including the AES mode of operation being used, whether all devices use the same key and "manufacturer-specific string" or not, and what exactly "AES cryptography function" means in this context) there is no way to tell if this scheme is vulnerable or not. – Ilmari Karonen Apr 8 '18 at 11:06
• Ps. If you're not sure how to describe the scheme yourself in sufficient detail to allow a definitive answer, a link to the spec would allow others to (hopefully) fill in any missing details. – Ilmari Karonen Apr 8 '18 at 11:10
• Important update: in my case AES GCM is used – sluge Apr 9 '18 at 10:19

I'm reading the question as: the IV consists of $n$ fixed bytes common to multiple devices, and 6 bytes forming a 48-bit incremental counter. This looks like counter mode (CTR), which is common for AES. The 6 counter bytes are good for 281 million million 16-byte blocks (as much of 4 PB).

In that case, a deterministic and predictable IV is fine, provided that each device has a unique key, and the incremental counter is reliable. The only minor downside is that a multi-target attack is slightly easier: an attacker knowing plaintext/ciphertext pairs gathered from $d$ devices using the same counter can test a key guess for all devices with a single encryption and a search among $d$ values, which is appreciably less expensive than the $d$ encryptions necessary for distinct IV (as they likely would be for random IV). This is not much an issue in practice, even for AES-128 (much less larger keys).

The devil lies in the implementation details. In particular, it is hard to make an invocation counter that never jumps backward despite interruption of power supply at adversarially chosen time. Yet, it is also common that a Random Number Generator fails under adversarially influenced conditions, in a way that make it repeat. It is also not unseen that either method of generating an IV fails as a result of a mere design oversight.

For other modes such as Cipher Block Chaining (CBC), predictable IV can be a serious issue, see Meir Maor's answer.

Assuming you are using CBC mode(since you are calling it IV and not nonce): You are correct, predictable IVs make it vulnerable to chosen plain text attack. In particular, say you captured a message $C$ with $IV_1$ and you can perform chosen plain text with predictable $IV_2$ in the simplest form you can verify a guess as to possible plain text which produced $C$. Just ask the opponent to encrypt the XOR of your guess $P_{guess}$ with $IV_1$ and $IV_2$ And see if it matches $C$.

How important chosen plain text attacks depends on the rest of the system.

With CTR mode predictable IV are not an issue so long as they never repeat(in same or other message).

AES GCM is used

Yes, we appear to have a serious problem; just not the one you were thinking of.

In the case of GCM, nonrandom IVs are absolutely not a problem; in fact, it is common practice with AES GCM to use incrementing IVs.

However, in your scenario, there's another possible issue. GCM doesn't mind predictable IVs, but it needs IVs to be unique; if the attacker can see two different messages encrypted with the same IV, security breaks down pretty badly.

Now, it sounds like for this protocol, every identical device with have the same manufacturer-specific string. If so, then we have a serious problem here; if two different devices use the same invocation number, then we have repeated IVs, and Bad Things happen.

And, even if the manufacturer-specific string wasn't identical between different physical devices (e.g. for a given manufacturer, there was a unique device id embedded), you can still run into problems if the device reboots (and then starts back at 0 with the invocation number).

So, yes, if the situation is as you described, we have a serious problem here (just not the one you thought).

BTW: could you mention which IOT spec this was?

It depends on what mode of encryption you are using. If you are using CBC mode then this is vulnerable. If you are using CTR mode, then all you need is that the IV be unique in every AES invocation.