LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Announcements
->One big page
This page
Previous weekFollowing week
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
SecurityPhantom: Decentralized anonymous networkingAnonymity 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 Bråding (slides [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 connected 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 [PDF] by Johannes Schlumberger as part of his Masters Degree work. Performance is, perhaps surprisingly, said 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 likely. 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.
Brief items Security quotes of the week
The possible impact on elections using optical scan ballots is more
mixed. One positive use is to detect ballot box stuffing---our methods
could help identify whether someone replaced a subset of the legitimate
ballots with a set of fraudulent ballots completed by herself. On the other
hand, our approach could help an adversary with access to the physical
ballots or scans of them to undermine ballot secrecy. Suppose an
unscrupulous employer uses a bubble form employment application. That
employer could test the markings against ballots from an employee's
jurisdiction to locate the employee's ballot.
-- Will
Clarkson reports on research showing that "bubble forms" may not provide their
presumed anonymity
RSA Security Chairman Art Coviello said that the reason RSA had not
disclosed the full extent of the vulnerability because doing so would have
revealed to the hackers how to perform further attacks. RSA's customers
might question this reasoning; the Lockheed Martin incident suggests that
the RSA hackers knew what to do anyway—failing to properly disclose the
true nature of the attack served only to mislead RSA's customers about the
risks they faced.
-- Peter
Bright in ars technica about the cracking of RSA's SecurID
New vulnerabilities couchdb: cross site scripting
drupal: multiple vulnerabilities
fetchmail: denial of service
flash-plugin: cross-site scripting
java: multiple vulnerabilities
libxml2: arbitrary code execution
oprofile: command injection/privilege escalation
phpMyAdmin: multiple vulnerabilities
tor: denial of service
Page editor: Jake Edge |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||