Search code examples
diffie-hellmanman-in-the-middle

How to exploit Diffie-hellman to perform a man in the middle attack

Im doing a project where Alice and Bob send each other messages using the Diffie-Hellman key-exchange. What is throwing me for a loop is how to incorporate the certificate they are using in this so i can obtain their secret messages.

From what I understand about MIM attakcs, the MIM acts as an imposter as seen on this diagram:

enter image description here

Below are the details for my project. I understand that they both have g and p agreed upon before communicating, but how would I be able to implement this with they both having a certificate to verify their signatures?

Alice prepares ⟨signA(NA, Bob), pkA, certA⟩ where signA is the digital signature algorithm used by Alice, “Bob” is Bob’s name, pkA is the public-key of Alice which equals gx mod p encoded according to X.509 for a fixed g, p as specified in the Diffie-Hellman key- exchange and certA is the certificate of Alice that contains Alice’s public-key that verifies the signature; Finally, NA is a nonce (random string) that is 8 bytes long.

Bob checks Alice's signature, and response with ⟨signB{NA,NB,Alice},pkB,certB⟩. Alice gets the message she checks her nonce NA and calculates the joint key based on pkA, pkB according to the Diffie-Hellman key exchange. Then Alice submits the message ⟨signA{NA,NB,Bob},EK(MA),certA⟩ to Bob and Bobrespondswith⟨SignB{NA,NB,Alice},EK(MB),certB⟩.

where MA and MB are their corresponding secret messages.

Solution

  • The internet can help!

    The Diffie-Hellman key exchange is vulnerable to a man-in-the-middle attack. In this attack, an opponent Carol intercepts Alice's public value and sends her own public value to Bob. When Bob transmits his public value, Carol substitutes it with her own and sends it to Alice. Carol and Alice thus agree on one shared key and Carol and Bob agree on another shared key. After this exchange, Carol simply decrypts any messages sent out by Alice or Bob, and then reads and possibly modifies them before re-encrypting with the appropriate key and transmitting them to the other party. This vulnerability is present because Diffie-Hellman key exchange does not authenticate the participants. Possible solutions include the use of digital signatures and other protocol variants.

    So you have your own value for A, and you just swap the message contents and recompute signatures and forward along.