GSM Security Workshop

On November 17 & 18, at the DeepSec conference in Vienna, Harald Welte and I will present a workshop on GSM security. Because I was under an injunction at the time the original workshop description was drafted, the material on the official schedule is very limited, which harms me and DeepSec by limiting advertising. Now that my speech rights have been restored, I'd like to use this blog for a shameless plug.

The DeepSec GSM security workshop will begin with an overview of the GSM air interface, Um, sufficient for those not yet familiar with cellular protocols to follow the subsequent material. We will then describe standard Um security mechanisms, their fundamental flaws, common operational mistakes and known techniques for exploiting these flaws and mistakes. We will describe the mechanisms, capabilities and limitations of passive interception, jamming, active attacks on Um and the use of other public networks for higher-layer attacks. More importantly, we will describe best security practices, means of identifying various attacks and the countermeasures available to carriers and to individual subscribers. Going beyond theory, we will demonstrate many of the attacks and countermeasures using a private GSM network built with commercially available components, software from the OpenBTS and OpenBSC projects, and additional software components not found in the public distributions of those projects. We will also take this opportunity to blow away a lot of the trade secret claims that typically surround this field by reviewing publicly available sources, including patents, academic papers and even the court records of intellectual property disputes, that describe these attacks and countermeasures in sufficient detail to allow their recreation by engineers of ordinary skill.

Of course, that's assuming we get at least three people to sign up for the workshop, which is the minimum number to justify the cost to the conference. For more information, see the conference registration page. Early bird registration ends September 7.

The Man Burns in 27 Days

Plans to run a cellular system at Burning Man are well under way. We have an FCC license and spectrum coordination with Verizon in the GSM850 band. We have most of our equipment in hand and are starting final assembly this week. We have a store-and-forward SIP/SIMPLE server, thanks to John Gilmore. We have official camp placement and early access to the site. We have a block of 10,000 iNum phone numbers in country code +883, thanks to Voxbone. We have a 70' tower and an installation crew, thanks to Martin Pelayo. Things are on schedule and a lot of people have stepped forward to help us and we thank them all.

We heard a story that Larry Harvey was very concerned when he got wind of our plans, thinking we'd turn the Playa into some kind of chatfest. I'd like to assure Mr. Harvey and anyone else that we don't have the bandwidth to provide normal calling service to 50,000 people, nor do we have roaming and settlement agreements with cellular carriers. We couldn't light up BRC with normal speech service if we wanted to, and we don't want to. Want we can do is provide speech service for about 1,000 early subscribers, which we assume will mostly be early arrivals, BM staff, Rangers, DPW, perimeter patrols, etc. After that, we will have enough bandwidth left to run about 1,500 SMS transfers per minute, allowing us to provide text service to pretty much anyone who wants it. We are hoping participants will find this service useful, as a means of locating friends, meeting new people and getting information about Playa events.

We'll post more on the details of using the service soon, after we have made a few final decisions on network configuration and policies.

Three Quotes

"No state has ever benefited from protracted war."

"Massimiliano Martone and Martone Radio Technology, Inc. and David Burgess, Kestrel Signal Processing, Inc. and Range Networks, Inc. have resolved all disputes between them and all litigation between them has been dismissed. Each of the parties is pursuing their own business interests."

"We have done so much for so long with so little that we are now qualified to do anything with nothing."

Pre-Paid, Revisited

In a previous post, I talked about a Net10 Nokia 1600 that appeared to be SIM-locked and have some special firmware that made it nearly useless for anything but Net10's prepaid service.

For the latest experiment, I found an AT&T "Go Phone" Nokia 2610.  I turned it on right next to a running OpenBTS system.  It powered up, registered with OpenBTS and then tried to send an SMS to the private ISDN address 1111340002 via an SMSC at + 14047259800.  Here is the raw TPDU of the message.

If anyone has immediate ideas on the meaning of that 69-byte payload or what the handset is expecting to see in response, let me know.  The known parameters are:

• IMSI 310410250887606
• MSISDN +1 707 386 8928
• PIN 8928
• ICCID 8901 4104 2125 0887 6088

