Forward Secrecy and Ephemeral Keys … Guarding Against Data Breaches in the Future and the Past

Forward Secrecy and Ephemeral Keys … Guarding Against Data Breaches in the Future and the Past

Upgading for the Future and the Past

Introduction

In our secure network connections, we need to create a session key to encrypt our data. Normally this is a 128-bit or 256-bit AES key. One method is for the server to send its public key, and then for the client to generate a random key, and encrypt it with the public key of the server and send it back. The server then uses the associated private key to decrypt it, and then the client and server will have the same key.

The perfect solution? Nope! This method is currently being kicked-off TLS and will not be supported by TLS 1.3. Why? Because a hack of one key — the long-term private key — will reveal all the previous and future keys.

One of the greatest risks in Cyber Security is the leakage of long-term keys (a breach of the trust infrastructure), and where all the communications associated with the keys could be comprised. Such as breach could bring down even the largest of companies, as their digital presence could not be trusted anymore. Imagine if this happened to Google or a major digital certificate provider?

So what’s the solution? Well, before we start, let’s look at the method that is most commonly associated with key exchange: the Diffie-Hellman (DH) method.

The Diffie-Hellman method

With the DH method, Bob and Alice agree on two numbers (G — a generator and N — a prime number). They then independently generate a random number (x for Bob and y for Alice). Let’s select [calculator]:

G =281 N=3049

Bob and Alice generate random numbers (x and y):

X = 21

Y = 6

Bob calculates A:

A = 28121 mod 3049 = 2856

Alice calculates B:

B = 2816 mod 3049 = 2545

They swap values and they generate the key:

Key (Bob) = 285621 mod 3049 = 452

Key (Alice) = 25456 mod 3049 = 452

This method suffers from a man-in-the-middle attack, as Eve can get in the middle and can negotiate a key with Bob and another with Alice. Bob thus cannot tell if he is really involved in a key exchange with Alice, and vice-versa.

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.

The Answer?

The answer is to use methods which support FS and which are ephemeral. Within SSL/TLS connections, such as for HTTPS accesses, we can use DHE (ephemeral DH) or Ephemeral Diffie-Hellman with RSA (DHE-RSA) to make sure we do not create the same key. But to support FS, we need a method such as Elliptic Curve Ephemeral Diffie-Hellman with ECDSA (ECDHE-ECDSA) as it supports both ephemeral and FS, and is thus robust against attacks. If you’re interested in the maths behind it, you can try a few things here:

A demo of this method is here.

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 Sockey 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 the 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^x and take the G, N and G^x 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^x and the signature of nonces (a random value) and the Diffie-Hellman parameters (G, N, and G^x). 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^x). 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^y back to the server. The G^(xy) 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

Conclusions

Within a few years, we will age out all of the methods which do not support ephemeral keys and forward secrecy. WPA-3 is a good example of this.