A privacy-protecting cellphone?
Mobile phones are a privacy disaster. While they are switched on, they continuously reveal the location of the person carrying them. Records of calls made, where the calls are made from, and text messages sent, are almost always kept by the networks. Surveillance also permits evesdropping on calls and on the content of text messages.
In this post, I’m going to try to sketch an unconventional design for a cellphone that offers good-to-excellent protection against all of these threats.
The first insight is to use open WiFi networks as a carrier. WiFi phones are not new, of course. They’ve been around for a few years, and there are handsets available from Netgear, Zyxel, RadioTele, UTStarCom, Hitachi, and others. There are some pretty fancy linux-based gadgets from Motorola and Philips (the latter has apparently been released through some telco in the Netherlands… but I can’t find one to buy). The design is going to involve reprogramming one of the above devices.
The phone will need to be set up to opportunistically connect to open WiFi networks. For privacy purposes, it is desirable to randomise the device’s MAC address each time that happens. Otherwise, MAC addresses create an audit trail accross every network the phone talks to. MAC addresses would not normally be reported beyond the WIFI router or hub that a gadget was talking to, but they do allow that router to create a long-term history of use by your phone. If recorded, these addresses could also be collected by a hacker or a retrospective forensic investigation (including a civil lawsuit).
An aside of interest in creating an opportunistic WiFi device is whether the gadget should ever automatically click-through a welcome/terms of service screen on a WiFi network. Some networks redirect a new connectee’s first HTTP requests to a page requiring that kind of agreement. I’m not currently aware of any standard protocols with which a device can automatically negotiate terms of service with the an arbitrary network. If there aren’t any, we might have to concoct one. In any case this is a fairly generic issue about building WiFi-linked gadgetry, and one that will become more important with the deployment of large free-of-charge-but-agreement-governed networks.
On to private phones! The fanciest privacy-protecting network tool around is Tor. Tor is an onion routing system that lets you bounce your traffic around a sequence of nodes before it reaches its final destination. Each node descrambles a layer of encryption (hence “onion” routing). None of the Tor routers can see anything beyond the nodes immediately before and after it, so they cannot tell who is talking to whom. Tor can serve very nicely for private mobile email/SMS replacement. But unfortunately it isn’t really satisfactory for voice, because it imposes a big latency hit and is unreliable in terms of connectivity and bandwidth.
So, what to do? The answer may be to use Tor to establish a call, and then some lower-latency setup for the actual VOIP data. Phone numbers could be anonymously published Tor services; if you want to call them, you phone finds their Tor service and arranges the details. Because 99%+ of these phones’ WiFi connections will be behind immutable [1] NAT firewalls, the call will need to be routed through an intermediate proxy. A centralised exchange proxy, that handles many calls, would work nicely. My colleague Seth Schoen pointed out that the two parties don’t even need to know each other’s IP addresses; they can just agree on a random call number, and ask the proxy to be connected to the other party who knows that number [2]. The parties of course use end-to-end encryption for their VOIP connection, so the central proxy knows which (wandering, open WiFi) IPs are talking to each other, but nothing more. If the proxy carries enough traffic and does not retain logs, outside parties might be left guessing even about which IP is paired with which [3].
This architecture seems to be pretty nice. Please let us know if you notice any flaws! Aside from that, it would be nice to start experimenting with it… In fact, any coders who are interested in working on this should give drop us a line.
NOTES
1. There might in theory be situations in which a mobile WiFi device could arrange to negotiate access to an incoming TCP/UDP port on a public IP address, but there is little point in engineering for such unlikely circumstances.
2. The right way to handle this session arrangement is a little more complicated than just signing up with a shared session number and getting a stream of UDP packets back. A single session number is inadequate, for example, if one of the devices jumps IP addresses, which can easily happen with a WiFi device. The protocol should not only allow recovery from IP address transitions, but in fact try to use them as cover against traffic analysis.
3. This would require some careful protocol design because, by default, the fact that two IPs have closely related start and end times for their sessions will usually allow them to be linked together.