reworld.org

A couple of years back, Jack Valenti argued that copyright law was supporting terrorism. Well, approximately. He argued that terrorists must be making money from piracy, which is really the same thing. He admitted to having no evidence for his claims, but if we presumed they were nonetheless true, criminal profits from piracy wouldn’t be possible under a sensible copyright system like an opt in universal license or a universal public funding system. In the same way that Prohibition in the 1930s funded crime by driving certain markets underground, modern copyright can fund crime too.

All of that is fairly straightforward. What is not so straightforward, dear readers, is the emerging possibility that attempts to enforce copyright are starting to protect paedophiles.

How is that? The most sophisticated attempts at DRM, based around trusted computing and some degree of tamper resistance, have a central tenet: provide a mechanism for denying local users full access to and control of their own computers. There must be cryptographic keys which are stored in the hardware but inaccesible to “unauthorised” applications, so that the user can’t get uncontrolled access to the decrypted versions of media files.

Precisely the same “trusted computing” mechanisms can be used to prevent someone who seizes your machine from performing any forensic investigation of it. Microsoft’s BitLocker project is just such an application. At the moment, encryption software is available to hide the contents of your hard disk. But BitLocker prevents two of the more obvious methods that law enforcement (or someone else) can use to defeat disk encryption: brute force attacks on passphrases, and software keystroke logging.

Apparently, some European computer police are very angry that Microsoft is making BitLocker widely available. They’re convinced that it will prove invaluable for paedophiles. Which, occasionally, it may — and also for political subversives, whistleblowers, and other questionable sorts.

To sum up: Hollywood’s push for DRM has lead Microsoft (with help from Intel and others) to build powerful privacy-protection tools that police believe will turn into a haven for paedophiles.

One wonders how long it will be before governments want their hands all over the private keys in the Trusted Platform Module in your PC. Apparently, China is already planning to prohibit the importation of trusted computing hardware that wasn’t made there. If this comes to pass, the only viruses, keystroke loggers and malware that will be able to infect your computer for any length of time will be the friendly goverment approved versions.

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.