\documentclass{beamer}

\mode<presentation>
{
  \usetheme{Warsaw}
  % or ...

  \setbeamercovered{transparent}
  % or whatever (possibly just delete it)
}

\usepackage[english]{babel}
\usepackage[latin1]{inputenc}
\usepackage{times}
\usepackage[T1]{fontenc}

\title{OpenBSC network-side GSM stack}

\subtitle
{running on top of Linux}

\author{Harald Welte <laforge@gnumonks.org>}

\institute
{gnumonks.org\\gpl-violations.org\\OpenBSC\\airprobe.org\\hmw-consulting.de}

\date[Linux Kongress 2009]
{Linux Kongress 2009, October 2009, Dresden/Germany}

\subject{GSM}


% If you have a file called "university-logo-filename.xxx", where xxx
% is a graphic format that can be processed by latex or pdflatex,
% resp., then you can add a logo as follows:
% \pgfdeclareimage[height=0.5cm]{university-logo}{university-logo-filename}
% \logo{\pgfuseimage{university-logo}}


% If you wish to uncover everything in a step-wise fashion, uncomment
% the following command: 
%\beamerdefaultoverlayspecification{<+->}


\begin{document}

\begin{frame}
  \titlepage
\end{frame}

\begin{frame}{Outline}
  \tableofcontents
  % You might wish to add the option [pausesections]
\end{frame}


% Structuring a talk is a difficult task and the following structure
% may not be suitable. Here are some rules that apply for this
% solution: 

% - Exactly two or three sections (other than the summary).
% - At *most* three subsections per section.
% - Talk about 30s to 2min per frame. So there should be between about
%   15 and 30 frames, all told.

% - A conference audience is likely to know very little of what you
%   are going to talk about. So *simplify*!
% - In a 20min talk, getting the main ideas across is hard
%   enough. Leave out details, even if it means being less precise than
%   you think necessary.
% - If you omit details that are vital to the proof/implementation,
%   just say so once. Everybody will be happy with that.

\begin{frame}{About the speaker}
\begin{itemize}
	\item Always been fascinated by networking and communications
	\item Using + playing with Linux since 1994
	\item Kernel / bootloader / driver / firmware development since 1999
	\item IT security specialist, focus on network protocol security
	\item Board-level Electrical Engineering
	\item Always looking for interesting protocols (RFID, DECT, GSM)
\end{itemize}
\end{frame}

\section{GSM/3G security}

\begin{frame}{GSM/3G protocol security}
\begin{itemize}
	\item Observation
	\begin{itemize}
		\item Both GSM/3G and TCP/IP protocol specs are publicly available
		\item The Internet protocol stack (Ethernet/Wifi/TCP/IP) receives lots of scrutiny
		\item GSM networks are as widely deployed as the Internet
		\item Yet, GSM/3G protocols receive no such scrutiny!
	\end{itemize}
	\item There are reasons for that:
	\begin{itemize}
		\item GSM industry is extremely closed (and closed-minded)
		\item Only about 4 closed-source protocol stack implementations
		\item GSM chipset makers never release any hardware documentation
	\end{itemize}
\end{itemize}
\end{frame}

\subsection{The closed GSM industry}

\begin{frame}{The closed GSM industry}{Handset manufacturing side}
\begin{itemize}
	\item Only very few companies build GSM/3.5G baseband chips today
	\begin{itemize}
		\item Those companies buy the operating system kernel and the protocol stack from third parties
	\end{itemize}
	\item Only very few handset makers are large enough to become a customer
	\begin{itemize}
		\item Even they only get limited access to hardware documentation
		\item Even they never really get access to the firmware source
	\end{itemize}
\end{itemize}
\end{frame}

\begin{frame}{The closed GSM industry}{Network manufacturing side}
\begin{itemize}
	\item Only very few companies build GSM network equipment
	\begin{itemize}
		\item Basically only Ericsson, Nokia-Siemens, Alcatel-Lucent and Huawei
		\item Exception: Small equipment manufacturers for picocell / nanocell / femtocells / measurement devices and law enforcement equipment
	\end{itemize}
	\item Only operators buy equipment from them
	\item Since the quantities are low, the prices are extremely high
	\begin{itemize}
		\item e.g. for a BTS, easily 10-40k EUR
	\end{itemize}
\end{itemize}
\end{frame}

