Man-in-the-middle attack

From Citizendium, the Citizens' Compendium
Jump to: navigation, search
This article is developing and not approved.
Main Article
Related Articles  [?]
Bibliography  [?]
External Links  [?]
Citable Version  [?]
This editable Main Article is under development and not meant to be cited; by editing it you can help to improve it towards a future approved, citable version. These unapproved articles are subject to a disclaimer.

In a man-in-the-middle attack on a communications system, the attacker is the man-in-the-middle.[1][2] He deceives the victims so they think they are communicating with each other but in fact both are talking to him. It is an active attack; the attacker needs not only the ability to intercept messages, but to insert his own and to prevent delivery of genuine ones.

Of course it need not be literally a man in the middle. An alternate term, not much used, is a "middleperson attack". The attacker might be a woman or a team, and the actual implementation of the attack is often along the lines of device-in-the-middle. The attacker either subverts an existing infrastructure device — a router, a virtual private network (VPN) gateway, an application layer gateway machine, a firewall, an Asynchronous Transfer Mode (ATM) switch, ... — or inserts an extra device in the communication path to do the dirty work.

Conventionally, the communicating parties are A and B or Alice and Bob. Let us call the attacker Edward, for Eavesdropper or EvilDoer. Edward's goal is to trick both Alice and Bob into talking to him instead of each other. Alice's message go to Edward who reads them, perhaps alters them, and passes them on to Bob. Bob's replies also come to Edward, who passes them on to Alice.

If this attack succeeds, it is utterly devastating, completely destroying the security of the communication system. Consider General Alice ordering Major Bob to "Take Hill 37". Having Edward the Enemy able to read that order is highly undesirable. A successful man-in-the-middle attack allows that, but it also lets him do far worse. The man-in-the-middle can alter messages, so he can both send Bob some completely different orders and give General Alice bogus reports that appear to come from Bob. In essence, the Enemy completely controls the communication.

The principle is not used solely for conventional cryptographic countermeasures; a basic technique of deceptive electronic warfare is to transmit a "more plausible" signal (e.g., a radar return or a navigational code) than the real source.


In a recent example in the US [3], attackers cyber-hijacked trucks. They got information on loads to be moved by hacking a government website, posed as a trucking company and submitted bids to the client then, posing as the client, arranged for a real trucking company to make the deliveries. The client paid them; they did not pay the truckers. They had made off with nearly $500,000 before they were caught.

Ross Anderson and others at Cambridge recently published a man-in-the-middle attack [4] on EMV or chip-and-pin, an authentication system very widely used in banking. They built a device that goes between the customer's card and the verifying device. With that device in place, PIN verification always succeeds no matter what number you input.

Early in 2011, the Tunisian government seems to have conducted a massive man-in-the-middle attack [1], stealing the passwords for a huge number of Facebook accounts.

A hardware key logger is a small device that goes between a computer and its keyboard. Several are commercially available and there are instructions on the web for homebrew versions. [5]

Principles of Countermeasures

Note that just encrypting the messages may not help. It does Alice absolutely no good to ensure that her messages are securely delivered and that only the recipient can read them if they are going to the wrong recipient. Along with any encryption, she needs some form of authentication to ensure she is in fact talking to Bob.

Encryption applied at lower levels of the communication system can prevent many man-in-the-middle attacks. For example, suppose we encrypt the communication link from Alice's headquarters to Bob's. To conduct a man-in-the-middle attack, Edward must then either find a way to attack from inside one of the headquarters or find a way to break that encryption in real time (a break that takes hours or months may be of great value to him, but it does not allow man-in-the middle). With good encryption methods and headquarters security procedures, these should be effectively impossible. Even with flaws in those areas, Edward's problem is much more difficult than without the encryption.

However, the most general defense against man-in-the-middle attacks is cryptographic authentication. If Alice and Bob check that they are in fact talking to each other, then no man-in-the-middle attack can succeed unless the attacker can defeat whatever authentication mechanism is in play. For example, if Alice and Bob do a Diffie-Hellman key negotiation, they much each authenticate themselves to the other.[6]

Trusted intermediaries and certificate authorities

If Alice and Bob both trust Charlie, and Charlie can independently verify identity, using a trusted channel to Alice (to verify Bob) and to Bob (to verify Alice), an alternative to Diffie-Hellman is use of a trusted intermediary. [7]


  1. Ellison, Carl M. (1996), Establishing Identity Without Certification Authorities, Sixth USENIX Security Symposium, pp. 67-76
  2. Scheier, Bruce (Second Edition, 1996), Applied Cryptography: Protocols, Algorithms, and Source Code in C, John Wiley & Sons, pp. 48-49
  3. Kevin Poulsen (October 2008), "Fed Blotter: Alleged Hackers Charged With Highway Robbery, Literally", Wired
  4. Steven J. Murdoch, Saar Drimer, Ross Anderson and Mike Bond (2010), EMV PIN verification “wedge” vulnerability
  5. Bruce Schneier (February 2006), Do-it-Yourself Keyboard Logger
  6. Rescorla, E. (June 1999), Diffie-Hellman Key Agreement Method, RFC2631
  7. Arora, Anish, Lecture 3: Cryptography Support Services: Key Management, CIS694K: Introduction to Network Security, Ohio State University, pp. 13-35