Protocol Bugs in GSM Handsets

[Mass-produced consumer goods with software faults?!  Say it's not so!]

Nearly all GSM handsets have bugs in their protocol stacks.  If your GSM network is sufficiently complete and correct, it will not exercise those bugs to any degree that will affect service.  But the bugs are there and if you are experimenting with GSM network equipment (like these good people) you will see them.  It would be useful, informative and (now) possible for us to start a public discussion of specific bugs in specific handset models.  To that end, the old OpenBTS sourceforge wiki is offered for that purpose.  It's very much a work in progress, but I would invite anyone with first-hand GSM implementation experience to use and contribute.

The most common handset bugs I have seen are in idle-mode behavior and the handling of the TMSI.  These bugs normally do not affect service, but can represent security threats for high-profile individuals who carry the wrong phones.  Here's one example it gross detail.

A GSM subscriber is ultimately identified by IMSI.  (The IMEI, common in IS-95 and IS-136, is rarely used in GSM.)  Subscriber identities are frequently sent across the air interface in unencrypted form.  That's because encryption cannot be activated until the subscriber's identity is known.  In fact, nearly every transaction in GSM L3 begins with an uplink message that carries the mobile identity, and the LAPDm contention resolution procedure causes the network to echo that first message back verbatim.

If an attacker knows the subscriber identity associated with a person and can intercept GSM control channels, the attacker can use these open identity exchanges to track that person's movement and calling activity from cell to cell through a GSM network. An attacker could also use the IMSI for direct toll fraud in networks that do not perform authentication, which is more common that you might think in some parts of the world. To mitigate these risks, the GSM specification introduces the TMSI, an arbitrary 32-bit tag that can be used in place of the IMSI for anonymizing transactions.

Exposure of the IMSI-TMSI relationship would make the TMSI useless, so in a well managed network these two identifiers never appear in the same unencrypted transaction.  Typically, the handset will use the IMSI for an initial access, the network will then perform authentication and engage encryption, and then assign a TMSI through the encrypted channel.  All future accesses will use the TMSI.  That's what you'll see in most American and European networks, which tend to be well-managed from a security standpoint, A5/1 weaknesses aside.

Now, the TMSI is valid only in the "location area" (LA) in which it is assigned.  The LA is normally the area served by a common base station controller (BSC).  In American networks, this usually means an area with a population of 100,000 to 250,000 people.  When a handset moves to a new location area it is supposed to invalidate its TMSI, forcing the use of the IMSI on the first access in the new LA.  Why?  Because if the phone initiates access with a TMSI, that TMSI will be useless in the new LA.  The network will just have to turn around and request the IMSI in order to authenticate the handset.  When that happens, the previous IMSI-TMSI relationship is exposed, unencrypted, on the air interface.  An attacker who keeps good records of CCCH transactions over several cells can then go back and reconstruct the user's movement and pattern of calling activity in the previous LA.

So there's an example of a common handset bug with security implications.  I welcome reports of others on the new wiki.

GSM WLLs and Carrier Acceptance

The biggest challenge to the deployment of OpenBTS is that all of the world's cellular spectrum is already licensed, most of it to very big companies.  These big companies don't have strong motivation to deploy low-cost services in rural areas.  First, their actual cost of operation is fairly high in rural areas.  Second, even if that cost of operation could be lowered dramatically, it would create a marketing problem.  Solving the first problem will only magnify the second.

Suppose you're "Big Cellular" and you run a GSM network in the developing world.  It costs you $4-$8 per subscriber per month to operate, costing less in urban areas and more in rural areas.  But the people who actually live in rural areas can only afford about $2/month, so you mostly avoid those areas, unless a major road happens to pass through them, carrying your richer urban customers between cities.  Government regulators may pressure you to serve the rural areas, but you can always just show them your balance sheets and argue (honestly, even) that you are already giving the broadest service that can reasonably be expected for a profitable network.  Everyone's happy -- expect for the rural poor who, will never get telephone service under this model.

This is all cozy until a disruptive technology makes $2/month rural service a real possibility.  If you're Big Cellular, that's not good news.  You already have a legacy network that you're still paying for and the new technology is not directly compatible with it.  Even if it were compatible, the new technology creates a marketing problem because your urban customers paying $12/month will soon be demanding to know why they can't get $2 service like their country cousins.  You can try starting a second brand, but that's very expensive and you fear that your new, cheap brand will simply erode your existing market along the urban-rural edge.

The solution here is to make sure that the new service is not a viable substitute for normal cellular.  I'm not saying give the rural poor broken service.  I'm saying give them what they really need, which is reliable telephone service at a very low price, which is not the same thing as cellular, even if the "subscriber terminal" was built to be a cellphone.

The purpose of the new network is to provide basic telephone service in rural areas.  You don't need full cellular functionality to do that.  For example, maybe you don't implement handovers of active calls between cells.  Maybe you don't allow your rural subscribers to roam into "real" cellular networks.  If you are really cheap, maybe you even bind each SIM to a specific cell site, eliminating all of the mobility management functions.  This functionality already has a name: wireless local loop (WLL).  You use GSM like you might use DECT or WiFi, but with much larger service areas and much cheaper handsets.

Operating in WLL mode offers several advantages in this scenario.  There is the technical advantage of a much simpler core network, although a carrier can still support roaming for conventional cellular subscribers if it chooses.  There is the business advantage of no longer being a direct competitor to legacy cellular networks.  And depending on what country you are in, there may be regulatory advantages as well.

If you are Big Cellular, this new low-cost WLL is not a particular threat to your existing business.  It serves a market you would rather not deal with.  Maybe you can open a new subsidiary to operate WLL networks, or, depending on your local regulations, you can lease your fallow rural spectrum to a WLL carrier.  The WLL becomes a modest source of profit.  Universal service can be someone else's problem while you, Big Cellular, can do what comes naturally: market ever more complex services to the cities and gouge tourists with crazy roaming fees.  Everyone is happy again, and maybe this time we can spread it around a bit more.

GPL and Security Applications

It is no great secret that many intelligence gathering processes rely on the ignorance or carelessness of their targets.  That is why parties that engage in intelligence gathering are loathe to reveal the technical details of their tools.  If potential intelligence targets know the tools, they can know the limitations of those tools and take appropriate countermeasures.  Since law enforce and intelligence are (or at least should be) legitimate activities to preserve public safety, it is (arguably) in the public interest to protect information about "sources and methods."

So given that, is there a problem with using copyleft practices in an intelligence or security application?  Not really, at least not if you can trust your own customers to behave responsibly.  The key principle of copyleft open source software is that you must make your source code  available to the customers who receive your products.  That is not at all the same thing as making it available to the general public and even classified software can be copylefted if the license is drafted correctly.

For example, you could, in principle, produce classified software under a copyleft license and still be within the license and the law while delivering that software to a government customer within the same classified program.  You could, in principle, produce law enforcement products, not sellable to the general public, do so under a copyleft license and make the source code available only the the law enforcement agencies that actually buy the products.  Again, this can be fully legal and within the terms of the license.  The key concept here is that even though the end customer is free, under the license, to redistribute the work, they will do not so because of other practical and legal constraints outside of the license.  To be blunt, if you are being prosecuted for a national security violation, a lawsuit from a software vendor is the least of your worries.  Civil intellectual property law is not an appropriate tool for protecting state secrets anyway.

Surprise Purge of OpenBTS from SourceForge

[The SF site was restored a week later.  I'd delete this, but there's a long comment thread.]

Back in December, when an injunction was issued against OpenBTS, I had put in a request to SourceForge to purge the project.  Then I removed the non-compliant material myself.  Then I forgot about the purge request.  Now SourceForge finally got around to purging the project.

For anyone who was on the OpenBTS mailing list at SourceForge, I apologize.  I'm seeing what can be done about restoring the mailing list and web pages.

Until then, I'll try to find another place to host the web pages.