\begin{frame}{The closed GSM industry}{Operator side}
\begin{itemize}
	\item Operators are mainly banks today
	\item Typical operator outsources
	\begin{itemize}
		\item Billing
		\item Network planning / deployment / servicing
	\end{itemize}
	\item Operator just knows the closed equipment as shipped by manufacturer
	\item Very few people at an operator have knowledge of the protocol beyond what's needed for operations and maintenance
\end{itemize}
\end{frame}

\subsection{Security implications}

\begin{frame}{The closed GSM industry}{Security implications}
The security implications of the closed GSM industry are:
\begin{itemize}
	\item Almost no people who have detailed technical knowledge outside the protocol stack or GSM network equipment manufacturers
	\item No independent research on protocol-level security
	\begin{itemize}
		\item If there's security research at all, then only theoretical (like the A5/2 and A5/1 cryptanalysis)
		\item Or on application level (e.g. mobile malware)
	\end{itemize}
	\item No open source protocol implementations
	\begin{itemize}
		\item which are key for making more people learn about the protocols
		\item which enable quick prototyping/testing by modifying existing code
	\end{itemize}
\end{itemize}
\end{frame}

\begin{frame}{Security analysis of GSM}{How would you get started?}
If you were to start with GSM protocol level security analysis, where and
how would you start?
\begin{itemize}
	\item On the handset side?
	\begin{itemize}
		\item Difficult since GSM firmware and protocol stacks are closed and proprietary
		\item Even if you want to write your own protocol stack, the layer 1 hardware and signal processing is closed and undocumented, too
		\item Known attempts
		\begin{itemize}
			\item The TSM30 project as part of the THC GSM project
			\item mados, an alternative OS for Nokia DTC3 phones
		\end{itemize}
		\item none of those projects successful so far
	\end{itemize}
\end{itemize}
\end{frame}

\begin{frame}{Security analysis of GSM}{How would you get started?}
If you were to start with GSM protocol level security analysis, where and
how would you start?
\begin{itemize}
	\item On the network side?
	\begin{itemize}
		\item Difficult since equipment is not easily available and normally extremely expensive
		\item However, network is very modular and has many standardized/documented interfaces
		\item Thus, if equipment is available, much easier/faster progress
	\end{itemize}
\end{itemize}
\end{frame}

\begin{frame}{Security analysis of GSM}{The bootstrapping process}
\begin{itemize}
	\item Read GSM specs day and night (> 1000 PDF documents)
	\item Gradually grow knowledge about the protocols
	\item Obtain actual GSM network equipment (BTS)
	\item Try to get actual protocol traces as examples
	\item Start a complete protocol stack implementation from scratch
	\item Finally, go and play with GSM protocol security
\end{itemize}
\end{frame}


\subsection{The GSM network}

\begin{frame}{The GSM network}
  \begin{figure}[h]
  \centering
  \includegraphics[width=100mm]{gsm_network.png}
  \end{figure}
\end{frame}

\begin{frame}{GSM network components}
  \begin{itemize}
    \item The BSS (Base Station Subsystem)
    \begin{itemize}
      \item MS (Mobile Station): Your phone
      \item BTS (Base Transceiver Station): The {\em cell tower}
      \item BSC (Base Station Controller): Controlling up to hundreds of BTS
    \end{itemize}
    \item The NSS (Network Sub System)
    \begin{itemize}
      \item MSC (Mobile Switching Center): The central switch
      \item HLR (Home Location Register): Database of subscribers
      \item AUC (Authentication Center): Database of authentication keys
      \item VLR (Visitor Location Register): For roaming users
      \item EIR (Equipment Identity Register): To block stolen phones
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}{GSM network interfaces}
  \begin{itemize}
    \item Um: Interface between MS and BTS
    \begin{itemize}
	\item the only interface that is specified over radio
    \end{itemize}
    \item A-bis: Interface between BTS and BSC
    \item A: Interface between BSC and MSC
    \item B: Interface between MSC and other MSC
  \end{itemize}
  GSM networks are a prime example of an asymmetric distributed network,
  very different from the end-to-end transparent IP network.
\end{frame}


\subsection{The GSM protocols}

\begin{frame}{GSM network protocols}{On the Um interface}
  \begin{itemize}
    \item Layer 1: Radio Layer, TS 04.04
    \item Layer 2: LAPDm, TS 04.06
    \item Layer 3: Radio Resource, Mobility Management, Call Control: TS 04.08
    \item Layer 4+: for USSD, SMS, LCS, ...
  \end{itemize}
\end{frame}

