In cryptography, the man-in-the-middle attack (often abbreviated MITM), or bucket-brigade attack, or sometimes Janus attack, is a form of active eavesdropping in which the attacker makes independent connections with the victims and relays messages between them, making them believe that they are talking directly to each other over a private connection, when in fact the entire conversation is controlled by the attacker. The attacker must be able to intercept all messages going between the two victims and inject new ones, which is straightforward in many circumstances (for example, an attacker within reception range of an unencrypted Wi-Fi wireless access point, can insert himself as a man-in-the-middle).

A man-in-the-middle attack can succeed only when the attacker can impersonate each endpoint to the satisfaction of the other. Most cryptographic protocols include some form of endpoint authentication specifically to prevent MITM attacks. For example, SSL authenticates the server using a mutually trusted certification authority.

Contents 1 Need for additional transfer over a secure channel 2 Example of an attack 3 Defenses against the attack 4 Quantum cryptography 5 Beyond cryptography 6 Implementations 7 See also 8 References 9 External links

[edit] Need for additional transfer over a secure channel

With the exception of Interlock Protocol, all cryptographic systems that are secure against MITM attacks require an additional exchange or transmission of information over some kind of secure channel. Many key agreement methods have been developed, with different security requirements for the secure channel.

[edit] Example of an attack

Suppose Alice wishes to communicate with Bob. Meanwhile, Mallory wishes to eavesdrop on the conversation, or possibly deliver a false message to Bob.

First, Alice asks Bob for his public key. If Bob sends his public key to Alice, but Mallory is able to intercept it, a man-in-the-middle attack can begin. Mallory sends a forged message to Alice that claims to be from Bob, but instead includes Mallory's public key.

Alice, believing this public key to be Bob's, encrypts her message with Mallory's key and sends the enciphered message back to Bob. Mallory again intercepts, deciphers the message using her private key, possibly alters it if she wants, and re-enciphers it using the public key Bob originally sent to Alice. When Bob receives the newly enciphered message, he believes it came from Alice.

1. Alice sends a message to Bob, which is intercepted by Mallory:

 Alice "Hi Bob, it's Alice. Give me your key"-->  Mallory      Bob 

2. Mallory relays this message to Bob; Bob cannot tell it is not really from Alice:

 Alice      Mallory "Hi Bob, it's Alice. Give me your key"-->   Bob 

3. Bob responds with his encryption key:

 Alice      Mallory   <--[Bob's_key] Bob 

4. Mallory replaces Bob's key with her own, and relays this to Alice, claiming that it is Bob's key:

 Alice   <--[Mallory's_key] Mallory      Bob 

5. Alice encrypts a message with what she believes to be Bob's key, thinking that only Bob can read it:

 Alice "Meet me at the bus stop!"[encrypted with Mallory's key]-->   Mallory      Bob 

6. However, because it was actually encrypted with Mallory's key, Mallory can decrypt it, read it, modify it (if desired), re-encrypt with Bob's key, and forward it to Bob:

 Alice      Mallory "Do not meet me!"[encrypted with Bob's key]-->   Bob 

7. Bob thinks that this message is a secure communication from Alice.

This example shows the need for Alice and Bob to have some way to ensure that they are truly using each other's public keys, rather than the public key of an attacker. Otherwise, such attacks are generally possible, in principle, against any message sent using public-key technology. Fortunately, there are a variety of techniques that help defend against MITM attacks.

[edit] Defenses against the attack

Various defenses against MITM attacks use authentication techniques that are based on:

• Public key infrastructures
• Stronger mutual authentication
• Secret keys (high information entropy secrets)
• Passwords (low information entropy secrets)
• Other criteria, such as voice recognition or other biometrics
• Off-the-Record Messaging for instant messaging
• Off-channel verification
• Carry-forward verification

The integrity of public keys must generally be assured in some manner, but need not be secret. Passwords and shared secret keys have the additional secrecy requirement. Public keys can be verified by a Certificate Authority, whose public key is distributed through a secure channel (for example, with a web browser or OS installation). Public keys can also be verified by a web of trust that distributes public keys through a secure channel (for example by face-to-face meetings).

See key agreement for a classification of protocols that use various forms of keys and passwords to prevent man-in-the-middle attacks.

[edit] Quantum cryptography

Quantum cryptography protocols typically authenticate part or all of their classical communication with an unconditionally secure authentication scheme (e.g. Wegman-Carter authentication).

[edit] Beyond cryptography

MITM should be seen as a general problem resulting from the presence of intermediate parties acting as proxy for clients on either side. If they are trustworthy and competent, all may be well; if they are not, nothing will be. How can one distinguish the cases? By acting as proxy and appearing as the trusted client to each side, the intermediate attacker can carry out much mischief, including various attacks against the confidentiality or integrity of the data passing through it.

A notable non-cryptographic man-in-the-middle attack was perpetrated by one version of a Belkin wireless network router in 2003. Periodically, it would take over an HTTP connection being routed through it: it would fail to pass the traffic on to destination, but instead itself respond as the intended server. The reply it sent, in place of the web page the user had requested, was an advertisement for another Belkin product. After an outcry from technically-literate users, this 'feature' was removed from later versions of the router's firmware.^[1]

Another example of a non-cryptographic man-in-the-middle attack is the "Turing porn farm." Brian Warner says this is a "conceivable attack" that spammers could use to defeat CAPTCHAs.^[2] The spammer sets up a pornographic web site where access requires that the user solves the CAPTCHAs in question. However, Jeff Atwood points out that this attack is merely theoretical — there is no evidence that any spammer has ever built a Turing porn farm.^[3] However, as reported in an October, 2007 news story while perhaps not being a farm as such, spammers have indeed built a Windows game in which users type in CAPTCHAs acquired from the Yahoo webmail service, and are rewarded with pornographic pictures.^[4] This allows the spammers to create temporary free email accounts with which to send out spam.

[edit] Implementations

• dsniff - A tool for SSH and SSL MITM attacks
• Cain - A Windows GUI tool which can perform MITM attacks, along with sniffing and ARP poisoning
• Ettercap - A tool for LAN based MITM attacks
• Karma - A tool that uses 802.11 Evil Twin attacks to perform MITM attacks
• AirJack - A tool that demonstrates 802.11 based MITM attacks
• wsniff - A tool for 802.11 HTTP/HTTPS based MITM attacks
• an additional card reader and a method to intercept key-presses on an Automated teller machine

[edit] See also

• Man in the Browser
• Computer security
• Cryptanalysis
• Secure channel
• Digital signature
• Key management
• Key agreement protocol
• Password-authenticated key agreement
• Interlock Protocol
• Miss in the middle attack
• Mutual authentication
• Quantum cryptography
• Relay attack
• Meet-in-the-middle attack
• Babington Plot
• Aspidistra (transmitter) Used for World War II radio "intrusion" operations, an early man-in-the-middle attack.

[edit] References

[edit] External links

• Non-cryptographic MITM attack involving nanny references