GNU ZRTP: Media Encryption Architecture

In conventional VoIP systems, call signaling is handled by SIP, while audio/video payloads are carried over RTP. Standard attempts to encrypt VoIP often suffered from fatal architectural flaws:

1. SIP Signaling Vulnerability: Many protocols (such as SDES, RFC 4568) placed the SRTP encryption keys in the SIP SDP (Session Description Protocol) message. Because SIP messages pass through SIP proxies, PBX servers, and corporate routers, anyone with access to an intermediate SIP proxy could intercept the cleartext master key and decrypt the call. 2. The PKI Vulnerability: Systems requiring X.509 digital certificates or public-key authorities required centralized certificate authorities (CAs). Centralized CAs are subject to government coercion, compromised private keys, and man-in-the-middle attacks.

ZRTP bypassed both traps: - In-Band Negotiation: ZRTP performs an ephemeral Diffie-Hellman key exchange directly within the RTP media channel after the call is established. - No Central PKI Required: To defeat Man-in-the-Middle (MitM) eavesdroppers who might intercept the Diffie-Hellman exchange, ZRTP uses a Short Authentication String (SAS). The users verbally read a 4-character phonetic code (or two PGP phonetic words) aloud to each other over the voice connection.

The SAS is derived by hashing the cryptographic session exchange values:

Alice                         Bob
  |                            |
  |--- ZRTP Hello ------------>|
  |<-- ZRTP Hello -------------|
  |                            |
  |--- Commit (DH-2048) ------>|
  |<-- DHPart1 ----------------|
  |--- DHPart2 --------------->|
  |                            |
  |=== Compute Shared Key =====|
  |=== Compute 4-char SAS =====|
  |                            |
  |-- "SAS: Echo-Foxtrot" ---->| (Vocal exchange over audio)
  |                            |
  |--- Confirm1 (MAC) -------->|
  |<-- Confirm2 (MAC) ---------|
  |                            |
  |==== SRTP Audio Encrypted ==|

If an active attacker (e.g., an intelligence agency or rogue ISP) intercepts the connection and runs two separate Diffie-Hellman exchanges, the attacker cannot make their hash outputs match the endpoints without solving the discrete logarithm problem. Consequently, Bob and Alice will calculate different SAS values. When Alice speaks her SAS code, Bob immediately detects the mismatch and terminates the call.

Furthermore, ZRTP implements Key Continuity. After the first call, both endpoints securely cache a shared secret (retained secret). On subsequent calls, this secret is factored into the key derivation, protecting even against future MitM attempts where the users might forget to verify the SAS.

GNU ZRTP was built as an extension to `ccrtp`. By sub-classing `ZrtpQueue`, applications could activate cryptographic state machines with minimal boilerplate:

// Historical example: initializing ZRTP over a ccRTP socket
#include <ccrtp/rtp.h>
#include <libzrtpcpp/ZrtpQueue.h>

class SecureCallSession : public ost::TRTPSession<ost::DualSocketHost> { public: SecureCallSession(const InetHostAddress& host, tport_t port) : TRTPSession<DualSocketHost>(host, port) { // Attach ZRTP processor zrtpContext = new ZrtpQueue(); enableZRTP(zrtpContext); } void onZrtpSecureOn(const std::string& cipher, const std::string& sas) { std::cout << "[SECURITY] Session encrypted with " << cipher << std::endl; std::cout << "[SECURITY] Verify SAS with peer: " << sas << std::endl; } }; ```

GNU SIP Witch leveraged this capability to enforce secure media policies: if an incoming or forwarded call could not negotiate ZRTP, the administrator could configure the daemon to drop the call or trigger an audible warning beep.