\begin{frame}{GSM network protocols}{On the A-bis interface}
  \begin{itemize}
    \item Layer 1: Typically E1 line, TS 08.54
    \item Layer 2: A variant of ISDN LAPD with fixed TEI's, TS 08.56
    \item Layer 3: OML (Organization and Maintenance Layer, TS 12.21)
    \item Layer 3: RSL (Radio Signalling Link, TS 08.58)
    \item Layer 4+: transparent messages that are sent to the MS via Um
  \end{itemize}
\end{frame}


\section{OpenBSC: Implementing GSM protocols} 

\subsection{Getting started}

\begin{frame}{Implementing GSM protocols}{How I got started!}
\begin{itemize}
	\item In September 2008, we were first able to make the BTS active and see it on a phone
	\begin{itemize}
		\item This is GSM900 BTS with 2 TRX at 2W output power (each)
		\item A 48kg monster with attached antenna
		\item 200W power consumption, passive cooling
		\item E1 physical interface
	\end{itemize}
	\item I didn't have much time at the time (day job at Openmoko)
	\item Started to read up on GSM specs whenever I could
	\item Bought a HFC-E1 based PCI E1 controller, has mISDN kernel support
	\item Found somebody in the GSM industry who provided protocol traces
\end{itemize}
\end{frame}

\begin{frame}{Implementing GSM protocols}{Timeline}
\begin{itemize}
	\item In November 2008, I started the development of OpenBSC
	\item In December 2008, we did a first demo at 25C3
	\item In January 2009, we had full voice call support
	\item In August 2009, we had the first field test with 2BTS and > 860 phones
\end{itemize}
\end{frame}

\subsection{OpenBSC software architecture}

\begin{frame}{OpenBSC: Overall architecture}
\begin{itemize}
	\item implement BSC, MSC, HLR, AUC, SMSC in a box
	\item Single-theaded, select-loop driven design
	\begin{itemize}
		\item avoids locking/synchronization complexity
		\item makes debugging much easier
		\item amount of singalling traffic low, scalability on multi-core systems not a design goal
	\end{itemize}
	\item Use Linux kernel coding style
	\item Have as few external dependencies as possible
\end{itemize}
\end{frame}

\begin{frame}{OpenBSC: A-bis OML (GSM TS 08.59 / 12.21)}
In order to fully boot and initialize a BTS, the OML (Organization and
Maintenance Layer) needs to be brought up.  It is implemented 
in OpenBSC {\tt abis\_nm.c}
\begin{itemize}
	\item download/installation + activation of BTS software
	\item RF parameters such as ARFCN, hopping, channel configuration
	\item RF power level, calibration, E1 timeslot + TEI configuration
\end{itemize}
\end{frame}

\begin{frame}{OpenBSC: A-bis RSL (GSM TS 08.58)}
The Radio Signalling Link is the signalling layer between BTS and BSC,
implemented in {\tt abis\_rsl.c}
\begin{itemize}
	\item non-transparent messages for BTS-side configuration
	\begin{itemize}
		\item channel activation on the BTS side
		\item channel mode / encryption mode on BTS side
		\item paging of MS
		\item setting of BCCH beacons (SYSTEM INFORMATION)
	\end{itemize}
	\item transparent messages to be passed through to MS
\end{itemize}
\end{frame}

\begin{frame}{OpenBSC GSM Layer 3 (GSM TS 04.08)}
The GSM Um Layer 3 is established between BSC and MS, the BTS
transparently passes it through RSL DATA INDICATION / DATA REQUEST,
implemented in {\tt gsm\_04\_08\_*.c}
\begin{itemize}
	\item Radio Resource (RR)
	\item Mobility Management (MM)
	\item Call Control (CC)
\end{itemize}
\end{frame}

\begin{frame}{OpenBSC: Input Drivers}
\begin{itemize}
	\item Concept of input drivers important, since there are many different E1 driver models and no clear standard (mISDN, VISDN, Sangoma, Zaptel)
	\begin{itemize}
		\item We so far implement a socket-based input driver to the Linux kernel mISDN stack
		\item Some proof-of-concept driver for Sangoma exists
	\end{itemize}
	\item ip.access A-bis over IP interface is very different from E1 interface, but can still be supported by the input driver API
	\item Input drivers are not implemented as plugins, as we don't want proprietary plugins.
\end{itemize}
\end{frame}

