I read that to mitigrate BEAST attack openSSL tried to inject empty TLS record before each real TLS record. and by doing that there is no opportunity to execute an attack but i dont understand way? what the diffrence between normal TLS? the attacker can still xor the block he want to guess with the last block to disable the iv affect.
1 Answer
$\begingroup$
$\endgroup$
9
Well, in TLS 1.0 and a CBC mode ciphersuite, the IV for the next record would always be the last ciphertext block for the previous record. That is, the first encrypted block of each record would be:
$$C_0 = Encrypt_k( P_0 \oplus C_{prev} )$$
What the BEAST attack did was exploit this to generate an encryption Oracle. If they had a guess that a plaintext block (xored with its previous ciphertext block) generated a specific ciphertext block, what they would do is take the current last ciphertext block $C_{prev}$, and have the device generate a plaintext block $P_0$ such that, the two xor'ed together would be the plaintext block (xor'ed with its previous ciphertext block) under test - if the resulting first ciphertext block of the record was what they expect, their guess was correct (and the rest of the exploit was using this Oracle to extract useful information).
Now, if you read through the above text, we see that this attack needs the previous ciphertext block immediately before we encrypt the plaintext, and the attacker needs to see that before he picks his $P_0$ plaintext block. In TLS 1.1, the IV is generated unpredictably by the sender, thus preventing this attack.
If we live with TLS 1.0, we can't change the protocol, but we can emulate it. What this defense does is generate an empty block; the resulting ciphertext is an encryption of data that the attacker cannot control (hence he cannot use that to perform the BEAST attack). And, that ciphertext has a last block that the attacker cannot predict, hence preventing him knowledge of the $C_{prev}$ that will be used when he generates $P_0$, hence effectively emulating the 'use an unpredictable IV' defense in TLS 1.1.
Historic note: TLS 1.1 predated the BEAST attack, but was specifically designed to foil this 'encryption oracle' facet of BEAST. The real innovation of BEAST was the part that used this oracle to perform real world attack.
-
$\begingroup$ I dont understand why "the resulting ciphertext is an encryption of data that the attacker cannot control" when you generate an enpry block? i can't take the empty block ciphertext and xor it with my guess like the beast attack? i guess i miss something but i don't find it:( $\endgroup$– eitanAug 29 at 13:23
-
$\begingroup$ @eitan: Actually, it's safe. When you encrypt a record (empty or not), what you actually encrypt is "record || HMAC || padding". The empty record and padding is predictable; the HMAC is not. Hence, the first data presented to the block cipher for an empty record is completely unpredictable, and hence is useless to BEAST $\endgroup$– ponchoAug 29 at 14:16
-
$\begingroup$ Thenk you very much! why with empty record HMAC is not predictable? how BEAST predict HMAC? $\endgroup$– eitanAug 29 at 14:23
-
$\begingroup$ @eitan: the HMAC is unpredictable because the HMAC key is unknown to the attacker, and it is on data (such as the record count) that changes for every record (and hence the HMAC will change from record to record). $\endgroup$– ponchoAug 29 at 14:26
-
$\begingroup$ @eitan: with the normal BEAST attack (against unprotected TLS 1.0) the attacker has no need to predict the HMAC - all he needs is the last ciphertext block (which he sees) and can control the next plaintext block. He doesn't really care what that last ciphertext block is an encryption of. $\endgroup$– ponchoAug 29 at 14:27