(Do read the comments on this one and follow Sylvain Munaut's link for an example of a GMR Channel Request captured in the wild. Is it technically possible for an unauthorized person to rig up an public Twitter feed of who's calling whom from where on GMR-1 phones all over the world? Yes!)
In a recent post, Some Comments on Satellite Phones, I stated the following:
GMR handsets include GPS receivers and transmit identity and location information to the network operator. These transmissions are completely in the clear, but even if they were encrypted, the network operator would have access to this information.By "GMR" I was specifically referring to GMR-1, the technology used by Thuraya, and possibly others. There seems to be some confusion about what is and is not encrypted in these systems. Personally, I think the fact that you are transmitting an identifiable GMR signal is enough of a security problem by itself, but there seems to be a lot of interest in what is and is not encrypted in these systems, so let me be clear: The Channel Request message is the first message sent from the handset to the satellite at the start of any transaction. This message cannot be encrypted. This message typically contains the following information:
- the IMSI of the satellite phone handset
- the called number (in the case of mobile-originated calls) and
- the GPS location of the handset.
The MES shall attempt to obtain the current GPS position before sending a CHANNEL REQUEST message on the RACH. A position shall be current if less than Page GPS Position Age (Mobile Terminated (MT) calls) or GPS Position Age (other accesses) time has elapsed since it was measured. If the last measured position is not current and the Establishment Cause is not IMSI Detach, the MES shall start the RACH Position timer and initiate GPS position calculation. If the position calculation is successful, the timer shall be stopped and the newly calculated position is used. If the timer expires or the Establishment Cause is IMSI Detach, the last available position (if any) shall be used. If no position information is available, an access attempt shall be made without position information. ...The Channel Request message is defined in Section 10.1.8. It looks like this:
The "SP/HPLMN ID" is usually an IMSI and the "Number Digits" are the dialed number and the "GPS Position" is exactly what it sounds like. This message cannot possibly be encrypted. Why? Because GMR uses symmetric encryption, so it cannot engage encryption until the network knows your identity, and it does not know your identity until after it decodes this message.
Are we all clear on that?
It gets better...
In the process of nailing down all of my facts on this, I also stumbled onto the GMR-1 3G specs. While GMR-1 is modeled largely after GSM, GMR-1 3G is modeled largely after UMTS. The ETSI document number for that radio resource control specification is TS 101 376-4-13, GMR-1 3G 44.118. "RRC Connection Establishment" is defined in Section 7.5.1. The first message from the terminal to the network is "RRC CONNECTION REQUEST", defined in Section 9.2.40. But 9.2.40 just refers back to TS 101 376-4-8 GMR-1 3G 44.008 Section 10.1.4.8, "Channel Request Type 3". And guess what? That message also contains an element called "MES Position" that encodes the terminal position relative to the center of the serving beam. Again, given the secret-key encryption of GMR, this message cannot possibly be encrypted. Furthermore, the terminal will need to expose some kind of identity token in the open before encryption can start.
And now it gets really interesting...
These Channel Request messages appear on the uplink. They go from the handset to the satellite. But where do they go from there? It turns out that they just go right back down to the Earth on a different radio frequency on a so-called "feeder link". What's so special about that? Well, the uplink from the handset is only visible for a kilometer or so, but the feeder link is visible over roughly 1/3 of the planet's surface to anyone with a C-Band dish and is not given any additional encryption. (Thanks Sylvain, for pointing this out.)
(David Burgess is a lead developer in the OpenBTS project and one of the founders of Range Networks.)