\begin{frame}{OpenBSC: mISDN integration}
\begin{itemize}
	\item Physical layer of A-bis is a E1 interface
	\item However, Layer 2 is slightly different to Q.921 on ISDN
	\begin{itemize}
		\item static TEI assignments, no dynamic TEI's
		\item different SAPI's are used for OML, RSL
		\item multiple BTS can be connected to one E1 link, requiring multiple TEI manager instances to run in different timeslots on one E1 line 
	\end{itemize}
	\item Patches have been contributed to mISDN and are in mainline
\end{itemize}
\end{frame}

\begin{frame}{OpenBSC: Multiple processes/Threads}
\begin{itemize}
	\item Currently, there is one single-threaded process for all of
	\begin{itemize}
		\item The signalling part (BSC/MSC features)
		\item Database access (HLR/VLR features)
		\item Relaying/remultiplexing of speech data (TRAU + RTP frames)
		\item SMS store-and-forward (SMSC features)
	\end{itemize}
	\item Single-threaded select loop is great for signalling
	\item TRAU + RTP multiplexing / relaying should become separate media gateway process
	\item SMSC features should become independent process, too.
\end{itemize}
\end{frame}

\begin{frame}{OpenBSC: Database model}
\begin{itemize}
	\item The HLR, EIR, SMSC are simple SQL tables
	\begin{itemize}
		\item {\tt subscribers} is the HLR (IMSI, phone number, tmsi, location area)
		\item {\tt equipment} is the EIR (IMEI, classmark1/2/3)
		\item {\tt sms} is the SMSC, one row for each SMS
	\end{itemize}
	\item At the moment, only SQLite3 is used (simplicity)
	\item DBD layer will enable easy migration to postgresql or MySQL
\end{itemize}
\end{frame}

\subsection{Code Reuse}

\begin{frame}{OpenBSC: Code reuse}
\begin{itemize}
	\item Configuration file + interactive terminal: Reuse the VTY code from zebra/quagga project
	\begin{itemize}
		\item "configure terminal; enable" style interface known to many network administrators
		\item no need to handle persistent configuration different than run-time configuration
	\end{itemize}
	\item Linked Lists: Imported code + API from Linux list\_head
	\item Timers: Imported code + A PI from Linux kernel
	\item Core select loop handling: Stolen frm ulogd2 (netfilter/iptables)
	\item Database interface: Use dbi and dbd-sqlite3
\end{itemize}
\end{frame}

\begin{frame}{OpenBSC: Voice call integration}
\begin{itemize}
	\item Integration with {\tt lcr} (Linux Call Router)
	\begin{itemize}
		\item Uses the OpenBSC codebase as library (libbsc.a)
		\item Uses the 'call switching API' (MNCC) inside OpenBSC
		\item Allows switching between ISDN and OpenBSC-based GSM
		\item Has itself an interface for Asterisk VoIP
	\end{itemize}
	\item Integration with Asterisk {\tt chan\_obenbsc}
	\begin{itemize}
		\item Directly integrate OpenBSC as Asterisk channel driver
		\item Ongoing effort by some community members
		\item {\em Interesting} from a Licensing point of view !
	\end{itemize}
	\item Integration with actual MSC
	\begin{itemize}
		\item Allows OpenBSC to be used as true BSC in real GSM network
	\end{itemize}
\end{itemize}
\end{frame}


%\subsection{GPRS support}

\begin{frame}{OpenBSC: GPRS support}
\begin{itemize}
	\item GPRS support is currently under active development
	\item Contrary to public belief, GPRS has very little relation to GSM beyond the physical layer
	\item OpenBSC is implementing SGSN and GGSN functionality for a {\em GPRS network in a box} apprach
	\item GPRS protocol stack of phone-originated HTTP request on a nanoBTS: 
	\begin{itemize}
		\item HTTP inside TCP inside IP (regular TCP/IP stack)
		\item inside PPP, SNDCP and LLC (adaption of IP onto Um)
		\item inside BSSGP and NS (Gb interf BTS - SGSN)
		\item inside UDP inside IP inside Ethernet (ip.access encapsulation)
	\end{itemize}
\end{itemize}
\end{frame}

%\subsection{Commercial interest in OpenBSC}

\begin{frame}{OpenBSC commercial interest}
\begin{itemize}
	\item On-Waves Inc. (Iceland), deploying small GSM networks like e.g. aboard ships
	\begin{itemize}
		\item funding the development of a functional split between MSC/BSC to use OpenBSC as a true BSC (without MSC/HLR/SMSC/...)
		\item funding the development of the A interface (the BSC-BTS network protocol stack)
	\end{itemize}
	\item Netzing AG (Dresden/Germany), GSM networks for emergency applications
	\begin{itemize}
		\item funding the development of ip.access nanoBTS support
	\end{itemize}
	\item However, OpenBSC remains primarily a research tool for research use.
