4
$\begingroup$

I think my limited understanding of DH might be messed up - what's wrong with this scenario?

  • C wants to connect to S.
  • C has an ECDSA public key that it trusts belongs to S.

Here's what happens:

  1. C connects to S.
  2. S sends its part of the DH key exchange, signed to prevent tampering*.
  3. C sends over its part of the DH key exchange, in plaintext and without a signature.
  4. C and S now calculate the shared key.
  5. The shared key is used for all further communication.

*Add padding, etc. to prevent forgeries and reuse.

A MitM can't lie to C, because it can't forge the signature, and if it lies to S, it isn't really gaining anything, because if it could effectively pretend to be C without routing everything back through C, it wouldn't have to make a MitM attack in the first place.

$\endgroup$

migrated from security.stackexchange.com Dec 17 '16 at 22:24

This question came from our site for information security professionals.

6
$\begingroup$

TLDR:

  1. Diffie-Hellman key exchange works differently
  2. Yes, DH is vulnerable to MitM.

Long answer:

Diffie-Hellman key exchange isn't about sending the public key with some kind of signature, but about negotiating the key.

Quick DH explaination (note: these values are very insecure):

  • Alice and Bob publicly agree on two values:
    1. The generator - g. Let's say this is 3.
    2. The prime modulus (obviously a prime number) - p. Let's say this is 17.
  • Both Alice and Bob think of a secret value, let's call this x
    1. Alice's secret value is 15
    2. Bob's secret value is 13
  • They calculate yet another values, using this formula: g^x mod p
    1. Alice: 3^15 mod 17 = 6
    2. Bob: 3^13 mod 17 = 12
  • Alice sends the result to Bob and vice versa
  • They both calculate the final value like this:
    1. Alice: 12^15 mod 17 = 10
    2. Bob: 6^13 mod 17 = 10
  • They have negotiated a key and Eve doesn't know what's the value of this key (the negotiation requires a lot of values to be exchanged and therefore simply listening but not participating in the exchange doesn't let you see the established key)

MitM example:

Imagine this "circuit":

Alice -- Eve -- Bob

Eve changed the values when they were exchanging them, decrypts everything that comes from Alice with the key she has exchanged with Alice, and then encrypts it with the key she has exchanged with Bob and vice versa.

Conclusion:

There's a need for some kind of "pre-shared secret" with DH. DH itself is not MitM-proof. For SSL/TLS that is Certificate Authorities. Instant messaging often uses OTR (which involves a question that only the actual other party should be able to answer - pre-shared secret).

$\endgroup$
  • $\begingroup$ Uhh, yeah I think I got that much. When I said public key, I meant the 6 and the 12 in your example - the calculated values that they share with each other. I'm just wondering if tacking that signature on the end of one of the exchanges is enough to prevent a MitM attack. $\endgroup$ – Draconian Dignitary Dec 16 '16 at 17:03
  • $\begingroup$ Wait what do you mean Eve can just "pass" the signed key exchange from Bob? $\endgroup$ – Draconian Dignitary Dec 16 '16 at 17:27
  • $\begingroup$ @DraconianDignitary Signed message, not signed key exchange. Bob signs a message hoping it will prove his identity, but Eve can just pass this message to Alice. $\endgroup$ – Samuel Shifterovich Dec 16 '16 at 17:47
  • $\begingroup$ Okay, I tried to make the question clearer. $\endgroup$ – Draconian Dignitary Dec 16 '16 at 18:10
  • $\begingroup$ @DraconianDignitary Like I said, "Surely encrypting the key exchange works as long as Eve doesn't know the pre-shared key." and signing is essentially encrypting. Therefore, it will work as long as the implementation is correct. $\endgroup$ – Samuel Shifterovich Dec 16 '16 at 20:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy