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:
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.
Offering the Wikipedia answer:
In the original description, the Diffie–Hellman exchange by itself does not provide authentication of the communicating parties and is thus vulnerable to a man-in-the-middle attack. A person in the middle may establish two distinct Diffie–Hellman key exchanges, one with Alice and the other with Bob, effectively masquerading as Alice to Bob, and vice versa, allowing the attacker to decrypt (and read or store) then re-encrypt the messages passed between them.
A method to authenticate the communicating parties to each other is generally needed to prevent this type of attack. Variants of Diffie-Hellman, such as STS, may be used instead to avoid these types of attacks.
You may consider impressing your professor by discussing the variants of Diffie-Hellman that are more secure. For now, given you've noted the original implementation, this will do.
Best of luck!
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With