Anonymity on the internet is an interesting problem, for which several
different solutions have been implemented (e.g. Tor, Freenet). Creating
such a network is an
interesting exercise for one thing, but using one is also highly useful to
avoid various kinds of internet activity monitoring. While people in
relatively free countries may find it useful to avoid their ISP and
government's monitoring, activists and others living under more repressive
regimes may find it to be much more than that—in some cases, it could
make a life-or-death difference. Phantom is another mechanism
for providing internet anonymity that has a number of interesting properties.
The Phantom protocol was introduced at DEFCON 16 in 2008 by Magnus
[PPT]) and is designed to provide decentralized anonymity. The idea is
that there is no central weak point that can be shut down or attacked to
stop the use of Phantom. It also requires end-to-end encryption, unlike
Tor and others, so that there is no "exit node"
problem, where a compromised or malicious participant can eavesdrop on
the communication. In addition, Phantom is designed for higher performance
so that large data volumes can be transferred through the network.
One of the most interesting aspects of Phantom is that it requires no
changes to existing internet applications. From the perspective of a web
browser or other application, it is just using standard-looking IP
addresses. In reality, those addresses are Anonymous Protocol (AP)
addresses that are handled by the Phantom software. One of the assumptions
that Phantom makes is that IP addresses can be mapped to real-life
identities (a very sensible assumption), so one of the major goals is to
ensure that those cannot leak.
While the internet is used to carry all of the Phantom traffic, that
traffic is virtually partitioned from the rest of the internet. Service
providers that want to enable anonymous access to their services (e.g. a
web server) have to register that service within the Phantom network.
Obviously, that registry could be a problem from a decentralization
standpoint, but Phantom uses a distributed hash
table (DHT) to contain the information. Various large-scale
implementations of DHTs, like Kademlia that was used by the eMule
peer-to-peer system, are already in existence.
The DHT is known as the "network database" and contains two separate
tables. One lists the IP addresses, ports, and properties of the currently
nodes in the network, while the other has the AP addresses and properties
of connected and registered nodes. The two tables are, obviously, not
directly correlated as that would defeat the whole purpose. In order to
get a "copy" of
the DHT, a new node just needs to contact one existing node and join into
the distributed database. Lists of valid IP addresses to connect to could
come via nearly any mechanism: web sites, email, or even distributed on
pieces of paper. If even one of the listed nodes is still valid, a new node
can use it to join in.
A client that wants to communicate on the network must set up its own exit
node. It does so by choosing a number of other nodes in the network with
which to establish a routing path, the last one of which is the exit node.
Unlike Tor, there isn't an established set of exit nodes as any system
participating in the network can potentially be an exit node. Also unlike
Tor, it is the endpoint that chooses its routing path, rather than the network
making those decisions. There is a detailed description of
the protocol for establishing a routing path in the Phantom
design white paper [PDF]. Each step along the path is encrypted using
SSL and the paper shows the details of the complicated process of
creating the exit node.
Similarly, any services on the network need to create a routing path to an
"entry node". In some cases, where the service itself does not require
anonymity but wants to provide access for anonymous clients, the entry node
may be the server itself. In any case, services register their AP-to-IP
address mapping in the DHT using the IP address of the entry node. For services
that do wish to remain anonymous, they will still be hidden behind
the routing path from that entry node.
Furthermore, nodes create routing tunnels between themselves and their exit
or entry node. These tunnels are under the control of the endpoints, not
the network or any intermediary (including entry/exit) nodes. Making a
connection is then a process of connecting the two routing tunnels together
with the exit node of the client connecting to the entry node of the
server. These tunnels are bi-directional, and encrypted in such a way that
the intermediaries cannot decrypt the traffic, nor can a man-in-the-middle
interfere with the communication without detection.
One of the important properties of the system is that nodes do not know
whether they are talking to an endpoint or just another node in a routing
path. The routing paths themselves can be arbitrarily long, and could even
be chained together to provide further isolation as desired.
While the whole scheme seems fiendishly complex, it has been implemented
Johannes Schlumberger as part of his Masters Degree work. Performance is,
to be reasonable: "maxing out a 100 Mb/s network connection for data
transfers over multi-hop Phantom routing tunnels, so the crypto overhead
does not seem to be significant at all". The code is available under the Hacktivismo Enhanced-Source
Software License Agreement (HESSLA), which seems to be a GPL-inspired
license with some additional "political" objectives. Based on the README,
the implementation uses a tun virtual network device
and may be fairly complicated to set up.
Overall, Phantom looks very interesting. Like Tor and others, though, it
requires a fairly large number of participating nodes in order to truly be
of use. One of the biggest barriers for Tor has been that exit nodes get
blamed for the behavior of the traffic that emanates from them. Since that
traffic can't be traced further back than the exit nodes (at least
hopefully), any criminal or
malicious traffic is associated with whoever runs the Tor node. Because
services will have to specifically enable anonymous access for Phantom,
that may be less of a problem. It may also make Phantom adoption less
It's a bit difficult to see widespread adoption of Phantom (or any of the
other anonymous network protocols), though the Electronic Frontier
Foundation has been pushing Tor
adoption recently. Some kind of solution is clearly needed but, so far,
the logistical and legal hurdles seem to be too large for many to overcome.
Unfortunately, anonymous networks may fall into the category of "things
that are not set up
until it's too late". But it is good to see that people are still thinking
about, and working on, this problem.
to post comments)