(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!)
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.)
I guess it makes sense to state "symmetric encryption" rather than "private key encryption", as asymmetric encryption also has a private (and public) key.
ReplyDeleteI don't think GMR-1 3G is used in BGAN, is it? Do you have any sources for that? I always thought GMR-1 3G is an unmodified UMTS NAS (non-access-stratum) with a highly proprietary AS (access stratum) for which unfortunately no specs/details have leaked so far.
Regards, Harald
Erm, I thoght _BGAN_ is an unmodified UMTS NAS ....
DeleteI stand corrected and have removed the comment about BGAN.
DeleteAs it turns out, I just implemented demod/decoding/dissection of RACH this week end and here's an example of what you find on there : http://pastebin.com/tr38Sy3f (some information redacted).
ReplyDeleteAlso interesting to not that with the right equipement, there is no need to be anywhere close to the target area. I didn't make the RF capture used for the example above, but that wasn't captured anywhere close to Afghanistan (where this call originated).
I also just had a quick look at the GMR-2 specs (used for Inmarsat iSatPhonePro AFAIK). The position doesn't seem to be in the RACH but there is the IMSI or Dialled Number (depending if the prodecure is a MOC or not).
Sylvain -
ReplyDeleteBy "there is no need to be anywhere close to the target area", do you mean to say that the C-band feeder links are unencrypted? And that L3 carries a lot of Abis-style pass-trough?
-- David
C-band data is really just the same thing as L-band. So whatever is in clear on L-band will be in clear on C-band, and whatever is ciphered on L-band will be ciphered on C-band.
ReplyDeleteSo this means that just about anyone on that side of the planet can make a log of the location of every GMR handset and what numbers they are calling. That's brilliant! Can someone build one of these and hook it to a Twitter feed? #realtimegmrcalls?
ReplyDeleteWell C-band is not as easy to receive ... you need a fairly large ( ~4m ) sat dish and a very good RF setup. But yes ... brilliant :)
DeleteThat's what they call "strategic" (C-band) interception vs "tactical" (L-band).
Note that the same kind of commercial system exist for Inmarsat so I would suspect it's really no better ... just that we haven't gotten around to implement that yet.
Why would you need a 4m dish to receive C-Band? A standard 1.5m antenna should work fine in theory.
DeleteYou only need the high gain of a 4m dish to transmit...and even then, it's mostly overkill in all but the harshest conditions (rain fade, etc).
I could see setting this up pretty much the same way I set up a feed from sportsticker into a gopher server back in 1993. Pretty much trivial, especially if someone has written a wireshark plugin to rip out the useful bits.
Well, in TV systems, they send a lot of power over large area on purpose.
DeleteHere they don't send that much power and they target specific sites. They also regulate tx power depending on the reception condition at the feeder site (Dubai for Thuraya).
So when you're at the edge of the visibility of the sat like we are here in EU, it's a bit tricky. The captures I worked with were done on a 6m tracking dish in eastern Russia and the signal is already much weaker than the L-band I can get with my small helical antenna.
Aaron -
ReplyDeleteSo can you do this with a scrap TRVO rig? I bet there are a lot of those in back yards across the rural US. Official flower of the state of Virginia, i hear.
http://www.satellite-tv.info/htm/trvo-basics.html
-- David
What about mapping l-band to c-band(feeder links). It changes every 24 hours, imho. Algorithm is known for this? Thanks for the answer.
ReplyDelete