IETF-SSH archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: an attack against SSH2 protocol
Wei Dai <weidai%eskimo.com@localhost>:
>> [Posted to sci.crypt and the IETF SSH working group mailing list.]
>>
>> Phil Rogaway observed that CBC mode is not secure against chosen-
>> plaintext attack if the IV is known or can be predicted by the attacker
>> before he choses his plaintext [1]. Similarly, CBC mode is not secure if
>> the attacker can observe the last ciphertext block before choosing the
>> next block of plaintext, because the last block of ciphertext
>> essentially serves as the IV for the rest of the message.
>>
>> The attack itself is very simple. Remember that in CBC mode, each
>> plaintext block is XOR'ed with the last ciphertext block and then
>> encrypted to produce the next ciphertext block. Suppose the attacker
>> suspects that plaintext block P_i might be x, and wants to test whether
>> that's the case, he would choose the next plaintext block P_j to be x
>> XOR C_(i-1) XOR C_(j-1). If his guess is correct, then C_j = Encrypt(P_j
>> XOR C_(j-1)) = Encrypt(P_i XOR C_(i-1)) = C_i, and so he can confirm his
>> guess by looking at whether C_j = C_i.
>>
>> The SSH2 protocol, when used with a block cipher in CBC mode, does allow
>> the attacker to observe the last ciphertext block of a packet, which is
>> then used as the (implicit) IV of the next packet. [...]
>> [1] http://www.cs.ucdavis.edu/~rogaway/papers/draft-rogaway-ipsec-comments-00.txt
> I have received some comments through private email. Apparently the exact
> same weakness was known for IPSec and may also exist in TLS (I haven't
> read enough of its RFC to be sure) [...]
In TLS, the "IV for subsequent records is the last ciphertext block
from the previous record" [RFC 2246], and plaintext blocks usually
consist of raw application data followed by a MAC, so the attack
applies. (Having the MAC at the *beginning* of each packet would
avoid the attack.)
In his CRYPTO 2001 paper "The Order of Encryption and Authentication
for Protecting Communications (or: How Secure Is SSL?)", Hugo Krawczyk
supposedly shows that SSL/TLS with CBC encryption is secure -- but
he assumes a random IV for each encrypted block, which is not how the
actual SSL protocol works.
Another problem with CBC as used in SSL/TLS was pointed out by Serge
Vaudenay, see <URL:http://www.openssl.org/~bodo/tls-cbc.txt>. That
one can easily be avoided by implementations. To avoid the new attack
without changing the protocol definition, implementations would have
to send an empty fragment before application data to ensure IV
randomization.
--
Bodo Möller <moeller%cdc.informatik.tu-darmstadt.de@localhost>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
Home |
Main Index |
Thread Index |
Old Index