Unfortunately, the phone itself has a power supply problem, so I will need to find another one.  And then I can post a second example for comparison.

A Big, Dangerous Assumption

Lately, I've been exchanging thoughts with people in the OpenBSC project about a specific class of DOS attacks against cellular networks. We discussed GSM vulnerabilities specifically, and tried and failed to think of ways to harden our systems against them.

The DOS attacks we discussed would made from the subscriber side of the cellular air interface. These "rogue handset" attacks have a fundamental commonality with false-basestation attacks: the key to performing either type of attack is having a GSM device that allows you to control layer 3 (L3), the layer where most of the resource management and call signaling actually happen. This observation touches on a huge shortcoming of many ISDN/SS7 systems, that they are built with the assumption that any entity in L3 can be trusted to follow the protcol. (I had a related conversation with Jacob Appelbaum a couple of weeks earlier where he made a broader comment about the error of "trusting the infrastructure".) The ugly truth is that if you can take control of an L3 entity you can make a lot of networks do a lot of strange things.

In a recent appeals case in England, MMI v. CellXion, the UK high court upheld a ruling that the function of an IMSI-catcher was sufficiently non-obvious to justify patent protection. Part of that decision was based on testimony from so-called experts that GSM security was once thought to be "unbreakable". It is unfortunate that the high court was mislead by such testimony. To be blunt, anyone who ever thought that GSM security was unbreakable must not have tried. Heck, you can build an IMSI catcher by accident just by misconfiguring certain cellular equipment. But the important point here is that the representations of these so-called experts reflect the long-standing assumption that rogue parties cannot get their hands on the equipment they need to spoof elements of the system. That assumption may have been reasonable in early days of SS7, when these technologies were new, the equipment was expensive and all of the networks were run by governments and megacorporations. Even then, though, breaking the security was merely expensive, far from impossible. The cost is down now. Today anyone with a few hundred dollars can get their hands on a trace phone, a surplus micro-BTS, a SIM kit, a used cellular network test set or an account with a commerical VoIP-PSTN gateway. All of these products can be used to attack cellular and PSTN networks in various ways, ranging from identity spoofing to shutting down whole cells. Most people are unaware of these risks, continue to trust the network and continue to carry potentially dangerous misconceptions about what is secure and what is not.

GSM Roaming

I was having an e-mail exchange with John Todd about call routing between cellular and VoIP networks.  He asked, "If am roaming with my AT&T phone in Germany and am on the T-Mobile network, and someone in Germany calls my +1-... E.164 number from their Deutsche Telecom land line, the call isn't routed via the US - it gets terminated locally because Deutsche Telecom passes the call to T-mobile directly.  But is DT sending the call to my "base" E.164 address, or to the MSRN?"

Good question.  I gave my best answer based on my reading of GSM 03.04 and GSM 04.08.  John suggested that the answer might also be useful information for other VoIP people trying to get a handle on what goes on inside a cellular network.  So here it is:

• The originating Deutsche Telekom (DT) local exchange (LE) in Germany, acting on your MSISDN (mobile subscriber ISDN, your normal cellular telephone number), contacts an international switching center (ISC) in Germany, which in turn contacts an ISC in the US.
• The US ISC, acting on your MSISDN, contacts AT&T's gateway mobile switching center (GMSC) which in turn contacts AT&T's HLR (home location register) to get your MSRN (mobile subscriber roaming number, the number where your call actually needs to terminate).
• The HLR returns an MSRN in Germany that had previously been assigned to you by the German T-Mobile network.
  
• The AT&T GMSC tells the US ISC to forward the call to the MSRN in Germany.
  
• The US ISC tells the German ISC to forward the call to the MSRN in Germany.
  
• The German ISC tells the DT LE to forward the call to the MSRN in Germany.
  
