From fca59bea770346cf1c1f9b0e00cb48a61b44a8f3 Mon Sep 17 00:00:00 2001 From: Harald Welte Date: Sun, 25 Oct 2015 21:00:20 +0100 Subject: import of old now defunct presentation slides svn repo --- 2009/openbsc-lk2009/openbsc.tex | 605 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 605 insertions(+) create mode 100644 2009/openbsc-lk2009/openbsc.tex (limited to '2009/openbsc-lk2009/openbsc.tex') diff --git a/2009/openbsc-lk2009/openbsc.tex b/2009/openbsc-lk2009/openbsc.tex new file mode 100644 index 0000000..e5a8fb1 --- /dev/null +++ b/2009/openbsc-lk2009/openbsc.tex @@ -0,0 +1,605 @@ +\documentclass{beamer} + +\mode +{ + \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 } + +\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} -- cgit v1.2.3