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/gsm_foss-mt2010/OBTSBM2010.jpg | Bin 0 -> 772751 bytes 2010/gsm_foss-mt2010/bts_tree_full.jpg | Bin 0 -> 1512137 bytes 2010/gsm_foss-mt2010/c123_pcb.jpg | Bin 0 -> 684904 bytes 2010/gsm_foss-mt2010/calypso-block.pdf | Bin 0 -> 14118 bytes 2010/gsm_foss-mt2010/gsm_foss.pdf | Bin 0 -> 4124429 bytes 2010/gsm_foss-mt2010/gsm_foss.snm | 0 2010/gsm_foss-mt2010/gsm_foss.tex | 177 ++++++++++++++++++ 2010/gsm_foss-mt2010/gsm_foss.vrb | 13 ++ 2010/gsm_foss-mt2010/openbsc_host.jpg | Bin 0 -> 706662 bytes 2010/gsm_foss-mt2010/part-mtk.tex | 101 +++++++++++ 2010/gsm_foss-mt2010/part-security.tex | 146 +++++++++++++++ 2010/gsm_foss-mt2010/section-openbsc.tex | 200 ++++++++++++++++++++ 2010/gsm_foss-mt2010/section-openbts.tex | 140 ++++++++++++++ 2010/gsm_foss-mt2010/section-osmocombb.tex | 282 +++++++++++++++++++++++++++++ 2010/gsm_foss-mt2010/section-simtrace.tex | 39 ++++ 2010/gsm_foss-mt2010/section-wireshark.tex | 61 +++++++ 16 files changed, 1159 insertions(+) create mode 100644 2010/gsm_foss-mt2010/OBTSBM2010.jpg create mode 100644 2010/gsm_foss-mt2010/bts_tree_full.jpg create mode 100644 2010/gsm_foss-mt2010/c123_pcb.jpg create mode 100644 2010/gsm_foss-mt2010/calypso-block.pdf create mode 100644 2010/gsm_foss-mt2010/gsm_foss.pdf create mode 100644 2010/gsm_foss-mt2010/gsm_foss.snm create mode 100644 2010/gsm_foss-mt2010/gsm_foss.tex create mode 100644 2010/gsm_foss-mt2010/gsm_foss.vrb create mode 100644 2010/gsm_foss-mt2010/openbsc_host.jpg create mode 100644 2010/gsm_foss-mt2010/part-mtk.tex create mode 100644 2010/gsm_foss-mt2010/part-security.tex create mode 100644 2010/gsm_foss-mt2010/section-openbsc.tex create mode 100644 2010/gsm_foss-mt2010/section-openbts.tex create mode 100644 2010/gsm_foss-mt2010/section-osmocombb.tex create mode 100644 2010/gsm_foss-mt2010/section-simtrace.tex create mode 100644 2010/gsm_foss-mt2010/section-wireshark.tex (limited to '2010/gsm_foss-mt2010') diff --git a/2010/gsm_foss-mt2010/OBTSBM2010.jpg b/2010/gsm_foss-mt2010/OBTSBM2010.jpg new file mode 100644 index 0000000..7759978 Binary files /dev/null and b/2010/gsm_foss-mt2010/OBTSBM2010.jpg differ diff --git a/2010/gsm_foss-mt2010/bts_tree_full.jpg b/2010/gsm_foss-mt2010/bts_tree_full.jpg new file mode 100644 index 0000000..6b5c5e8 Binary files /dev/null and b/2010/gsm_foss-mt2010/bts_tree_full.jpg differ diff --git a/2010/gsm_foss-mt2010/c123_pcb.jpg b/2010/gsm_foss-mt2010/c123_pcb.jpg new file mode 100644 index 0000000..a9f24fc Binary files /dev/null and b/2010/gsm_foss-mt2010/c123_pcb.jpg differ diff --git a/2010/gsm_foss-mt2010/calypso-block.pdf b/2010/gsm_foss-mt2010/calypso-block.pdf new file mode 100644 index 0000000..27f8be8 Binary files /dev/null and b/2010/gsm_foss-mt2010/calypso-block.pdf differ diff --git a/2010/gsm_foss-mt2010/gsm_foss.pdf b/2010/gsm_foss-mt2010/gsm_foss.pdf new file mode 100644 index 0000000..4048816 Binary files /dev/null and b/2010/gsm_foss-mt2010/gsm_foss.pdf differ diff --git a/2010/gsm_foss-mt2010/gsm_foss.snm b/2010/gsm_foss-mt2010/gsm_foss.snm new file mode 100644 index 0000000..e69de29 diff --git a/2010/gsm_foss-mt2010/gsm_foss.tex b/2010/gsm_foss-mt2010/gsm_foss.tex new file mode 100644 index 0000000..fa26c86 --- /dev/null +++ b/2010/gsm_foss-mt2010/gsm_foss.tex @@ -0,0 +1,177 @@ + +\newcommand{\degree}{\ensuremath{^\circ}} +%\documentclass[handout]{beamer} +\documentclass{beamer} + +% 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) +} + +\mode{ + \usepackage{handoutWithNotes} + \pgfpagesuselayout{2 on 1 with notes landscape}[a4paper,border shrink=5mm] + \usecolortheme{seahorse} +} + +% ensure the page number is printed in front of the author name in the footer +\newcommand*\oldmacro{} +\let\oldmacro\insertshortauthor% save previous definition +\renewcommand*\insertshortauthor{% + \leftskip=.3cm% before the author could be a plus1fill ... + \insertframenumber\,/\,\inserttotalframenumber\hfill\oldmacro} + +\usepackage[english]{babel} +\usepackage[latin1]{inputenc} +\usepackage{times} +\usepackage[T1]{fontenc} + +\usepackage{subfigure} +\usepackage{hyperref} +\usepackage{textcomp,listings} +%\usepackage{german} +\lstset{basicstyle=\scriptsize\ttfamily, upquote} + +% \title{GSM Air Interface Security} +\title{Free / Open Source Software for GSM} %Hashdays 2010 title + +%\subtitle{and other GSM related fun} + +\author{Harald~Welte} + +\institute{gnumonks.org\\OpenBSC\\airprobe.org\\osmocom.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[December 2010] % (optional, should be abbreviation of conference name) +{December 2010, Taiwan} +% - 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} +% 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} + + +% 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. + +%\include{part-introduction} + +\part{Open Source GSM Tools} + +\begin{frame}{Part I - Open Source GSM Tools} +\tableofcontents +\end{frame} + +\include{section-openbsc} +\include{section-openbts} +\include{section-osmocombb} +\include{section-wireshark} +\include{section-simtrace} + +\include{part-mtk} + +\part{Summary} + +\section{Summary} + +\section{Further Reading} + +\begin{frame}{Further Reading} +\tiny{ +\begin{itemize} + \item Open source Software on a GSM protocol level + \begin{description}[OsmocomBB] + \item[OpenBSC] \url{http://openbsc.osmocom.org/} + \item[OpenBTS] \url{http://openbts.org/} + \item[OsmocomBB] \url{http://bb.osmocom.org/} + \item[airprobe] \url{http://airprobe.org/} + \end{description} + \item A5 security related publications + \begin{description}[] + \item[A5 public] \url{http://groups.google.com/group/uk.telecom/msg/ba76615fef32ba32} + \item[Biham2003] \url{http://cryptome.org/gsm-crack-bbk.pdf} + \item[Biham2006] \url{http://www.cs.technion.ac.il/users/wwwb/cgi-bin/tr-get.cgi/2006/CS/CS-2006-07.pdf} + \item[HAR2009] \url{https://har2009.org/program/attachments/119_GSM.A51.Cracking.Nohl.pdf} + \item[rainbow tables] \url{http://reflextor.com/trac/a51/wiki} + \end{description} +\end{itemize} +} +\end{frame} + +\end{document} diff --git a/2010/gsm_foss-mt2010/gsm_foss.vrb b/2010/gsm_foss-mt2010/gsm_foss.vrb new file mode 100644 index 0000000..d917a88 --- /dev/null +++ b/2010/gsm_foss-mt2010/gsm_foss.vrb @@ -0,0 +1,13 @@ +\frametitle {OpenBTS USRP Clocking}\framesubtitle {Kalibrator Example} +\begin{block}{Example of running {\tt kal}} +\begin{lstlisting} +[openBTS@openBTS kal-0.2]# ./kal -f 946600000 -u +USRP side: B +FPGA clock: 52000000 +Decimation: 192 +Antenna: RX2 +Sample rate: 270833.343750 +average [min, max] (range, stddev) -2197.789062 [-2431, -1843] (588, 146.761444) +\end{lstlisting} +\end{block} +The value {\bf -2198 should be used as FREQOFF constant in Transceiver/USRPDevice.cpp} diff --git a/2010/gsm_foss-mt2010/openbsc_host.jpg b/2010/gsm_foss-mt2010/openbsc_host.jpg new file mode 100644 index 0000000..10c575d Binary files /dev/null and b/2010/gsm_foss-mt2010/openbsc_host.jpg differ diff --git a/2010/gsm_foss-mt2010/part-mtk.tex b/2010/gsm_foss-mt2010/part-mtk.tex new file mode 100644 index 0000000..17baffc --- /dev/null +++ b/2010/gsm_foss-mt2010/part-mtk.tex @@ -0,0 +1,101 @@ +% Day 2 +\part{How MTK could use GSM FOSS} + +\begin{frame}{Part II - MTK and Free / Open Source Software} +\tableofcontents +\end{frame} + +\section{Open Source GSM tools for Debugging + Testing} + +\begin{frame}{Possible use cases for OpenBSC} +OpenBSC or OpenBTS in R\&D +\begin{itemize} + \item Inexpensive simulation of GSM network for R\&D + \item Flexible since any aspect can be modified by altering source code + \item Complex and more exotic parts of GSM protocol spec can be tested + \item Much more functionality than CMD 55 / Racal 6103 or similar + \item Ability to send malformed L3 messages (fuzzing) for MTK MS stack security improvement +\end{itemize} +\end{frame} + +\begin{frame}{Other GSM tools} +\begin{itemize} + \item airprobe: Tracing of Um air interface + \item SIMtrace: Tracing of SIM card interface +\end{itemize} +\end{frame} + +\begin{frame}{General advantages of FOSS based solution} +\begin{itemize} + \item MTK has full access to source code + \item New features can be added on any level of the protocol stack + \item No dependency on a single supplier + \item Lower cost means available to more MTK engineers + \item Lower cost means available to more MTK customers (factory testing, field tests with OEM customers, ...) +\end{itemize} +\end{frame} + +\section{Single-Core Android smart phone} + +\begin{frame}{MTK feature phone vs. smart phone} +\begin{itemize} + \item MTK's advantage so far: Low cost sigle-core feature phone + \begin{itemize} + \item Baseband processor runs Nucleus, GSM stack, UI and rich application stack (Camera, H.264, GPRS, TCP/IP, ...) + \item Other suppliers have to use dual core + \end{itemize} + \item However, MTKs Nucleus based OS has custom/proprietary APIs + \item Not many 3rd party applications can be installed on the phone + \item Android, iPhone, Windows Mobile have standard API / environment + \item Thus, MTK needs to offer 'standard' smart phone solution +\end{itemize} +\end{frame} + +\begin{frame}{Proposal: Single core Android smart phone} +\begin{itemize} + \item Android, WinMobile, etc. have dual-core architecture + \begin{itemize} + \item GSM/3G protocol stack on baseband processor + \item UI + applications on application processor + \end{itemize} + \item If MTK now goes for Android smart phone, why go dual core? + \begin{itemize} + \item Simply port L1 code into Linux kernel (IRQ/FIQ driven) + \item Make sure you follow the GPL and release L1 as Open Source + \item Run your L2/L3/L4 as proprietary userspace process on Linux + \end{itemize} + \item Single-core Android phone has less ARM core licensing cost and less silicon size +\end{itemize} +\end{frame} + +\section{Linux development and the community} + +\begin{frame}{SoC vendors and Linux ports} +\begin{itemize} + \item A number of SoC vendors have been used with Linux for many years + \item Port of Linux / BSP has originally been done by 3rd party or community + \item SoC vendors started to become more active in the last 5 years + \item Original: Create port, ship it to customer, done. + \item SoC customers end up with vendor-specific code +\end{itemize} +\end{frame} + +\begin{frame}{Disadvantages of vendor ports} +\begin{itemize} + \item Fast progress in mainline Linux kernel development + \item Customers want latest kernel for latest features / performance + \item Vendor port (not in mainline) always behind mainline + \item Porting out-of-mainline vendor port into new mainline is lots of work + \item Customers end up with old vendor-specific code +\end{itemize} +\end{frame} + +\begin{frame}{SoC vendors need to include their port mainline} +\begin{itemize} + \item Major SoC vendors now work together with mainline developers + \item Support SoC in latest mainline developer version + \item Actively submit port into mainline Linux kernel + \item Port in mainline stays automatically current/up-to-date + \item Continued maintenance effort is shared by all parties +\end{itemize} +\end{frame} diff --git a/2010/gsm_foss-mt2010/part-security.tex b/2010/gsm_foss-mt2010/part-security.tex new file mode 100644 index 0000000..d5b7fbd --- /dev/null +++ b/2010/gsm_foss-mt2010/part-security.tex @@ -0,0 +1,146 @@ +% Day 2 +\part{Security Research} +\section{Researching GSM/3G security} + +\subsection{An interesting observation} + +\begin{frame}{GSM/3G protocol level 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 chip set makers never release any hardware documentation + \end{itemize} +\end{itemize} +\end{frame} + +\subsection{The closed GSM industry -- Handset side} + +\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} + +\subsection{The closed GSM industry -- Network side} + +\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 + \item minimal network using standard components definitely in the 100,000s of EUR range + \end{itemize} +\end{itemize} +\end{frame} + +\begin{frame}{The closed GSM industry}{Operator side} +From my experience with Operators (prove me wrong!) +\begin{itemize} + \item Operators are mainly finance + marketing today + \item Many operators outsources + \begin{itemize} + \item Network servicing / deployment, even planning + \item Other aspects of business like Billing + \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} + +\begin{frame}{GSM networks are victim and source of attacks on user privacy} +\includegraphics[bb=0in 0in 12in 6in,clip,width=5.3in,page=7]{nohl-slides-14.pdf} +\end{frame} + +\begin{frame}{Network operator and manufacturer can install software on a phone} +\includegraphics[bb=0in 0in 12in 6in,clip,width=5.3in,page=8]{nohl-slides-14.pdf} +\end{frame} + +\subsection{Security implications} + +\begin{frame}{The closed GSM industry}{Security implications} +The security implications of the closed GSM industry are: +\begin{itemize} + \item Almost no people who have detailed technical knowledge outside the protocol stack or GSM network equipment manufacturers + \item No independent research on protocol-level security + \begin{itemize} + \item If there's security research at all, then only theoretical (like the A5/2 and A5/1 cryptanalysis) + \item Or on application level (e.g. mobile malware) + \end{itemize} + \item No open source protocol implementations + \begin{itemize} + \item which are key for making more people learn about the protocols + \item which enable quick prototyping/testing by modifying existing code + \end{itemize} +\end{itemize} +\end{frame} + +\begin{frame}{Security analysis of GSM}{How would you get started?} +If you were to start with GSM protocol level security analysis, where and +how would you start? +\begin{itemize} + \item On the handset side? + \begin{itemize} + \item Difficult since GSM firmware and protocol stacks are closed and proprietary + \item Even if you want to write your own protocol stack, the layer 1 hardware and signal processing is closed and undocumented, too + \item Known attempts + \begin{itemize} + \item The TSM30 project as part of the THC GSM project + \item MADos, an alternative OS for Nokia DTC3 phones + \end{itemize} + \item Since 2010 we have a new project: {\tt OsmocomBB} + \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 Also, using SDR (software defined radio) approach, special-purpose / closed hardware can be avoided + \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 + \begin{itemize} + \item OpenBSC: Obtain actual GSM network equipment (BTS) + \item OpenBTS: Develop SDR based GSM Um Layer 1 + \end{itemize} + \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} + + diff --git a/2010/gsm_foss-mt2010/section-openbsc.tex b/2010/gsm_foss-mt2010/section-openbsc.tex new file mode 100644 index 0000000..0c1b9f4 --- /dev/null +++ b/2010/gsm_foss-mt2010/section-openbsc.tex @@ -0,0 +1,200 @@ +\section{OpenBSC} + +%\subsection{OpenBSC Introduction} + +\begin{frame}{OpenBSC software} +OpenBSC is a Open Source implementation of (not only) the BSC features +of a GSM network. +\begin{itemize} + \item Support A-bis interface over E1 and IP + \item Support for BTS vendor/model is modular, currently Siemens BS-11 and ip.access nanoBTS + \item Multiple BTS models/vendorrs can be mixed! + \item Can work as a {\em pure BSC} or as a full {\em network in a box} + \item Supports mobility management, authentication, intra-BSC hand-over, SMS, voice calls (FR/EFR/AMR) + \item GPRS + EDGE support if combined with OsmoSGSN and OpenGGSN +\end{itemize} +\end{frame} + +\begin{frame}{OpenBSC} +\begin{itemize} + \item Supports Siemens BS-11 BTS (E1) and ip.access nanoBTS (IP based) + \item Has classic 2G signalling, voice and SMS support + \item Implements various GSM protocols like + \begin{itemize} + \item A-bis RSL (TS 08.58) and OML (TS 12.21) + \item TS 04.08 Radio Resource, Mobility Management, Call Control + \item TS 04.11 Short Message Service + \end{itemize} + \item Telnet console with Cisco-style interface +\end{itemize} +\end{frame} + +\begin{frame}{OpenBSC software architecture} +\begin{itemize} + \item Implemented in pure C, similarities to Linux kernel + \begin{itemize} + \item Linked List handling, Timer API, coding style + \end{itemize} + \item Single-threaded event-loop / state machine design + \item Telnet based command line interface {\em Cisco-style} + \item Input driver abstraction (mISDN, Abis-over-IP) +\end{itemize} +\end{frame} + +\begin{frame}{OpenBSC: GSM network protocols}{The A-bis interface} + \begin{description}[Layer 4+] + \item[Layer 1] Typically E1 line, TS 08.54 + \item[Layer 2] A variant of ISDN LAPD with fixed TEI's, TS 08.56 + \item[Layer 3] OML (Organization and Maintenance Layer, TS 12.21) + \item[Layer 3] RSL (Radio Signalling Link, TS 08.58) + \item[Layer 4+] transparent messages that are sent to the MS via Um + \end{description} +\end{frame} + +%\begin{frame}{OpenBSC: How it all started} +%\begin{itemize} +% \item In 2006, I bought a Siemens BS-11 microBTS on eBay +% \begin{itemize} +% \item This is GSM900 BTS with 2 TRX at 2W output power (each) +% \item A 48kg monster with attached antenna +% \item 200W power consumption, passive cooling +% \item E1 physical interface +% \end{itemize} +% \item I didn't have much time at the time (day job at Openmoko) +% \item Started to read up on GSM specs whenever I could +% \item Bought a HFC-E1 based PCI E1 controller, has mISDN kernel support +% \item Found somebody in the GSM industry who provided protocol traces +%\end{itemize} +%\end{frame} + +%\begin{frame}{OpenBSC: Timeline} +%\begin{itemize} +% \item In November 2008, I started the development of OpenBSC +% \item In December 2008, we did a first demo at 25C3 +% \item In January 2009, we had full voice call support +% \item In June 2009, I started with actual security related stuff +% \item In August 2009, we had the first field test with 2BTS and > 860 phones +%\end{itemize} +%\end{frame} + +\begin{frame}{OpenBSC: Field Test at HAR2009} +\begin{figure}[h] +\subfigure{\includegraphics[width=5cm]{bts_tree_full.jpg}} +\subfigure{\includegraphics[width=5cm]{openbsc_host.jpg}} +\end{figure} +\end{frame} + + +\subsection{OpenBSC Network In The Box} + +\begin{frame}{OpenBSC in NITB mode}{Network In a Box Mode} +The {\tt bsc\_hack} program +\begin{itemize} + \item implements the A-bis interface towards any number of BTS + \item provides most typical features of a GSM network in one software + \item no need for MSC, AuC, HLR, VLR, EIR, ... + \begin{itemize} + \item HLR/VLR as SQLite3 table + \item Authentication + Ciphering support + \item GSM voice calls, MO/MT SMS + \item Hand-over between all BTS + \item Multiple Location Areas within one BSC + \end{itemize} +\end{itemize} +\end{frame} + +\begin{frame}{OpenBSC NITB features} +OpenBSC NITB features +\begin{itemize} + \item Run a small GSM network with 1-n BTS and OpenBSC + \item No need for MSC/HLR/AUC/... + \item No need for your own SIM cards (unless crypto/auth rqd) + \item Establish signalling and voice channels + \item Make incoming and outgoing voice calls between phones + \item Send/receive SMS between phones + \item Connect to ISDN PBX or public ISDN via Linux Call Router +\end{itemize} +\end{frame} + +\begin{frame}{OpenBSC in NITB mode}{Network In a Box Mode} +The {\tt bsc\_hack} program +\begin{itemize} + \item does not implement any other GSM interfaces apart from A-bis + \item no SS7 / TCAP / MAP based protocols + \item no integration (roaming) with existing traditional GSM networks + \item wired telephony interfacing with ISDN PBX {\tt lcr} (Linux Call Router) + \item Has been tested with up to 800 subscribers on 5 BTS + \item Intended for R\&D use or private PBX systems +\end{itemize} +\end{frame} + +\begin{frame}{OpenBSC LCR integration}{Interfacing with wired telephony} +OpenBSC (NITB mode) can be linked into Linux Call Router ({\tt lcr}) +\begin{itemize} + \item OpenBSC is compiled as libbsc.a + \item libbsc.a includes full OpenBSC NITB mod code + \item linking the library into {\tt lcr} results in GSM {\em line interfaces} to become available inside {\tt lcr} + \item OpenBSC no longer takes care of call control, but simply hands everything off to {\tt lcr} + \item Dialling plan, etc. is now configure in {\tt lcr} like for any other wired phones +\end{itemize} +\end{frame} + +\subsection{OpenBSC BSC-only mode} + +\begin{frame}{OpenBSC in BSC-only mode} +The {\tt osmo-bsc} program +\begin{itemize} + \item behaves like a classic GSM BSC + \item uses SCCP-Lite (ip.access multipex) to any SoftMSC like ADC + \item used in production/commercial deployments (~ 75 BSCs) + \item mainly intended to replace proprietary BSC in traditional GSM networks +\end{itemize} +\end{frame} + +\begin{frame}{OpenBSC} + Demonstration +\end{frame} + +\subsection{OpenBSC GPRS support} + +\begin{frame}{GPRS and OpenBSC} +\begin{itemize} + \item The BSC doesn't really do anything related to GPRS + \item GPRS implemented in separate SGSN and GGSN nodes + \item GPRS uses its own Gb interface to RAN, independent of A-bis + \item OpenBSC can configure the nanoBTS for GPRS+EDGE support via OML + \item Actual SGSN and GGSN implemented as OsmoSGSN and OpenGGSN programs +\end{itemize} +\end{frame} + +\begin{frame}{OsmoSGSN} +The Osmocom SGSN program implements +\begin{itemize} + \item basic/minimal SGSN functionality + \item the Gb interface (NS/BSSGP/LLC/SNDCP) + \item mobility management, session management +\end{itemize} +It's a work in progress, many missing features +\begin{itemize} + \item no HLR integration yet + \item no paging coordination with MSC/BSC + \item no encryption support yet +\end{itemize} +\end{frame} + +\begin{frame}{OpenGGSN} +\begin{itemize} + \item GPL licensed Linux program implementing GGSN node + \item Implements GTP-U protocol between SGSN and GGSN + \item User-configurable range/pool of IPv4 addresses for MS + \item Uses {\tt tun} device for terminating IP tunnel from MS + \item provides GTP implementation as libgtp + \item Experimental patches for IPv6 support +\end{itemize} +\end{frame} + +%\begin{frame}{OpenBSC + OpenGGSN + OsmoSGSN} +% Demonstration +%\end{frame} + +% FIXME: include slide showing full OpenBSC+OsmoSGSN+OpenGGSN network diff --git a/2010/gsm_foss-mt2010/section-openbts.tex b/2010/gsm_foss-mt2010/section-openbts.tex new file mode 100644 index 0000000..3675e85 --- /dev/null +++ b/2010/gsm_foss-mt2010/section-openbts.tex @@ -0,0 +1,140 @@ +\subsection{OpenBTS} + +\begin{frame}{What is OpenBTS?} +\begin{itemize} + \item is {\em NOT} a BTS in the typical GSM sense + \item is better described as a GSM-Um to SIP gateway + \item implements the GSM Um (air interface) as SDR + \item uses the USRP hardware as RF interface + \item does not implement any of BSC, MSC, HLR, etc. + \item bridges the GSM Layer3 protocol onto SIP + \item uses SIP switch (like Asterisk) for switching calls + SMS + \item is developed as C++ program and runs on Linux + MacOS +\end{itemize} +\end{frame} + +\begin{frame}{What is OpenBTS?} +\begin{itemize} + \item Open implementation of Um L1 \& L2, an all-software BTS. + \item L1/L2 design based on an object-oriented dataflow approach. + \item Includes L3 RR functions normally found in BSC. + \item Uses SIP PBX for MM and CC functions, eliminating the conventional GSM network. L3 is like an ISDN/SIP gateway. + \item Intended for use in low-cost and rapidly-deployed communications networks, but can be used for experiments (including by Chris Pagent at Def Con). +\end{itemize} +\end{frame} + +\begin{frame}{OpenBTS Hardware} +OpenBTS supports the following SDR hardware +\begin{itemize} + \item Ettus USRP(1) with two RFX 900 or RFX 1800 daughter boards + \begin{itemize} + \item Modification for external clock input recommended + \item External 52 MHz precision clock recommended + \end{itemize} + \item Kestrel Signal Processing / Range Networks custom radio + \item Close Haul Communications / GAPfiller (work in progress) + \item Ported to other radios by other clients. +\end{itemize} +\end{frame} + + +\begin{frame}{OpenBTS History + Tests} +\begin{itemize} + \item Started work in Aug 2007, first call in Jan 2008, first SMS in Dec 2008. + \item First public release in September 2008, assigned to FSF in Oct 2008. + \item Ran 3-sector 3-TRX system with 10,000-20,000 handsets at Sept 2009 Burning Man event in Nevada. + \item Ran 2-sector 5-TRX system with 40,000 handsets at Sept 2010 Burning Man event in Nevada. + \item Release 2.5 is about 13k lines of C++. + \item Part of GNU Radio project, distributed under AGPLv3. + \item Range Networks launched in Sept 2010 to produce commercial products and distributions. +\end{itemize} +\end{frame} + + +\begin{frame}{Burning Man 2010 Tower Base} +\begin{figure}[h] + \centering + \includegraphics[width=85mm]{OBTSBM2010.jpg} +\end{figure} +\end{frame} + +%\subsection{Clocking} +% +%\begin{frame}{OpenBTS USRP Clocking}{Clock Stability} +%\begin{itemize} +% \item USRP has regular XO (Crystal Oscillator) with 20ppm accuracy +% \item GSM requires 20ppb carrier clock accuracy +% \item possible solutions +% \begin{itemize} +% \item use external VCTCXO clocking module +% \item use external OCXO clocking module +% \item use a software calibration program comparing USRP XO with real GSM BTS carrier clocks +% \end{itemize} +% \item due to clock multiplication, absolute error in GSM1800 is higher than in GSM900 +%\end{itemize} +%\end{frame} + + +%\begin{frame}{OpenBTS USRP Clocking}{64 MHz vs. 52 MHz clock} +%\begin{itemize} +% \item The USRP master clock is 64 Mhz +% \item In GSM, all clocks are derived from 13 MHz +% \item Thus, a poly-phase re-sampler is part of SDR software +% \item Alternative: use 52 MHz (13 MHz * 4) external clock +% \item OpenBTS has two transceiver programs, one for each 64 MHz and 52 MHz +% \begin{itemize} +% \item Make sure to never use the wrong transceiver for your clock! +% \end{itemize} +%\end{itemize} +%\end{frame} + +%\begin{frame}{OpenBTS USRP Clocking}{Software Calibration} +%Basic idea: Use real GSM cell as clock source +%\begin{itemize} +% \item Implemented by the {\em Kalibrator} ({\tt kal}) program +% \item Acquire the FCCH burst of a real GSM cell +% \item Measure the clock difference between USRP XO and that cell +% \item Use the computed error as offset to USRP up/downconverter +% \item However, temperature and other drift will make clocks go out of sync over time +% \item Can only be used if a real-world GSM network is within range +%\end{itemize} +%\end{frame} + +%\begin{frame}[fragile]{OpenBTS USRP Clocking}{Kalibrator Example} +%\begin{block}{Example of running {\tt kal}} +%\begin{lstlisting} +%[openBTS@openBTS kal-0.2]# ./kal -f 946600000 -u +%USRP side: B +%FPGA clock: 52000000 +%Decimation: 192 +%Antenna: RX2 +%Sample rate: 270833.343750 +%average [min, max] (range, stddev) -2197.789062 [-2431, -1843] (588, 146.761444) +%\end{lstlisting} +%\end{block} +%The value {\bf -2198 should be used as FREQOFF constant in Transceiver/USRPDevice.cpp} +%\end{frame} + + +%\begin{frame}{OpenBTS} +% Demonstration +%\end{frame} + + +%\begin{frame}{OpenMS} +%\begin{itemize} +% \item Subscriber side stack based on OpenBTS. +% \item Called MS, but just a BTS stack with data flows reversed and a different RR control logic. +% \item Behavior is more like a passive interceptor that can also transmit. +% \item Release 1.0 supports non-hopping multi-ARFCN networks. +% \item Most L3 control logic provided by the end user. +% \item A platform for +% \begin{itemize} +% \item passive interceptors +% \item custom subscriber-side applications +% \item environment analysis +% \item intelligent jamming +% \end{itemize} +%\end{itemize} +%\end{frame} + diff --git a/2010/gsm_foss-mt2010/section-osmocombb.tex b/2010/gsm_foss-mt2010/section-osmocombb.tex new file mode 100644 index 0000000..07ff2f4 --- /dev/null +++ b/2010/gsm_foss-mt2010/section-osmocombb.tex @@ -0,0 +1,282 @@ +\section{OsmocomBB Project} + +%\begin{frame}{A GSM phone baseband processor} +%\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} + + +\subsection{OsmocomBB Introduction} + +\begin{frame}{OsmocomBB Introduction} +\begin{itemize} + \item Project was started only in January 2010 (9 months ago!) + \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} + +\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 Drivers for Audio/Voice signal path + \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 + \item Automatic Rx gain control (AGC) + \item Frequency Hopping + \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: Working (2/2)} +OsmocomBB can now do GSM Voice calls (08/2010) +\begin{itemize} + \item Very Early Assignment + Late Assignment + \item A3/A8 Authentication of SIM + \item A5/1 + A5/2 Encryption + \item Full Rate (FR) and Enhanced Full Rate (EFR) codec +\end{itemize} +\end{frame} + +\begin{frame}{OsmocomBB Project Status: Not working} +\begin{itemize} + \item Fully-fledged SIM card reader inside phone (WIP) + \item Layer1 + \begin{itemize} + \item Neighbor Cell Measurements + \item In-call hand-over to other cells + \end{itemize} + \item Actual UI on the phone + \item Circuit Switched Data (CSD) calls + \item GPRS (packet data) +\end{itemize} +\end{frame} + +\begin{frame}{OsmocomBB Project Status: Executive Summary} +\begin{itemize} + \item We can establish control/signalling channels to both hopping and non-hopping GSM cells + \begin{itemize} + \item Control over synthesizer means we can even go to GSM-R band + \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 TCH (Traffic Channel) support for voice calls + \begin{itemize} + \item Dieter Spaar and Andreas Eversberg have made multiple 20 minute call with current master branch + \item Some people have tried alpha code on real networks for real 30+ minute calls! + \end{itemize} +\end{itemize} +\end{frame} diff --git a/2010/gsm_foss-mt2010/section-simtrace.tex b/2010/gsm_foss-mt2010/section-simtrace.tex new file mode 100644 index 0000000..75aed46 --- /dev/null +++ b/2010/gsm_foss-mt2010/section-simtrace.tex @@ -0,0 +1,39 @@ +\section{Osmocom SIMtrace} + +\subsection{Debugging SIM drivers and STK apps} + +\begin{frame}{Debugging SIM toolkit applications is hard} +\begin{itemize} + \item Regular end-user phone does not give much debugging + \item SIM card itself has no debug interface for printing error messages, warnings, etc. + \item However, as SIM-ME interface is unencrypted, sniffing / tracing is possible + \item Commercial / proprietary solutions exist, but are expensive +\end{itemize} +\end{frame} + +\subsection{Osmocom SIMtrace Introduction} + +\begin{frame}{Introducing Osmocom SIMtrace} +\begin{itemize} + \item Osmocom SIMtrace is a passive (U)SIM-ME communication sniffer + \item Insert SIM adapter into actual phone + \item Insert (U)SIM into SIMtrace hardware + \item SIMtrace hardware provides USB interface to host PC + \item {\tt simtrace} program on PC encapsulates APDU in GSMTAP + \item GSMTAP is sent via UDP to localhost + \item wireshark dissector for GSM TS 11.11 decodes APDUs +\end{itemize} +\end{frame} + +\subsection{Osmocom SIMtrace Hardware} + +\begin{frame}{Osmocom SIMtrace Hardware} +\begin{itemize} + \item Hardware is based around AT91SAM7S controller + \item SAM7S Offers two ISO 7816-3 compatible USARTs + \item USARTs can be clock master (SIM reader) or slave (SIM card) + \item Open Source Firmware on SAM7S implementing APDU sniffing + \item Auto-bauding depending CLK signal, PPS supported + \item Only prototype hardware right, but will be manufactured in Q1/2011 +\end{itemize} +\end{frame} diff --git a/2010/gsm_foss-mt2010/section-wireshark.tex b/2010/gsm_foss-mt2010/section-wireshark.tex new file mode 100644 index 0000000..588b4ab --- /dev/null +++ b/2010/gsm_foss-mt2010/section-wireshark.tex @@ -0,0 +1,61 @@ +\section{wireshark Protocol Analyzer} + +\begin{frame}{The wireshark protocol analyzer} +\begin{itemize} + \item Software protocol analyzer for plethora of protocols + \item Portable, works on most flavors of Unix and Windows + \item Decode, display, search and filter packets with configurable level of detail + \item Over 1000 protocol decoders + \item Over 86000 display filters + \item Live capturing from many different network media + \item Import files from other capture programs + \item Used to be called ethereal, but is now called wireshark +\item \url{http://www.wireshark.org/} +\item \url{http://www.wireshark.org/download/docs/user-guide-a4.pdf} +\end{itemize} +\end{frame} + +\begin{frame}{The wireshark protocol analyzer} +GSM protocol dissectors in wireshark +\begin{itemize} + \item TCP/IP (transport layer for Abis/IP) + \item E1 Layer 2 (LAPD) + \item GSM Um Layer 2 (LAPDm) + \item GSM Layer 3 (RR, MM, CC) + \item A-bis Layer 3 (RSL) + \begin{itemize} + \item A-bis OML for Siemens and ip.access in OpenBSC git + \end{itemize} + \item GSMTAP pseudo-header (airprobe, OpenBTS, OsmocomBB) +\end{itemize} +\end{frame} + +\begin{frame}{wireshark integration in OsmocomBB} +\begin{itemize} + \item OsmocomBB L1 runs on phone + \item OsmocomBB L23 runs on host PC + \item OsmocomBB L23 encapsulates 23byte L2 message in GSMTAP + \item GSMTAP includes information not present in L2, such as + \begin{itemize} + \item ARFCN, Timeslot + \item GSM Frame Number + \item Rx Signal Level / SNR + \end{itemize} + \item OsmocomBB L23 sends GSMTAP message over UDP socket + \item wireshark captures UDP packet like any UDP/IP +\end{itemize} +\end{frame} + +\begin{frame}{wireshark integration in OpenBTS and airprobe} +\begin{itemize} + \item airprobe software runs on host PC + \item implements Rx-only GSM L1 as SDR + \item airprobe L23 encapsulates 23byte L2 message in GSMTAP + \item wireshark captures UDP packet like any UDP/IP + \item OpenBTS wireshark intergration similar, but for Rx + Tx +\end{itemize} +\end{frame} + +\begin{frame}{The wireshark protocol analyzer} + Demonstration +\end{frame} -- cgit v1.2.3