• The DT LE, now using the MSRN, contacts a T-Mobile GMSC in Germany.
• The T-Mobile GMSC looks up your MSRN in its visitor location register (VLR), where it finds your IMSI and sees that you are an AT&T subscriber, since that is encoded into the IMSI.  The GMSC also gets the identity of the basestation controller (BSC) where you most recently registered.
• The T-Mobile VLR contacts the AT&T HLR to verify your account.  (Not absolutely sure on this step, but probably.  We'll contact AT&T's HLR again in a few seconds, though, so they might defer this step.)
• The T-Mobile GMSC contacts your serving BSC to initiate paging on the radio interface.  The paging message, sent on the common control channel (CCCH) of every BTS controlled by that BSC, contains your IMSI or TMSI.
• Your handset sees the paging message and responds on the random access channel (RACH).
• The BTS/BSC sees the RACH message and responds with a channel assignment on your serving BTS through the CCCH.
  
• You pick up the newly assigned dedicated control channel (DCCH) and establish LAPDm async balanced mode.  At this point, you have effectively have an ISDN D-channel connection to the BSC.
  
• On the new D-channel, you send a "paging response" message that identifies you, by IMSI or TMSI, to the BSC.  (If you send a TMSI, the BSC resolves it to an IMSI at this point.)
• The BSC (optionally) authenticates you with AT&T's HLR, (optionally) initiates encryption, and then sends you a message informing you that "connection mode" is established.  You may also (optionally) get reassigned to a new radio channel at this point, or simply be told that the mode of your existing radio channel has changed.  Either way, you now have an ISDN-like connection to T-Mobile's GMSC, with a D-channel for signaling and B-channel for media.
• From this point forward, the signaling part is just like Q.931.
  

I would encourage any ISDN jockeys out there, especially from OpenBSC or Linux Call Router to correct anything I overlooked or got wrong in that.

Some Comments on IMSI-Catchers

Update 30 Jan 2012: Since originally writing this post in mid-2009, there have been some noteworthy developments in this area, the biggest of which is that UK patent case MMI & CellXion, referenced below, went to appeal with the result that the IMSI-catcher was deemed too obvious to patent in light of known prior art. For anyone to claim secrecy here is, I think, becoming something of an intelligence test. Enjoy the original post.

I'm going to comment briefly on IMSI-catchers. These are devices that perform false-basestation attacks on cellular networks, including man-in-the-middle call interception. Here's an example of one.

First, I wrote software for IMSI-catchers in the past. That is now a matter of public record.

Second, the GSM protocol operations of an IMSI-catcher are not trade secrets. The IMSI-catcher was patented by Rohde & Schwarz (R&S) in 2003 under the name "virtual basestation" and the implementation of the device is explained in this patent to a degree sufficient to allow a cellular engineer of reasonable skill to construct one, as is the standard for patent applications worldwide. Most of the patent is in German, but this recent ruling from the UK high court summarizes the R&S patent in English for a non-engineering audience. Moreover, that MMI v. CellXion ruling references an earlier published patent application from Nokia, and although I cannot find a copy of that particular document on the web, the high court clearly accepts its existence. Either way, R&S or Nokia, once something is published in a patent application, it is no longer a trade secret. So here's a quick lesson on IP law as relates to 2G-2.5G GSM IMSI-catching:

• It's no secret. There are public documents distributed by UK & EU governments that describe how to do it.
• Even if it were a secret, that secret would belong to Nokia or R&S, because they appear to have started working on that problem not long after the GSM standard was published.
• If you are selling IMSI-catchers in the UK or Europe without the blessing of R&S, you are setting yourself up for a lawsuit, with MMI v. CellXion as a precedent.

Third, I cannot build IMSI-catchers for anyone outside of a verified US government contract. So the next time some unauthorized party contacts me asking for one, I will publish your contact information in this blog.

Fourth, the most common way to build an IMSI-catcher comes directly from the R&S patent itself and is based entirely on off-the-shelf commercial equipment. Nearly any BTS or BTS simulator can be used as the basis of an IMSI-catcher.

Pre-Paid

Last week I was in a close-out store and found a bunch of Net10 prepaid Nokia 1600s for $20 each.  At first I thought I'd found a good source of cheap handsets for testing.  I got one home and even though I provisioned it in my OpenBTS system, and even though it registered and showed service, it refused to place a call without any minutes in its "tank".

