antecipate: Protecting identities with XOR

When the average user speaks of security, encryption often comes first in the conversation. While encryption is an important component of security, it only deals with a subset of the challenges inherent to communications security. This is missing the bigger picture. Cryptology covers primarily the confidentiality of transmitted data, while the identities of the communicating parties remain unprotected. On the Internet, this shortcoming has been addressed by a technology called “onion routing” (OR). OR as a technology has been around to provide anonymous communication for some time. TOR, its second generation, is adding perfect forward secrecy, congestion control, directory servers, integrity checking, configurable exit policies to the original design, while avoiding infringing patented patterns used in the original design.

Onion Routing is a distributed overlay network designed to anonymize TCP-based applications like web browsing, secure shell, and instant messaging. Clients choose a path through the network and build a circuit, in which each node (or “onion router” or “OR”) in the path knows its predecessor and successor, but no other nodes in the circuit. Traffic flows down the circuit in fixed-size cells, which are unwrapped by a symmetric key at each node (like the layers of an onion) and relayed downstream.

I have been toying with the idea of applying the principles of OR to XMPP at the protocol level to provide end to end anonymity of conversations. I am presenting the overview of how XOR (XMPP Onion Routing) could be implemented on top of XMPP. TOR enhance the original OR design of layered cryptographic payloads by introducing “telescoping circuits”. This type of circuit allows an initiator to negotiate a short-lived session key with each successive node along a path, and use this key to encrypt the onion layers. Diffie-Hellman is used for key exchange. The "telescoping circuit" model brings two important benefits on top of forward secrecy. First, it allows multiplexing multiple conversations over a single circuit, letting the initiator to set up a single long lived path across the Onion Routing network, which can be use to access multiple destinations. Second, it allows “leaky pipe” routing. Any node along the path is a candidate exit point, making traffic analysis particularly difficult. Individual Onion Routers can be configured as exit nodes, and the type of traffic they will allow to exit specified.

The Tor network is an overlay network; each onion router (OR) runs as a normal user-level process without any special privileges. Each onion router maintains a TLS connection to every other onion router. Each user runs local software called an onion proxy (OP) to fetch directories, establish circuits across the network, and handle connections from user applications. These onion proxies accept TCP streams and multiplex them across the circuits. The onion router on the other side of the circuit connects to the requested destinations and relays data.

Applying this model to XMPP is easy. The XOR network is an overlay network, implemented using XMPP S2S connectivity. Each XOR router will use a TLS connection to reach every other XOR router participating in the overlay network. XOR will require an extension to the protocol to allow a XOR client to discover XOR support, and browse the overlay network nodes directory. XOR clients and nodes should use JEP-0116 encrypted sessions as the base mechanism to establish the “telescoping circuit” layers along the chosen path. XOR nodes will accept XMPP stanzas streams and multiplex them across the circuits. The XOR node at the other end of the circuit connects to the requested destination and relays the stanzas.

Instead of taking a direct route from source to destination, data packets on the Tor network take a random pathway through several servers that cover your tracks so no observer at any single point can tell where the data came from or where it's going. To create a private network pathway with Tor, the user's software or client incrementally builds a circuit of encrypted connections through servers on the network. The circuit is extended one hop at a time, and each server along the way knows only which server gave it data and which server it is giving data to. No individual server ever knows the complete path that a data packet has taken. The client negotiates a separate set of encryption keys for each hop along the circuit to ensure that each hop can't trace these connections as they pass through.

In the now traditional Shakespearian way, When Juliet wants to have a secure and anonymous conversation with Romeo, she will chose a random path between the capulet.net and the montague.com server from the retrieved XOR directory information. She will then negotiate an ephemeral session key with each XOR node along the path, including Romeo's client. She will then build all the onion layers to encapsulate her message and deliver it to her own XOR server. Each XOR node on the path will peel off its own layer, decrypting it with the ephemeral key negotiated with Juliet, and route the remaining layers to the next node. Upon receiving Juliet's stanza, Romeo will be able to build its own “telescoping circuit” to respond to Juliet. This circuit will use a randomly chosen path to Juliet's client, which will be different from path taken by Juliet's stanza to reach him.

As stated at the beginning, this is an overview of how the OR model can be applied to provide anonymous conversations on top of XMPP. I believe this technique added to the encrypted sessions negotiation will provide additional protection of the identities involved in a particular conversation.