diff options
Diffstat (limited to '2010/gsm_security')
| -rw-r--r-- | 2010/gsm_security/gsm_security.tex | 767 |
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} |