16 Jun 2014
Ars Technica and NPR collaborated on an interesting story. The Ars reporter, Sean Gallaghan, installed a "modified" Wi-Fi router in the office of the NPR journalist, Steve Henn. The "PwnPlug" router can capture and analyze the traffic, mimicking what the NSA can do by tapping the network. And, of course, the network analysis revealed lots of data about Steve Henn. It is as if each of us is carrying a personal spy in his or her pockets! When I heard about this on the radio, I was not really surprised by the result, but I was interested that this study was making its way to prime time radio news. That's a good first step. If more people are aware of the spying going on, someone may eventually do something about it.
The most striking part of the report concerned what happens when Steve merely brings his iPhone in his office, without actually using it or starting any application. As soon as it obtains connectivity, the phone starts contacting a variety of web sites to update business and personal mail, calendar, maps, notes, twitter, Facebook, and probably a few more. Some of that traffic is encrypted, but even then the IP addresses are enough to understand who connects where. Enough headers are still in clear text to provide good correlation, pretty much as I was describing in an Internet Draft last year.
The same week, Quartz reported about a small feature in the latest version of Apple's IOS: MAC address randomization. The article just provides a general description of the feature, picking a random MAC address before connecting to a Wi-Fi network. The article does not provide much detail about the implementation, but I assume that the software developers at Apple spent a lot of time tuning the feature. In general, changing the MAC address as often as possible provides better privacy, but changing it too often may force the user to repeat network authentication procedures, which is cumbersome. The IETF IPv6 working group debated a similar feature for "randomized IPv6 addresses" for over a year before publishing RFC 7217. Whatever the details of the implementation, it feels like a step in the right direction, and I hope that other operating systems will soon follow. (I don't work in the Windows Wireless team anymore, so I have no idea whether my colleagues are working on something like that.) But then, Wi-Fi is only one part of the problem. Your phone probably has three other wireless interfaces: Near Field Communication (NFC), Bluetooth, and of course the 2G, 3G, 4G or LTE cellular radio.
The very short range of NFC reduces the risk of it being used for tracking. The user may deliberately uses NFC to provide information for example to perform an electronic payment, but then the tracking is pretty similar to what could be done with a credit card payment.
Bluetooth has a nominal range of a few meters, but spies can use powerful antenna and listen to Bluetooth at longer distance. Store or building owners can install networks of "Bluetooth Tracking Devices" to follow the movement of people and their cell phones around their store. This can only be thwarted if we develop some form of Bluetooth privacy feature. Of course, the simplest solution is to turn Bluetooth off when not needed, but this is quite inconvenient. I like my phone to discover my car automatically, and would not like to have to manually turn Bluetooth back on when stepping in the driver seat! The most convenient way is probably some form a "passive discovery" mode, which used to be the default behavior for Windows PC. In short, Bluetooth needs the same kind of attention as Wi-Fi.
The cellular radio poses a much more difficult problem. The connection between a cell phone and a mobile service starts by an authentication exchange. Each phone has a unique 15-digit "International mobile subscriber identity" (IMSI). At the beginning of the connection, the phone presents its IMSI to the visited network. The Mobility Management Entity of the visited network uses the first 5 or 6 digits of the IMSI to identify the "home network" of the phone, and requests authentication data from the Home Subscriber Server (HSS) to verify that the phone is authorized to connect. It then uses this data in an authentication request sent to the phone. The authentication request also includes information provided by the HSS to authenticate the visited network. When the exchange concludes, the phone and the network have verified each other's identities, and have negotiated keys to secure and encrypt the exchanges.
There are two obvious problem with that design. First, the mobile phone provides its identity to the network before it had a chance to authenticate the network. This vulnerability is currently used by devices like the Stingray phone tracker, which various agencies use to spy on phone users without any need for warrants. The second problem is that the protocol discloses the actual identity of the device, when in fact it only needs the identity of the home service.
The same problems used to happen in another context, network authentication using the EAP protocols. The IETF working groups provided a solution with methods like EAP-TLS, which use two distinct identities. The mobile presents to the visited network a privacy Network Access Identifier (NAI) that identify the home server but randomizes the identity of the mobile, as defined in RFC 4282. The real identity is then sent in an encrypted way to the home server, without being revealed to the visited network.
The EAP-TLS solution cannot be easily implemented in the LTE world, if only because at this stage of deployment the LTE protocol will be very hard to change. But a Mobile Network Operator or maybe a Virtual Mobile Operator could still adopt something similar. Suppose for example that each mobile is provisioned with a set of "throw away" IMSI that can play the same role as the NAI or EAP-TLS. When the mobile wants to connect, it picks one of the throw-away IMSI. The request is routed to the HSS of the MNO, which knows the relation between the throw-away ID and the real identity. Later, the throw away IMSI is discarded, and the phone is provided with a new one. The connection completes, as expected by the visited network, but the identity is not disclosed – and devices like the Stingray become very much useless. Of course, this will need more engineering than a two lines analysis, there may well be some tricky accounting issues, the provisioning protocols will have to be defined, but it seems that a willing provider could provide much better privacy than is currently the norm.
We are seeing the first move in the right direction. Let's hope that after randomizing Wi-Fi we will see some protection for Bluetooth and for LTE. And more encryption to plug all these leaks detailed in the Ars Technica article!