How SUPL Reveals My Identity And Location To Google When I Use GPS

In a previous post I was delighted to report that assisted GPS (A-GPS) has become fast enough so I no longer have to rely on Google's Wi-Fi location service that in return requires me to send Wi-Fi and location data back to Google periodically. Unfortunately it turns out that the A-GPS implementation of one of my Android smartphones sends the ID of my SIM card (the IMSI) to the A-GPS server. From a technical point of view absolutely unnecessary and a gross privacy violation.

Read on for the details…

How Assisted GPS (A-GPS) works

To get a position fix, the GPS chip in a device needs to acquire the signal of at least three satellites. If the GPS chip is unaware of the identities of the satellites and their orbits this task can take several minutes. To speed things up a device can get information about satellites and their current location from an A-GPS server on the Internet. The single piece of information the server requires is a rough location estimate from the device. Usually a device is not aware of its rough location but it knows other things that can help such as the current cellular network id (MCC and MNC) and the id of the cell that is currently used. This information is sent to the A-GPS server on the Internet that then determines the location of the cell or network with a cell id / location database.The location off the cell or network is precise enough to assemble the satellite information that applies to the user's location which is then returned over the Internet connection. The satellite information is then fed to the GPS chip which can then typically find the signals of the GPS satellites in just a few seconds.

No Private Information Required

It's important to realize at this point that no personal information such as a user's ID is required in this process. The only information that can be traced back to a person, if the A-GPS client is implemented with privacy in mind, is the IP address from which the request was made to the server. In practice a mobile device is usually assigned a private IP address which is mapped to a public IP address from which the request seems to have originated. This public IP address is shared with many other users. Hence, only the network operator can identify which user has originated the request while the A-GPS server never gains any insight into who has sent the request.

The SUPL protocol and Privacy Breaching Information Fields

A standardized method for a device to gather A-GPS information from a server is the Secure User Plane Location protocol (SUPL). Several companies provide A-GPS SUPL servers answering requests on TCP port 7275 such as Google (supl.google.com) and Nokia/Microsoft (supl.nokia.com). In the case of my Android smartphone, supl.google.com is used. As the 'S' in 'SUPL' suggests, the protocol uses an encrypted connection for the request. As a consequence, using Wireshark without any additional tools to decode the request won't work as the content of the exchange is encrypted. Fortunately there's SUPL-PROXY, an open source piece of software by Tatu Mannisto that can be used in combination with domain redirection to proxy the SUPL SSL connection and decode the request and response messages. And on top, the SSL certificate generated by Tatu's software for the proxying can be fed into Wireshark which will then also decode the SUPL messages. And what I saw here very much disappointed me:

My SIM Card ID In The SUPL Request And No SSL Certificate Check

I almost anticipated it but I was still surprised and disappointing so see my SIM card's ID, the International Mobile Subscriber Identity (IMSI) in the request. This is shown in the first screenshot below. As explained above, the IMSI or any other personal information is not necessary at all for the request so I really wonder why it is included!? And just to make sure this is really the case I ran another test without a SIM card in the device and also got a valid SUPL return with the IMSI field set to 0's.

The second screenshot shows the cell id in the request which is required for the SUPL request. The IMSI in combination with the cell ID provides the owner of the SUPL server (i.e. Google in my case) a permanent personal identifier and as a consequence the ability to pinpoint and record my location whenever a SUPL request is made. And in this day and age, it's pretty certain that my network operator is not the only entity that is aware of my IMSI…

The third screenshot below shows the first part of the SUPL response which includes the location of the cell that served me when I recorded the SUPL request. Just type the two coordinates into Google search and you'll end up with a nice map of the part of Austria where I was when I put together this post. The second part, not shown in the screenshot, contains the satellite information for the GPS receiver.

And the cream on top is that the SUPL client on my Android device did NOT check the SSL certificate validity. I did not include the server certificate in the trusted certificate list so the client should have aborted the request during the SSL negotiation phase. But it didn't and thus anyone between me and the SUPL server at Google can get my approximate location by spoofing the request in the same way I did. I'm sure that two years ago, most people would have laughed and said that it's unlikely this could happen or that someone else but my network operator would know my IMSI, but one year post-Snowden I don't think anyone's laughing anymore…

When The Baseband Makes The Query

And now to the really scary part: The next thing I tried was if I could reproduce this behavior with other Android devices at hand. To my surprise the two I had handy would not send a SUPL request over Wi-Fi and also not over the cellular network (which I traced with tcpdump on the device). After some more digging I found out that some cellular radio chips that include a GPS receiver seem to perform the requests themselves over an established cellular IP connection. That means that there is NO WAY to trace the request and ascertain if it contains personal information or not. This is because the request completely bypasses the operating system of the device if it is made directly by the radio chip. At this point in time I have no evidence that the two devices from which I did not see SUPL requests actually use such a baseband chip A-GPS implementation and if there are personal indentifiers in the message or not. However, I'm determined to find out.

And for those of you who'd like to try yourselves I'll have a follow up post that describes the details of my trace setup with two Raspberry PI's, Wireshark, and the SUPL-PROXY software mentioned above.