\end{itemize}
\end{frame}


\section{Security analysis}

\subsection{Theory}

\begin{frame}{Known GSM security problems}{Scientific papers, etc}
\begin{itemize}
	\item No mutual authentication between phone and network
	\begin{itemize}
		\item leads to rogue network attacks
		\item leads to man-in-the-middle attacks
		\item is what enables IMSI-catchers
	\end{itemize}
	\item Weak encryption algorithms
	\item Encryption is optional, user does never know when it's active or not
	\item DoS of the RACH by means of channel request flooding
	\item RRLP (Radio Resource Location Protocol)
	\begin{itemize}
		\item the network can obtain GPS fix or even raw GSM data from the phone
		\item combine that with the network not needing to authenticate itself
	\end{itemize}
\end{itemize}
\end{frame}

\subsection{The Baseband}

\begin{frame}{Known GSM security problems}{The Baseband side}
\begin{itemize}
	\item GSM protocol stack always runs in a so-called baseband processor (BP)
	\item What is the baseband processor
	\begin{itemize}
		\item Typically ARM7 (2G/2.5G phones) or ARM9 (3G/3.5G phones)
		\begin{itemize}
			\item Runs some RTOS (often Nucleus, sometimes L4)
			\item No memory protection between tasks
		\end{itemize}
		\item Some kind of DSP, model depends on vendor
		\begin{itemize}
			\item Runs the digital signal processing for the RF Layer 1
			\item Has hardware peripherals for A5 encryption
		\end{itemize}
	\end{itemize}
	\item The software stack on the baseband processor
	\begin{itemize}
		\item is written in C and assembly
		\item lacks any modern security features (stack protection, non-executable pages, address space randomization, ..)
	\end{itemize}
\end{itemize}
\end{frame}


\subsection{Observations}

\begin{frame}{Interesting observations}{Learned from implementing the stack}
While developing OpenBSC, we observed a number of interesting
\begin{itemize}
	\item Many phones use their TMSI from the old network when they roam to a new network
	\item Various phones crash when confronted with incorrect messages.  We didn't even start to intentionally send incorrect messages (!)
	\item There are tons of obscure options on the GSM spec which no real network uses.  Potential attack vector by using rarely tested code paths.
\end{itemize}
\end{frame}

\section{Summary}

\subsection{What we've learned}

\begin{frame}{Summary}{What we've learned}
\begin{itemize}
	\item Until recently, there was no Open Source software for GSM protocols
	\item It is well-known that the security level of the GSM stacks is very low
	\item The GSM industry is making security analysis very difficult
	\item With OpenBSC and OpenBTS we now have tools for everyone
	\begin{itemize}
		\item to learn more about and experiment with GSM protocols
		\item to actually study protocol-level GSM security
		\item to do penetration testing against GSM protocol stacks in phones
	\end{itemize}
\end{itemize}
\end{frame}

\subsection{Where we go from here}

\begin{frame}{TODO}{Where we go from here}
\begin{itemize}
	\item The tools for fuzzing mobile phone protocol stacks are available
	\item It is up to the security community to make use of those tools (!)
	\item Don't you too think that TCP/IP security is boring
	\item Join the GSM protocol security research projects
	\item Boldly go where no (free) man has gone before
\end{itemize}
\end{frame}

\subsection{Future Plans}

\begin{frame}{Future plans}
\begin{itemize}
	\item Complete packet data (GPRS/EDGE) support in OpenBSC
	\begin{itemize}
		\item GPRS is used extensively on modern smartphones
		\item Enables us to play with those phones without a heavily filtered operator network
	\end{itemize}
	\item UMTS(3G) support in OpenBSC
	\item Access to MS side layer 1
	\item Playing with SIM Toolkit from the operator side
	\item Playing with MMS
	\item More exploration of RRLP
\end{itemize}
\end{frame}

\subsection{Further Reading}

\begin{frame}{Further Reading}
\begin{itemize}
	\item http://openbsc.gnumonks.org/
	\item http://airprobe.org/
	\item http://openbts.sourceforge.net/
	\item http://wiki.thc.org/gsm/
\end{itemize}
\end{frame}


\end{document}