Ephemeral Diffie-Hellman with RSA (DHE-RSA)
Ephemeral Diffie-Hellman with RSA (DHE-RSA)
Cryptography is going to the top of the agenda within many areas of our lives, and it is being targeted by the EU within GDPR, and by some politicians in cracking the keys involved.
One way for Bob and Alice to create a shared encryption key is for Alice to pass her public key to Bob, and then for Bob to generate the key and encrypt it with Alice’s public key. Bob then passes this back and Alice decrypts it with her private key. They will then have the same key to use with symmetric key encryption (such as with AES).
But what happens if Alice leaks her private key, the Eve will be able to crack all the keys that were generated? So, these days, we increasingly use a key exchange method to generate the secret shared key. One of the most popular methods in the past is the wonderful Diffie-Hellman (DH) method:
The problem with DH is that if Bob and Alice generate the same values, they will always end up with the same secret key. Along with this, Eve can sit in the middle of the communications and exchange different keys with Bob and Alice — the Man-in-the-Middle attack.
With Ephemeral Diffie-Hellman (DHE) a different key is used for each connection, and a leakage of the private key would still mean that all of the communications were secure. Within DHE-RSA, the server signs the Diffie-Hellman parameter (using a private key from an RSA key pair) to create a pre-master secret, and where a master is created which is then used to generate a shared symmetric encryption key.
Normally when we create a shared key we created a tunneled connected between a client and a server. This is normally defined through an SSL (Secure Socket Layer) or TLS (Transport Layer Security), and where a client connects to a server. Normally we define the tunnel type (such as TLS or SSL), the key exchange method (such as DHE-RSA), a symmetric key method to be used for the encryption process (such as 256-bit AES with CBC) and a hashing method (such as SHA). This can be defined as a string as:
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
and is contained in a ClientHello message that goes from the client to the server. A ServerHello is then returned with the digital certificate of the server and which contains the public key of the server. A simplified handshake is defined in Figure 1 where the client sends the definition for a TLS cipher suite.
In this case we are using a handshaking methods of DHE-RSA, a 256-bit AES-CBC shared key, and with a SHA hash signature. The server will then generate a random value (x) and create a value for G (the generator) and N (the prime number). Along with this the server will then generate Gˣ and take the G, N and Gˣ parameters and encrypt them with the private key of the server. This created a signature for the server.
Next the server will create a message with G, N, gˣ and the signature of a nonce (a random value) and the Diffie-Hellman parameters (G, N, and Gˣ). The server then sends this message with a digital certificate containing its public key.
When the client receives it, it will check the certificate for its validity, and then extract the public key. The client then checks the signature by decrypting the signed value and check it against the parameters already contained in the message (G, N, and Gˣ). If the values are the same, then the server has been validated. Now, as with DH, the client will create a random value of y, and send the value of Gʸ back to the server. The Gˣʸ value will then be the pre-master secret. In this way the client knows that it has received a valid value of the DH parameters, and can trust that the connection does not have a man-in-the-middle.
Figure 1: DHE-RSA
We now have a pre-master secret, as illustrated in Figure 2, which is shared by the client and server, and which can then be used to create a master key by using a PRF (Pseudorandom Function). In TLS 1.2 this is created using an HMCA-SHA256 hashed value (and which will generate a 256-bit key). To create the actual key used we feed the master key and the nonce into the PRF and generate the shared key for the session.
Figure 2: Generating the shared key
Forward Secrecy and Ephemeral
An important concept within key exchange the usage of forward secrecy (FS), which means that a comprise of the long-term keys will not compromise any previous session keys. For example if we send the public key of the server to the client, and then the client sends back a session key for the connection which is encrypted with the public key of the server, then the server will then decrypt this and determine the session. A leakage of the public key of the server would cause all the sessions which used this specific public key to be compromised. FS thus aims to overcome this by making sure that all the sessions keys could not be compromised, even though the long-term key was compromised. The problem with using the RSA method to pass keys is that a breach of the long keys would breach the keys previously used for secure communications.
Another important concept is where is key is ephemeral. With some key exchange methods, the same key will be generated if the same parameters are used on either side. This can cause problems as an intruder could guess the key, or even where the key was static and never changed. With ephemeral methods a different key is used for each connection, and, again, the leakage of any long-term would not cause all the associated session keys to be breached. The problem with the Diffie-Hellman method is that the keys are not ephemeral, so we should avoid it in generating keys.