Perfect Forward Secrecy in M2M Communication


Figure 1: Node F eavesdrops on secure communication between nodes P and S

Perfect Forward Secrecy (PFS) is a well understood property of cryptographic protocols. It ensures that a session key SK derived from a long-term public and private key pair (PuK and PrK, the former typically embedded in a digital certificate) will not be compromised if the private key PrK is recovered in the future.

For example, a widely used client/server key agreement mechanism implemented in TLS requires the client node (P in Figure 1) to generate a random pre-master secret, which is encrypted using the server’s public key PuK, before being sent to the server (S in Figure 1). This allows the server to recover the pre-master secret and subsequently both sides to calculate the same session key, which is then used for the (symmetric) encryption of network traffic. However, if a third party (F in Figure 1) logs the entire data communication between both sides and is later able to recover the server’s private key PrK (via brute force, cryptanalysis, court order etc.), the pre-master secret, the session key and consequently the entire encrypted data communication can be retrospectively recovered. In other words perfect forward secrecy is not provided.

PFS can be achieved via a different key exchange protocol, e.g. Diffie–Hellman (DH) or Elliptic curve Diffie–Hellman (ECDH). Both methods do not require the exchange of a pre-master secret to agree on a session key.
But even though these key exchange mechanisms have already been adopted in many major cryptographic protocols including TLS, SSH and IPSec, they are not widely used in secure Internet data communication yet.

There are 2 reasons for this:

  1. PFS comes at a price, as it extends the session key negotiation phase of the cryptographic protocol.
  2. The recovery of a private key PrK by a third party is seen as a rather hypothetical scenario.

However, recent revelations about the widespread capture and storage of encrypted network communication (for later cryptanalysis) by some government agencies brings PFS back into the spotlight. And while the recovery of private key material might still not be feasible yet, concerned users and organisations want to see PFS adopted in their secure data communication.

What are the implications for M2M communication?

PFS should be the default for secure M2M communication, regardless of the type of data being transmitted and regardless of how feasible (or not) the recovery of private key material is.
DH and ECDH are computationally expensive, which is a particular concern for resource constraint embedded systems, but PFS is a fundamental building block of trust. Security in distributed embedded systems can potentially be a leaky bucket (if not properly implemented), so it is essential to plug all potential holes upfront.

Did I already mention that the OSNA authentication protocol has PFS by default?

Speak Your Mind


This site uses Akismet to reduce spam. Learn how your comment data is processed.