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 --- 2010/osmocombb-sstic2010/c123_pcb.jpg | Bin 0 -> 684904 bytes 2010/osmocombb-sstic2010/calypso-block.pdf | Bin 0 -> 14118 bytes 2010/osmocombb-sstic2010/gsm_network.png | Bin 0 -> 57000 bytes 2010/osmocombb-sstic2010/osmocombb-abstract.txt | 24 + 2010/osmocombb-sstic2010/osmocombb-security.pdf | Bin 0 -> 1059754 bytes 2010/osmocombb-sstic2010/osmocombb-security.snm | 0 2010/osmocombb-sstic2010/osmocombb-security.tex | 666 +++++++++++++++++++++ .../osmocombb-sstic2010/osmocombb-security.tex.bak | 666 +++++++++++++++++++++ 8 files changed, 1356 insertions(+) create mode 100644 2010/osmocombb-sstic2010/c123_pcb.jpg create mode 100644 2010/osmocombb-sstic2010/calypso-block.pdf create mode 100644 2010/osmocombb-sstic2010/gsm_network.png create mode 100644 2010/osmocombb-sstic2010/osmocombb-abstract.txt create mode 100644 2010/osmocombb-sstic2010/osmocombb-security.pdf create mode 100644 2010/osmocombb-sstic2010/osmocombb-security.snm create mode 100644 2010/osmocombb-sstic2010/osmocombb-security.tex create mode 100644 2010/osmocombb-sstic2010/osmocombb-security.tex.bak (limited to '2010/osmocombb-sstic2010') diff --git a/2010/osmocombb-sstic2010/c123_pcb.jpg b/2010/osmocombb-sstic2010/c123_pcb.jpg new file mode 100644 index 0000000..a9f24fc Binary files /dev/null and b/2010/osmocombb-sstic2010/c123_pcb.jpg differ diff --git a/2010/osmocombb-sstic2010/calypso-block.pdf b/2010/osmocombb-sstic2010/calypso-block.pdf new file mode 100644 index 0000000..27f8be8 Binary files /dev/null and b/2010/osmocombb-sstic2010/calypso-block.pdf differ diff --git a/2010/osmocombb-sstic2010/gsm_network.png b/2010/osmocombb-sstic2010/gsm_network.png new file mode 100644 index 0000000..c5f6399 Binary files /dev/null and b/2010/osmocombb-sstic2010/gsm_network.png differ diff --git a/2010/osmocombb-sstic2010/osmocombb-abstract.txt b/2010/osmocombb-sstic2010/osmocombb-abstract.txt new file mode 100644 index 0000000..497e495 --- /dev/null +++ b/2010/osmocombb-sstic2010/osmocombb-abstract.txt @@ -0,0 +1,24 @@ +OsmocomBB: A tool for GSM protocol level security analysis of GSM networks + +By: Harald Welte[1] + +The OsmocomBB project[2] is a Free Software implementation of the GSM +protocol stack running on a mobile phone. + +For decades, the cellular industry comprised by cellphone chipset makers and +network operators keep their hardware and system-level software as well as GSM +protocol stack implementations closed. As a result, it was never possible +to send arbitrary data at the lower levels of the GSM protocol stack. +Existing phones only allow application-level data to be specified, such as +SMS messages, IP over GPRS or circuit-switched data (CSD). + +Using OsmocomBB, the security researcher finally has a tool equivalent +to an Ethernet card in the TCP/IP protocol world: A simple transceiver +that will send arbitrary protocol messages to a GSM network. + +Well-known and established techniques like protocol fuzzing can finally +be used in GSM networks and reveal how reliable and fault tolerant the +equipment used in the GSM networks really is. + +[1] http://laforge.gnumonks.org/ +[2] http://bb.osmocom.org/ diff --git a/2010/osmocombb-sstic2010/osmocombb-security.pdf b/2010/osmocombb-sstic2010/osmocombb-security.pdf new file mode 100644 index 0000000..d5f76c4 Binary files /dev/null and b/2010/osmocombb-sstic2010/osmocombb-security.pdf differ diff --git a/2010/osmocombb-sstic2010/osmocombb-security.snm b/2010/osmocombb-sstic2010/osmocombb-security.snm new file mode 100644 index 0000000..e69de29 diff --git a/2010/osmocombb-sstic2010/osmocombb-security.tex b/2010/osmocombb-sstic2010/osmocombb-security.tex new file mode 100644 index 0000000..55e66bc --- /dev/null +++ b/2010/osmocombb-sstic2010/osmocombb-security.tex @@ -0,0 +1,666 @@ +% $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 +{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}{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} diff --git a/2010/osmocombb-sstic2010/osmocombb-security.tex.bak b/2010/osmocombb-sstic2010/osmocombb-security.tex.bak new file mode 100644 index 0000000..7a82bb0 --- /dev/null +++ b/2010/osmocombb-sstic2010/osmocombb-security.tex.bak @@ -0,0 +1,666 @@ +% $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 +{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}{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 genric 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 possilble + \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 laeked 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}{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 and ABM mode + \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 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