Why do new versions of TLS use an explicit IV for CBC suites?

Question

SSL 3.0 and TLS 1.0 used an insecure scheme to generate implicit IVs when encrypting records in CBC mode: they used the last part of the previous record, a value that can be predicted by the attacker. This attack was demonstrated in the BEAST attack.

To avoid these issues, TLS 1.1 and later use explicit IVs, which are sent as part of the record. This avoids the attack, but also adds a 16 byte overhead to each record.

[CBCATT] describes a chosen plaintext attack on TLS that depends on knowing the IV for a record. Previous versions of TLS [TLS1.0] used the CBC residue of the previous record as the IV and therefore enabled this attack. This version uses an explicit IV in order to protect against this attack.

My first idea to fix this problem wouldn't have been explicit IVs, but rather implicit IVs that get derived securely from a shared secret. TLS already defines schemes to generate arbitrary-length pseudo-random data from the master secret (see 5. HMAC and the Pseudorandom Function).

Why did the designers of TLS 1.1 decide to go with explicit IVs, instead of simply replacing the weak implicit IV scheme with a strong one? Do explicit IVs offer any advantage over well-generated implicit IVs?

Answer 1

TLS 1.0 uses initialization vector (IV) to refer to two different processes. TLS 1.1 introduces a new type of IV that causes an entire block to be discarded and isn't directly comparable to the old series of IVs based on CBC residue. By simply changing an operation at the beginning of a record, the hope was apparently to make implementations easy to patch and prevent strain on some systems.

Overview

IVs attempt to prevent any (key, message) pair from producing the same ciphertext on retransmission. They generally need to be unique, preferably random, but shouldn't need to be secret. (A shared secret IV is really just more key.)

There are many ways to try to use an IV. Let's start with ECB (no IV), then examine TLS 1.0 first, then examine how TLS 1.1/1.2 uses its new IV.

I. ECB

If you just broke up a plaintext into chunks and encrypted each chunk, you're going to risk retransmission of the same block if the plaintext repeats. So the way CBC improves on ECB is to XOR the previous block's ciphertext into the current block's plaintext before encryption. That's sufficient to lower the likelihood of retransmission on every block but the first, which aren't XOR'd with anything yet. So you toss in an explicit IV to the first round to get CBC.

II. TLS 1.0 with CBC

In TLS 1.0, each party might like to be able to ensure this first IV is random. So each party proposes an IV. The two IVs are then mixed together through a pseudo-random function.

Initialization Vector (IV) When a block cipher is used in CBC mode, the initialization vector is exclusive-ORed with the first plaintext block prior to encryption. --RFC 2246

The sender then takes the IV and XORs it with the first block of plaintext. This will propagate through the block chain, it should be sufficient to ensure no repeated ciphertext blocks (at least not corresponding to repeated plaintext blocks).

While an IV proper shouldn't need to be secret, BEAST showed it isn't wise to let your attacker anticipate your next IV and also be able to shape your next chunk of plaintext.

III. BEAST

So in the BEAST attack, the attacker gets the IV for the next message, and then tricks the sender into sending some message of the form (not IV xor CPT).

Once the IV (aka 'mask') is XOR'd in before encryption, it cancels (NOT IV). CPT is now some chosen plaintext that will be encrypted (sans any mask). That's bad.

In version 1.1 of TLS, the big change was providing a fresh IV at the start of each record (every 16k bytes).

The TLS 1.0 "IV" for each block is just called a mask in 1.1. The TLS 1.0 IV for the first block can even be optionally kept. So the new IV doesn't actually replace (either of) the old IVs directly, they serve slightly different purposes and are implemented in slightly different ways.

Per RFC 4346, one of the following two algorithms SHOULD be used to generate the per-record IV:

1. Generate a cryptographically strong random string R for the IV. Mask the data with R. The first cipher block will be encrypted as:

   E(R XOR Data).

2. Generate a cryptographically strong random R and prepend to the plaintext prior to encryption. In this case the mask can be fixed, or the CBC residue from the previous record may be used as the mask. Using the residue preserves maximum code compatibility with TLS 1.0 and SSL 3. It also has the advantage that it does not require the ability to quickly reset the IV, which is known to be a problem on some systems.

The decryption operation for all alternatives is the same: The receiver decrypts the entire structure but discards the first cipher block, corresponding to the IV component.

The priorities were to preserve as much of the existing spec as possible, making implementation easier.

In TLS 1.1 and 1.2, they're encrypting the IV in the first block, which will be discarded by the sender. The TLS 1.0 IV is now called a "mask." By keeping the old IV as a mask, but introducing a new IV that makes a disposable block, they leave the algorithm changed as little as possible.

The parties no longer cooperate on this new, more frequently generated IV, meaning fewer code changes, and less strain on some systems.

Further reading

• Tor on the BEAST attack
• Slaying BEAST
• Beauty and the BEAST
• Security impact of Rizzo/Duong
• RFC 2246 (TLS 1.0), RFC 4346 (TLS 1.1)
• Block cipher modes of operation

Answer 2

One further reason, in addition to what Brownbat wrote above, is that by the time TLS 1.1 was designed, DTLS already existed. DTLS is a variant of TLS using UDP instead of TCP for the transport. In a UDP communication, you cannot rely on any record actually beeing delivered to the destination, thus any record has to decipherable by itself without requiring knowledge of the previous ones. So if you want to use CBC mode in DTLS, you must have an explicit IV.

When DTLS was first published, they had to define their own ciper suites, because the then current TLS 1.0 did not specify any usable ones. But since TLS 1.1 and DTLS 1.1, the can share (most) cipher suites.