TLS and Perfect Forward Secrecy

Recently there has been a lot of ruckus about security vulnerabilities in the way we communicate over the web. SSL/TLS (used in HTTPS), which has become the de-facto standard for secure online communication, has come under a lot of flak for being vulnerable to data breach attacks. Snooping of encrypted traffic by government agencies and the recent Heartbleed vulnerability haven’t helped its cause either. However we need to remember that these breaches were not due to vulnerabilities in the TLS protocol itself. Rather, they were the result of either how TLS was configured to run or bugs in the implementation of the protocol itself. For example, Heartbleed bug was caused due to a simple coding mistake in a particular version of OpenSSL.

But programming bugs aside, there is another vulnerability by which TLS encrypted data can be recorded by an attacker and deciphered at a later point of time. This is the problem that we are going to discuss in this article. We will also look at a solution to this problem and it is based on a cryptographic concept called “Perfect Forward Secrecy (PFS)”.

Before we go further, a few things to note here:

1. In any cryptographic system, the “thing” that ultimately provides security is not the cryptographic algorithm. Rather, that power is vested with the key which works with the algorithm. Any secure system has to keep its keys safe and secure from prying eyes. And in the context of a “Public Key Infrastructure (PKI)” based system such as TLS, it is of outmost importance to keep private keys secure. As we shall see in the next section, the private key plays an important role in generating TLS session keys securely.
2. SSL/TLS is a set of protocols which enables two parties to mutually authenticate each other using digital certificates and establish a secure session for communication. It relies on a handshake protocol to achieve this. Once TLS session is established, all communication between the two parties are protected using the session keys for that session.
3. Although TLS supports mutual authentication, in its most widespread use (e.g. HTTPS based websites), it is only the server (web server) which is authenticated by the client (browser). A TLS server sends it certificate to the client for authentication during the handshake.
4. TLS works with cipher-suites. A cipher suite is a set of cryptographic algorithms which can be used to set up a secure session. Typically it specifies three key types – one for key agreement mechanism, one for authentication and one symmetric cipher algorithm for bulk encryption. For example a ciphersuite of type TLS_DH_RSA_WITH_AES_256_CBC_SHA denotes that Diffie Hellman (DH) protocol should be used as a key agreement mechanism, RSA for authentication and AES 128 CBC for bulk encryption (SHA being the digest algorithm). There are many such ciphersuites defined by the TLS standard, each having a different combination of algorithms.
   During the TLS handshake, the server and the client agree upon a particular ciphersuite to set up a secure TLS session.

5. Most commonly, servers are provisioned with a RSA key pair, the public key of which is also embedded in its certificate. These are fixed keys i.e. until and unless they have been compromised the server will keep using them for all TLS handshakes.
6. Most servers commonly support the TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite. This means that the server is capable of using its fixed RSA key pairs for both key agreement and authentication. It also means that the server supports AES-CBC encryption with 128 bit symmetric key. As we shall see later, the usage of this ciphersuite is the root cause of our problem i.e. the ability of an attacker to record TLS messages and decipher them later.

TLS Handshake

Let us now see how a secure session is established in a TLS setup with ciphersuite TLS_RSA_WITH_AES_128_CBC_SHA. Please note that this does not describe the TLS handshake in accurate details, but tries to convey the basic idea behind the handshake.

As a part of the TLS handshake:

1. The server sends its certificate to the client. The client verifies the authenticity of the certificate and extracts the server’s RSA public key from it.
2. The client then generates a random number called pre-master secret and encrypts it with the server’s public key. This encrypted pre-master secret is sent back to the server.
3. The server decrypts this using its private RSA key and gets back the original pre-master secret. Thus, at this point of time, both parties are in possession of the pre-master secret.

4. Both parties now independently use a function (defined by the TLS standard) to generate a set of session keys from the pre-master secret. The standard guarantees that the session keys generated on both sides will be the same. Thus both parties end up with the same set of session keys without explicitly sending them over the network, hence lending security against eavesdroppers.

