Perfect Forward Secrecy explained

What is Perfect Forward Secrecy?

Perfect Forward Secrecy (PFS), also known as forward secrecy, is a style of encryption that enables short-term, private key exchanges between clients and servers. PFS can be found within transport layer security (SSL/TLS) and prevents hackers from decrypting data from other sessions, past or future, even if the private keys used in an individual session are stolen at some point.

PFS accomplishes this by utilizing unique session keys, generated automatically each time a connection is made. The keys do not use prior knowledge when they are generated, eliminating the need for long-term storage of keys and preventing sensitive data from being accessed using existing ones that have been compromised.

Hackers are thus unable to obtain the session key through decryption without involvement at a foundational level, with the key agreement and exchange mechanism, which requires much more effort than other attack methods.

PFS is supported by all major internet browsers and is usually seen as a security feature. Most modern operating systems support PFS and have for quite a while. For instance, the last version of Windows to not support PFS was Windows XP.

The growth of PFS is expected to continue as more technology giants force customer adoption. Google has used it with Gmail and other products for years now, and Apple made perfect forward secrecy, within iOS, a requirement on the App Store in 2017. When TLS 1.3 was introduced, the Internet Engineering Task Force (IETF) mandated perfect forward secrecy, only allowing cipher suites that offered it. It’s an important part of the future of cryptography, and for good reason.

How PFS works

Since PFS uses unique session keys, attackers are only able to view the data specific to a particular exchange if they recover the private keys for that exchange. This segmentation of SSL/TLS sessions greatly reduces the risk of a severe data breach through this vector.

Therefore, malicious actors will be less likely to target a server utilizing PFS since their efforts will result in access to significantly less data, with no guarantee that the data retrieved will be the intended target until they decrypt it using the stolen keys.

In practice, PFS works by organizations switching session keys each time a service is used—for example, each time a visitor goes to an encrypted page, perhaps for financial or identification reasons. PFS is also used in messaging. A new set of session keys can be used for every message sent, completely segmenting any information that is gathered.

The preferred method to decrypt a PFS session is through utilizing an agent installed on the server itself. There are other methods, but these bring with them drawbacks that must be addressed before they can be used securely.

Installing an agent on a server integrates third-party software that collects encryption keys and provides visibility without disruption to the SSL/TLS session.

Which encryption algorithms use it?

SSL/TLS is accomplished through the exchange of keys via agreed-upon cryptographic processes called cipher suites. The agreement to establish these connection parameters is called a handshake.

For perfect forward secrecy to be implemented, a compliant type of encryption must be used. Currently, two key exchange algorithms will work:

• Ephemeral Diffie-Hellman (DHE)
• Ephemeral Elliptic Curve Diffie-Hellman (ECDHE)

The specific algorithms used will most likely change as better methods are discovered, but one of the most important tenets of PFS is that the key exchanges must be ephemeral, meaning the session keys are one-time use only. These are also known as ephemeral keys. They are based on random values created during each exchange so they are unique to that exchange and will no longer be valid when it ends. All the encrypted information is deleted afterward and new parameters are created for the next session.

In addition to limiting the exposure of data once a key is compromised, the design of the Diffie-Hellman key exchange ensures the session key cannot be obtained via brute force. Since the session key is created through independent, non-shared cryptographic methods, the server's private key is all but useless. The corresponding public key in the pair is never actually used to encrypt any of the data.

The main purpose of PFS

PFS prevents the proliferation of risk across multiple SSL/TLS sessions.

Previously, a malicious actor targeting a commonly used connection between a client and server could record encrypted traffic for as long as they wanted, waiting until they’re able to get their hands on the private key. Then, once that is acquired, they can go back and decrypt everything that has been recorded. PFS substantially limits this.

Before PFS, this vulnerability was common and potentially devastating. A clear example of this can be seen in the Heartbleed OpenSSL vulnerability that was discovered in 2012 and publicly announced in 2014.

With the Heartbleed bug, attackers instructed the server that they were going to send it a 64KB heartbeat request message, but instead, they sent a much smaller message. The server would reply with the shorter message, but since the server anticipated replying with a longer message, it would pad the rest of the message with whatever data happened to be in its memory. This was devastating, as the attack was able to be run repeatedly to gather large amounts of data. The data could contain anything within the server; passwords, personal information, session data, and even the server’s private key were all within the hacker's reach.

Since a heartbeat request is a routine event, it never gets logged within the system. This not only causes a problem for forensic investigation of the hack but makes the hack impossible to discover without specifically looking for it.

If the server’s private key was one of the items compromised by the breach, then the attacks would also be able to intercept and decrypt any SSL/TLS sessions that occurred without participants realizing it.

Users of PFS are not only worried about malicious actors but also other types of surveillance. After Edward Snowden's release on the National Security Agency's (NSA) spying programs, many organizations see PFS as a necessary step to limit government spying and oversight.

A solution for the future

If current technological processing development follows Moore's Law or the leap to quantum computing is made at a large scale, many cryptographic algorithms and best practices will be overcome and made obsolete. This will expose anything the encryption is protecting and could put legacy data in danger. Many experts have raised concerns that individuals and nations around the world are collecting data with the goal in mind of decrypting it at a later date when the processing makes it trivial.

PFS prevents this strategy as an option altogether. It does not transmit any of its session keys over the network, instead, PFS uses symmetric encryption methods that generate session keys independently through complex authentication equations performed by both sides.

Another option to help prevent this issue is the utilization of quantum cryptography, a developing field.

How to achieve perfect forward secrecy

Enabling PFS support on a server is simple, and most modern servers are already configured for it. If not, you can generally do so in four straightforward steps:

1. Go to the SSL protocol configuration
2. Add the SSL protocols
3. Set an SSL cipher that’s compatible with PFS
4. Restart your server

Perfect forward secrecy can be accomplished on most web servers including Apache, Nginx, RSA, and others.