Over the years, there has been a lot of interest in the security of the
TCP/IP protocol suite. But there is another set of protocols - the GSM
mobile telephony suite - which is easily as widely deployed as TCP and
for which security is just as important, but a lot fewer people have ever
taken a deep look at GSM. Harald Welte, along with a small group of
co-conspirators, is out to change that; in a fast-paced Linux-Kongress
), he outlined what they have been up to and how far they have gotten.
While they may be hard to find, the specifications for the GSM protocols are
available. But the industry around GSM is very closed, Harald says, and
closed-minded as well. There are only about four implementations (closed,
naturally) of the GSM stack; everybody else licenses one of them. There
are also no documents released for GSM hardware - at least, none which have
been released intentionally. There are very few companies making GSM or 3G
chips, and they buy their software from elsewhere. Only the biggest of
handset manufacturers get to buy these chips directly, and even they don't
get comprehensive documentation or source code.
On the network side, there are, once again, just a few companies making
GSM-related equipment. Beyond the major manufacturers, there are a couple
of nano/femtocell companies, and a shadowy group of firms making equipment
for law-enforcement agencies. These companies have a small number of
customers - the cellular carriers - and the quantities sold are low. So,
in other words, prices for this equipment are very high. That means that
anybody wanting to do GSM protocol research needs to set up a network
dedicated to that purpose, and that is an expensive proposition.
Even the cellular operators don't know all that much about what is going on
under the hood; they outsource almost everything they do to others. These
companies, Harald says, are more akin to banks than technology companies;
actual operation of the network equipment is outsourced to the companies
which sold that equipment in the first place. As a result, there are very
few people who know much about the protocols or the equipment which
This state of affairs has some significant implications. Protocol
knowledge is limited to the small number of manufacturers out there. There
is almost no protocol-level security research happening; most of what is
being done is very theoretical and oriented around cryptographic
technology. The only other significant research is at the application
level, which is several layers up the stack from the area that Harald is
interested in. There are also no open-source protocol implementations,
which is a problem: these implementations are needed to help people learn
about the protocols. The lack of open reference implementations also
restricts innovation in the GSM space to the manufacturers.
So how should an aspiring GSM security researcher go about it? One
possibility is to focus on the network side, but, as was mentioned before,
that is an expensive way to go. The good news is that the protocols on the
network side are relatively well documented; that has helped the
OpenBSC and OpenBTS projects to make some
progress in this area.
If, instead, one wanted to look at GSM from the handset side, there is a
different set of obstacles to deal with. The firmware and protocol code
used in handset baseband processors is, naturally, closed and proprietary.
The layer-1 and signal-processing hardware and software is equally closed.
There is also a complete lack of documented interfaces between these
layers; we don't even know how they talk to each other. There have been
some attempts to make things better - the TSM30 and MADos projects
were mentioned - but things are still in an early state.
Nonetheless, the handset side is where Harald and company decided to work.
The bootstrap process was a bit painful; it involved wading through over
1000 documents (full documents - not pages) to gradually learn about the
protocols and how they interact with each other. Then it's necessary to
get some equipment and start messing with it.
Harald gave a whirlwind tour of the protocols and acronyms found in
cellular telephony. On the network side, there is the BTS (the cell
tower), which talks with the base station controller (BSC), which can
handle possibly hundreds of towers. The BSC, in turn, talks to the network
subsystem (NSS), which is responsible for making most of the details of
mobile telephone work. The protocol for talking with the handsets is
called UM. It breaks down into several layers, starting with layer 1
(the radio layer, TS 04.04), up to layer 2 (LAPDm, TS 04.06), and
layer 3, with names like "radio resource," "mobility management," and
"call control." The layer 3 specification is TS 04.08 - the single
most important spec, Harald says, for people interested in how mobile
Various people, looking at the specifications, have already turned up a few
security problems. There is, for example, no mutual authentication between
the handset and the cellular tower, making tower-in-the-middle attacks
possible. Cryptographic protocols are weak - and optional at that - and
there is no way for the user to know what kind of encryption, if any, is in
use. And so on.
On the handset side, these protocols are handled by a dedicated baseband
processor; it is usually some sort of ARM7 or ARM9 processor running a
real-time operating system. Evidently L4 microkernels are in use on a
number of these
processors. The CPU has no memory protection, and the software is written
in C or assembly. There are no security features like stack protection,
non-executable memory, or address-space layout randomization. It's a huge
amount of software running in an unforgiving environment; Harald has
written up a description of how this processor works in this
What an aspiring GSM security researcher needs is a baseband processor
under his or her control. There are a couple of approaches which could be
taken to get one of those, starting with simply building one from generic
components. With a digital signal processor and a CPU, one would
eventually get there, but it would be a lot of work. The alternative is to
use an existing baseband chipset, working from information gained from
reverse engineering or leaked documentation. That approach might be
faster, but it still leads to working with custom, expensive hardware.
So the OsmocomBB hackers took neither of those approaches, choosing instead
the "alternative, lazy approach" of repurposing an existing handset. There
is a clear advantage to working this way: the hardware is already known to
work. There is still a fair amount of reverse engineering to be done, and
hardware drivers need to be written, but the job is manageable. The key is
to find the right phone; a good candidate would be as cheap as possible,
readily available, old and simple, and, preferably, contain a baseband
chipset with at least some leaked information.
The team settled on the TI Calypso chipset, which actually has an
open-source GSM stack available for it. Actually, it's not open source,
but it did sit on SourceForge for four years until TI figured out it was
there; naturally, the code is still available for those who look hard
enough. The chipset is past the end of its commercial life, but phones
built on this chipset are easy to find on eBay. As an added bonus, the
firmware is not encrypted, so there are no DRM schemes to bypass.
With these devices in hand, the OsmocomBB project started in January of
2010 with the goal of creating a GSM baseband implementation from scratch.
At this point, they have succeeded, in that they have almost everything
required to run the phone. Their current approach involves running as
little code as possible on the phone itself - debugging is much easier when
the code is running on a normal computer. So the drivers and layer 1
code run on the phone; everything else is on the PC. Eventually, most of
the rest of the code will move to the handset, but there seems to be no
hurry in that regard.
The firmware load currently has a set of hardware drivers for the radio,
screen, and other parts of the phone. The GSM layer 1 code runs with
no underlying operating system - there really is no need for one. It is a
relatively simple set of event-driven routines. The OsmocomBB develpers
have created a custom protocol, called l1ctl, for talking with the
layer 1 code. Layers 2 and 3 run on the host computer, using l1ctl to
talk to the phone; they handle tasks like cell selection, SIM card
emulation, and various "applications" like making calls.
The actual phones used come from the Motorola C1xx family, with the C123
and C155 models preferred for development and testing. One nice feature of
these phones is that they contain the same GSM modem as the OpenMoko
handset; that made life a lot easier. These phones also have a headset
jack which can, under software control, be turned into an RS-232 port; this
jack is how software is loaded onto the phone.
At this point, the hardware drivers for this phone are complete; the layer
1-3 implementations are also "quite complete." The OsmocomBB stack is now
able to make voice calls, working with normal cellular operators. The
user interface is not meant for wider use - tasks like cellular
registration and dialing are command-line applications - but it all works.
The code is also nicely integrated with wireshark; there are dissectors for
the protocols in the wireshark mainline now.
Things which are not working include reading SIM cards, automatic power
control (the phone always operates with fixed transmit power), and data
transmission with GPRS. Getting GPRS working is evidently a lot of work,
and there does not seem to be anybody interested in doing it, so Harald
thinks there is "not much of a future" for GPRS support. Also not
supported is 3G, which is quite different from GSM and which will not be
happening anytime soon. There is also, naturally enough, no official
approval for the stack as a whole. Even so, it's a capable system at this
point; it is, Harald says, "an Ethernet card for GSM." With OsmocomBB,
developers who want to build something on top of GSM have a platform they
can work with.
The developers have already discovered a few "wild things" which can be
done. It turns out, for example, that there is no authentication of
deregistration messages. So it is possible to kick any other phone off the
cellular network. There are some basic fuzzing tools available for those
who would like to stress the protocols; their usefulness is limited,
though, by the fact that the developers can't get any feedback from the
The GSM industry, Harald says, is making security analysis difficult. So
it should not be surprising that the security of existing GSM stacks is
quite low. Things are going to have to change in the future; Harald hopes
that OsmocomBB will help to drive that change. It is, however, up to the
security community to make use of the tools which have been created for
them. He hopes that community will step up to the challenge. At this
point, TCP/IP security is a boring area; GSM security is where the
interesting action is going to be.
to post comments)