7

I just read about ECDH and while getting a overview over the process, I noticed that this key exchange method does neither provide any forward secrecy, nor does it protect against replay-attacks, because the shared secret will be the same for each session. Are there any common methods that extend ECDH to support these security features?

Tom Leek
  • 170,038
  • 29
  • 342
  • 480
cooky451
  • 193
  • 1
  • 5

1 Answers1

14

To get Perfect Forward Secrecy, you have to use ephemeral keys.

With static Diffie-Hellman (elliptic curve or not, that's not the issue), Alice and Bob both own a DH key pair: Alice's private key is a, public key is aG (elliptic curve notation, G is the conventional "base point" for the curve); Bob's private key is b, public key is bG. When Alice and Bob want to talk to each other, they do the DH thing, which means that they end up with the shared secret value abG. They always have this exact shared secret. If an attacker manages to steals Alice's private key (a), then he can recompute the shared secret, and thus decrypt all past and future conversations between Alice and Bob.

Ephemeral Diffie-Hellman is about generating DH key pairs "on the fly" and not recording private keys anywhere (the private keys are kept in RAM only, and for the duration of the conversation only). Never being recorded ought to make these private keys immune from ulterior theft; that's where PFS comes from. This is used in SSL/TLS with the "DHE" (and "ECDHE") cipher suites: the server owns a private/public key pair, with the public key being in a certificate, and fit for signatures (e.g. that key pair is of type RSA or DSA). When a client connects, both client and server generates new DH key pairs; the server signs his newly generated DH public key with its signature key (the client verifies that signature and validates the server certificate). The key which is actually used to encrypt the data is the one derived from the Diffie-Hellman algorithm.

With DHE cipher suites, should the server's private key be stolen, then the thief only gains the power to compute forged signatures. The thief may then impersonate the server and endanger future communications by running a Man-in-the-Middle attack, but past connections were encrypted with regards to DH keys which have long been lost, and thus won't be decrypted by the attacker. That's PFS.

Community
  • 1
Tom Leek
  • 170,038
  • 29
  • 342
  • 480
  • *This is used in SSL/TLS with the "DHE" (and "ECDHE") cipher suites* - Do the DHE/ECDHE ciphers mean "PFS, always", or are they required but not sufficient - i.e. PFS is an option on top of those ciphers? I keep finding texts like yours saying PFS *requires* ephemeral key exchange, and then the rest of the text implies that ephemeral key exchange *is* PFS... – TessellatingHeckler Jan 31 '17 at 23:57
  • @TessellatingHeckler DHE and ECDHE are a form of key exchange, allowing two devices to exchange a secret key over a public network where people are assumed to be eavesdropping. Once the key is exchange both parties can save the key and use it in further sessions. The ephemeral bit is the two parties do not save the key. Instead for future connections they use DHE and ECDHE to set up a new secret key to use just for that session. Past session keys are deleted, not stored and reused. – elwhite Aug 22 '18 at 15:59