On Fri, 8 Feb 2002, Bodo Moeller wrote:
> 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.
Bodo's observation is correct.
My paper essentially assumes a random IV per message.
Without it (i.e. with the specification of using the last ctext block
from msg i as the IV of msg i+1) CBC mode is NOT even secure against
chosen plaintext attacks!
In this case even MACing the ciphertext does not help.
Thus, future revisions of TLS should also take this into account.
That is, either transmit a fresh (unpredictable) IV with each msg,
or implcitly compute this IV in an *unpredictable* way, for example by
applying a prf to the msg counter.
>
> 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.
This is a nice attack (do you know of a publicly available paper on this
that I can cite?), and indeed easier to fix than the others.
The analytical model in my paper (for the case of
authenticate-then-encrypt with CBC) makes the assumption that decryption
and mac verification are performed as an atomic operation with a single
"ciphertext invalidity" bit learned by the attacker regardless of the
reason for failure. This points out to yet another advantage of the
encrypt-then-mac approach, namely, there you first check the MAC and if
not valid you do NOT decrypt (in particular, you provide no info to the
other side or the atacker about the result of decryption). No need for
assumptions on the atomicity of combined operations.
I wonder if any one cares in ssl/tls community about all these
basic crypto-security design issues; any plans for future protocol
versions?
Hugo
PS: since Wei Dai mentioned the case of SSH in this context, the bad news
there is that even using CBC and fixing the problem of predictable IV
leaves the protocol open to the attacks on authenticate-and-mac
showed in my paper (e.g. the attack in appendix C)
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
