AES CBC over TCP - when is new IV needed

Question

I am working on a project where two devices will be communicating with AES with CBC over TCP. We already have a secure mechanism for sharing the encryption/decryption key. I am not sure if we need to have a random IV or not, or how often to begin a new "message".

Here is how I think it will work:

Both sides send hello messages to each other to signal the start of the channel. Each side's message will start with a random IV. After that point each side will occasionally send a small message to the other which will be chained off of the previous messages. This will likely continue for a few minutes but could go on indefinitely.

Does that work? Does each message need a new IV? Each potential session will have a new encryption key, so are random IVs required?

Answer 1

There are three points to be made, I think:

1. Do not build your own protocols ! Or, at least, do not believe the result to be secure. Otherwise, stick to well-studied protocols, like SSL. If your goal is to learn, then go on.

2. In CBC, the IV (or previous block) must be unpredictible for the attacker. Consider SSL, where data is split into records (that's your "messages"). Each record is sent atomically. In SSL 3.0 and TLS 1.0, the last block of a record is also the IV for the next record; this means that an attacker observing the stream and being able to input some data of his own in the cleartext stream can observe a record, learn the IV for the next record, and then compute the cleartext data he wants to insert in the next record. That's the basis for the BEAST attack which was published last year for SSL (actually an older attack, but NEAST is about make it plausible in HTTPS context). So, to sum up: you must choose a new, random IV (with a cryptographically strong generator) whenever you are about to encrypt plaintext data which was obtained after having sent over the wire the previous encrypted block.

3. You need an integrity check; otherwise, an attacker could modify your messages, and beside the obvious problem of using corrupted data, this can endanger their confidentiality as well. Do yourself a favour and use an encryption mode which includes integrity, e.g. EAX. This makes the problem quite simpler:

   • The IV need no longer to be unpredictible, only non-repeating. A simple counter will do.
   • You need a new IV whenever you start a new message.
   • By construction, the receiver cannot process a message without having received it completely (because its contents cannot be trusted until the integrity has been checked). So your incentive for breaking data into messages is to limit RAM usage on the receiver; and you need to close the current message whenever you want to "flush" the data.

   The old-style way to add integrity is to use an independent MAC construction (such as HMAC) but combining symmetric encryption and a MAC can be tricky (see this question for details) so you'd better use EAX (or something equivalent like GCM).

Answer 2

Initialization vectors are only designed to provide a way of making each conversation unique, so that identical blocks of plaintext do not produce identical blocks of ciphertext, for the same key. Each new message does not need a new IV. You can simply use one IV per conversation.

One implementation issue to take into account is IV transmission. You'll need to agree upon a key initially, via whatever mechanism (DH is a good one), then provide a MAC on the IV to ensure that it is not tampered with, similar to how WPA2 (TKIP) performs the IV exchange.

I'm not aware of any attacks on systems such as yours where the IV is static and the key is different, but it makes me nervous. I'm not a cryptographer, though, so I can't give you any solid reasoning. I'm sure someone like Thomas Pornin would be happy to weigh in with an answer!