Forward secrecy

Last updated
A Key derivation function (KDF) can help achieve Forward Secrecy. A KDF is a one-way function that generates a new key from the current key. Leaking a key does not allow discovery of prior keys. KDF chain.png
A Key derivation function (KDF) can help achieve Forward Secrecy. A KDF is a one-way function that generates a new key from the current key. Leaking a key does not allow discovery of prior keys.

In cryptography, forward secrecy (FS), also known as perfect forward secrecy (PFS), is a feature of specific key-agreement protocols that gives assurances that session keys will not be compromised even if long-term secrets used in the session key exchange are compromised, limiting damage. For HTTPS, the long-term secret is typically the private key of the server. Forward secrecy protects past sessions against future compromises of keys or passwords. By generating a unique session key for every session a user initiates, the compromise of a single session key will not affect any data other than that exchanged in the specific session protected by that particular key. This by itself is not sufficient for forward secrecy which additionally requires that a long-term secret compromise does not affect the security of past session keys.

Contents

Forward secrecy protects data on the transport layer of a network that uses common transport layer security protocols, including OpenSSL, when its long-term secret keys are compromised, as with the Heartbleed security bug. If forward secrecy is used, encrypted communications and sessions recorded in the past cannot be retrieved and decrypted should long-term secret keys or passwords be compromised in the future, even if the adversary actively interfered, for example via a man-in-the-middle (MITM) attack.

The value of forward secrecy is that it protects past communication. This reduces the motivation for attackers to compromise keys. For instance, if an attacker learns a long-term key, but the compromise is detected and the long-term key is revoked and updated, relatively little information is leaked in a forward secure system.

The value of forward secrecy depends on the assumed capabilities of an adversary. Forward secrecy has value if an adversary is assumed to be able to obtain secret keys from a device (read access) but is either detected or unable to modify the way session keys are generated in the device (full compromise). In some cases an adversary who can read long-term keys from a device may also be able to modify the functioning of the session key generator, as in the backdoored Dual Elliptic Curve Deterministic Random Bit Generator. If an adversary can make the random number generator predictable, then past traffic will be protected but all future traffic will be compromised.

The value of forward secrecy is limited not only by the assumption that an adversary will attack a server by only stealing keys and not modifying the random number generator used by the server but it is also limited by the assumption that the adversary will only passively collect traffic on the communications link and not be active using a man-in-the-middle attack. Forward secrecy typically uses an ephemeral Diffie–Hellman key exchange to prevent reading past traffic. The ephemeral Diffie–Hellman key exchange is often signed by the server using a static signing key. If an adversary can steal (or obtain through a court order) this static (long term) signing key, the adversary can masquerade as the server to the client and as the client to the server and implement a classic man-in-the-middle attack. [1]

History

The term "perfect forward secrecy" was coined by C. G. Günther in 1990 [2] and further discussed by Whitfield Diffie, Paul van Oorschot, and Michael James Wiener in 1992 [3] where it was used to describe a property of the Station-to-Station protocol. [4]

Forward secrecy has also been used to describe the analogous property of password-authenticated key agreement protocols where the long-term secret is a (shared) password. [5]

In 2000 the IEEE first ratified IEEE 1363, which establishes the related one-party and two-party forward secrecy properties of various standard key agreement schemes. [6]

Definition

An encryption system has the property of forward secrecy if plain-text (decrypted) inspection of the data exchange that occurs during key agreement phase of session initiation does not reveal the key that was used to encrypt the remainder of the session.

Example