Here's what I did find, which may be of interest.  First, the SIM was generic-looking, no corporate logo, just the letters "SIM" printed on it.  Second, when the phone tried to register, the IMSI was from AT&T: 310410226242003.  Third, the phone rejected other SIMs, including other AT&T SIMs.  The handset appears to be keyed to a specific SIM, so to get this handset to act like a normal phone I'd need to get it rebranded, not just unlocked.  Fourth, menus in the phone showed the IMSI, the IMEI, the phone number and a "random number".  That was unusual, since a handset normally does not know its own phone number.  I am also eager to see if that "random number" is really Ki.

So I won't be buying a big pile of Nokia 1600s at Big Lots, but I'm keeping this one phone because it will be a great opportunity to see how prepaid phones interact with the network.  Hopefully, in a couple of weeks I'll have a chance to play with that, unless some other OpenBTS developer out there beats me to that.  (Hint, hint...)

The Value of Knowing How Stuff Works

I was in a thrift store yesterday and came across an old automatic fire alarm.  It was a wind-up bell-clapping mechanism triggered by a thermostat.  Just by holding it you hand, your could feel how it worked.  There was a time when most equipment was like that.  You could look at a device and get a pretty good idea of how worked, how to fix it and what its limitations where.  You could even do this with electronic equipment once you learned to recognize a few basic component types.  I am old enough to have grown up in a world that was mostly like that, but I may well have been in the last generation to do so.  For example, I used to repair my cars myself, diagnosing problems by sound and smell.  I haven't touched an engine in years though, partly because I can afford more reliable cars now, but partly because when I look under the hood of a modern automobile I can't find the engine.  My best friend's dad was a TV repair man, who learned his trade as a radioman in the Marines.  He know his craft was in its twilight the first time he saw a "gutless wonder", a unit with hardly anything in it but 2  big ICs and a high-voltage transformer.

Now, I don't mean to sound like some kind of old crabby guy here.  I'm getting to a point.  Today, most people are surrounded by world of gadgets and appliances of stunning complexity and haven't a clue as to how most of it works.  And I say "how it works" instead of "how they work" because these gadgets are all working together, as a system.  You punch a text message into your cell phone and hit send and a few minutes later a post appears on Twitter and chances are you literally have no idea what happened in between, or how much information you exposed about yourself in the process.  Frankly, I think it's a little dangerous to be so dependent on an interconnected world most people don't understand.  (James Burke talked about this kind of danger in his "Connections" program over 30 years ago, a program that made a strong impression on me as a child, but the world of 30 years ago just seems quaint now.)  And it's more than a little dangerous when these people are regulating this world they don't understand, lawmakers who have never used e-mail, whose mental model of the internet is "a series of tubes" and who are constantly surrounded by paid lobbyists representing agendas that often run counter to public interest.

What does all of that have to do with OpenBTS?  One of the motivations for releasing a GSM stack in open source is to help curious people understand how cellular technologies work, to demystify the GSM network by reducing it to a simple form.  This is happening, to some degree, through students and "makers" who have built working OpenBTS nodes as class or club projects.  I think there are about a dozen such systems out there now, not counting commercial development kits, and I love to hear from these people.  Congratulations to everyone who has even tried to run OpenBTS, but especially to those who succeeded.  That first phone call was pretty exciting, wasn't it?  And it was very satisfying to know how it happened.  Granted, we're not educating lawmakers yet, if that's even a meaningful goal, but it's a start.

The Man Burns in 130 Days

We have cleared the legal hurdles to run a test network at Burning Man 2009. This network will probably operate in the PCS1900 band, making it compatible with nearly all AT&T and T-Mobile handsets currently used in the US, as well as with any tri-band or quad-band handsets sold anywhere else in the world.

The current plan is to deploy a system largely intended for local (BRC-only) text messaging. We will also support limited speech service, connecting on-playa calls through user-provided numbers and routing inbound calls through the +883 country code. As a practical matter, the Burning Man 2009 experimental network will be important for testing hardware and software designs for use in rural villages, remote facilities and disaster relief applications.

We will release more details as they come together.