606 lines
21 KiB
TeX
606 lines
21 KiB
TeX
\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}
|