When a device connects to a server for the first time, they usually do not already share a session key. They need to agree on a symmetric key over an open network.
This is often compressed into: “Use ECDH to compute a key.”
That skips two important boundaries. ECDH/X25519 produces a shared secret, not the final key to feed into AES-GCM. And the whole path depends on randomness and context binding.
A more complete path is:
local ephemeral private key + peer public key
-> ECDH/X25519
-> shared secret
-> HKDF/KDF with salt, info, and handshake context
-> send key, receive key, nonce base
-> AEAD protects application data
Key exchange, KDF, and randomness solve different problems.
Key Exchange Lets Both Sides Derive the Same Secret
ECDH and X25519 let two peers compute the same shared secret without sending that secret directly.
Simplified model:
device private key a + server public key B -> shared secret S
server private key b + device public key A -> shared secret S
An observer sees public keys but not private keys, so they cannot directly compute S.
This solves a core open-network problem: peers do not have a pre-shared session key, but want secret material for later communication.
But S is usually not a final key. It is raw shared secret material that must go through a KDF.
Shared Secret Is Not a Direct Key
Putting ECDH output directly into AES or HMAC is a common mistake.
Reasons include:
- raw shared secret format and length may not fit the target algorithm
- different purposes need different keys
- protocol context must be bound in
- handshake transcript should affect key derivation
- send and receive directions need separation
- the same secret material should not be reused for multiple purposes
KDF turns raw secret material into purpose-separated key material.
shared secret
-> KDF
-> client_write_key
-> server_write_key
-> iv / nonce base
-> exporter key
This is why protocols such as TLS do not use ECDH output directly.
HKDF Turns Secret Material Into Context-Bound Keys
HKDF is a common KDF. It can be understood as two stages:
Extract: mix raw secret and salt into a pseudorandom key
Expand: derive output of specific length and purpose using info
Where:
salthelps normalize the input secretinfobinds the output to usage and context- output length depends on the specific purpose
info is important. It can include:
- protocol version
- handshake transcript hash
- device and server roles
- direction of use
- cipher suite
- session ID
- application usage label
The derived key is not just bytes. It is bound to this protocol, this session, and this use.
Randomness Decides Whether Ephemeral Keys Are Really Ephemeral
Key exchange usually needs ephemeral private keys. Those keys must come from reliable randomness.
If randomness fails, consequences are severe:
- ephemeral private keys repeat, reusing session secrets
- private keys become predictable
- many devices generate the same key during manufacturing
- early-boot entropy is insufficient
- factory reset regenerates old keys
IoT devices are especially prone to RNG problems. At early boot, the network may not be connected, there is no user input, peripherals may not provide enough noise, and the system may not have collected enough entropy.
Security systems must not generate long-term keys or ephemeral handshake keys before RNG is ready. If the secret is bad, the rest of the algorithm stack is running on bad material.
Separate Long-Term Keys From Session Keys
Devices often have long-term identity keys: a device private key, PSK, PUF-derived key, or secure-element key.
Those long-term keys should not encrypt bulk data directly.
A safer model is:
long-term key: identity authentication or key agreement
session key: data protection for this connection
Separation gives:
- session keys can be discarded when the session ends
- each connection uses different keys and nonce spaces
- long-term keys have smaller exposure
- forward secrecy becomes possible
- different directions and purposes can use different keys
In TLS, for example, certificate private keys mainly authenticate identity. Application data is encrypted with keys derived after the handshake.
Forward Secrecy Depends on Ephemeral Keys
Forward secrecy means that even if a long-term identity key leaks later, past completed sessions should not be decryptable.
It usually depends on ephemeral ECDH:
generate ephemeral key pair for each session
-> use ephemeral private key for key exchange
-> destroy ephemeral private key and session keys after session
If a system encrypts data directly with a long-term key, or reuses long-term ECDH keys, later key leakage may expose historical traffic.
Resource-constrained devices may trade performance, power, and forward secrecy. But that tradeoff must be explicit. Public-key cryptography alone does not automatically provide forward secrecy.
PSK Also Needs KDF and Context
Some devices use pre-shared keys instead of certificates.
PSK does not mean “use this as the AEAD key directly”. A safer pattern is:
PSK + nonce/challenge/session context
-> KDF
-> session keys
The reasons are the same: separate uses, bind context, and avoid putting the long-term key directly on the bulk data path.
PSK designs need special care:
- whether every device has its own PSK
- whether the server can identify the correct PSK by device
- what the blast radius is if PSK leaks
- whether replay protection exists
- whether key rotation is supported
- whether the same PSK is reused across protocols
One PSK shared by all devices is dangerous. One compromised device can affect the whole fleet.
KDF info Is Not Filler
KDF info is sometimes set to empty or "key". That discards useful context.
Better practice is to encode purpose:
info = "iot-v1 client write key"
info = "iot-v1 server write key"
info = "firmware encryption key"
info = "device attestation session"
Different purposes should derive different keys. Do not use one key for:
- encryption
- MAC
- firmware decryption
- log authentication
- device authentication
Key reuse lets a weakness in one use affect another. One purpose of KDF is to expand one root secret into isolated usage keys.
Debugging Order
For handshake failures, mismatched session keys, reboot-only communication failures, or repeated fleet keys, inspect:
is randomness ready
-> is ephemeral private key generated fresh every time
-> are ECDH/X25519 peer public keys validated as required
-> does shared secret go through KDF
-> do salt/info bind protocol context
-> are send and receive keys separated
-> does AEAD nonce space reset only with new session key
-> is the long-term key used only for identity or agreement
-> is PSK unique per device
If the problem appears at early boot, factory reset, manufacturing, or low-entropy environments, inspect RNG and key generation timing first.
The Boundary to Remember
Key exchange, KDF, and randomness form a chain.
ECDH/X25519 lets peers derive the same raw secret. KDF turns that secret into purpose-, direction-, and context-separated session keys. Randomness makes ephemeral keys, nonces, and challenges unpredictable and non-repeating.
The dangerous shortcut is “compute a key and encrypt”. A reliable device security design separates long-term keys, ephemeral keys, shared secrets, session keys, and nonce state.