How to resist MITM and replay attacks when sending encrypted data?

Question

Assuming I've securely exchanged keys with another computer (using Diffie-Hellman perhaps), here's my tentative solution:

packet number + encrypted data + message authentication code (MAC)

The packet number is an incrementally-increased number starting at 0. After that is the encrypted data itself, followed by a MAC of them both. If someone attempts a MITM attack, the MAC should fail to compute. If they attempt a replay attack, the recipient will notice it has already received that packet number.

Is there any flaw in my reasoning here?

Answer 1

You're not describing a man in the middle attack, but a replay attack.

With a MITM attack the key exchange is intercepted and you say that you already have exchanged keys securely - so it is not the problem.

Replay attacks are easy enough to mitigate against, you include a unique message ID and then check it for uniqueness on the receiving side. Generally each message has an expiry date and time so you don't need to keep an ever growing list of message IDs to validate.

Answer 2

Your approach for protecting against replay attacks seems reasonable to me. You are essentially describing a method called timestamping. Your packet number is a "virtual time" that is used by the recipient to verify that the message was not sent before.

Answer 3

Assuming I've securely exchanged keys with another computer (using Diffie-Hellman perhaps)

This is where you face the biggest danger - if the man-in-the-middle manages to control the key exchange (for example, by establishing one key with the client and itself, and establishing another key with server and itself), then the MITM can decrypt (and re-encrypt) everything. Once you've established the secure key exchange, you should be invulnerable to the MITM attack. But the hard part is ensuring that the key exchange is truly secure.

Consult Practical Cryptography (or at Amazon) by Ferguson and Schneier for information about this.

Answer 4

Once the keys have been exchanged then the data cannot be intercepted or spoofed by a third party. (Except when your packet # counter loops. Hypothetically packets from the old window could be replayed as being from the new window.) The solution to this problem is timestamping (as others have mentioned.) Again, though, this can be sabotaged if the attacker is able to compromise in some way the system time. (If they are a man in the middle, they could hypothetically imitate an NTP server and in that way modify a client's system time.)

What an eavesdropper COULD do however is to insert himself between the two parties and disrupt the channel. This would likely cause a new key exchange to occur which could be observed. In order to make key exchange truly secure, you must use 3rd party validation or a pre shared key which only the two communicators know.