Replay attack in ECB mode

Question

How do replay attacks work in ECB mode? I found this in Wikipedia:

"ECB mode can also make protocols without integrity protection even more susceptible to replay attacks, since each block gets decrypted in exactly the same way. For example, the Phantasy Star Online: Blue Burst online video game uses Blowfish in ECB mode. Before the key exchange system was cracked leading to even easier methods, cheaters repeated encrypted "monster killed" message packets, each an encrypted Blowfish block, to illegitimately gain experience points quickly.^{[citation needed]}"

But I want to know how a replay attack really works in ECB mode, and how the other block cipher operation modes (like OFB) avoid it.

Answer 1

A replay attack simply means that an attacker who intercepts a valid message can re-send that message as many times as they want. If there's nothing in the message that could not be legitimately repeated, then the recipient will have no reason not to accept it as a valid message.

In general, all encryption modes are potentially vulnerable to replay attacks, depending on how they're used. The usual way to defend against such attacks is to include some kind of unique identifier and/or a timestamp in each message, so that the recipient can detect repeated messages. The messages should then also be protected against modification using a message authentication code (MAC) or an authenticated encryption mode, so that the attacker cannot simply change the ID or timestamp.

As the claim you quoted from Wikipedia lacks any references that would let me look at the details of that particular attack (or even verify that it really took place), all I can do to answer your question is offer some guesses as to how ECB mode might be more vulnerable to replay attacks, or how other block cipher modes could be made more resistant to them:

• First of all, one weakness particular to ECB mode is that you can take two messages, cut them apart at cipher block boundaries and join the halves together again to get a valid message combining parts of the two original messages. Depending on how the messages are constructed, this might allow an attacker to e.g. glue the contents of an old message to the ID and timestamp from a new message, which obviously defeats their purpose.

• Second, other block cipher modes, such as CBC, CFB, OFB and CTR, all require a unique initialization value (IV) or a "nonce" (essentially a unique identifier). While preventing replay attacks is not the primary reason why these IVs / nonces are required, since they're there and since they need to be unique anyway, they can also be used to detect duplicate messages.

  A potentially convenient feature is that, for many (but not all!) modes, even in the absence of a MAC, trying to modify the IV / nonce will turn the entire message into random garbage when it is decrypted. This is particularly true of the OFB and CTR modes, which are otherwise very vulnerable to ciphertext modification. (Of course, this is still not a good substitute for a MAC in other respects.)

• Finally, in some applications, it might not be necessary to transmit the IV / nonce at all, since it may be inferred from some external information (such as the number of messages or blocks seen before, if messages are transmitted in strict sequence on a supposedly reliable channel). In some cases, all messages might even be encrypted and transmitted as a single continuous stream, essentially just one long message.

  This obviously makes replay attacks on non-ECB modes difficult or impossible, since repeating an old message would just lead to the recipient trying to decrypt it with the wrong IV / nonce. However, ECB mode still remains vulnerable due to the property described above, namely that, as each block is encrypted independently and in the same way regardless of its position in the stream, an attacker can shuffle (and delete or duplicate) blocks in any manner without affecting their decryption.

Still, I should note that all of these attacks only apply in the absence of authentication. Even ECB mode, if combined with a MAC and with unique message IDs to detect duplicates, would be secure against replay attacks. Of course, the same goes for no encryption at all, but just unique message IDs and a MAC, but at least adding ECB mode encryption to the mix wouldn't make things any worse.

Answer 2

A replay attack works by blindly re-using an earlier message or ciphertext, or fragment thereof, typically one that was encrypted or signed. A simple example would be a bunker which receive the encrypted message "I'm General X, open the door". Now if this encrypted message was captured a week earlier and replayed by some opponent, well you get the idea.

This works against many schemes that (wrongly) use encryption when authentication is sought, or/and forget to associate the signature of something with a date or incremental counter. Such vulnerabilities are quite common. An example is a device that produce an RSA-signed log of incidents not including a date of generation of the signature: it might be possible to hide recent incidents by replaying an earlier signed log, instead of the current one. Moral: Neither encryption nor signature prevents replay.

For every block cipher operation mode, a replay attack works if the full message (including Initialisation Vector, if any) can be replayed.

When portions of an encrypted session using a unique session key are replayed, some modes are more vulnerable than others. ECB is particularly vulnerable because a repeated ciphertext fragment will always decrypt to the original plaintext. Apparently, in the attack given in the question, the encrypted message fragment triggering experience points was captured at the beginning of a session, and replayed, and this worked because of that property of ECB.

This is true to a lesser degree with CBC and CFB, where the first block of deciphered plaintext from a replayed ciphertext fragment will start with one block of garbage. The attacker, knowing that, will replay one more block of ciphertext before the portion corresponding to the plaintext intended for reuse, and success or failure of the attack will depend on how the receiving end handles that particular garbage.

Some other modes (like OFB and CTR) do not exhibit the property that replay of a ciphertext fragment yields the original ciphertext. They may still be vulnerable to replay attacks, e.g. if the IV can be repeated also.