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 --- .../osmocombb-phneutral2010/osmocombb-security.tex | 645 +++++++++++++++++++++ 1 file changed, 645 insertions(+) create mode 100644 2010/osmocombb-phneutral2010/osmocombb-security.tex (limited to '2010/osmocombb-phneutral2010/osmocombb-security.tex') diff --git a/2010/osmocombb-phneutral2010/osmocombb-security.tex b/2010/osmocombb-phneutral2010/osmocombb-security.tex new file mode 100644 index 0000000..848b889 --- /dev/null +++ b/2010/osmocombb-phneutral2010/osmocombb-security.tex @@ -0,0 +1,645 @@ +% $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 . +% +% 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 +{ + \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 +{Sending arbitrary protocol data to GSM networks} + +\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[ph-neutral 2010] % (optional, should be abbreviation of conference name) +{ph-neutral 2010, May 2010, Berlin/Germany} +% - 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}{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 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 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} + + +\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} + +\subsection{GSM Protocol Fuzzing} + +\begin{frame}{GSM Protocol Fuzzing}{Theoretical basis} +How to do GSM protocol fuzzing +\begin{itemize} + \item From the handset to the network + \begin{itemize} + \item Basically impossible due to closeness of baseband + \item However, some incomplete projects working on it + \end{itemize} + \item From the network side + \begin{itemize} + \item Easy in case of {\em rogue network} attacks + \item Fuzzing target is the GSM stack in the baseband processor + \end{itemize} + \item As an A-bis man in the middle + \begin{itemize} + \item Needs access to an A-bis interface of an actual network + \item Very attractive, since no encryption and ability to fuzz both network and handset + \end{itemize} +\end{itemize} +\end{frame} + +\begin{frame}{scapy GSM support}{The actual fuzzing} +How to actually craft the packets for the fuzzing +\begin{itemize} + \item GSM has many, many protocols + \item Writing custom code will be a hard-coded special case for each of them + \item Solution: Use scapy and implement the GSM protocols as scapy "layers" + \begin{itemize} + \item IPA protocol header + \item RSL protocol layer + \item RLL data indication / data request + \item GSM 04.08 RR / MM / CC messages + \end{itemize} +\end{itemize} +\end{frame} + +\section{OsmocomBB Project} + +\subsection{OsmocomBB Introduction} + +\begin{frame}{OsmoocmBB 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 protocl 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}{OsmoocmBB 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}{OsmoocmBB 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}{OsmoocmBB 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}{OsmoocmBB 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}{OsmoocmBB Supported Hardware} +\begin{itemize} + \item Baseband Chipsets + \begin{itemize} + \item TI Calypso/Iota/Rita + \item Some early research being doen 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}{OsmoocmBB 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 trnasmit of normal bursts on SDCCH + \item Transmit of RACH bursts + \end{itemize} + \item Layer2 UI/SABM/UA frames + \item Layer3 Messages for RR / MM / CC + \item Cell (re)selection according GSM 03.22 +\end{itemize} +\end{frame} + +\begin{frame}{OsmoocmBB 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 Layer2 Asynchronous Balanced Mode (ACK/retransmissions) + \item Actual UI on the phone + \item Drivers for Audio/Voice signal path +\end{itemize} +\end{frame} + +\begin{frame}{OsmoocmBB Project Status: Executive Summary} +\begin{itemize} + \item We can esetablish 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} -- cgit v1.2.3