import of old now defunct presentation slides svn repo

1 files changed, 767 insertions, 0 deletions

diff --git a/2010/gsm_security/gsm_security.tex b/2010/gsm_security/gsm_security.tex
new file mode 100644
index 0000000..18db4d5
--- /dev/null
+++ b/2010/gsm_security/gsm_security.tex
@@ -0,0 +1,767 @@
+\documentclass[a4paper]{article}
+\usepackage[english]{babel}
+\usepackage{graphicx}
+\usepackage{subfigure}
+\pagestyle{plain}
+
+%\usepackage{url}
+
+\setlength{\oddsidemargin}{0in}
+\setlength{\evensidemargin}{0in}
+\setlength{\topmargin}{0in}
+\setlength{\headheight}{0in}
+\setlength{\headsep}{0in}
+\setlength{\textwidth}{6.5in}
+\setlength{\textheight}{9.5in}
+%\setlength{\parindent}{0in}
+\setlength{\parskip}{0.05in}
+
+\begin{document}
+
+\title{GSM Air interface DoS Attack on the RACHe}
+\author{Harald Welte $<$laforge@gnumonks.org$>$}
+\maketitle
+
+\begin{abstract}
+%% add citation for the nubmer of gsm users and phones / carriers.
+Billions of cell phones are being used every day by an almost equally large
+number of users.  The majority of those phones are built according to
+the GSM protocol specifications and interoperate with GSM networks of hundreds
+of carriers.
+
+Despite being an openly published international standard, the architecture of
+GSM networks and its associated protocols are only known to a relatively
+small group of R\&D engineers.
+
+Even less public information exists about the security weaknesses of that
+architecture and inherent limitations
+
+This paper is an attempt to serve as an introductory text into the commonly-known
+security issues of the GSM mobile telephony system.
+\end{abstract}
+
+%\tableofcontents
+
+\section{Foreword}
+
+This document is the result of my personal research on mobile phone
+hardware and system-level software throughout the last six years.
+
+Despite my past work for Openmoko Inc., I have never been professionally
+involved in any aspect of the actual GSM related hardware of any phone.
+Nevertheless I have the feeling that in the wider information technology
+industry, I am part of a very, very small group of people who actually
+understand mobile phones down to the lowest layer.
+
+I hope it is useful for any systems level engineer with an interest in
+understanding more about how mobile phone hardware actually works.
+
+There are no guarantees for accuracy or correctness of any part of the
+document.  I happily receive your feedback and corrections.
+
+\section{Is your phone smart or does it have features?}
+
+Initially, for the first couple of years, GSM cell phones were actual phones
+with very little additional functionality.  They provided everything that was
+required for voice calls, as well as SIM phone book editing features.  The only
+additional non-features were simple improvements like the ability to use them
+as an alarm clock.
+
+In the mid-1990s, a certain new type of devices became popular: The PDA
+(personal digital assistant).  They pioneered handheld computing by introducing
+touch screen user interfaces and a wide range of application programs, ranging
+from calendar/scheduling applications, dictionaries, exchange rate and tip
+calculators, scientific calculators, accounting / finance software, etc.
+
+While in mobile phones the actual cellphone aspect was becoming more and more
+commoditized, at some point the PDA features and functionalities were added to
+phones, coining the term {\em smartphone}.  At that point there was a
+need to differentiate from those phones that were not-so-smart.  Those
+phones were then called {\em feature phones}.
+
+There has never been an industry-wide accepted definition of those terms,
+and especially in the late 2000s, feature phones started to inherit a lot
+of the functionality that was formerly only present in smartphones.
+
+This document will define the terms (only for the purpose of this document)
+along a very clear border in hardware architecture, as will be described in the
+following sections:
+
+\subsection{Feature Phone}
+
+A feature phone is a phone that runs the GSM protocol stack (the software
+implementing the GSM protocol) as well as the user interface and all
+applications on a single processor.  For historic reasons, this
+processor is known as the so-called {\em baseband processor} (BP).
+
+The baseband processor often exposes a serial port (or today USB) over which
+the phone can be used as a terminal adapter, similar to old wireline modems.
+The industry standard protocol for this interface is an AT command set -
+extended and modified from how computers interfaced old wireline modems.
+The AT-command interface can be connected to a computer.  The computer can then
+use the phone to establish data calls, send/receive short messages via SMS,
+and generally remote-control the phone.
+
+\subsection{Smartphone}
+
+A smartphone is a phone that has a dedicated processor for the GSM protocol
+stack, and another (potentially multi-core) general purpose processor for
+the user interface and applications.  This processor is known as the
+{\em application processor} (AP).
+
+The first hardware generations of smartphones did nothing else but to put the
+feature phone and a PDA into one case.  The keypad and display of the baseband
+processor is removed.  What remains of the feature phone is a {\em GSM modem},
+controlled by AT commands sent from the AP.
+
+Each processor has its own memory (RAM and Flash), peripherals, clocking, etc.
+So this setup is not to be confused with the symmetric multi-processor setups
+like those seen in the personal computer industry.
+
+Later generations of smartphones have exchanged the AT command interface by
+various proprietary protocols.  Also, the serial line was replaced by a
+higher-bandwidth hardware connection such as USB, SPI or a shared memory
+interface.
+
+Due to market pressure for ever smaller phones with ever more functions,
+the industry has produced highly integrated products, uniting the AP and BP
+inside one physical package.  Further pressure on reducing cost and PCB
+footprint has led to products where there is no need to have independent
+RAM and Flash chips for AP and BP.  Rather, a single RAM and Flash chip
+is divided by assigning portions of the RAM and Flash to each of the two
+processors.
+
+However, the fundamental separation between the AP and BP, each with their own
+memory address space and software, remains present in all smartphones until
+today.
+
+\section{GSM modem architecture}
+
+Every GSM phone, feature phone and smartphone alike, has a GSM modem interfacing
+with the GSM network.
+
+This GSM modem consists of several parts:
+\begin{itemize}
+\item RF Frontend, responsible for receiving and transmitting on GSM frequencies
+\item Analog Baseband, responsible for modulation and demodulation
+\item Digital Baseband, responsible for digital signal processing and the GSM protocol stack
+\end{itemize}
+
+\begin{figure}[h]
+\centering
+\includegraphics[width=160mm]{calypso-block.pdf}
+\caption{Block schematics of a TI Calypso/Iota/Rita GSM modem}
+\label{reg-form}
+\end{figure}
+
+\subsection{The RF Frontend}
+
+The RF Frontend is tasked with the physical receive and transmit
+interface with the GSM air interface (sometimes called Um interface).
+
+It minimally consists of an antenna switch, GSM band filters, low-noise
+amplifier (LNA) for the receive path, power amplifier for the transmit
+path, a local oscillator (LO) and a mixer.
+
+By mixing the LO frequency with the received RF signal, it generates an
+analog baseband signal that is passed to the Analog Baseband (ABB) part
+of the modem.  By mixing the output of the ABB with the LO frequency, it
+generates a RF signal that is to be transmitted in the GSM frequency
+band.
+
+As the receive and transmit framing has an offset of 3 TDMA frames,
+there is no need for a frequency duplexer.  Instead, an antenna switch
+is used.  The switch typically is implemented using a MEMS or diode
+switch.  For a quad-band phone, typically a single-pole 6-throw (SP6T)
+switch is used: 4 for the four Rx bands (one for each band), and 2 for
+Tx (where 850+900 and 1800+1900 each share one PA output, respectively).
+
+\subsubsection{RF Frontend receive path}
+
+The antenna picks up the GSM radio signal as it is sent from a GSM cell tower
+(properly called a Base Transceiver Station, or abbreviated as BTS).  The
+antenna signal first hits the antenna switch, which connects the antenna with
+the Rx path for the GSM band of the to-be-received radio frequency.  It is then
+filtered by a bandpass to block out-of-band signals before entering a low-noise
+amplifier for increasing signal amplitude.
+
+After passing the LNA, the RF signal is mixed with a frequency generated
+by the LO.  Depending on the LO signal, either an intermediate frequency
+(IF) or a direct baseband signal is produced.  In modern GSM modems,
+zero-IF designs with immediate down-conversion to analog baseband
+signals are most common.
+
+The baseband signal is then filtered to remove unwanted images and sent
+as analog I/Q signals (representing amplitude and phase) to the ABB.
+
+\subsubsection{RF Frontend transmit path}
+
+The ABB generates analog I/Q signals, which are filtered and passed
+into the mixer, where they are mixed with the LO frequency and thus
+up-converted to the GSM RF band.  From there, they are sent to the
+transmit amplifier (RF PA) for amplification.  After amplification, they
+traverse the antenna switch and are transmitted by the antenna.
+
+\subsubsection{Local Oscillator}
+
+The LO of a GSM modem has to be synchronized very closely to that of the
+cell (BTS).  To achieve the required precision, a Voltage-Controlled,
+Temperature-Compensated Crystal Oscillator (VCTCXO) is used.
+
+Common frequencies for this VCTCXO are 26MHz or 13MHz, as the GSM bit
+clock (270,833 Hz) is an integral division (/96 or /48, respectively) of
+those frequencies.  The tuning range of the VCTCXO is several kHz to
+compensate for temperature drift.
+
+\subsection{The Analog Baseband (ABB)}
+
+The ABB part of a GSM modem is responsible to interface between the
+digital domain and the analog domain of the GSM modem.
+
+\subsubsection{ABB Receive path}
+
+The analog baseband I/Q signals are potentially filtered again and
+digitized by an Analog-Digital converter (ADC).  The sample clocks used
+are typically integral multiples of the GSM bit-clock.  The sample clock
+itself is derived by dividing the VCTCXO of the RF frontend.
+
+The digital I/Q samples are passed to the Digital Signal Processor
+(DSP) in the Digital Baseband (DBB).  To reduce the number of traces to
+be routed on the PCB, the samples are typically sent over some kind of
+synchronous serial link.
+
+\subsubsection{ABB Transmit path}
+
+There are multiple architectures found in the ABB transmit path.
+
+The obvious architecture is to do the inverse of the receive operation:
+Transmit digital I/Q samples from the DSP to the ABB and convert
+them into an analog signal that is then to be sent to the mixer of the
+RF Frontend.
+
+However, sending a GSM signal with its GMSK modulation is much simpler
+than receiving.  So in order to reduce computational complexity (and
+thus cost as well as power consumption) inside the DSP, the modulation
+of the bits is often performed in hardware inside the ABB.
+
+In this design, the unmodulated GSM burst bits are sent from the DBB to
+a burst buffer inside the ABB.  From there, based on ROM tables and a
+Digital-to-Analog converter (DAC), an analog GMSK modulated signal is
+generated.
+
+\subsection{The Digital Baseband (DBB)}
+
+The digital baseband implements the actual GSM protocols from Layer1 up
+to Layer3 as well as higher layers such as a user interface in the case
+of the feature phone.  In a smartphone, the DBB only implements a
+machine interface to be used by the AP.
+
+A typical DBB design includes a Digital Signal Processor (DSP) for the
+lower half of Layer1, and a general-purpose processor (MCU) for the
+upper part of Layer1, as well as anything above.
+
+\subsubsection{Digital Signal Processor}
+
+The choice of DSP architecture largely depends on the DBB chipset
+vendor. Often they already have a line of DSP cores in-house and will of
+course want to reuse that in their DBB chip designs.  Every major DSP
+architecture can be found (TI, Analog Devices, ...).
+
+The DSP performs the primary tasks such as Viterbi equalization,
+demodulation, decoding, forward error correction, error detection, burst
+(de)interleaving.
+
+Of course, if actual speech data is to be communicated over the GSM
+network, the DSP will also have the auxiliary task to perform the
+computation of the lossy speech codec used to compress the speech.
+
+Communication between the DSP and MCU happens most commonly by a shared
+memory interface.  The shared memory contains both actual data that is
+to be processed, as well as control information and parameters
+describing what to be done with the respective data.
+
+For the receive side, the MCU will instruct the DSP to perform decoding
+for a particular GSM burst type, after which the DSP will receive I/Q
+samples from the ABB, perform detection/demodulation/decoding and
+report the result of the operation (including any decoded data) back to
+the MCU.
+
+For the transmit path, the MCU will present the to-be-transmitted data
+and auxiliary information to the DSP, which then takes care of encoding
+and sends the corresponding burst bits to the ABB (remember, most ABB
+devices take care of the modulation to reduce DSP load).
+
+The detailed programming information (API) of the DSP shared memory
+interface is a closely-guarded secret of the baseband chip maker and is
+not commonly disclosed even to their customers (the actual phone making
+companies).
+
+In doing so, the baseband chip makers create a close dependency between
+the GSM Layer1 software (running on the MCU) driving/implementing this
+API and the actual baseband chip.  Whoever buys their chip will also
+have to license their GSM protocol stack software.
+
+It is thus almost impossible for an independent software vendor to get
+access to the DSP API documentation, which the author of this paper
+finds extremely anti-competitive.
+
+\subsubsection{DSP Peripherals}
+
+The specifications of the GSM proprietary On-air encryption A5/1 and
+A5/2 are only made available to GSM baseband chip makers who declare
+their confidentiality.  Implementing the algorithm in software is
+apparently considered as breach of that confidentiality.  Thus, the
+encryption algorithms are only implemented in hardware - despite them
+being reverse-engineered and publicly disclosed by cryptographers as
+early as 1996. %% cite
+
+Thus, the DSP in a DBB commonly has a integrated peripheral implementing the A5
+encryption. 
+
+Further integrated DSP peripherals may include a viterbi hardware accelerator,
+a DMA capable serial interface to the ABB and others.
+
+\subsection{Baseband Processor (MCU)}
+
+The MCU of almost all modern GSM DBBs is a System-on-a-Chip (SoC) utilizing a
+32bit ARM7TDMI core.  The only notable exception are low-cost Infineon chips
+like PM7870, who still use a version of their 16bit C166 core.
+
+Baseband chips that support 3G cellular networks often use a more powerful
+ARM926 or ARM975 core as MCU.
+
+\subsection{MCU peripherals}
+
+The MCU cores have the typical set of peripherals of any ARM7 based
+microcontroller, such as RTC, UARTs for RS232 and IRDA, SPI, I2C, SD/MMC card
+controller, keypad scan controller, USB device, ...
+
+However, there are some additional peripherals that are very GSM specific:
+\begin{itemize}
+\item A GPRS crypto unit for the proprietary GEA family of ciphers
+\item Extended power management facilities, including a timer that can calibrate the RTC clock based on the synchronized VCTCXO in order to wake-up the MCU ahead of pre-programmed events in the GSM time multiplex
+\item GSM TDMA timers that can synchronize to the on-air time frames and generate interrupts to MCU and DSP
+\item Software-programmable hardware state machines for sequencing GSM burst Rx or Tx in ABB and RF Frontend
+\item An ISO7816 compatible smart card reader interface for the SIM card
+\item Audio routing, i.e. selecting how audio is routed in the phone,
+considering integrated earpiece, ringtone speaker and microphone, as
+well as external analog headset, handsfree or even bluetooth-attached
+audio devices.
+\end{itemize}
+
+The programming of those peripherals is highly device-specific and there are no
+industry standards.  Every DBB architecture of every supplier has its own
+custom register set and programming interface.
+
+The register-level documentation for those proprietary peripherals is (like all
+documentation on DBB chipsets) closely guarded by NDAs, effectively preventing
+the development of Free Software / Open Source drivers for them, unless such
+documents are leaked by third parties.
+
+However, as opposed to the DSP API documentation, the register-level
+documentation to the MCU peripherals is normally provided to the cellphone
+manufacturers.
+
+\section{Digital Baseband Software Architecture}
+
+This section provides an introductory reading in the typical software
+architecture as it is found on contemporary GSM digital baseband designs.
+
+The MCU usually runs a very small realtime operating system (RTOS) such
+as Nucleus, VxWorks or the L4 microkernel.  In some cases, no operating
+system is used at all, in order to save royalties or licensing fees that
+would occurr for proprietary RTOS. 
+
+\subsection{GSM Layer 1}
+
+The Layer1 (L1) software is highly device-specific, as it closely interacts
+with the DSP using the shared memory DSP API, as well as the proprietary
+integrated peripherals controlling the ABB and RF Frontend.
+
+However, there are some general observations that can be made about the L1:
+
+\subsubsection{L1 Synchronous part}
+
+The synchronous part is executed synchronously to the GSM TDMA frame clock.
+Both CPU and DSP are interrupted by some hardware GSM timer every TDMA frame.
+
+The L1 synchronous part typically runs inside IRQ or FIQ context of the MCU,
+taking care of retrieving data from and providing data to the DSP API.
+
+\subsubsection{L1 Asynchronous part}
+
+The asynchronous part is scheduled as a normal task, potentially with high
+or even real-time priority.  It picks up the information provided by the L1
+Sync and schedules its next actions.
+
+The L1 async typically communicates via a message queue with the Layer2
+above.  Common primitives for L1 control are described (as non-normative parts)
+of the GSM specifications.
+
+\subsection{GSM Layer 2}
+
+As opposed to L1, the GSM Layer 2 (L2) is already fully hardware independent.
+It implements the LAPDm protocol as specified in GSM TS 04.06.  LAPDm is a
+derivative of the ISDN Layer 2 called LAPD, which in turn is a descendent
+of the HDLC family of protocols.
+
+LAPDm takes care of providing communication channels for Layer3.  Those
+channels are protected from frame loss by the use of sequence numbers and
+retransmissions.
+
+The interface to Layer3 is typically implemented by means of a message queue.
+
+Primitives (but no detailed protocol) for use of the Layer2 / Layer3 interface
+are provided in the GSM specifications.
+
+\subsection{GSM Layer 3}
+
+GSM Layer 3 (L3) consist of sublayers for Radio Resource (RR), Mobility
+Management (MM) and Call Control (CC).
+
+There is sufficient treatment of the GSM L3 and its sublayers in
+existing texts, so there is no point in making a futile attempt
+repeating that here.
+
+\section{Synchronization and Clocking}
+
+The author of this paper has been quoted saying {\em GSM is a synchronous
+TDMA nightmare}.  This is by no means intended as an insult to the
+technology itself or to its inventors.  It merely serves as evidence how
+hard it is to get into the synchronous TDMA mindset, especially for
+engineers who have spent most of their career in the world of packet
+switched networks.
+
+GSM is synchronous in multiple ways between cell (BTS) and phone (MS):
+\begin{itemize}
+\item Synchronization of the carrier clock to tune the receiver and transmitter to the correct frequency
+\item Synchronization of the bit clock in order to perform sampling at the most optimal sample intervals
+\item Synchronization of the frame clock (and thus timeslots) to know when a TDMA frame and its 8 timeslots start
+\item Synchronization of the TDMA multiplex to correctly (de)multiplex the logical channels that are sent over each timeslots
+\end{itemize}
+
+As all those clocks are related to each other, they can (and should) all be
+derived from the same master clock:  The VCTCXO present in each GSM
+phone.
+
+\subsection{How to synchronize the VCTCXO}
+
+Every cell sends frequency correction bursts as part of the Frequency
+Correction CHannel (FCCH), which is itself part of the BCCH, which in turn is
+constantly transmitted by the BTS.
+
+To acquire initial synchronization to the GSM network, the LO is tuned to the
+desired GSM RF channel (ARFCN) frequency.  However, at this point, the LO
+frequency is a multiple of the VCTCXO frequency which in turn still has an
+undetermined error.  This initial frequency error is as large as that of a
+regular crystal oscillator, potentially already with temperature compensation.
+
+The resulting baseband signal thus can be shifted by a fairly large amount in
+our baseband spectrum.  A specific DSP code is now using correlation and other
+techniques to identify the frequency correction burst.  The DSP can then
+further calculate the actual frequency error of the LO by comparing the
+received FCCH burst with the FCCH burst as specified.
+
+This computed frequency error can be fed into a (software) frequency control
+loop filter.  The loop filter output is applied to an auxiliary DAC, which
+generates the control voltage for the VCTCXO.
+
+After a number of FCCH bursts and corresponding frequency control loop
+iterations, the VCTCXO generated clock has only a residual error.  Whenever the
+phone is receiving, the frequency control loop is continuously exercised in
+order to maintain synchronization.
+
+\subsection{How to synchronize the frame clock}
+
+When the DSP performs FCCH burst detection as described above, it identifies
+the exact position in the incoming sample stream when the FCCH burst was
+happening.  By knowing from the specification that the FCCH burst is
+part of the BCCH, and that the BCCH is sent on timeslot 0, the Layer1
+software can then synchronize the phone to the TDMA frame start.
+
+Commonly, a hardware timer unit is clocked by a (divided) VCTCXO clock and thus
+counts in multiples of the GSM bit clock, wrapping/resetting at the TDMA duration
+of 1250 bits.
+
+By scheduling events synchronously to this GSM bit-clock timer, the L1 can now
+trigger events (such as asking the DSP to demodulate incoming data) or
+instructing the LO to retune synchronously to every TDMA frame.
+From this timer the DBB typically also generates interrupts to the DSP and MCU.
+
+\subsection{How to synchronize the GSM TDMA multiplex}
+
+As part of the BCCH, the BTS not only sends the FCCH but also the
+Synchronization CHannel (SCH).  The Synchronization channel indicates the
+current GSM time / frame number (skipping the 3 least significant bits).
+By using this received GSM time and incrementing it every time the GSM bit-clock
+timer wraps at the beginning of a new TDMA frame, the GSM time is synchronized.
+
+Understanding the multiple layers of time multiplex such as the 26/51
+multiframe, superframe and hyperframe, the L1 can multiplex and demultiplex all
+the logical channels of GSM.
+%% this is awkwardly worded
+
+\section{Miscellaneous Topics}
+
+\subsection{GPRS}
+
+GPRS was the first packet switched extension to GSM.  In fact, it is much more
+its entirely own mobile network, independent of GSM.  The only parts shared are
+the GSM modulation scheme (GMSK) and time multiplex, in order to ensure peaceful
+coexistence between them.
+
+The L1 and L2 protocols are very different (and much more complex) than GSM.
+
+So while the phone baseband hardware did not need any modifications for a basic
+GPRS enabled phone, the software needed to be extended quite a lot.
+
+\subsection{EDGE}
+
+EDGE is a very small incremental set of changes from GPRS.  It reuses all of
+the time multiplex and protocol stack, but introduces a new modulation: Offset
+8-PSK instead of GMSK to increase the bandwidth that can be transmitted.
+Offset 8-PSK is used (as opposed to simple 8-PSK) to avoid
+zero-crossings in the modulator output.
+
+So while the software modifications from GPRS to EDGE are minimal, the 8PSK
+modulation scheme has a significant impact on the DSP, ABB and even RF
+PA design.
+
+\subsection{UMTS}
+
+UMTS (sometimes called WCDMA) is an entirely separate cellular network
+technology.  Its physical layer, modulation schemes, encoding, frequency
+bands, channel spacing are entirely different, as is the Layer1.
+
+UMTS Layer2 has some resemblance to the GPRS Layer2.
+
+UMTS Layer3 for Mobility Management and Call Control are very similar to GSM.
+
+Given the vast physical layer and L1 differences, a UMTS phone hardware design
+significantly differs from what has been described in this document.
+
+Notwithstanding, all known commercial UMTS phone chipsets as of today still
+include a full GSM modem in hardware and software to remain
+backwards-compatible.
+
+\subsection{Dual-SIM and Triple-SIM phones}
+
+In recent years, a large number of so-called {\em Dual-SIM} or even {\em
+Triple-SIM} phones have entered the market, particularly in China and other
+parts of East Asia.
+
+Those phones come in various flavours.  Some of them simply have a multiplexer
+that allows electrical switching between multiple SIM card slots.  This is
+similar to replacing the SIM card in a phone, just without the manual process
+of mechanically removing/inserting the card.  As a result, you can only use one
+of the two SIMs at any time.
+
+The more sophisticated Dual-SIM phones have two complete phones in one case.  Yes,
+that's right!  They contain two full GSM phone chipsets, i.e. 2 antennas, 2 rf
+frontends, 2 analog basebands, 2 digital basebands, ...
+
+However, they use the same trick as smartphones:  One of the two basebands does
+not have keypad or display and is simply a GSM modem connected via serial line
+to the other baseband processor.
+
+So if a smartphone (as defined in this document) is a GSM modem connected to a
+PDA in one case, a Dual-SIM phone is a GSM modem connected to a feature phone
+in one case.
+
+Triple-SIM phones often combine the two approaches, i.e. they contain two
+complete GSM baseband chips, but three SIM slots that can be switched among
+the base bands.  Only two SIMs can be active at the same time.
+
+\subsection{Powerful feature phones}
+
+Feature phones are becoming more and more powerful.  However, their
+comparatively lower market price cannot afford a full-blown smartphone design
+with its two independent processors and the associated design complexity.
+
+Thus, more and more hardware peripherals are added to the only processor left
+in the phone: The baseband processor.  Such peripherals include sophisticated
+camera interfaces, high-resolution color display controllers, TV output,
+touchscreen controllers, audio and video codecs and even interfaces for mobile
+TV reception.
+
+However, all of those features are still implemented on a fairly weak ARM7 or
+ARM9 CPU core (compared to ARM11 and Cortex-A8 in the smartphone market).  They
+also lack a real operating system and still run on top of a real-time
+microkernel intended for much less complex systems.  They almost always lack
+any form of memory protection or multiple address spaces.  This makes them
+more prone to security issues as there is no privilege separation between
+the GSM protocol stack and the applications, or between the applications
+themselves.
+
+\subsection{GSM baseband security features}
+
+There are several (sometimes conflicting) security requirements that
+apply to mobile phones.  Interestingly, the security features are
+typically used to protect some industry interest against the interest of
+the customer.  There are very few security features in a phone that are
+meant to protect the users or their interests.
+
+\subsubsection{IMEI - The hardware serial number}
+
+The International Mobile Equipment Identifier (IMEI) uniquely identifies
+a GSM phone.  It is a globally unique serial number which is programmed
+into the phone non-volatile memory (Flash or EEPROM) during the
+production process.  There are no particular security features used to
+store the IMEI.  Once you are able to write to flash and have found it,
+it can be changed.
+
+\subsubsection{The SIM Card}
+
+The SIM card is a cryptographic smart card that stores the secret key
+used for authenticating the user to the GSM network (Ki).  The Ki is
+never released by the card, and as such copying (cloning) of the SIM
+is prevented.  Some early implementations of the SIM card had
+cryptographic weaknesses that inadvertently permitted cloning until the
+late 1990s.
+
+Furthermore, the SIM stores the International Mobile Subscriber Identity
+(IMSI).  The IMSI is not encrypted or protected in any way.
+
+There is no security channel on the connection between the SIM card and
+the baseband MCU.  Furthermore, there is no way how the MCU can securely
+identify/authenticate the SIM itself.  Physical access to the SIM card
+slot allows sniffing and/or modification of the communications between
+the MCU and the SIM.
+
+\subsubsection{SIM or Operator Locking}
+
+GSM is an international standard.  This ensures interoperability, i.e.
+any phone can be used on any network.
+
+However, in some cases, the vendors of a GSM phone want to restrict this
+interoperability and lock a phone to one specific network, or even lock
+it to a particular SIM.
+
+Those locks are implemented by software only, i.e. the MCU software will
+instruct the GSM protocol stack not to register with a network unless
+its network operator code is a certain factory-programmed network number.
+
+As such, techniques for circumventing those locks have become
+commonplace.  It's somewhat of an ongoing race between the phone makers
+and the phone-unlockers.  The industry invents ever more complex methods
+of obfuscating their locks in the software, while the phone-unlockers
+reverse engineer those bits for each and every phone model after some
+time.
+
+\subsubsection{DBB firmware signatures}
+
+In order to protect the operator and phone manufacturers peculiar
+business models based on SIM or operator locking, some vendors
+extended their baseband software with cryptographic signatures.  Only
+if the correct signature is present in a software update, the bootloader
+program will accept the new software.
+
+However, there are more or less invasive hardware-related approaches in
+circumventing those signature checks, such as hardware debugging
+interfaces like JTAG, or replacing the external flash memory components.
+
+More recently, GSM chipset vendors introduced features such as
+hardware-assisted software signature checks.  In this case a master key
+hash might be present in DBB-internal fuses, together with a
+signature-verifying boot loader in DBB-internal mask ROM.  As the root
+of the chain of trust is moving deeper into the hardware, it becomes
+more difficult for anyone to make software modifications to the DBB.
+
+Especially with tighter integration, where RAM and FLASH are no longer
+present as discrete components but part of a multi-chip-package, the
+number of options are becoming more limited.
+
+On the other hand, an ever more complex baseband software stack is
+opening up many more options for exploiting software vulnerabilities.
+Given the lack of a proper/modern operating system with privilege
+separation and virtual memory, such exploits immediately give away
+full access to all aspects of the respective DBB.
+
+\section{Personal rant on the closedness of the GSM industry}
+
+The GSM industry is one of the most closed areas of computing that I've
+encountered so far.  It is very hard to get any hard technical
+information out of them.  All they like to spread is high-level
+marketing information, but they're very reluctant when it comes down to
+hard technical facts on their products.
+
+If you want to build a phone, you need to buy a GSM chipset for your
+product.  There are only very few companies that offer such chipsets.
+The classic suppliers are Infineon, Texas Instruments, ST/Ericsson, ADI
+(now MediaTek) and Freescale.
+
+The GSM handset products they sell are not generally available and
+distributed like other electronic components they manufacture.  If you
+need a Microcontroller/SoC, a power management IC, a Wifi or Bluetooth
+chip, RFID reader ASIC, you simply approach the respective distributors
+and order them.  You get your samples directly from Digikey.
+
+This is impossible for GSM (or other cellphone) chipsets.  For some
+reason those chips are sold only to hand-picked manufacturers.  If you
+want to qualify, you have to subscribe to at least six-digit annual
+purchasing quantities.  And in order for them to believe you, you have
+to cough up a significant NRE (non-refundable engineering fee).  This
+has been reported as high as a seven-digit US\$ amount and is to make
+sure that even if you end up buying less chips than you indicate, the
+chipset maker will still have your upfront NRE money and keep it.
+
+And if you buy your way into that select club of cellphone makers, what
+you get from the chipset maker is typically not all too impressive
+either.   The documentation you get is incomplete, i.e. it alone would
+not enable you as a cellphone maker to make any use of the hardware,
+unless you license the software (drivers, GSM protocol stack, ...) from
+the chipset maker, too.
+
+On the software side, most of the technologically interesting bits (like
+the protocol stack) are provided as binary-only libraries, you only get
+source code to some parts of the systems, i.e. some hardware drivers
+that might need modification for your particular phone electrical
+design.
+
+That GSM protocol stack was not written by the chipset maker either.
+They simply license a stack from one of the estimated 4 or 5
+organizations who have ever implemented a commercial GSM protocol stack.
+
+It is not like the GSM protocols were some kind of military secret.
+They are a published international standard, freely accessible for
+anyone.  So why does everybody in that industry think that there is
+a need to be so secretive?
+
+Having spent a significant part of the last 6 years with reverse
+engineering of various aspects of mobile phones in order to understand
+them better and to write software tools for security analysis, I still
+don't understand this secrecy.
+
+All the various vendors do more or less the same.  The fundamental
+architecture of a GSM baseband chip is the same, whether you buy it from
+TI, Infineon or from MediaTek.  {\em They all cook with water}, like we
+Germans tend to say.  The details like the particular DSP vendor or
+whether you use a traditional IF, zero-IF or low-IF analog baseband
+differ.  But from whom do they want to hide it?  If people like myself
+with a personal interest in the technical aspects of mobile phones can
+figure it out in a relatively short time, then I'm sure the competition
+of those chipset makers can, too.  In much less time, if they actually
+care.
+
+This closedness of the cellular industry is one of the reasons why there
+has been very little innovation in the baseband firmware throughout the
+last decades.  Innovation can only happen by very few players.  Source
+code bugs can only be found and fixed by very few developers at even
+fewer large corporations.  There is little to no chance for a small start-up to
+innovate, like they can in the sphere of the internet.
+
+It is fundamentally also the reason why the traditional phone makers
+have been losing market share to newcomers to the mobile sphere like
+Apple with its iPhone or Google with its Android platform.
+
+Those innovations really only happened on the application processor on
+high-end smartphones.  The closed GSM baseband processor had to be
+accompanied by an independent application processor running a real
+operating system, with real processes, memory management, shared
+libraries, memory protection, virtual memory spaces, user-installable
+applications, etc.
+
+They still don't happen on the baseband processor, which is as closed as
+it was 15 years ago.
+
+\end{document}