# ECDH Man-in-the-middle active attack

We have Alice and Bob. The man in the middle can manipulate(remove, add something etc.) A sent from Alice and B sent from Bob, how can he figure out what the common key K(A,B) is, without knowing kpr(a) and kpr(b)? Everything is based on Elliptic Curves.

• Why are you asking? Do you know that or ask if the MITM can get this info? Is this a homework assigment? Any starting points that you have thought of already?
– user19973
May 23, 2016 at 17:50
• Question is: How can he figure out the common key? I think he cant, but can someone prove that he can do it?
– Sick654
May 23, 2016 at 18:26
• Figuring out the common key is not possible; that's what DH is supposed to protect. Posing as either one of the two partners is however possible, generating a different common key for each connection. Now Alice and Bob think they share a common key but they are actually sharing a different "common key" with Mallory (who will probably share it with Mickey). May 27, 2016 at 8:27

Diffie-Hellman (and variants such as ECDH) protect against passive eavesdroppers, but not (at least by themselves) against active man-in-the-middle attacks. An active MITM can substitute his own keys for Alice and Bob's keys during the initial exchange, something like this:

Alice -> Bob (intercepted by Mallory): Hi Bob, I'm Alice and here's my public key: [Alice's public key]

Mallory -> Bob: Hi Bob, I'm Alice and here's my public key: [Mallory's public key]

Bob -> Alice (intercepted by Mallory): Pleased to meet you Alice, I'm Bob and here's my public key: [Bob's public key]

Mallory -> Alice: Pleased to meet you Alice, I'm Bob and here's my public key: [Mallory's public key]

Alice then computes a shared key based on her private key and "Bob" (actually Mallory)'s public key, and uses that to encrypt data to/from "Bob" (actually Mallory). Similarly, Bob computes a shared key he thinks is shared with Alice, but is actually shared with Mallory. Mallory uses the two public keys and his own private keys to compute both shared keys, and uses them to decrypt and reencrypt the messages passing between Alice and Bob.

This is why it's important to couple DH key exchange with some sort of authentication. For instance, in TLS's ephemeral DH and ECDH modes, the server signs its DH parameters (including its DH public key) to insure that they haven't been tampered with.