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.