ECDH with Static Keys: Is it Secure?

TL;DR

Using ECDH with a static public key and parameters is not recommended for secure communication. While technically possible, it severely weakens the security of your system and makes it vulnerable to attacks. Always generate fresh ephemeral (temporary) keys for each session.

Why Static Keys are Problematic

Elliptic-Curve Diffie-Hellman (ECDH) relies on the secrecy of the private key. If an attacker obtains your public key, they can potentially compromise past and future communications if you reuse it. Here’s a breakdown:

• Key Compromise: If your static private key is ever compromised, all sessions using that public key are immediately decryptable.
• Passive Attacks: An attacker can passively record encrypted traffic and attempt to decrypt it later if they manage to obtain the private key.
• Man-in-the-Middle (MITM) Attacks: While ECDH itself prevents MITM attacks when used correctly, a static public key makes it easier for an attacker to intercept and manipulate communications.

Step-by-Step Explanation of the Risks

1. ECDH Basics: ECDH involves two parties (Alice and Bob) generating private keys and deriving corresponding public keys. They exchange public keys, and each uses their own private key and the other’s public key to compute a shared secret.
2. Static Key Scenario: If Alice always uses the same public key, an attacker can intercept that single public key.
3. Attacker’s Advantage: The attacker now has one piece of information needed for decryption (Alice’s public key). If they can obtain Alice’s private key through other means (e.g., phishing, malware), they can decrypt all past and future communications using that key pair.

Secure ECDH: Using Ephemeral Keys

The correct way to use ECDH is with ephemeral keys – meaning a new key pair is generated for each session. This significantly improves security.

1. Key Generation per Session: Each time Alice wants to communicate, she generates a fresh private/public key pair.
2. Exchange and Shared Secret: She exchanges the public key with Bob, and they compute a shared secret as usual.
3. Limited Exposure: If an attacker intercepts Alice’s public key, it’s only useful for that single session. The private key is never reused, so compromising the public key doesn’t compromise past or future sessions.

Example using OpenSSL (Illustrative)

This example shows how to generate an ECDH key pair and compute a shared secret. Note that this does not demonstrate proper session management; it’s for illustration only.

Generating Keys

openssl ecparam -name prime256v1 -genkey -noout -out alice_private.pem

This generates a private key using the prime256v1 curve and saves it to alice_private.pem.

Deriving Public Key

openssl ec -in alice_private.pem -pubout -out alice_public.pem

This extracts the public key from the private key and saves it to alice_public.pem.

Computing Shared Secret (Bob’s side)

Assuming Bob also has a key pair, he would use Alice’s public key to compute the shared secret:

openssl ec -in bob_private.pem -pubin -in alice_public.pem -out shared_secret

Best Practices

• Always Use Ephemeral Keys: Implement a mechanism to generate new key pairs for each communication session.
• Key Exchange Protocols: Use established key exchange protocols like TLS 1.3 or SSH, which handle ephemeral key generation and secure key exchange automatically.
• Perfect Forward Secrecy (PFS): Ensure your chosen protocol supports PFS, meaning that even if a server’s private key is compromised, past sessions remain secure.
• Regular Key Rotation: Even with ephemeral keys, consider rotating session keys frequently for added security.