More info in my AES128-CBC question

Leichter, Jerry leichter_jerrold at emc.com
Fri Apr 27 17:13:44 EDT 2007


| > What problem does this (chaining IV from message to message) introduce
| > in our case?
| 
| See RFC4251:
| 
| "
|    Additionally, another CBC mode attack may be mitigated through the
|    insertion of packets containing SSH_MSG_IGNORE.  Without this
|    technique, a specific attack may be successful.  For this attack
|    (commonly known as the Rogaway attack [ROGAWAY], [DAI], [BELLARE]) to
|    work, the attacker would need to know the Initialization Vector (IV)
|    of the next block that is going to be encrypted.  In CBC mode that is
|    the output of the encryption of the previous block.  If the attacker
|    does not have any way to see the packet yet (i.e., it is in the
|    internal buffers of the SSH implementation or even in the kernel),
|    then this attack will not work.  If the last packet has been sent out
|    to the network (i.e., the attacker has access to it), then he can use
|    the attack.
| "
This still doesn't describe how the attack works.  It's very special-
ized: A chosen-plaintext attack that can confirm the decryption of a a
previously intercepted block (but cannot directly reveal it).

In the following, all encryptions are with respect to a fixed (but
unknown to the attacker) key.  Earlier, the attacker intercepted I and
E(I xor X), where X is some unknown data and I is the IV that was used
in encrypting it.  (That is, I is simply the previous encrypted block.)
The attacker has a guess Y as to what X is and wishes to confirm it.  He
also knows J, the next IV to be used; and can choose the next block to
be encrypted.  He chooses Y xor J xor I.  The CBC encryptor sends:

	E(J xor Y xor J xor I) == E(I xor Y)

The attacker examines this block as it's transmitted, and compares it
to E(I xor X).  If they are the same, then X == Y.

Notice that this requires true *chosen* plaintext - known plaintext does
you no good at all.  And you have to be able to choose any plaintext -
what you're stuffing in there will look essentially random, because J
and for that matter I are essentially random.  Since all you'll see is
the encrypted result, you have to be able to choose *all* the bits.

Since SSH sends the password at a guessable point in the stream, the
block containing is locatable and it has high value.  If an attacker
grabs it, he could try password guessing attacks "through" the
subsequent encryption.

Frankly, for SSH this isn't a very plausible attack, since it's not
clear how you could force chosen plaintext into an SSH session between
messages.  A later paper suggested that SSL is more vulnerable:
A browser plugin can insert data into an SSL protected session, so
might be able to cause information to leak.  Note that for this to be
an interesting attack, we have to posit that the plugin can be caused
to run within a browser during a secure session containing valuable
data, but also that the browser is sufficiently secure that the plugin
can't get at the data directly.  (The Java security model does try to
enforce this kind of separation.)

It's really tough to formalize exactly what is going on here, since
there's this whole funny notion of "knowing the next IV to be used in
time to choose the next plaintext".  I guess we assume that the
implementation doesn't allow you to change the contents of a message
once you've passed it down to the crypto layer; otherwise, you could
in principle apply this attack between every pair of CBC-encrypted
blocks.  Unrealistic?  There were attacks against OS 360 in which
you passed in a channel program, then modified it while it was being
executed, sometimes from the CPU, sometimes by causing one element
in the channel program to do I/O that overwrote another element before
the channel got there.  So I would certainly not dismiss this as
completely impossible.

What the RFC seems to be suggesting is that the first block of every
message be SSH_MSG_IGNORE.  Since the first block in any message is now
fixed, there's no way for the attacker to choose it.  Since the attacker
doesn't know the key, even knowing the IV used with this fixed message
doesn't tell him what IV will be used for the block after, the earliest
one he could specify.  The same IV will likely never by seen again
during the lifetime of the key, so knowing the output of encrypting the
fixed message with that IV is also useless.  Adding some random data to
the ignored block can be done but has no effect on the security.  Note
that the wire overhead is the same here as with sending a new IV: One
block.  You can avoid that by making the IV's computable by a party that
knows the key:  E.g., use E(n) as the IV for the n'th block.  Or even
simpler, take the saved IV and encrypt it an extra time before using it.
The advantage of the RFC's approach is that it works with older peers:
They messages they send remain vulnerable, but the messages a new
implementation sends them are not, but are completely understandable.
If you need to upgrade an already fielded protocol, this is the best you
can hope for - and it's actually very good.

Frankly, while I find this attack interesting as a clever bit of math
and certainly worth knowing about when designing protocols, it's not
something I'd worry about except in very unusual circumstances.

							-- Jerry

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com



More information about the cryptography mailing list