Is this secure?

This looks quite secure and indeed it is. An attacker might have to use brute force to guess the session keys with which the ongoing TLS session data is encrypted and that is a tough proposition. But if the attacker can somehow get hold of the server’s fixed RSA private key, then it’s a piece of cake for him to decipher the TLS transactions. We will see how he can do this in the next section.

But for now let us see how can an attacker access the private key of a server.

1. Well as it turns out, if you work for a government agency, you can easily do it by getting a court to issue a warrant telling the server provider to hand over its fixed private key to you. This has, in fact, happened to a few companies providing secure e-mail services to customers.
2. Another way would be to rely on Heartbleed bug to do this for you. If you are a lucky hacker, you can exploit any TLS server running OpenSSL’s Heartbleed affected code to get a dump of its memory. This dump might give you the private key of the server along with other critical data. Of course, any elite hacker worth his salt would have other methods in his/her arsenal to compromise a server’s private key such as social engineering.

Thus, a wise hacker will sniff and record all the messages of a TLS handshake happening between a client and a server. At some point of time in the future, he is somehow able to get hold of the private key of the server (legally or otherwise :)). All he needs to do now is to decrypt the message which contained the encrypted pre-master secret using the private RSA key (See step 2 of the TLS handshake). Then he can easily generate the session keys using the pre-master secret. These session keys can then be used to decrypt all the encrypted messages of that particular TLS session.

He will also be able to break into any future TLS sessions between the server and other clients since he has the private key. Not to mention the fact that he can now actually masquerade as the SSL server itself! (To re-iterate, protect your private keys!!!)

Can we prevent this type of attack?

So is there a way to prevent this problem? Since preventing access to a server’s fixed key is never foolproof, our solution should not rely on it. Rather it should make it cryptographically impossible for an attacker in possession with a server’s fixed private key to decrypt recorded TLS traffic from the past or future TLS sessions. This is the idea behind Perfect Forward Secrecy.

Perfect Forward Secrecy prevents the compromise of a long term secret key from affecting the confidentiality of past conversations.

So how do we achieve Perfect Forward Secrecy? By using a mechanism called Ephemeral Diffie Hellman key exchange mechanism.

Diffie Hellman Key Exchange Mechanism

Diffie-Hellman (DH) is a really cool protocol using which a shared secret key can be established between two parties using public-private DH parameters.

Without going into the (magical!) details of the algorithm, let us simply understand it now as a protocol in which two parties capable of DH:

1. exchange their DH public key components in the clear,
2. agree on two public parameters- a generator and a large prime (again in the clear) and then
3. compute a secret key independently using the above mentioned values and their own DH private key.

The mathematics behind the protocol guarantees that the secret key generated on both sides will be the same. The secret key can be used to encrypt further communication between the two parties.   Even though an attacker can sniff the exchanged parameters from the network, he won’t be able to generate the final secret key as he does not have the private key.

Ephemeral Diffie Hellman Exchange

But the above mechanism still does not provide perfect forward secrecy unless the exchanged key material are ephemeral i.e. short lived. Thus the idea is, for every new TLS session, the server generates an ephemeral DH key pair and use it to establish a secure TLS session. This DH key pair is discarded as soon as the session is established. This makes it infeasible for the attacker to decipher recorded TLS traffic later, as the private DH key is already deleted from the server. And even though an attacker has somehow got access to the ephemeral DH private key in real time, he would only be able to compromise that particular session only. Past or future TLS sessions will not be affected.

A modified TLS handshake mechanism will now look somewhat like this:

Conclusion

The lesson here is that we can have perfect forward secrecy in our TLS conversations if we use ephemeral key pairs to generate session keys for the TLS session. Although the article mainly deals with TLS to describe the concept of Perfect Forward Secrecy, the idea is applicable to other protocols too such as IPSec