Diffie-Hellman Key Exchange
What is Diffie-Hellman Key Exchange?
In the world of electronic communications, we need a way to communicate sensitive information securely. To most people, this means that we must encrypt the data using some sort of encryption algorithm; however, encryption alone does not ensure a secure transfer. We must develop a secure way to transfer the encryption key without giving it away to any malicious third party. This can be done with Diffie-Hellman Key Exchange.
How does Diffie-Hellman Key Exchange work?
Mike and Ike would like to make a secure connection to each other to make a bank transaction. They both decide on a random number, called the generator, (g) and very large prime number (p). Individually, they each select a secret key (sM for Mike and sI for Ike), and from that secret key, they calculate a public key (yM = g^sM mod p for Mike and yI = g^sI mod p for Ike).
Once p, g, s and y have been determined, the two parties exchange their public keys on the insecure channel and each calculate a crypto-variable (c) of the form cM = yI^sM mod p for Mike and cI = yM^sI mod p for Ike. Now, assuming the information is transferred without a man-in-the-middle attack, Mike and Ike will derive the same crypto-variable. Remember that yI = g^sI mod p and yM = g^sM mod p. If y is replaced in each equation, the result is c = g^sIsM mod p. A shared secret key has now been established for data encryption without each party giving away their secret key.
What is a ‘Man-In-The-Middle’ Attack?
Not everyone in the world has good intentions online. The “man-in-the-middle” is an attack in which a third party, Seth, listens to the data being transferred between Mike and Ike. Intercepting the communications is easy because all communications are transferred over the insecure channel, also called “in the clear”. Being able to decrypt them is not easy without knowing the values g, p and y because the encryptions are “one way functions”. In order to do this, Seth simply listens to the transfer of g and p and remembers the values. He then intercepts the public key from Mike (yM) and calculates a crypto-variable as cSM = yM^sS mod p and sends this value to Ike. Seth also intercepts the public key from Ike (yI) and calculates another crypto-variable cSI = yI^sS mod p and sends this value to Mike.
Since Mike and Ike both think that they have devised a shared secret key, they begin encrypting all of their data using this key and sending it out into the insecure channel. To both Mike and Ike, their transmissions sound like noise, so they are ignored; but to Seth, they are intelligible messages. He grabs all of this data, decrypts it, and re-encrypts it, using the keys he derived, and sends it on its way.
Once the messages are re-encrypted, they make sense to both Mike and Ike, so they decrypt them and read the message. Since Seth is reading all of the information, he can also change some of the information before sending it on its way. This makes the messages that Mike and Ike receive unreliable and inaccurate.
How can I stop a ‘Man-In-The-Middle’ attack?
Stopping a man-in-the-middle attack is just as easy as launching one. There are a couple of methods in use to stop this kind of attack being used today in secure transactions. We’ll explore a couple of them.
Method 1: Certified Public Keys
A public key is the y value that an individual can compute given a static p and g. Anyone can register one of these keys with an agency like VeriSign. Once the key is registered, it becomes a certified public key. These agencies function as large phone books, keeping record of thousands of public keys and to whom they belong. VeriSign will allow anyone to see the keys on their list as well as to whom the keys belong. For this example, assume Mike and Ike are both banks that have a certified public key and would like to transfer account information in the clear. They look into VeriSign’s database and find each other’s public key and compute a crypto-variable (c). They each then follow the steps above to establish communications. After they have derived a crypto-variable on their own, they compare that value to c, the value computed from the key in the VeriSign database. If the values do not match, they repeat the process until they have established a secure communication channel.
Method 2: Anti-spoof Variables
An anti-spoof variable is a variable used to verify that a spoofer (man-in-the-middle) has not intercepted communications. At both Mike’s and Ike’s computer stations, there is an auxiliary screen. This screen is used to display a short anti-spoof variable; a value calculated as a function of the crypto-variable that both Mike and Ike derive using the default method. After the crypto-variable is computed, the auxiliary screens calculate the anti-spoof variable – by converting the crypto-variable into a four digit hexadecimal number – and then display the result. Mike then calls Ike via the telephone and ensures that the number is the same on both ends. If the number is not the same, Mike and Ike know that their system is under a man-in-the-middle attack and must re-establish the connection.
Method 3: Netkeys
A netkey is simply a value that is computed by each party in a secure communication. Each client has a table of common netkeys. Before a secure channel is established, Mike and Ike will determine if they have a shared netkey. This can be done by exchanging their netkey tables, or simply by asking value per value, if they have the same key. If there is a shared value, then they calculate the crypto-variable as before and concatenate the netkey onto it to ensure its integrity. If the two crypto-variable, netkey combinations are not identical, then the system is under a ‘Man-In-The-Middle’ attack and the channel must be established again.
So what does this all mean to me?
Translated to layman’s terms, this means that using Diffie-Hellman Key Exchange alone is not sufficient to ensure secure data transfer between two parties. It must be used in combination with one of the above methods to prevent a ‘Man-In-The-Middle’ attack.
- 3.6.1 What is Diffie-Hellman? RSA Labratories. 2004. http://www.rsasecurity.com/rsalabs/node.asp?id=2248.
- Maher, David P. Secure Communication Method and Apparatus. United States Patent and Trademark Office. Patent 5,450,493. September 12, 1995.