The following is a hypothetical example of a simple instant messaging protocol that employs forward secrecy:

  1. Alice and Bob each generate a pair of long-term, asymmetric public and private keys, then verify public-key fingerprints in person or over an already-authenticated channel. Verification establishes with confidence that the claimed owner of a public key is the actual owner.
  2. Alice and Bob use a key exchange algorithm such as Diffie–Hellman, to securely agree on an ephemeral session key. They use the keys from step 1 only to authenticate one another during this process.
  3. Alice sends Bob a message, encrypting it with a symmetric cipher using the session key negotiated in step 2.
  4. Bob decrypts Alice's message using the key negotiated in step 2.
  5. The process repeats for each new message sent, starting from step 2 (and switching Alice and Bob's roles as sender/receiver as appropriate). Step 1 is never repeated.

Forward secrecy (achieved by generating new session keys for each message) ensures that past communications cannot be decrypted if one of the keys generated in an iteration of step 2 is compromised, since such a key is only used to encrypt a single message. Forward secrecy also ensures that past communications cannot be decrypted if the long-term private keys from step 1 are compromised. However, masquerading as Alice or Bob would be possible going forward if this occurred, possibly compromising all future messages.

Attacks

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 defend against a successful cryptanalysis of the underlying ciphers being used, since a cryptanalysis consists of finding a way to decrypt an encrypted message without the key, and forward secrecy only protects keys, not the ciphers themselves. [7] A patient attacker can capture a conversation whose confidentiality is protected through the use of public-key cryptography and wait until the underlying cipher is broken (e.g. large quantum computers could be created which allow the discrete logarithm problem to be computed quickly). This would allow the recovery of old plaintexts even in a system employing forward secrecy.

Non-interactive forward-secure key exchange protocols face additional threats that are not relevant to interactive protocols. In a message suppression attack, an attacker in control of the network may itself store messages while preventing them from reaching the intended recipient; as the messages are never received, the corresponding private keys may not be destroyed or punctured, so a compromise of the private key can lead to successful decryption. Proactively retiring private keys on a schedule mitigates, but does not eliminate, this attack. In a malicious key exhaustion attack, the attacker sends many messages to the recipient and exhausts the private key material, forcing a protocol to choose between failing closed (and enabling denial of service attacks) or failing open (and giving up some amount of forward secrecy). [8]

Non-interactive forward secrecy

Most key exchange protocols are interactive, requiring bidirectional communication between the parties. A protocol that permits the sender to transmit data without first needing to receive any replies from the recipient may be called non-interactive, or asynchronous, or zero round trip (0-RTT). [9] [10]

Interactivity is onerous for some applications—for example, in a secure messaging system, it may be desirable to have a store-and-forward implementation, rather than requiring sender and recipient to be online at the same time; loosening the bidirectionality requirement can also improve performance even where it is not a strict requirement, for example at connection establishment or resumption. These use cases have stimulated interest in non-interactive key exchange, and, as forward security is a desirable property in a key exchange protocol, in non-interactive forward secrecy. [11] [12] This combination has been identified as desirable since at least 1996. [13] However, combining forward secrecy and non-interactivity has proven challenging; [14] it had been suspected that forward secrecy with protection against replay attacks was impossible non-interactively, but it has been shown to be possible to achieve all three desiderata. [10]

Broadly, two approaches to non-interactive forward secrecy have been explored, pre-computed keys and puncturable encryption. [12]

With pre-computed keys, many key pairs are created and the public keys shared, with the private keys destroyed after a message has been received using the corresponding public key. This approach has been deployed as part of the Signal protocol. [15]

In puncturable encryption, the recipient modifies their private key after receiving a message in such a way that the new private key cannot read the message but the public key is unchanged. Ross J. Anderson informally described a puncturable encryption scheme for forward secure key exchange in 1997, [16] and Green & Miers (2015) formally described such a system, [17] building on the related scheme of Canetti, Halevi & Katz (2003), which modifies the private key according to a schedule so that messages sent in previous periods cannot be read with the private key from a later period. [14] Green & Miers (2015) make use of 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 a 0-RTT forward secure and replay-resistant key exchange implemented with puncturable encryption incurred significantly increased resource usage, but not so much as to make practical use infeasible. [19]

Weak perfect forward secrecy

Weak perfect forward secrecy (Wpfs) is the weaker property whereby when agents' long-term keys are compromised, the secrecy of previously established session-keys is guaranteed, but only for sessions in which the adversary did not actively interfere. This new notion, and the distinction between this and forward secrecy was introduced by Hugo Krawczyk in 2005. [20] [21] This weaker definition implicitly requires that full (perfect) forward secrecy maintains the secrecy of previously established session keys even in sessions where the adversary did actively interfere, or attempted to act as a man in the middle.

Protocols

Forward secrecy is present in several major protocol implementations, such as SSH and as an optional feature in IPsec (RFC 2412). Off-the-Record Messaging, a cryptography protocol and library for many instant messaging clients, as well as OMEMO which provides additional features such as multi-user functionality in such clients, both provide forward secrecy as well as deniable encryption.

In Transport Layer Security (TLS), cipher suites based on Diffie–Hellman key exchange (DHE-RSA, DHE-DSA) and elliptic curve Diffie–Hellman key exchange (ECDHE-RSA, ECDHE-ECDSA) are available. In theory, TLS could choose appropriate ciphers since SSLv3, but in everyday practice many implementations refused to offer forward secrecy or only provided it with very low encryption grade. [22] This is no longer the case with TLS 1.3, which ensures forward secrecy by leaving ephemeral Diffie–Hellman (finite field and elliptic curve variants) as the only remaining key exchange mechanism. [23]

OpenSSL supports forward secrecy using elliptic curve Diffie–Hellman since version 1.0, [24] with a computational overhead of approximately 15% for the initial handshake. [25]

The Signal Protocol uses the Double Ratchet Algorithm to provide forward secrecy. [26]

On the other hand, among popular protocols currently in use, WPA Personal did not support forward secrecy before WPA3. [27]

Use

Forward secrecy is seen as an important security feature by several large Internet information providers. Since late 2011, Google provided forward secrecy with TLS by default to users of its Gmail service, Google Docs service, and encrypted search services. [24] Since November 2013, Twitter provided forward secrecy with TLS to its users. [28] Wikis hosted by the Wikimedia Foundation have all provided forward secrecy to users since July 2014 [29] and are requiring the use of forward secrecy since August 2018.

Facebook reported as part of an investigation into email encryption that, as of May 2014, 74% of hosts that support STARTTLS also provide forward secrecy. [30] TLS 1.3, published in August 2018, dropped support for ciphers without forward secrecy. As of February 2019, 96.6% of web servers surveyed support some form of forward secrecy, and 52.1% will use forward secrecy with most browsers. [31]

At WWDC 2016, Apple announced that all iOS apps would need to use App Transport Security (ATS), a feature which enforces the use of HTTPS transmission. Specifically, ATS requires the use of an encryption cipher that provides forward secrecy. [32] ATS became mandatory for apps on January 1, 2017. [33]

The Signal messaging application employs forward secrecy in its protocol, notably differentiating it from messaging protocols based on PGP. [34]

See also

Related Research Articles

<span class="mw-page-title-main">Diffie–Hellman key exchange</span> Method of exchanging cryptographic keys

Diffie–Hellman (DH) key exchange is a mathematical method of securely exchanging cryptographic keys over a public channel and was one of the first public-key protocols as conceived by Ralph Merkle and named after Whitfield Diffie and Martin Hellman. DH is one of the earliest practical examples of public key exchange implemented within the field of cryptography. Published in 1976 by Diffie and Hellman, this is the earliest publicly known work that proposed the idea of a private key and a corresponding public key.

<span class="mw-page-title-main">HTTPS</span> Extension of the HTTP communications protocol to support TLS encryption

Hypertext Transfer Protocol Secure (HTTPS) is an extension of the Hypertext Transfer Protocol (HTTP). It uses encryption for secure communication over a computer network, and is widely used on the Internet. In HTTPS, the communication protocol is encrypted using Transport Layer Security (TLS) or, formerly, Secure Sockets Layer (SSL). The protocol is therefore also referred to as HTTP over TLS, or HTTP over SSL.

<span class="mw-page-title-main">Public-key cryptography</span> Cryptographic system with public and private keys

Public-key cryptography, or asymmetric cryptography, is the field of cryptographic systems that use pairs of related keys. Each key pair consists of a public key and a corresponding private key. Key pairs are generated with cryptographic algorithms based on mathematical problems termed one-way functions. Security of public-key cryptography depends on keeping the private key secret; the public key can be openly distributed without compromising security.

A key in cryptography is a piece of information, usually a string of numbers or letters that are stored in a file, which, when processed through a cryptographic algorithm, can encode or decode cryptographic data. Based on the used method, the key can be different sizes and varieties, but in all cases, the strength of the encryption relies on the security of the key being maintained. A key's security strength is dependent on its algorithm, the size of the key, the generation of the key, and the process of key exchange.

<span class="mw-page-title-main">Symmetric-key algorithm</span> Algorithm

Symmetric-key algorithms are algorithms for cryptography that use the same cryptographic keys for both the encryption of plaintext and the decryption of ciphertext. The keys may be identical, or there may be a simple transformation to go between the two keys. The keys, in practice, represent a shared secret between two or more parties that can be used to maintain a private information link. The requirement that both parties have access to the secret key is one of the main drawbacks of symmetric-key encryption, in comparison to public-key encryption. However, symmetric-key encryption algorithms are usually better for bulk encryption. With exception of the one-time pad they have a smaller key size, which means less storage space and faster transmission. Due to this, asymmetric-key encryption is often used to exchange the secret key for symmetric-key encryption.

In cryptography and computer security, a man-in-the-middle (MITM) attack, or on-path attack, is a cyberattack where the attacker secretly relays and possibly alters the communications between two parties who believe that they are directly communicating with each other, as the attacker has inserted themselves between the two parties.

Transport Layer Security (TLS) is a cryptographic protocol designed to provide communications security over a computer network. The protocol is widely used in applications such as email, instant messaging, and voice over IP, but its use in securing HTTPS remains the most publicly visible.

Articles related to cryptography include:

Cryptography, the use of codes and ciphers to protect secrets, began thousands of years ago. Until recent decades, it has been the story of what might be called classical cryptography — that is, of methods of encryption that use pen and paper, or perhaps simple mechanical aids. In the early 20th century, the invention of complex mechanical and electromechanical machines, such as the Enigma rotor machine, provided more sophisticated and efficient means of encryption; and the subsequent introduction of electronics and computing has allowed elaborate schemes of still greater complexity, most of which are entirely unsuited to pen and paper.

<span class="mw-page-title-main">Key exchange</span> Cryptographic method

Key exchange is a method in cryptography by which cryptographic keys are exchanged between two parties, allowing use of a cryptographic algorithm.

Multimedia Internet KEYing (MIKEY) is a key management protocol that is intended for use with real-time applications. It can specifically be used to set up encryption keys for multimedia sessions that are secured using SRTP, the security protocol commonly used for securing real-time communications such as VoIP.

<span class="mw-page-title-main">Cryptography</span> Practice and study of secure communication techniques

Cryptography, or cryptology, is the practice and study of techniques for secure communication in the presence of adversarial behavior. More generally, cryptography is about constructing and analyzing protocols that prevent third parties or the public from reading private messages. Modern cryptography exists at the intersection of the disciplines of mathematics, computer science, information security, electrical engineering, digital signal processing, physics, and others. Core concepts related to information security are also central to cryptography. Practical applications of cryptography include electronic commerce, chip-based payment cards, digital currencies, computer passwords, and military communications.

A cipher suite is a set of algorithms that help secure a network connection. Suites typically use Transport Layer Security (TLS) or its deprecated predecessor Secure Socket Layer (SSL). The set of algorithms that cipher suites usually contain include: a key exchange algorithm, a bulk encryption algorithm, and a message authentication code (MAC) algorithm.

Post-quantum cryptography (PQC), sometimes referred to as quantum-proof, quantum-safe, or quantum-resistant, is the development of cryptographic algorithms that are thought to be secure against a cryptanalytic attack by a quantum computer. The problem with popular algorithms currently used in the market is that their security relies on one of three hard mathematical problems: the integer factorization problem, the discrete logarithm problem or the elliptic-curve discrete logarithm problem. All of these problems could be easily solved on a sufficiently powerful quantum computer running Shor's algorithm or even faster and less demanding alternatives.

wolfSSL is a small, portable, embedded SSL/TLS library targeted for use by embedded systems developers. It is an open source implementation of TLS written in the C programming language. It includes SSL/TLS client libraries and an SSL/TLS server implementation as well as support for multiple APIs, including those defined by SSL and TLS. wolfSSL also includes an OpenSSL compatibility interface with the most commonly used OpenSSL functions.

In cryptography, a padding oracle attack is an attack which uses the padding validation of a cryptographic message to decrypt the ciphertext. In cryptography, variable-length plaintext messages often have to be padded (expanded) to be compatible with the underlying cryptographic primitive. The attack relies on having a "padding oracle" who freely responds to queries about whether a message is correctly padded or not. The information could be directly given, or leaked through a side-channel.

The YAK is a public-key authenticated key-agreement protocol, proposed by Feng Hao in 2010. It is claimed to be the simplest authenticated key exchange protocol among the related schemes, including MQV, HMQV, Station-to-Station protocol, SSL/TLS etc. The authentication is based on public key pairs. As with other protocols, YAK normally requires a Public Key Infrastructure to distribute authentic public keys to the communicating parties. The security of YAK is disputed.

s2n Open-source implementation of TLS

s2n is an open-source C99 implementation of the Transport Layer Security (TLS) protocol developed by Amazon Web Services (AWS) and released in 2015. It was developed to ensure the code—about 6,000 lines long—would be easier to review than that of OpenSSL—with 500,000 lines, 70,000 of which are involved in processing TLS.

In cryptography, the Double Ratchet Algorithm is a key management algorithm that was developed by Trevor Perrin and Moxie Marlinspike in 2013. It can be used as part of a cryptographic protocol to provide end-to-end encryption for instant messaging. After an initial key exchange it manages the ongoing renewal and maintenance of short-lived session keys. It combines a cryptographic so-called "ratchet" based on the Diffie–Hellman key exchange (DH) and a ratchet based on a key derivation function (KDF), such as a hash function, and is therefore called a double ratchet.

Application Layer Transport Security (ALTS) is a Google-developed authentication and transport encryption system used for securing Remote Procedure Call (RPC) within Google machines. Google started its development in 2023, as a tailored modification of TLS.

References

  1. ↑ "tls - Does Perfect Forward Secrecy (PFS) make Man-in-the-Middle (MitM) attacks more difficult?". Information Security Stack Exchange. Retrieved 2020-10-11.
  2. ↑ Günther, C. G. (1990). An identity-based key-exchange protocol. Advances in Cryptology EUROCRYPT '89 (LNCS 434). pp. 29–37.
  3. ↑ Menzies, Alfred; van Oorscot, Paul C; Vanstone, SCOTT (1997). Handbook of Applied Cryptography . CRC Pres. ISBN   978-0-8493-8523-0.
  4. ↑ Diffie, Whitfield; van Oorschot, Paul C.; Wiener, Michael J. (June 1992). "Authentication and Authenticated Key Exchanges" (PDF). Designs, Codes and Cryptography. 2 (2): 107–125. CiteSeerX   10.1.1.59.6682 . doi:10.1007/BF00124891. S2CID   7356608 . Retrieved 2013-09-07.
  5. ↑ Jablon, David P. (October 1996). "Strong Password-Only Authenticated Key Exchange". ACM Computer Communication Review. 26 (5): 5–26. CiteSeerX   10.1.1.81.2594 . doi:10.1145/242896.242897. S2CID   2870433.
  6. ↑ "IEEE 1363-2000 - IEEE Standard Specifications for Public-Key Cryptography". standards.ieee.org. Retrieved 2018-06-14.
  7. ↑ Nilsson, Dennis K.; Roosta, Tanya; Lindqvist, Ulf; Valdes, Alfonso (2008-03-31). "Key management and secure software updates in wireless process control environments". Proceedings of the first ACM conference on Wireless network security. WiSec '08. Alexandria, VA, USA: Association for Computing Machinery. pp. 100–108. doi:10.1145/1352533.1352550. ISBN   978-1-59593-814-5. S2CID   15382932.
  8. ↑ Boyd & Gellert 2020, p. 645.
  9. ↑ Boyd & Gellert 2020, p. 639-640.
  10. 1 2 Günther et al. 2017, p. 1.
  11. ↑ Boyd & Gellert 2020, p. 640.
  12. 1 2 Boyd & Gellert 2020, p. 643.
  13. ↑ Back 1996.
  14. 1 2 Green & Miers 2015, p. 1.
  15. ↑ Boyd & Gellert 2020, p. 644-645.
  16. ↑ Anderson 2002.
  17. ↑ Boyd & Gellert 2020, p. 643-644.
  18. ↑ Günther et al. 2017, p. 5.
  19. ↑ Dallmeier et al. 2020, p. 18-19.
  20. ↑ Krawczyk, Hugo (2005). HMQV: A High-Performance Secure Diffie-Hellman Protocol. Advances in Cryptology – CRYPTO 2005. Lecture Notes in Computer Science. Vol. 3621. pp. 546–566. doi: 10.1007/11535218_33 . ISBN   978-3-540-28114-6.
  21. ↑ Cremers, Cas; Feltz, Michèle (2015). "Beyond eCK: perfect forward secrecy under actor compromise and ephemeral-key reveal" (PDF). Designs, Codes and Cryptography. 74 (1): 183–218. CiteSeerX   10.1.1.692.1406 . doi:10.1007/s10623-013-9852-1. hdl:20.500.11850/73097. S2CID   53306672 . Retrieved 8 December 2015.
  22. ↑ Discussion on the TLS mailing list in October 2007
  23. ↑ "A Detailed Look at RFC 8446 (a.k.a. TLS 1.3)". The Cloudflare Blog. 2018-08-10. Retrieved 2019-02-26.
  24. 1 2 "Protecting data for the long term with forward secrecy" . Retrieved 2012-11-05.
  25. ↑ Vincent Bernat (28 November 2011). "SSL/TLS & Perfect Forward Secrecy" . Retrieved 2012-11-05.
  26. ↑ Unger, Nik; Dechand, Sergej; Bonneau, Joseph; Fahl, Sascha; Perl, Henning; Goldberg, Ian; Smith, Matthew (17–21 May 2015). "SoK: Secure Messaging". 2015 IEEE Symposium on Security and Privacy (PDF). San Jose, CA: Institute of Electrical and Electronics Engineers. p. 241. doi:10.1109/SP.2015.22. ISBN   978-1-4673-6949-7. S2CID   2471650 . Retrieved 4 December 2015.
  27. ↑ "Wi-Fi Gets More Secure: Everything You Need to Know About WPA3 - IEEE Spectrum". spectrum.ieee.org. Retrieved 2024-05-04.
  28. ↑ Hoffman-Andrews, Jacob. "Forward Secrecy at Twitter". Twitter. Retrieved 25 November 2013.
  29. ↑ "Tech/News/2014/27 - Meta". Wikimedia Foundation. 2014-06-30. Retrieved 30 June 2014.
  30. ↑ "The Current State of SMTP STARTTLS Deployment". Facebook . Retrieved 7 June 2014.
  31. ↑ Qualys SSL Labs. "SSL Pulse". Archived from the original (3 February 2019) on 15 February 2019. Retrieved 25 February 2019.
  32. ↑ "iOS 9.0".
  33. ↑ "App Transport Security REQUIRED January 2017 | Apple Developer Forums". forums.developer.apple.com. Retrieved 2016-10-20.
  34. ↑ Evans, Jon (22 January 2017). "WhatsApp, Signal, and dangerously ignorant journalism". TechCrunch . Retrieved 18 April 2018.

Bibliography

This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.