Lecture
In cryptography, forward secrecy ( FS ), also known as perfect forward secrecy ( PFS ), is a property of certain key-agreement protocols that guarantees session keys will not be compromised even if the long-term secrets used in the session-key exchange are later compromised. For HTTPS, the long-term secret is usually the server's private key. Forward secrecy protects past sessions against future compromise of keys or passwords. By generating a unique session key for every session a user initiates, compromising one session key does not affect any data other than that exchanged within the specific session protected by that particular key. This alone is not sufficient for forward secrecy, which additionally requires that a long-term compromise of the secret not affect the security of past session keys.
Forward secrecy protects data at the network's transport layer, which uses common transport-layer security protocols, including OpenSSL, when its long-term secret keys are compromised, as in the case of the Heartbleed security bug. If forward secrecy is used, encrypted messages and sessions recorded in the past cannot be retrieved and decrypted even if the long-term secret keys or passwords are compromised in the future, even if the attacker actively intervened, for example through a «man-in-the-middle» (MITM) attack.
The value of forward secrecy lies in the fact that it protects past messages. This reduces attackers' motivation to compromise keys. For example, if an attacker learns a long-term key but the compromise is detected and the long-term key is revoked and updated, a system with forward secrecy will only leak a relatively small amount of information.
The value of forward secrecy depends on the adversary's assumed capabilities. Forward secrecy matters if it is assumed that an attacker can obtain secret keys from a device (read access) but either is detected or cannot change how session keys are generated on the device (full compromise). In some cases, an attacker who can read long-term keys from a device may also be able to alter the operation of the session-key generator, as with a backdoored dual elliptic-curve deterministic random bit generator. If the attacker can make the random number generator predictable, then past traffic remains protected, but all future traffic will be compromised.
The value of forward secrecy is limited not only by the assumption that an attacker will attack the server merely by stealing keys without altering the random number generator used by the server, but also by the assumption that the attacker will only passively collect traffic on the communication channel and will not act actively by using a «man-in-the-middle» attack. Forward secrecy typically uses an ephemeral Diffie-Hellman key exchange to prevent past traffic from being read. The ephemeral Diffie-Hellman key exchange is often signed by the server using a static signing key. If an attacker can steal (or obtain by court order) this static (long-term) signing key, they can impersonate the server to the client and the client to the server, carrying out a classic «man-in-the-middle» attack.
The term «perfect forward secrecy» was coined by C.G. Günther in 1990 and was further discussed by Whitfield Diffie, Paul van Oorschot, and Michael James Wiener in 1992 , where it was used to describe a property of the Station-to-Station Protocol.
Forward secrecy has also been used to describe an analogous property of password-authenticated key-agreement protocols, where the long-term secret is a (shared) password.
In 2000, IEEE first ratified the IEEE 1363 standard, which establishes the corresponding half-forward and full (mutual) forward-secrecy properties for various standard key-agreement schemes.
An encryption system has the forward-secrecy property if inspection of the plaintext (decrypted) exchange that takes place during key agreement at session initiation does not reveal the key that was used to encrypt the remainder of the session.
Below is a hypothetical example of a simple instant-messaging exchange protocol that uses forward secrecy:
Forward secrecy (achieved by generating new session keys for each message) guarantees that past messages cannot be decrypted if one of the keys generated in an iteration of step 2 is compromised, since such a key is used only to encrypt a single message. Forward secrecy also guarantees that past messages cannot be decrypted if the long-term secret keys obtained in step 1 are compromised. If that does happen, however, impersonating Alice or Bob becomes possible, which could put all future messages at risk.
Forward secrecy is designed to prevent the compromise of a long-term secret key from affecting the confidentiality of past conversations. However, forward secrecy cannot protect against successful cryptanalysis of the underlying ciphers used, since cryptanalysis consists of finding a way to decrypt an encrypted message without the key, and forward secrecy protects only the keys, not the ciphers themselves. A patient attacker can intercept a conversation whose confidentiality is protected through the use of public-key cryptography and wait until the underlying cipher is broken (for example, large quantum computers might eventually be built that would make it possible to solve the discrete logarithm problem quickly). This would allow the recovery of old plaintexts even in a system that uses forward secrecy.
Non-interactive key-exchange protocols with forward protection face additional threats that do not apply to interactive protocols. In a message-suppression attack, an attacker who controls the network can simply withhold messages, preventing them from reaching their intended recipient; because the messages are never received, the corresponding private keys are never destroyed or punctured, so compromise of a private key can lead to successful decryption. Deleting private keys promptly on a fixed schedule mitigates but does not eliminate this attack. In a malicious key-exhaustion attack, an attacker sends the recipient a large number of messages and exhausts its private-key material, forcing the protocol to choose between failing closed (and enabling a denial-of-service attack) or failing open (and losing some measure of forward secrecy).
Most key-exchange protocols are interactive and require two-way communication between the parties. A protocol that lets the sender transmit data without first needing to receive any response from the recipient may be called non-interactive , asynchronous , or zero round-trip time (0-RTT).
Interactivity is burdensome for some applications — for example, in a secure messaging system it may be desirable to have a store-and-forward implementation rather than requiring the sender and recipient to be online at the same time; relaxing the requirement of bidirectionality can also improve performance even where it is not a strict requirement, for example when establishing or resuming a connection. These use cases have driven interest in non-interactive key exchange, and, since forward secrecy is a desirable property of a key-exchange protocol, in non-interactive forward secrecy. This combination has been considered desirable since at least 1996. However, combining forward secrecy with non-interactivity has proven to be a difficult problem; it was believed that forward secrecy with replay-attack protection was impossible in a non-interactive setting, but it has since been shown that all three goals can be achieved.
Two general approaches to non-interactive forward secrecy have been explored: precomputed keys and puncturable encryption .
With precomputed keys, many key pairs are created, the public keys are shared, and the private keys are destroyed once a message using the corresponding public key has been received. This approach was deployed as part of the Signal protocol.
With puncturable encryption, the recipient modifies their private key after receiving a message so that the new private key can no longer read that message, while the public key remains unchanged. Ross J. Anderson informally described a puncturable encryption scheme for forward-secure key exchange in 1997, and Green and Miers (2015) formally described such a system, building on the corresponding scheme by Canetti, Halevi, and Katz (2003), which modifies the private key on a schedule so that messages sent in earlier periods cannot be read using a private key from a later period. Green & Miers (2015) use hierarchical identity-based encryption and attribute-based encryption, while Günther et al. (2017) use a different construction that can be based on any hierarchical identity-based scheme. [18] Dallmeier et al. (2020) experimentally found that modifying QUIC to use forward-secure and replay-resistant 0-RTT key exchange, implemented via puncturable encryption, led to a significant increase in resource use, though not enough to make practical use impossible.
Weak perfect forward secrecy (Wpfs) — is a weaker property under which, if the long-term keys of the parties are compromised, the secrecy of previously established session keys is guaranteed, but only for sessions in which the attacker did not actively interfere. This is a new concept, and the distinction between it and forward secrecy was introduced by Hugo Krawczyk in 2005. This weaker definition implicitly requires that full (perfect) forward secrecy preserve the secrecy of previously established session keys even in sessions where the adversary actively interfered or attempted to act as a man in the middle.
Forward secrecy is present in several major protocol implementations, such as SSH, as well as an optional feature in IPsec (RFC 2412). Off-the-Record Messaging, a cryptographic protocol and library used by many instant-messaging clients, as well as OMEMO, which adds features such as multi-user functionality to such clients, both provide forward secrecy and deniable encryption.
In Transport Layer Security (TLS), cipher suites are available based on Diffie-Hellman key exchange (DHE- RSA , DHE- DSA ) and elliptic-curve Diffie-Hellman key exchange (ECDHE- RSA , ECDHE- ECDSA ). In theory, TLS could select suitable ciphers starting with SSLv3, but in everyday practice many implementations either failed to provide forward secrecy or offered only a very low grade of encryption. This is no longer the case with TLS 1.3, which provides forward secrecy, leaving the ephemeral Diffie-Hellman method (finite-field and elliptic-curve variants) as the only remaining key-exchange mechanism.
OpenSSL has supported forward secrecy using elliptic-curve Diffie-Hellman since version 1.0, at a computational cost of roughly 15% for the initial handshake.
The Signal Protocol uses the Double Ratchet Algorithm to provide forward secrecy.
On the other hand, among popular protocols currently in use, WPA does not support forward secrecy.
Forward secrecy is regarded by several major Internet information providers as an important security feature. Since late 2011, Google has provided forward secrecy by default via TLS for users of its Gmail service, Google Docs service, and encrypted search services. Since November 2013, Twitter has provided its users with forward secrecy via TLS.
Facebook reported, as part of an investigation into email encryption, that as of May 2014, 74% of hosts supporting STARTTLS also provided forward secrecy. In the TLS 1.3 version, published in August 2018, support for ciphers without forward secrecy was dropped. As of February 2019, 96.6% of surveyed web servers supported some form of forward secrecy, and 52.1% would use forward secrecy with most browsers.
At WWDC 2016, Apple announced that all iOS apps would be required to use App Transport Security (ATS) — a feature that mandates the use of HTTPS transport. In particular, ATS requires the use of a cipher suite that provides forward secrecy. [ ATS became mandatory for apps as of January 1, 2017.
The Signal messaging app uses forward secrecy in its protocol, which notably distinguishes it from messaging protocols based on PGP.
Comments