667 lines
21 KiB
TeX
667 lines
21 KiB
TeX
% $Header: /cvsroot/latex-beamer/latex-beamer/solutions/conference-talks/conference-ornate-20min.en.tex,v 1.7 2007/01/28 20:48:23 tantau Exp $
|
|
|
|
\documentclass{beamer}
|
|
|
|
\usepackage{url}
|
|
\makeatletter
|
|
\def\url@leostyle{%
|
|
\@ifundefined{selectfont}{\def\UrlFont{\sf}}{\def\UrlFont{\tiny\ttfamily}}}
|
|
\makeatother
|
|
%% Now actually use the newly defined style.
|
|
\urlstyle{leo}
|
|
|
|
|
|
% This file is a solution template for:
|
|
|
|
% - Talk at a conference/colloquium.
|
|
% - Talk length is about 20min.
|
|
% - Style is ornate.
|
|
|
|
|
|
|
|
% Copyright 2004 by Till Tantau <tantau@users.sourceforge.net>.
|
|
%
|
|
% In principle, this file can be redistributed and/or modified under
|
|
% the terms of the GNU Public License, version 2.
|
|
%
|
|
% However, this file is supposed to be a template to be modified
|
|
% for your own needs. For this reason, if you use this file as a
|
|
% template and not specifically distribute it as part of a another
|
|
% package/program, I grant the extra permission to freely copy and
|
|
% modify this file as you see fit and even to delete this copyright
|
|
% notice.
|
|
|
|
|
|
\mode<presentation>
|
|
{
|
|
\usetheme{Warsaw}
|
|
% or ...
|
|
|
|
\setbeamercovered{transparent}
|
|
% or whatever (possibly just delete it)
|
|
}
|
|
|
|
|
|
\usepackage[english]{babel}
|
|
% or whatever
|
|
|
|
\usepackage[latin1]{inputenc}
|
|
% or whatever
|
|
|
|
\usepackage{times}
|
|
\usepackage[T1]{fontenc}
|
|
% Or whatever. Note that the encoding and the font should match. If T1
|
|
% does not look nice, try deleting the line with the fontenc.
|
|
|
|
|
|
\title{OsmocomBB}
|
|
|
|
\subtitle
|
|
{A tool for GSM protocol level security}
|
|
|
|
\author{Harald Welte}
|
|
|
|
\institute
|
|
{gnumonks.org\\gpl-violations.org\\OpenBSC\\airprobe.org\\hmw-consulting.de}
|
|
% - Use the \inst command only if there are several affiliations.
|
|
% - Keep it simple, no one is interested in your street address.
|
|
|
|
\date[SSTIC 2010] % (optional, should be abbreviation of conference name)
|
|
{SSTIC 2010, June 2010, Rennes/France}
|
|
% - Either use conference name or its abbreviation.
|
|
% - Not really informative to the audience, more for people (including
|
|
% yourself) who are reading the slides online
|
|
|
|
\subject{GSM Security}
|
|
% This is only inserted into the PDF information catalog. Can be left
|
|
% out.
|
|
|
|
|
|
|
|
% 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}}
|
|
|
|
|
|
|
|
% Delete this, if you do not want the table of contents to pop up at
|
|
% the beginning of each subsection:
|
|
%\AtBeginSubsection[]
|
|
%{
|
|
% \begin{frame}<beamer>{Outline}
|
|
% \tableofcontents[currentsection,currentsubsection]
|
|
% \end{frame}
|
|
%}
|
|
|
|
|
|
% 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[hideallsubsections]
|
|
% 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 Using + playing with Linux since 1994
|
|
\item Kernel / bootloader / driver / firmware development since 1999
|
|
\item IT security expert, focus on network protocol security
|
|
\item Core developer of Linux packet filter netfilter/iptables
|
|
\item Board-level Electrical Engineering
|
|
\item Always looking for interesting protocols (RFID, DECT, GSM)
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\section{GSM/3G Network Security Introduction}
|
|
|
|
\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 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
|
|
\item Has been done in 2008/2009: Project OpenBSC
|
|
\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}{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, MS tester, ...)
|
|
\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}
|
|
|
|
\section{Security Problems and the Baseband}
|
|
|
|
\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}
|
|
|
|
\begin{frame}{A GSM Baseband Chipset}
|
|
\begin{figure}[h]
|
|
\centering
|
|
\includegraphics[width=100mm]{calypso-block.pdf}
|
|
\end{figure}
|
|
\url{http://laforge.gnumonks.org/papers/gsm_phone-anatomy-latest.pdf}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Requirements for GSM security analysis}
|
|
What do we need for protocol-level security analysis?
|
|
\begin{itemize}
|
|
\item A GSM MS-side baseband chipset under our control
|
|
\item A Layer1 that we can use to generate arbitrary L1 frames
|
|
\item A Layer2 protocol implementation that we can use + modify
|
|
\item A Layer3 protocol implementation that we can use + modify
|
|
\end{itemize}
|
|
None of those components existed, so we need to create them!
|
|
\end{frame}
|
|
|
|
\begin{frame}{A GSM baseband under our control}
|
|
The two different DIY approaches
|
|
\begin{itemize}
|
|
\item Build something using generic components (DSP, CPU, ADC, FPGA)
|
|
\begin{itemize}
|
|
\item No reverse engineering required
|
|
\item A lot of work in hardware design + debugging
|
|
\item Hardware will be low-quantity and thus expensive
|
|
\end{itemize}
|
|
\item Build something using existing baseband chipset
|
|
\begin{itemize}
|
|
\item Reverse engineering or leaked documents required
|
|
\item Less work on the 'Layer 0'
|
|
\item Still, custom hardware in low quantity
|
|
\end{itemize}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{A GSM baseband under our control}
|
|
Alternative 'lazy' approach
|
|
\begin{itemize}
|
|
\item Re-purpose existing mobile phone
|
|
\begin{itemize}
|
|
\item Hardware is known to be working
|
|
\item No prototyping, hardware revisions, etc.
|
|
\item Reverse engineering required
|
|
\item Hardware drivers need to be written
|
|
\item But: More time to focus on the actual job: Protocol software
|
|
\end{itemize}
|
|
\item Searching for suitable phones
|
|
\begin{itemize}
|
|
\item As cheap as possible
|
|
\item Readily available: Many people can play with it
|
|
\item As old/simple as possible to keep complexity low
|
|
\item Baseband chipset with lots of leaked information
|
|
\end{itemize}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Baseband chips with leaked information}
|
|
\begin{itemize}
|
|
\item Texas Instruments Calypso
|
|
\begin{itemize}
|
|
\item DBB Documentation on cryptome.org and other sites
|
|
\item ABB Documentation on chinese phone developer websites
|
|
\item Source code of GSM stack / drivers was on sf.net (tsm30 project)
|
|
\item End of life, no new phones with Calypso since about 2008
|
|
\item No cryptographic checks in bootloader
|
|
\end{itemize}
|
|
\item Mediatek MT622x chipsets
|
|
\begin{itemize}
|
|
\item Lots of Documentation on chinese sites
|
|
\item SDK with binary-only GSM stack libraries on chinese sites
|
|
\item 95 million produced/sold in Q1/2010
|
|
\end{itemize}
|
|
\end{itemize}
|
|
Initial choice: TI Calypso (GSM stack source available)
|
|
\end{frame}
|
|
|
|
|
|
\section{OsmocomBB Project}
|
|
|
|
\subsection{OsmocomBB Introduction}
|
|
|
|
\begin{frame}{OsmocomBB Introduction}
|
|
\begin{itemize}
|
|
\item Project was started in January 2010
|
|
\item Implementing a GSM baseband software from scratch
|
|
\item This includes
|
|
\begin{itemize}
|
|
\item GSM MS-side protocol stack from Layer 1 through Layer 3
|
|
\item Hardware drivers for GSM Baseband chipset
|
|
\item Simple User Interface on the phone itself
|
|
\item Verbose User Interface on the PC
|
|
\end{itemize}
|
|
\item Note about the strange project name
|
|
\begin{itemize}
|
|
\item Osmocom = Open Source MObile COMmunication
|
|
\item BB = Base Band
|
|
\end{itemize}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\subsection{OsmocomBB Architecture}
|
|
|
|
\begin{frame}{OsmocomBB Software Architecture}
|
|
\begin{itemize}
|
|
\item Reuse code from OpenBSC where possible (libosmocore)
|
|
\begin{itemize}
|
|
\item We build libosmocore both for phone firmware and PC
|
|
\end{itemize}
|
|
\item Initially run as little software in the phone
|
|
\begin{itemize}
|
|
\item Debugging code on your host PC is so much easier
|
|
\item You have much more screen real-estate
|
|
\item Hardware drivers and Layer1 run in the phone
|
|
\item Layer2, 3 and actual phone application / MMI on PC
|
|
\item Later, L2 and L3 can me moved to the phone
|
|
\end{itemize}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{OsmocomBB Software Interfaces}
|
|
\begin{itemize}
|
|
\item Interface between Layer1 and Layer2 called L1CTL
|
|
\begin{itemize}
|
|
\item Fully custom protocol as there is no standard
|
|
\item Implemented as message based protocol over Sercomm/HDLC/RS232
|
|
\end{itemize}
|
|
\item Interface between Layer2 and Layer3 called RSLms
|
|
\begin{itemize}
|
|
\item In the GSM network, Um Layer2 terminates at the BTS but is controlled by the BSC
|
|
\item Reuse this GSM 08.58 Radio Signalling Link
|
|
\item Extend it where needed for the MS case
|
|
\end{itemize}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\subsection{OsmocomBB Software}
|
|
|
|
\begin{frame}{OsmocomBB Target Firmware}
|
|
\begin{itemize}
|
|
\item Firmware includes software like
|
|
\begin{itemize}
|
|
\item Drivers for the Ti Calypso Digital Baseband (DBB)
|
|
\item Drivers for the Ti Iota TWL3025 Analog Baseband (ABB)
|
|
\item Drivers for the Ti Rita TRF6151 RF Transceiver
|
|
\item Drivers for the LCD/LCM of a number of phones
|
|
\item CFI flash driver for NOR flash
|
|
\item GSM Layer1 synchronous/asynchronous part
|
|
\item Sercomm - A HDLC based multiplexer for the RS232 to host PC
|
|
\end{itemize}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{OsmocomBB Host Software}
|
|
\begin{itemize}
|
|
\item Current working name: layer23
|
|
\item Includes
|
|
\begin{itemize}
|
|
\item Layer 1 Control (L1CTL) protocol API
|
|
\item GSM Layer2 implementation (LAPDm)
|
|
\item GSM Layer3 implementation (RR/MM/CC)
|
|
\item GSM Cell (re)selection
|
|
\item SIM Card emulation
|
|
\item Supports various 'apps' depending on purpose
|
|
\end{itemize}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\subsection{OsmocomBB Hardware Support}
|
|
|
|
\begin{frame}{OsmocomBB Supported Hardware}
|
|
\begin{itemize}
|
|
\item Baseband Chipsets
|
|
\begin{itemize}
|
|
\item TI Calypso/Iota/Rita
|
|
\item Some early research being done on Mediatek (MTK) MT622x
|
|
\end{itemize}
|
|
\item Actual Phones
|
|
\begin{itemize}
|
|
\item Compal/Motorola C11x, C12x, C13x, C14x and C15x models
|
|
\item Most development/testing on C123 and C155
|
|
\item GSM modem part of Openmoko Neo1973 and Freerunner
|
|
\end{itemize}
|
|
\item All those phones are simple feature phones built on a ARM7TDMI based DBB
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{The Motorola/Compal C123}
|
|
\begin{figure}[h]
|
|
\centering
|
|
\includegraphics[width=100mm]{c123_pcb.jpg}
|
|
\end{figure}
|
|
\end{frame}
|
|
|
|
|
|
\subsection{OsmocomBB Project Status}
|
|
|
|
\begin{frame}{OsmocomBB Project Status: Working}
|
|
\begin{itemize}
|
|
\item Hardware Drivers for Calypso/Iota/Rita very complete
|
|
\item Layer1
|
|
\begin{itemize}
|
|
\item Power measurements
|
|
\item Carrier/bit/TDMA synchronization
|
|
\item Receive and transmit of normal bursts on SDCCH
|
|
\item Transmit of RACH bursts
|
|
\end{itemize}
|
|
\item Layer2 UI/SABM/UA frames and ABM mode
|
|
\item Layer3 Messages for RR / MM / CC
|
|
\item Cell (re)selection according GSM 03.22
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{OsmocomBB Project Status: Not working}
|
|
\begin{itemize}
|
|
\item Actual SIM card reader inside phone (WIP)
|
|
\item Layer1
|
|
\begin{itemize}
|
|
\item Automatic Tx power control (APC)
|
|
\item Automatic Rx gain control (AGC)
|
|
\item Frequency Hopping
|
|
\item Neighbor Cell Measurements
|
|
\item Traffic Channels (TCH)
|
|
\end{itemize}
|
|
\item Actual UI on the phone
|
|
\item Drivers for Audio/Voice signal path
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{OsmocomBB Project Status: Executive Summary}
|
|
\begin{itemize}
|
|
\item We can establish control/signalling channels with non-hopping cells
|
|
\begin{itemize}
|
|
\item Used in small single-TRX cells in rural areas
|
|
\item Used in GSM-R networks
|
|
\item As provided by OpenBSC + OpenBTS
|
|
\end{itemize}
|
|
\item We can send arbitrary data on those control channels
|
|
\begin{itemize}
|
|
\item RR messages to BSC
|
|
\item MM/CC messages to MSC
|
|
\item SMS messages to MSC/SMSC
|
|
\end{itemize}
|
|
\item Adding frequency hopping support not very hard
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
|
|
\section{Summary}
|
|
|
|
\subsection{What we've learned}
|
|
|
|
\begin{frame}{Summary}{What we've learned}
|
|
\begin{itemize}
|
|
\item The GSM industry is making security analysis very difficult
|
|
\item It is well-known that the security level of the GSM stacks is very low
|
|
\item We now have multiple solutions for sending arbitrary protocol data
|
|
\begin{itemize}
|
|
\item From a rogue network to phones (OpenBSC, OpenBTS)
|
|
\item From an A-bis proxy to the network or the phones
|
|
\item From custom GSM phone baseband firmware to the network
|
|
\end{itemize}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\subsection{Where we go from here}
|
|
|
|
\begin{frame}{TODO}{Where we go from here}
|
|
\begin{itemize}
|
|
\item The basic tools for fuzzing mobile networks are available
|
|
\item No nice interface/integration from OsmocomBB to scapy yet
|
|
\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 man has gone before
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\subsection{Further Reading}
|
|
|
|
\begin{frame}{Further Reading}
|
|
\begin{itemize}
|
|
\item \url{http://laforge.gnumonks.org/papers/gsm_phone-anatomy-latest.pdf}
|
|
\item \url{http://bb.osmocom.org/}
|
|
\item \url{http://openbsc.gnumonks.org/}
|
|
\item \url{http://openbts.sourceforge.net/}
|
|
\item \url{http://airprobe.org/}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\end{document}
|