2598 lines
93 KiB
TeX
2598 lines
93 KiB
TeX
|
|
\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 <tantau@users.sourceforge.net>.
|
|
%
|
|
% In principle, this file can be redistributed and/or modified under
|
|
% the terms of the GNU Public License, version 2.
|
|
%
|
|
% However, this file is supposed to be a template to be modified
|
|
% for your own needs. For this reason, if you use this file as a
|
|
% template and not specifically distribute it as part of a another
|
|
% package/program, I grant the extra permission to freely copy and
|
|
% modify this file as you see fit and even to delete this copyright
|
|
% notice.
|
|
|
|
|
|
\mode<presentation>
|
|
{
|
|
\usetheme{Warsaw}
|
|
% or ...
|
|
|
|
\setbeamercovered{transparent}
|
|
% or whatever (possibly just delete it)
|
|
}
|
|
|
|
\mode<handout>{
|
|
\usepackage{handoutWithNotes}
|
|
\pgfpagesuselayout{1 on 1 with notes portrait}[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}
|
|
% 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.
|
|
|
|
\usepackage{subfigure}
|
|
\usepackage{hyperref}
|
|
|
|
\title{GSM Air Interface Security}
|
|
|
|
%\subtitle{and other GSM related fun}
|
|
|
|
\author{David~Burgess\inst{1} \and Harald~Welte\inst{2}}
|
|
|
|
\institute[Kestrel and others]{
|
|
\inst{1}OpenBTS, Kestrel Signal Processing (USA)
|
|
\and
|
|
\inst{2}OpenBSC, hmw-consulting.de (Germany)
|
|
}
|
|
% - Use the \inst command only if there are several affiliations.
|
|
% - Keep it simple, no one is interested in your street address.
|
|
|
|
\date[DeepSec 2009] % (optional, should be abbreviation of conference name)
|
|
{DeepSec conference, November 2009, Vienna/Austria}
|
|
% - Either use conference name or its abbreviation.
|
|
% - Not really informative to the audience, more for people (including
|
|
% yourself) who are reading the slides online
|
|
|
|
\subject{GSM Security}
|
|
% This is only inserted into the PDF information catalog. Can be left
|
|
% out.
|
|
|
|
|
|
|
|
% If you have a file called "university-logo-filename.xxx", where xxx
|
|
% is a graphic format that can be processed by latex or pdflatex,
|
|
% resp., then you can add a logo as follows:
|
|
|
|
% \pgfdeclareimage[height=0.5cm]{university-logo}{university-logo-filename}
|
|
% \logo{\pgfuseimage{university-logo}}
|
|
|
|
|
|
|
|
% Delete this, if you do not want the table of contents to pop up at
|
|
% the beginning of each subsection:
|
|
%\AtBeginSubsection[]
|
|
%{
|
|
% \begin{frame}<beamer>{Outline}
|
|
% \tableofcontents[currentsection,currentsubsection]
|
|
% \end{frame}
|
|
%}
|
|
|
|
|
|
% If you wish to uncover everything in a step-wise fashion, uncomment
|
|
% the following command:
|
|
|
|
%\beamerdefaultoverlayspecification{<+->}
|
|
|
|
|
|
\begin{document}
|
|
|
|
\begin{frame}
|
|
\titlepage
|
|
\end{frame}
|
|
|
|
|
|
% 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.
|
|
|
|
\part{Introduction}
|
|
|
|
\begin{frame}{Introduction}
|
|
\tableofcontents
|
|
% You might wish to add the option [pausesections]
|
|
\end{frame}
|
|
|
|
|
|
\begin{frame}{Our Goals in this Workshop}
|
|
\begin{itemize}
|
|
\item{Familiarize you with the internals of GSM systems.}
|
|
\item{Examine security weaknesses in GSM systems.}
|
|
\begin{itemize}
|
|
\item{Theoretical weaknesses.}
|
|
\item{Demonstrations.}
|
|
\item{Products and practices.}
|
|
\end{itemize}
|
|
\item{Describe countermeasures to avoid these weaknesses\\ ...where possible.}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\section{About the Speakers}
|
|
|
|
\subsection{David A.~Burgess}
|
|
|
|
\begin{frame}{About David A.~Burgess}{dburgess@kestrelsp.com}
|
|
\begin{itemize}
|
|
\item Degrees in Electrical Engineering (BEE) and Computer Science (MSc).
|
|
\item Signal processing experience: audio synthesis and simulation, radar, sonar and electronic warfare.
|
|
\item First introduced to GSM in 1998 in SIGINT project.
|
|
\item Provide software for fielded intelligence systems in use today.
|
|
\item Started the OpenBTS project in mid-2007.
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\subsection{Harald Welte}
|
|
|
|
\begin{frame}{About Harald Welte}{hwelte@hmw-consulting.de}
|
|
\begin{itemize}
|
|
\item Using + playing with Linux since 1994
|
|
\item Kernel, bootloader, driver, firmware development since 1999
|
|
\item IT security specialist, focus on network protocol security
|
|
\item Board-level Electrical Engineering
|
|
\item Interested in various protocols (RFID, DECT, GSM)
|
|
\item netfilter/iptables, OpenPCD, OpenMoko, librfid, OpenEZX
|
|
\item Main developer of OpenBSC project
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\section{Legal Disclaimer}
|
|
|
|
\begin{frame}{Legal Disclaimer}
|
|
\begin{itemize}
|
|
\item We are demonstrating normal GSM operations and security flaws using a private network and informed participants.
|
|
\item By leaving your GSM handset turned on during this workshop, you consent to participate in these demonstrations.
|
|
\item Nothing we do will damage your handset, but you may suffer temporary disruptions in service, unsolicited text messages and other annoyances.
|
|
\item Not all of the software used to demonstrate security weaknesses is not part of the normal OpenBTS or OpenBSC distributions.
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\subsection{Applicable Law -- US}
|
|
|
|
\begin{frame}{Applicable Law -- US}
|
|
\begin{itemize}
|
|
\item 47 USC 302 and 18 USC 2512 ban distribution or advertisement of jammers or intercept devices to the general public, limits import and manufacture.
|
|
\item 47 USC 333 bans interference with licensed operations.
|
|
\item 18 USC 2511 bans unauthorized intercept of communications ``not available to the public''.
|
|
\item 47 USC 605 bans publication of intercepted content.
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Applicable Law -- US}
|
|
US laws control ``devices''. That normally means complete HW/SW systems. Whether or not these laws can be applied to pure software is probably an open question. We do not intend to become test cases.
|
|
Another key phrase in some of these laws is ``primary purpose''. User interfaces, default configurations, documentation and statements of intention are important in establishing ``primary purpose''.
|
|
\end{frame}
|
|
|
|
\subsection{Applicable Law -- EU}
|
|
|
|
\begin{frame}{Applicable Law -- EU}
|
|
\begin{itemize}
|
|
% You guys got any laws against this stuff?
|
|
\item Laws on jammers vary across Europe. Legal to own in some places, generally illegal to use but several countries make exceptions for jails.
|
|
\item EMC Directive 2004/108/EC: Use of equipment. Not applicable for R\&TTED devices
|
|
\item R\&TTED Directive 1999/5/EC: Declaration of Conformity sufficient, no strict need to invove certification lab
|
|
\item 2000/299/EC: Classification of radio equipment -- GSM900/GSM1800 equipment is "Class 1", can be redistributed all over Europe
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Applicable Law -- DE}
|
|
\begin{itemize}
|
|
\item \S 317 StGB: Stoerung von Telekommunikationsanlagen
|
|
\begin{itemize}
|
|
\item Causing interference with or deactivating public telecommunications networks
|
|
\item Punishable up to 5 years imprisonment
|
|
\item Even the attempt is punishable
|
|
\end{itemize}
|
|
\item \S 202a StGB: Ausspaehen von Daten
|
|
\begin{itemize}
|
|
\item Accessing data intended for other recipients and which are specially protected against unauthorized access
|
|
\item Punishable up to 3 years imprisonment
|
|
\end{itemize}
|
|
\item \S 303a StGB: Datenveraenderung
|
|
\begin{itemize}
|
|
\item Unauthorized deletion, modification or suppression of data
|
|
\item Punishable up to 2 years imprisonment
|
|
\item Even the attempt is punishable
|
|
\end{itemize}
|
|
\item \S 149 (1) Satz 10 TKG: Bussgeldvorschriften
|
|
\begin{itemize}
|
|
\item Transmitting without an apropriate license
|
|
\item penalty of up to EUR 1,500 plus EUR 600/900
|
|
\end{itemize}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
|
|
\subsection{Information Sources}
|
|
|
|
\begin{frame}{Information Sources}
|
|
\begin{itemize}
|
|
\item All information presented here is available form public sources
|
|
\item Most of the information presented here is readily derived from public specifications, \emph{if you actually take the time to read them}
|
|
\item Nothing presented here is subject to trade secret restrictions
|
|
\item Nothing presented here was received under a government security clearance agreement
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\section*{Outlines}
|
|
|
|
\begin{frame}<handout:0>
|
|
\nameslide{outline}
|
|
\frametitle{Outline of Part I}
|
|
\tableofcontents[hideallsubsections,part=2]
|
|
\end{frame}
|
|
|
|
\begin{frame}<handout:0>
|
|
\nameslide{outline}
|
|
\frametitle{Outline of Part II}
|
|
\tableofcontents[hideallsubsections,part=3]
|
|
\end{frame}
|
|
|
|
\begin{frame}<handout:0>
|
|
\nameslide{outline}
|
|
\frametitle{Outline of Part III}
|
|
\tableofcontents[hideallsubsections,part=4]
|
|
\end{frame}
|
|
|
|
\begin{frame}<handout:0>
|
|
\nameslide{outline}
|
|
\frametitle{Outline of Part IV}
|
|
\tableofcontents[hideallsubsections,part=5]
|
|
\end{frame}
|
|
|
|
\begin{frame}<handout:0>
|
|
\nameslide{outline}
|
|
\frametitle{Outline of Part V}
|
|
\tableofcontents[hideallsubsections,part=6]
|
|
\end{frame}
|
|
|
|
\begin{frame}<handout:0>
|
|
\nameslide{outline}
|
|
\frametitle{Outline of Part VI}
|
|
\tableofcontents[hideallsubsections,part=7]
|
|
\end{frame}
|
|
|
|
\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 chipset 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
|
|
\end{itemize}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{The closed GSM industry}{Operator side}
|
|
\begin{itemize}
|
|
\item Operators are mainly banks today
|
|
\item Typical operator outsources
|
|
\begin{itemize}
|
|
\item Billing
|
|
\item Network planning / deployment / servicing
|
|
\end{itemize}
|
|
\item Operator just knows the closed equipment as shipped by manufacturer
|
|
\item Very few people at an operator have knowledge of the protocol beyond what's needed for operations and maintenance
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\subsection{Security implications}
|
|
|
|
\begin{frame}{The closed GSM industry}{Security implications}
|
|
The security implications of the closed GSM industry are:
|
|
\begin{itemize}
|
|
\item Almost no people who have detailed technical knowledge outside the protocol stack or GSM network equipment manufacturers
|
|
\item No independent research on protocol-level security
|
|
\begin{itemize}
|
|
\item If there's security research at all, then only theoretical (like the A5/2 and A5/1 cryptanalysis)
|
|
\item Or on application level (e.g. mobile malware)
|
|
\end{itemize}
|
|
\item No open source protocol implementations
|
|
\begin{itemize}
|
|
\item which are key for making more people learn about the protocols
|
|
\item which enable quick prototyping/testing by modifying existing code
|
|
\end{itemize}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Security analysis of GSM}{How would you get started?}
|
|
If you were to start with GSM protocol level security analysis, where and
|
|
how would you start?
|
|
\begin{itemize}
|
|
\item On the handset side?
|
|
\begin{itemize}
|
|
\item Difficult since GSM firmware and protocol stacks are closed and proprietary
|
|
\item Even if you want to write your own protocol stack, the layer 1 hardware and signal processing is closed and undocumented, too
|
|
\item Known attempts
|
|
\begin{itemize}
|
|
\item The TSM30 project as part of the THC GSM project
|
|
\item mados, an alternative OS for Nokia DTC3 phones
|
|
\end{itemize}
|
|
\item none of those projects successful so far
|
|
\end{itemize}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Security analysis of GSM}{How would you get started?}
|
|
If you were to start with GSM protocol level security analysis, where and
|
|
how would you start?
|
|
\begin{itemize}
|
|
\item On the network side?
|
|
\begin{itemize}
|
|
\item Difficult since equipment is not easily available and normally extremely expensive
|
|
\item However, network is very modular and has many standardized/documented interfaces
|
|
\item Thus, if equipment is available, much easier/faster progress
|
|
\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}
|
|
|
|
|
|
\part{The GSM network}
|
|
|
|
\begin{frame}{Part I -- The GSM network}
|
|
\tiny{\tableofcontents}
|
|
% You might wish to add the option [pausesections]
|
|
\end{frame}
|
|
|
|
\section{The GSM network -- Overview}
|
|
|
|
\begin{frame}{The GSM network}
|
|
\begin{figure}[h]
|
|
\centering
|
|
\includegraphics[width=100mm]{gsm_network.png}
|
|
\end{figure}
|
|
\end{frame}
|
|
|
|
\subsection{GSM network components}
|
|
|
|
\begin{frame}{GSM network components}
|
|
\begin{itemize}
|
|
\item The BSS (Base Station Subsystem)
|
|
\begin{description}[BTS]
|
|
\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{description}
|
|
\item The NSS (Network Sub System)
|
|
\begin{description}[MSC]
|
|
\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{description}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\subsection{GSM network structure}
|
|
|
|
\begin{frame}{GSM Network Structure}
|
|
\begin{description}[BTS]
|
|
\item[BTS] Generates the actual radio interface. Mostly an L1/L2. Serves a single cell sector.
|
|
\begin{description}[TRX]
|
|
\item[TRX] Transceiver inside a BTS, serves one physical channel (ARFCN)
|
|
\end{description}
|
|
\item[BSC] Manages radio resources and some mobility functions. Serves up to a few dozen BTSs in a ``location area''.
|
|
\item[MSC] Actual call switching and top-level mobility functions. May serve dozens of location areas.
|
|
\item[HLR] (and VLR) The subscriber databases, routing databasses and authentication centers.
|
|
\end{description}
|
|
\end{frame}
|
|
|
|
%\begin{frame}{GSM Network Structure}
|
|
%\includegraphics[width=100mm]{GSMNetwork.pdf}
|
|
%\end{frame}
|
|
|
|
\subsection{GSM network interfaces}
|
|
|
|
\begin{frame}{GSM network interfaces}
|
|
\begin{description}[A-bis]
|
|
\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{description}
|
|
GSM networks are a prime example of an {\em asymmetric distributed} network,
|
|
very different from the end-to-end transparent IP network.
|
|
\end{frame}
|
|
|
|
\begin{frame}{Think ISDN (E1/T1), not 802.11}
|
|
\begin{itemize}
|
|
\item{Many computer networking people assume that cellular is similar to WiFi. \alert{It is NOT!}}
|
|
\item{Cellular interfaces are modeled after TDM trunk lines, not Ethernet}
|
|
\begin{itemize}
|
|
\item{multiplexed L1 with dedicated channels}
|
|
\item{HDLC-style L2}
|
|
\item{ISDN-style L3}
|
|
\end{itemize}
|
|
\item Channel establishmend often takes \emph{seconds}
|
|
\item Bandwidth is a scarce resource
|
|
\item Message source and destination not part of every packet but implicitly known based on TDMA assignment.
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\subsection{GSM network identities}
|
|
|
|
\begin{frame}{GSM Identity \& Address Types}
|
|
\begin{description}[MSISDN]
|
|
\item[IMSI] 15 digits, universally unique to the subscriber
|
|
\item[TMSI] 32 bits, assigned temporarily within a network
|
|
\item[IMEI] 15 digits, universally unique to the handset
|
|
\item[MSISDN] a permanently-assigned E.164; the subscriber's phone number
|
|
\item[MSRN] a temporary E.164 for routing to a mobile subscriber
|
|
\end{description}
|
|
\end{frame}
|
|
|
|
\section{GSM Um Interface}
|
|
|
|
\subsection{Overview}
|
|
|
|
\begin{frame}{Understanding Um}{Overview}
|
|
% Following GSM 04.03 Section 4
|
|
%\small{
|
|
\begin{itemize}
|
|
\item Modeled after the U interface of ISDN
|
|
\item Broadcast channels: SCH, BCCH, FCCH
|
|
\item Common channels: CCCH (PCH \& AGCH), RACH
|
|
\item Dedicated Channels:
|
|
\begin{description}[Dm]
|
|
\item[Dm] SDCCH, FACCH, SACCH
|
|
\item[Bm] TCH/H, TCH/F
|
|
\end{description}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Understanding Um}{Channels \& Layers}
|
|
\begin{figure}[h]
|
|
\centering
|
|
\includegraphics[width=100mm]{GSMLayers.pdf}
|
|
\end{figure}
|
|
\end{frame}
|
|
|
|
\subsection{Time Division Multiplex}
|
|
|
|
\begin{frame}{Understanding Um}{TDM Structure}
|
|
\begin{itemize}
|
|
\item ARFCN (Absolute Radio Freq.~Chan.~Num.)-- A 270,833 Hz radio channel. ARFCNs within a BTS numbered C0, C1, etc.
|
|
\item 8 timeslots per frame on each ARFCN, numbered T0..T7.
|
|
\item ``physical channel'' -- one slot on one ARFCN, designated C0T0, C0T1, C1T5, etc.
|
|
\item Physical channel TDM follows a 26- or 52-frame multiframe, carrying multiple logical channels.
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Understanding Um --TDM Example}
|
|
\begin{figure}[h]
|
|
\centering
|
|
\includegraphics[width=90mm]{26Multiframe.pdf}
|
|
\caption{Example of traffic channel TDM}
|
|
\end{figure}
|
|
\end{frame}
|
|
|
|
\subsection{Logical Channels}
|
|
|
|
\begin{frame}{Understanding Um}{The Beacon}
|
|
The beacon is always on C0T0 and always constant full power
|
|
\begin{description}[CCCH]
|
|
\item[SCH] (Sync.) -- TDM timing and reduced BTS identity
|
|
\item[FCCH] (Freq.~Corr.) -- Fine frequency synchronization
|
|
\item[BCCH] (Broadcast Control) -- Cell configuration and neighbor list
|
|
\item[CCCH] (Common Control) -- a set of unicast channels
|
|
\begin{description}[AGCH]
|
|
\item[PCH] paging channel for network-originated transactions
|
|
\item[AGCH] access grant channel
|
|
\item[RACH] uplink access request
|
|
\end{description}
|
|
\end{description}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Understanding Um}{SCH -- Synchronization CHannel}
|
|
\begin{itemize}
|
|
\item First channel acquired by a handset
|
|
\item T1, T2, T3' -- TDM clocks for GSM frame number
|
|
\item BCC -- 3 bits, identifies BTS in the local group
|
|
\item NCC -- 3 bits, identifies network within a region
|
|
\item BSIC is NCC:BCC
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Understanding Um}{BCCH -- Broadcast Control CHannel}
|
|
\begin{itemize}
|
|
\item Second channel acquired by the handset.
|
|
\item A repeating cycle of system information messages.
|
|
\begin{description}[Type 4]
|
|
\item[Type 1] ARFCN set
|
|
\item[Type 2] Neighbor list
|
|
\item[Type 3] Cell/Network identity, CCCH configuration
|
|
\item[Type 4] Network identity, cell selection parameters
|
|
\item[GPRS] adds a few more (7, 9, 13, 16, 17)
|
|
\end{description}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Understanding Um}{CCCH -- Common Control CHannel}
|
|
\begin{description}[AGCH]
|
|
\item[PCH] Paging
|
|
\begin{itemize}
|
|
\item Unicast. Handsets addressed by IMSI or TMSI, never IMEI.
|
|
\item Handset sees paging request and then requests service on RACH.
|
|
\end{itemize}
|
|
\item[RACH] Random Access
|
|
\begin{itemize}
|
|
\item Handset requests channel with RACH burst, 8-bit tag.
|
|
\end{itemize}
|
|
\item[AGCH] Access Grant
|
|
\begin{itemize}
|
|
\item BTS answers on AGCH, echoing tag and timestamp.
|
|
\end{itemize}
|
|
\end{description}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Understanding Um}{Dm Channels}
|
|
\begin{description}[SDCCH]
|
|
\item[SDCCH] Most heavily used control channel: registration, SMS transfers, call setup in many networks. Payload rate of 0.8 kb/s.
|
|
\item[FACCH] Blank and burst channel steals bandwidth from traffic. Used for in-call signaling, call setup in some networks. Payload rate up to 9.2 kb/s on TCH/F.
|
|
\item[SACCH] Low rate channel muxed onto every other logical channel type. Used for timing/power control, measurement reports and in-call SMS transfers.
|
|
\end{description}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Understanding Um}{Bm Channels}
|
|
\begin{itemize}
|
|
\item Full rate TCH/F 22.7 kb/s raw rate, occupies a full slot
|
|
\item Half rate TCH/H 11.4 kb/s raw rate, 2 per slot using every other frame
|
|
\item Payloads:
|
|
\begin{description}[Speech]
|
|
\item[Speech] HR, FR, EFR, AMR
|
|
\item[Fax]
|
|
\item[CSD] Circuit Switched Data
|
|
\end{description}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\subsection{Miscellaneous}
|
|
|
|
\begin{frame}{Understanding Um -- Connectivity and ``Presence''}
|
|
\begin{itemize}
|
|
\item A handset is connected to the network only when it is assigned to a dedicated channel, otherwise it is {\em IDLE} and listening passively to the beacon.
|
|
\item Creation of a dedicated channel can take \emph{several seconds}.
|
|
\item The network can only guess the status of an idle handset based on the last transaction or transaction attempt, which may be several minutes old even under \emph{the best} conditions.
|
|
\item Even in a connected state, the signal between the handset and the network can disappear for several seconds at a time without resulting in loss of the channel.
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Frequency Hopping}
|
|
\begin{itemize}
|
|
\item Intended to improve radio performance through diversity in fading and interference
|
|
\item Two ways to implement hopping
|
|
\begin{itemize}
|
|
\item Baseband hopping: $N$ fixed-frequency transceivers are connected to $N$ baseband processors through a switch or commutator. Allows CA of $N$ ARFCNs. C0 can be in the CA.
|
|
\item Synthesizer hopping: Each of $N$ baseband processors connects to a dedicated transceiver. This requires transceivers that can be retuned and settled in less than 30~$\mu$s. Allows CA to have $\gg N$ ARFNCs. C0 is not in the CA.
|
|
\end{itemize}
|
|
\item Some networks implement synchronous hopping to prevent collisions of hopping bursts from neighboring cells.
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Frequency Hopping Parameters}
|
|
A {\em hopping sequence} is an ordered list of ARFCNs used by a given physical channel (PCH), synced to the GSM frame clock.
|
|
Each PCH can have an independent hopping sequence.
|
|
\begin{description}[MAIO]
|
|
\item[CA] Cell Allocation, set of ARFCNs used for hopping in BTS
|
|
\item[HSN] Hopping Sequence Number, parameter used in pseudorandom algorithm generating hopping sequence
|
|
\item[MA] Mobile Allocation, subset of CA used by a particular PCH
|
|
\item[MAIO] MA Index Offset, offset added to hopping sequence when indexing MA.
|
|
\end{description}
|
|
\begin{itemize}
|
|
\item CA is the same for every PCH in the BTS
|
|
\item HSN, MA and MAIO can be different for every PCH, usually only MAIO is unique
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
|
|
\begin{frame}{Understanding Um}{GPRS}
|
|
\begin{itemize}
|
|
\item{More like a separate service running parallel to GSM.}
|
|
\item{PCCCH and PBCCH used to make short-term assignments onto PDTCHs.}
|
|
\item{Burst data rates up to 50 kb/s for half-duplex handset on GMSK network.}
|
|
\item{Burst data rates up to 250 kb/s for full duplex handset on EDGE network.}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\section{The Layers of the Um Interface}
|
|
|
|
\begin{frame}{Understanding Um}{The Layers}
|
|
The Layers are not exactly the ISO model, but a similar theme.
|
|
\begin{description}
|
|
\item[L1] The radiomodem, TDM and FEC functions
|
|
\item[L2] Frame segmentation and retransmission
|
|
\item[L3] Connection \& mobility management
|
|
\item[L4] Relay functions between BSC and other entities
|
|
\end{description}
|
|
\end{frame}
|
|
|
|
|
|
\begin{frame}{Understanding Um}{The Layers}
|
|
\begin{figure}[h]
|
|
\centering
|
|
\includegraphics[width=85mm]{L2Figure.pdf}
|
|
\caption{Layers of a Dm channel}
|
|
\end{figure}
|
|
\end{frame}
|
|
|
|
\subsection{Um Layer 1}
|
|
|
|
\begin{frame}{Understanding Um}{L1}
|
|
\begin{itemize}
|
|
\item Analog radio path (transceiver, amplifiers, duplexer, antenna)
|
|
\item{GMSK or GMSK/EDGE radiomodem (``L0'')}
|
|
\item{TDM to define logical channels}
|
|
\item{FEC (Forward Error Correction)}
|
|
\begin{itemize}
|
|
\item{Rate-1/2 convolutional code is typical.}
|
|
\item{40-bit Fire code parity word on most control channels.}
|
|
\item{4-burst or 8-burst interleaving is typical.}
|
|
\end{itemize}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{L1 Overview (see handout)}
|
|
\begin{figure}[h]
|
|
\centering
|
|
\includegraphics[width=50mm]{UmL1Overview.pdf}
|
|
\end{figure}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Example -- OpenBTS L1 Dm Receive Path}
|
|
\small{
|
|
\begin{enumerate}
|
|
\item Tune, filter and decimate down to a 270.833~kHz baseband channel.
|
|
\item Demodulate GMSK with Laurent approximation, one burst at a time, to get probability estimates channel bits. (Soft-output demod.)
|
|
\item Demux burst to the the logical channel based on current frame number.
|
|
\item Deinterleave bursts according to T2 or T3. Mark bits from missing bursts as unknown bits.
|
|
\item Apply soft input Viterrbi decoder to L1 frame to recover L2 frame and parity word.
|
|
\item Compute parity word for received L2 frame.
|
|
\item If parity computed and received parity match, pass frame up to L2.
|
|
\end{enumerate}
|
|
}
|
|
\end{frame}
|
|
|
|
|
|
\begin{frame}{Um Radiomodem}
|
|
\begin{itemize}
|
|
\item Gaussian Minimum Shift Keying -- constant modulus to simplify amplifier design
|
|
\item Each timeslot carries a radio burst:
|
|
\begin{itemize}
|
|
\item guard period (between slots)
|
|
\item tail bits (at start and end of modulated data)
|
|
\item midamble (in center of burst)
|
|
\item payload bits (on each side of midamble)
|
|
\end{itemize}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Um ``Normal'' Burst}
|
|
\begin{figure}[h]
|
|
\centering
|
|
\includegraphics[width=100mm]{NormalBurst.pdf}
|
|
(From Wikipedia.)
|
|
\end{figure}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Um L1 Interleaving}
|
|
\begin{itemize}
|
|
\item Every GSM data frame is spread over 4 or 8 radio bursts.
|
|
\begin{itemize}
|
|
\item 4-burst block interleave on most channels
|
|
\item 8-burst diagonal interleave on TCHs
|
|
\end{itemize}
|
|
\item Loss of one burst means 1/4 or 1/8 missing channel bits, scattered throughout a frame.
|
|
\item Allows a slow-hopping system to achieve many performance gains associated with fast-hopping.
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Um L1 Decoding}
|
|
\begin{itemize}
|
|
\item Most channels use a rate-1/2 4th-order convolutional code.
|
|
\item With a soft-input decoder, you can discard 1/2 of the input bits and still recover a frame.
|
|
\item Dm channels use a 40-bit Fire parity code, designed to correct burst errors up to 12 bits long.
|
|
\item Parity coding on Bm channels is media-specific.
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Um Training Sequence}
|
|
\begin{itemize}
|
|
\item used to train equalizer for multipath mitigation
|
|
\item 26 symbols long, intended for use with 16-symbol correlator (12 dB processing gain)
|
|
\item chosen for good autocorrelation, low cross-correlation
|
|
\item with midamble \& tails, GSM TCH is 22\% known bits, 38 dB processing gain over 1 second
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Um Clock Control}
|
|
\begin{itemize}
|
|
\item MS has VCTCXO with natural error of a few kHz.
|
|
\item BTS has VCOCXO with natural error of a few Hz, calibrated regularly.
|
|
\item MS makes an initial search over a wide frequency window, then uses FCCH to calibrate VCTCXO to the BTS.
|
|
\item Once locked, the MS will not make another wide search unless it loses service completely.
|
|
\item GSM Specification mandates an accuracy of the carrier clock 30 ppb, that's less than 50 Hz @ 900MHz
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Um Timing Advance}
|
|
\begin{itemize}
|
|
\small{
|
|
\item Guard period 30~$\mu$s, a round trip distance of 4.5~km.
|
|
\item If a burst arrives delayed by more than 30~$\mu$s it can collide with the next timeslot at the receiver.
|
|
\item Avoid collisions with with active timing advance (TA) control.
|
|
\begin{itemize}
|
|
\item BTS measures timing error of arriving burst midamble.
|
|
\item MS reports current TA value in physical header on SACCH
|
|
\item BTS calculates new TA and sends it back on the SACCH physical header
|
|
\end{itemize}
|
|
\item Maximum TA of 63 symbols limits normal GSM range to 35 km.
|
|
}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Um Uplink Power Control}
|
|
\begin{itemize}
|
|
\item BTS controls uplink power to reduce dynamic range requirements in the receiver.
|
|
\item Power is controlled in roughly 2 dB steps in a closed loop:
|
|
\begin{itemize}
|
|
\item BTS measures power of arriving burst.
|
|
\item MS reports current tx power value in physical header on SACCH.
|
|
\item BTS calculates new tx power and sends it back in physical header on the SACCH.
|
|
\end{itemize}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Um Downlink Power Control}
|
|
\begin{itemize}
|
|
\item BTS can use downlink power control on carriers other than C0 to minimize interference with other BTSs.
|
|
\item Power is controlled in a closed loop:
|
|
\begin{itemize}
|
|
\item MS measures power of arriving bursts.
|
|
\item MS reports current RSSI in measurement reports on SACCH.
|
|
\item BTS adjusts its output power on that MS's timeslot to meet RSSI target.
|
|
\end{itemize}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Um Discontinuous Transmission (DTX)}
|
|
\begin{itemize}
|
|
\item On average, a participant in a call is silent half of the time.
|
|
\item GSM allows an MS or BTS to suspend transmission during silent periods, just sending an occasional keep-alive frame.
|
|
\item Vocoders generate ``comfort noise'' during silent periods.
|
|
\item For the MS, this saves battery power.
|
|
\item For the BTS, this minimizes interference with other cells.
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\subsection{Um Layer 2}
|
|
|
|
\begin{frame}{Understanding Um}{L2}
|
|
\begin{itemize}
|
|
\item L1 drops frames, but L3 assumes a reliable link.
|
|
\item L1 uses fixed-length frames, but L3 uses variable-length messages.
|
|
\item L2 (Data Link Layer) bridges the gap with segmentation, sequencing and retransmission.
|
|
\item ISDN uses LAPD for L2, derived from HDLC, derived from SDLC, dating back to IBM's SNA mainframe networks.
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Understanding Um}{L2}
|
|
\begin{itemize}
|
|
\item{LAPDm on Dm channels, a HDLC derivative, similar to ISDN's LAPD but simplified.}
|
|
\item{LLC on GPRS channels, another HDLC derivative.}
|
|
\item{GSM defines no L2 in Bm channels.}
|
|
\begin{itemize}
|
|
\item{Speech/fax are just media and have no L2.}
|
|
\item{CSD typically used with PPP for L2.}
|
|
\end{itemize}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Understanding Um}{L2 LAPDm}
|
|
\begin{itemize}
|
|
\small{
|
|
\item Frame types UI, UA, SABM RR, REJ, I.
|
|
\item Address, Control and Length fields in header. Some fields implied on some channel types.
|
|
\item Asynchronous Balanced Mode (ABM, ``multiframe mode'')
|
|
\begin{itemize}
|
|
\item 3-bit sequence numbers, in RR-, REJ- and I-frame control headers. NS for sent, NR for acked
|
|
\item T200 timeout for repeating unacked frames
|
|
\item channel abandoned after too many timeouts
|
|
\end{itemize}
|
|
\item Idle frame filling.
|
|
}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\subsection{Um Layer 3}
|
|
|
|
\begin{frame}{Understanding Um}{L3 Sublayers}
|
|
\begin{description}[SMSCP]
|
|
\item[RR] Radio Resource -- assigns and releases logical channels. Terminates in BSC
|
|
\item[MM] Mobility Management -- location, authentication. Terminates in BSC and MSC
|
|
\item[GMM] (GPRS Mobility Management) -- location, authentication. Terminates in BSC and SGSN
|
|
\item[CC] (Call Control) -- Q.931, like ISDN. Terminates in MSC
|
|
\item[SMSCP] (SMS Connection Protocol) -- tunnel from handset to SMSC
|
|
\end{description}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Example Transaction -- Location Update}
|
|
\begin{figure}[h]
|
|
\centering
|
|
\includegraphics[width=70mm]{LadderLU.pdf}
|
|
\end{figure}
|
|
% Demo with OpenBTS and OpenBSC.
|
|
\end{frame}
|
|
|
|
\begin{frame}{Example Transaction -- MO Call Setup}
|
|
\begin{figure}[h]
|
|
\centering
|
|
\includegraphics[width=50mm]{LadderMOC.pdf}
|
|
\end{figure}
|
|
% Demo with OpenBTS and OpenBSC
|
|
\end{frame}
|
|
|
|
\begin{frame}{Example Transaction -- MT Call Setup}
|
|
\begin{figure}[h]
|
|
\centering
|
|
\includegraphics[width=50mm]{LadderMTC.pdf}
|
|
\end{figure}
|
|
% Demo with OpenBTS and OpenBSC
|
|
\end{frame}
|
|
|
|
\subsection{Short Message Service}
|
|
|
|
\begin{frame}{SMS -- Layers}
|
|
GSM TS 04.11 and 03.40 define SMS in five layers:
|
|
\begin{description}[L1]
|
|
\item[L1] is taken from the Dm channel type used, either SDCCH or SACCH. This layer terminates in the BTS.
|
|
\item[L2] is normally LAPDm, but can be LLC in GPRS devices. In LAPDm SMS uses SAPI 3. This layer terminates in the BTS.
|
|
% Does SMS-CP really terminate in the MSC? Or in the BSC?
|
|
\item[L3] the connection layer, defined in GSM 04.11 5. This layer terminates in the MSC.
|
|
\item[L4] the relay layer, defined in GSM 04.11 6. This layer terminates in the MSC.
|
|
\item[L5] the transfer layer, defined in GSM 03.40. This layer terminates in the SMSC.
|
|
\end{description}
|
|
As a general rule, every PDU transferred in L(n) requires both a transfer and an acknowledgment on L(n-1).
|
|
\end{frame}
|
|
|
|
\begin{frame}{SMS Connection Layer (L3)}
|
|
\begin{itemize}
|
|
\item Terminates in the MSC.
|
|
\item No addressing. Just peers on Dm link.
|
|
\begin{description}[CP-ERROR]
|
|
\item[CP-DATA] carries an RPDU.
|
|
\item[CP-ACK] acks CP-DATA.
|
|
\item[CP-ERROR] nacks CP-DATA with cause code.
|
|
\end{description}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{SMS Relay Layer (L4)}
|
|
\begin{itemize}
|
|
\item Terminates in MSC.
|
|
\item Addresses are SMSC E.164s.
|
|
\begin{description}[RP-ERROR]
|
|
\item[RP-DATA] carries a TDPU to submit/deliver SMS between the MS and network.
|
|
\item[RP-SMMA] polls network for SMS.
|
|
\item[RP-ACK] acks RP-DATA. May carry TPDU.
|
|
\item[RP-ERROR] nacks RP-DATA with cause code. May carry TPDU.
|
|
\end{description}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{SMS Transfer Layer (L5)}
|
|
\begin{itemize}
|
|
\item Terminates in the SMSC.
|
|
\item Addresses are user E.164s.
|
|
\begin{description}[SMS-DELIVER-REPORT]
|
|
\item[SMS-DELIVER] carries user data to MS.
|
|
\item[SMS-DELIVER-REPORT] acks/nacks SMS-DELIVER
|
|
\item[SMS-SUMBIT] carrier user data from MS.
|
|
\item[SMS-SUBMIT-REPORT] acks/nacks SMS-SUBMIT.
|
|
\item[SMS-STATUS-REPORT] reports status of previously submitted SMS.
|
|
\item[SMS-COMMAND] can delete or cancel status report for a previously submitted SMS.
|
|
\end{description}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{SMS User Data Header (L6)}
|
|
\begin{itemize}
|
|
\item Endpoints are user devices.
|
|
\item The User Data part of the TPU has an optional header, the UDH, described in GSM 03.40 9.2.3.24.
|
|
\begin{itemize}
|
|
\item Segmentation for long messages.
|
|
\item Message waiting indications.
|
|
\item SIM Toolkit Security Header, wraps STK APDU.
|
|
\item WCMP, for WAP transport
|
|
\end{itemize}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{MT-SMS in L3 \& L4}
|
|
\begin{figure}[h]
|
|
\centering
|
|
\includegraphics[width=90mm]{MTSMS.pdf}
|
|
\end{figure}
|
|
\end{frame}
|
|
|
|
\begin{frame}{MO-SMS in L3 \& L4}
|
|
\begin{figure}[h]
|
|
\centering
|
|
\includegraphics[width=100mm]{MOSMS.pdf}
|
|
\end{figure}
|
|
\end{frame}
|
|
|
|
\section{Um Testing Tools}
|
|
|
|
\subsection{Trace Phones}
|
|
|
|
\begin{frame}{Um Testing Tools -- Nokia DCT-3}
|
|
\begin{itemize}
|
|
\item Nokia DCT-3 handsets (1998-2003) include testing features in their firmware. These features can be enabled to covert these phones into useful test equipment.
|
|
\item ``Field Test Mode'' can be enabled in many models through keypad sequences, serial port or IR ports.
|
|
\item Some models (3310, for example) can provide full L2 traces through the serial port. These traces can be decoded with gammu and wireshark.
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Um Testing Tools -- Other Trace Tools}
|
|
\begin{itemize}
|
|
\item Many Motorola handsets have a ``Netmonitor'' feature, similar to Nokia's Field Test Mode.
|
|
\item Other tools can give functionality similar to 3310 trace feature, but with more convenience and at $10\times$ to $50\times$ the cost.
|
|
\begin{itemize}
|
|
\item Sagem OT-series engineering handsets.
|
|
\item Ericsson TEMS handsets.
|
|
\end{itemize}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Um Testing Tools -- Example}
|
|
\begin{figure}[h]
|
|
\centering
|
|
\includegraphics[width=100mm]{TEMS.pdf}
|
|
\end{figure}
|
|
\small{(TEMS system, from Ericsson brochure. Watch the road, buddy.)}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Um Testing Tools -- Emulators/Testers}
|
|
\begin{itemize}
|
|
\small{
|
|
\item Handset emulators to exercise BTS units:
|
|
\begin{itemize}
|
|
\item Verify beacon content and modulation, measure RACH response, run standard transactions. Some include Abis support for end-to-end testing.
|
|
\item Rohde \& Schwarz CMD57, used for US\$4.5k-6k, for example.
|
|
\end{itemize}
|
|
\item Network emulators to exercise handsets:
|
|
\begin{itemize}
|
|
\item Generate beacon, verify modulation, answer RACH, run standard transactions.
|
|
\item Hewlett Packard 8922, used for US\$10k-20k, for example.
|
|
\end{itemize}
|
|
}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\subsection{OpenBSC}
|
|
|
|
\begin{frame}{Open Source GSM Tools}{OpenBSC}
|
|
What is OpenBSC
|
|
\begin{itemize}
|
|
\item A {\em GSM network in a box} software
|
|
\item Implements minimal subset of BSC, MSC, HLR, SMSC
|
|
\item Is Free and Open Source Software licensed under GNU GPLv2+
|
|
\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}
|
|
\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{OpenBTS}
|
|
|
|
\begin{frame}{Open Source GSM Tools: 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.
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Open Source GSM Tools: OpenBTS}
|
|
\begin{itemize}
|
|
\item Started work in August 2007, first call in January 2008, first SMS in December 2008.
|
|
\item First public release in September 2008, assigned to FSF in October 2008.
|
|
\item Tested 3-sector system with 10,000-20,000 handsets at September 2009 Burning Man event in Nevada.
|
|
\item Latest release (2.5) is about 13k lines of C++.
|
|
\item Now part of GNU Raido project, distributed under GPLv3
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{OpenBTS -- ``Nevada Test Site'' \& 21m Mast}
|
|
\begin{figure}[h]
|
|
\centering
|
|
\includegraphics[width=85mm]{NevadaTestSite.jpg}
|
|
\end{figure}
|
|
\end{frame}
|
|
|
|
\subsection{airprobe}
|
|
|
|
\begin{frame}{Open Source GSM Tools: Airprobe}
|
|
\begin{itemize}
|
|
\item {\em airprobe} is a collection of Um protocol analyzer tools using the USRP software defined radio
|
|
\item A number of different Um receiver implementations
|
|
\begin{description}[gsm-receiver]
|
|
\item[gssm] One of the two early Um receiver implementations (M\&M clock recovery)
|
|
\item[gsmsp] The other early Um receiver implementation
|
|
\item[gsm-tvoid] For a long time the Um receiver with best performance
|
|
\item[gsm-receiver] The latest generation of Um receiver
|
|
\end{description}
|
|
\item Today, gsm-receiver seems to be the most popular choice
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Open Source GSM Tools: Airprobe}
|
|
\begin{itemize}
|
|
\item Some other airprobe tools
|
|
\begin{description}[viterbi\_gen]
|
|
\item[gsmdecode] A standalone text-mode Um L2 frame parser
|
|
\item[wireshark] Dissector code for feeding Um frames into wireshark
|
|
\item[gsmstack] An unfinished more modular implementation of a Rx-only L1
|
|
\item[viterbi\_gen] Generate C++ implementations of a viterbi decoder
|
|
\end{description}
|
|
\item Still under development, no user friendly solution
|
|
\begin{itemize}
|
|
\item gsmtap frame format needs to be added as clean wireshark interface
|
|
\item receivers need automatic frequency scanning
|
|
\item full solution needs proper UI
|
|
\end{itemize}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
|
|
|
|
|
|
\part{Um Security Features ...and their shortcomings}
|
|
|
|
\begin{frame}{Part II - Um Security Features}
|
|
\tiny{\tableofcontents}
|
|
% You might wish to add the option [pausesections]
|
|
\end{frame}
|
|
|
|
\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 never knows 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 GPS data from the phone
|
|
\item combine that with the network not needing to authenticate itself
|
|
\end{itemize}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\subsection{The Baseband}
|
|
|
|
\begin{frame}{Known GSM security problems}{The Baseband side}
|
|
\begin{itemize}
|
|
\item GSM protocol stack always runs in a so-called baseband processor (BP)
|
|
\item What is the baseband processor
|
|
\begin{itemize}
|
|
\item Typically ARM7 (2G/2.5G phones) or ARM9 (3G/3.5G phones)
|
|
\begin{itemize}
|
|
\item Runs some RTOS (often Nucleus, sometimes L4)
|
|
\item No memory protection between tasks
|
|
\end{itemize}
|
|
\item Some kind of DSP, model depends on vendor
|
|
\begin{itemize}
|
|
\item Runs the digital signal processing for the RF Layer 1
|
|
\item Has hardware peripherals for A5 encryption
|
|
\end{itemize}
|
|
\end{itemize}
|
|
\item The software stack on the baseband processor
|
|
\begin{itemize}
|
|
\item is written in C and assembly
|
|
\item lacks any modern security features (stack protection, non-executable pages, address space randomization, ..)
|
|
\end{itemize}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\subsection{Observations}
|
|
|
|
\begin{frame}{Interesting observations}{Learned from implementing the stack}
|
|
While developing OpenBSC, we observed a number of interesting
|
|
\begin{itemize}
|
|
\item Many phones use their TMSI from the old network when they roam to a new network
|
|
\item Various phones crash when confronted with incorrect messages. We didn't even start to intentionally send incorrect messages (!)
|
|
\item There are tons of obscure options on the GSM spec which no real network uses. Potential attack vector by using rarely tested code paths.
|
|
\end{itemize}
|
|
OpenBTS developers observed the same.
|
|
\end{frame}
|
|
|
|
|
|
\section{GSM Security Features}
|
|
|
|
\begin{frame}{GSM Security Overview}
|
|
% This slide is just to establish a context for the rest of the discussion.
|
|
\begin{itemize}
|
|
\item Anonymization -- The TMSI is assigned on a temporary basis and is substituted for the IMSI whenever possible.
|
|
\item Authentication -- Challenge-response dialog based on 128-bit secret key $K_i$ and A3 \& A8 algorithms.
|
|
\item Ciphering -- Authentication produces a 64-bit ciphering key $K_C$ as a byproduct that is used to encrypt Dm and Bm channels with one of the A5 algorithms.
|
|
\item Hopping -- Not intended as a security feature, but makes interception considerably more difficult.
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\subsection{TMSI -- Anonymization}
|
|
|
|
\begin{frame}{GSM Security: TMSI -- Anonymity}
|
|
\begin{itemize}
|
|
\item For anonymity, transmitting the IMSI in cleartext is avoided
|
|
\item However, we still need to identify the MS that has requested a channel activation
|
|
\item TMSI is a 32bit number and used as substitute for IMSI
|
|
\item MS identifies itself the first time by IMSI, then the network allocates a TMSI.
|
|
\begin{itemize}
|
|
\item MS stores allocated TMSI in SIM, even across reboots
|
|
\item network stores TMSI in HLR
|
|
\end{itemize}
|
|
\item Network can reallocate TMSI at will
|
|
\begin{itemize}
|
|
\item e.g. during location update
|
|
\item e.g. every 4 transactions (call, sms, ...)
|
|
\end{itemize}
|
|
\item TMSI reallocation can happen after A5 encryption is started
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\subsection{A3/A8 -- Authentication}
|
|
|
|
\begin{frame}{GSM Security: A3/A8 -- Keys involved}
|
|
\begin{itemize}
|
|
\item Much of GSM security is based on a 128-bit shared secret, $K_i$.
|
|
\item There is one copy of $K_i$ inside in the SIM.
|
|
\begin{itemize}
|
|
\item regular SIM cards do not permit reading it back
|
|
\item of course, SIM card maker or operator might have a special key for that
|
|
\end{itemize}
|
|
\item There is another copy of $K_i$ in the AUC (Auth Center)
|
|
\item $K_i$ is never exposed directly anywhere.
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{GSM Security: A3/A8 -- Authentication}
|
|
%Specified in TS 04.08 4.3.2, 03.20 03.20
|
|
\begin{enumerate}
|
|
\item Network generates 128 bit random value (RAND)
|
|
\item Network sends RAND to the MS in the MM Authentication Request message
|
|
\item MS forms a 32-bit hash (SRES) by encrypting RAND with A3 algorithm, using $K_i$ as a key. Network performs identical SRES calculation
|
|
\item MS sends back its SRES value in the RR Authentication Response message
|
|
\item Network compares its calculated SRES value to the value provided by MS. If they match, the MS is authenticated.
|
|
\item Both the MS and the network also compute a 64-bit ciphering key ($K_C$) from RAND and $K_i$ using the A8 algorithm. Both parties save this value for later use when ciphering is enabled.
|
|
\end{enumerate}
|
|
\end{frame}
|
|
|
|
\begin{frame}{GSM Security: A3/A8 -- Authentication}
|
|
\begin{figure}[h]
|
|
\centering
|
|
\includegraphics[width=100mm]{LadderAuth.pdf}
|
|
\end{figure}
|
|
% Demo with OpenBTS and OpenBSC
|
|
\end{frame}
|
|
|
|
\subsection{A5 -- Ciphering}
|
|
|
|
\begin{frame}{GSM Security: A5 -- Ciphering}
|
|
\begin{itemize}
|
|
\item A5 is a family of symmetric ciphers inside the GSM Um Layer 1
|
|
\begin{description}[A5/4..8]
|
|
\item[A5/0] means no encryption
|
|
\item[A5/1] is the {\em secure} cipher variant
|
|
\item[A5/2] is the {\em weak} cipher variant
|
|
\item[A5/3] is the UMTS replacement; can be used on GSM, too
|
|
\item[A5/4..8] mentioned in protocol spec but never defined
|
|
\end{description}
|
|
\item MS indicates A5 capabilities in classmark procedure
|
|
\begin{itemize}
|
|
\item Compromised MS software could indicate no A5/1 capability to the network
|
|
\item Network can decide to use A5/0 even if the phone supports A5/1,2,3
|
|
\end{itemize}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{GSM Security: A5 -- Ciphering}
|
|
\begin{itemize}
|
|
\item Encryption Key $K_C$ is produced as result to A3/A8 authentication
|
|
\item Re-keying can be initiated by the network at any given time by means of the authentication procedure
|
|
\item $K_C$ as a result of authentication is stored on SIM
|
|
\item $K_C$ can be read and written by the phone itself
|
|
\begin{itemize}
|
|
\item OS on Baseband Processor typically has some kind of API to access SIM
|
|
\item However, quite often direct access to $K_C$ is not permitted
|
|
\item Still, baseband processor software exploits do exist!
|
|
\end{itemize}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{GPRS Security}
|
|
\begin{itemize}
|
|
\item GPRS uses same A3/A8 Authentication as GSM
|
|
\item GPRS uses its own GEA family of ciphers
|
|
\begin{itemize}
|
|
\item Algorithm spec as secret as A5
|
|
\item However, no leaked / reverse engineered implementation yet
|
|
\item No academic or practical attacks known (yet?)
|
|
\end{itemize}
|
|
\item GEA is used on Layer 2 (LLC), not Layer 1 as in GSM
|
|
\begin{itemize}
|
|
\item Encryption between MS and SGSN, does not terminate at BTS
|
|
\item Not possible to capture unencrypted data on backhaul anymore
|
|
\end{itemize}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
|
|
\subsection{Frequency Hopping}
|
|
|
|
\begin{frame}{GSM Security: Frequency Hopping}
|
|
\begin{itemize}
|
|
\item Requires that an interceptor support hopping or have sufficient bandwidth to capture the entire carrier allocation.
|
|
\item Complicates decryption for a hopping interceptor, since you may have to decrypt a channel assignment before you even know where to tune next. (Wideband interceptors do not have this problem.)
|
|
\item Hopping parameters can be reverse engineered from the spectrum if call activity is low.
|
|
\item But you may not need to reverse engineer much:
|
|
\begin{itemize}
|
|
\item The CA is global and usually divided into a small number (1 or 2) of non-overlapping MAs.
|
|
\item The HSN is usually the same for every assignment in the cell
|
|
\item In networks with synchronized cells, the HSN is the same even accross cells
|
|
\end{itemize}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
|
|
\section{GSM Security -- Design Flaws}
|
|
|
|
\begin{frame}{GSM Security -- Bad Assumption}
|
|
\begin{block}{Bad Assumption}
|
|
No rogue actors in L3
|
|
\end{block}
|
|
\begin{itemize}
|
|
\item Any entity that can implement L1 and L2 correctly is assumed to be legitimate until a challenge fails
|
|
\item This was a common telco security assumption in the 1980's, back when equipment was big and expensive and all of the networks were run by governments and quasi-governmental monopolies
|
|
\item It is an assumption inherited from wireline telcos, and is even weaker in the wireless world
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\subsection{Oversights}
|
|
|
|
\begin{frame}{GSM Security -- Oversights}
|
|
\begin{block}{Oversight}
|
|
No authentication of the network
|
|
\end{block}
|
|
\begin{itemize}
|
|
\item GSM allows the network to authenticate a handset, but provides no means for the handset to authenticate the network
|
|
\item Authentication is based on challenge-response, but the only comparison happens in the network end
|
|
\item Any entity that can present a network-side Um interface is assumed to the legitimate, making it easy to create the GSM equivalent of a rogue access point.
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
|
|
\begin{frame}{GSM Security -- Oversights}
|
|
\begin{block}{Oversight}
|
|
Handset cannot release in L3 RR
|
|
\end{block}
|
|
\begin{itemize}
|
|
\item The channel release operation must always be initiated by the network
|
|
\item As long as the handset sees a valid idle pattern in L2, it can be made to hold an active channel indefinitely
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{GSM Security -- Oversights}
|
|
\begin{block}{Oversight}
|
|
The network controls privacy
|
|
\end{block}
|
|
\begin{itemize}
|
|
\item GSM privacy controls are in the network, not in the handset
|
|
\item Ciphering indications controlled by carrier.
|
|
\item Any entity that assumes the role of the network takes control of the privacy features as well.
|
|
\item Once camped, the MS is essentially a slave of the BTS.
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
|
|
\begin{frame}{GSM Security -- Oversights}
|
|
\begin{block}{Oversight}
|
|
Ciphering was an afterthought
|
|
\end{block}
|
|
\begin{itemize}
|
|
\item Ciphering was added to the system low in L1, below FEC
|
|
\item L2 idle frames generate a lot of known plaintext
|
|
\item FEC lowers the entropy of the plaintext stream
|
|
\item The A5 ciphering algorithms were not subject to adequate review by cryptographic experts prior to standardization
|
|
\item Encryption at L1 cannot be end-to-end since L1 terminates in the BTS, \emph{so microwave backhaul can still be fully exposed}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{GPRS Security -- Oversights}
|
|
\begin{block}{Oversight}
|
|
GPRS uses same $K_C$ key generation (A3/A8) as GSM
|
|
\end{block}
|
|
\begin{itemize}
|
|
\item Even if GPRS has stronger crypto algorithm, $K_C$ is generated the same way as in GSM
|
|
\item $K_C$ key recovery attack using A5/2 can be performed using same random challenge
|
|
\item GPRS traffic can thus be recorded and later reviewed if MS with same SIM enters IMSI-Catcher and is presented with challenge from the recording
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{GSM Security -- Oversights}
|
|
\begin{block}{Oversight}
|
|
UMTS handsets also support GSM
|
|
\end{block}
|
|
\begin{itemize}
|
|
\item Many GSM security problems are fixed in UMTS, but all UMTS handsets fall back to 2.5G GSM operation when UMTS is not available.
|
|
\item UMTS handsets can be ordered to fall back to GSM by a rogue 3G Node B before mutual authentication even happens.
|
|
\item UMTS handsets can be forced into the GSM mode by jamming the UMTS service.
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{GSM Security -- Anachronism}
|
|
\begin{block}{Anachronism}
|
|
Predates public key encryption
|
|
\end{block}
|
|
\begin{itemize}
|
|
\item Network cannot authenticate the initial access attempt
|
|
\item Any transaction must begin with the revelation of some subscriber ID over an unencrypted channel
|
|
\item All security depends on the protection of $K_i$
|
|
\item Once $K_i$ is broken, the SIM is permanently compromised
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\subsection{Intentional Weaknesses}
|
|
|
|
\begin{frame}{GSM Security -- Intentional Weaknesses}
|
|
\begin{block}{Intentional Weakness}
|
|
A5/1 \& A5/2
|
|
\end{block}
|
|
\begin{itemize}
|
|
\item Western governments were reluctant to export ``strong'' encryption to other parts of the world, so they defined two ciphering algorithms, A5/1 for the US and Europe and A5/2 for everywhere else
|
|
\item The specification requires that any handset support both of these algorithms, so the cryptosystem is exported anyway and determined party can reverse-engineer either A5 from a standard handset.
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{GSM Security -- Intentional Weaknesses}
|
|
% This is old information.
|
|
% Still need a good reference to verify this in recent systems.
|
|
\begin{block}{Intentional Weakness}
|
|
Carriers do not use the full range of $K_i$, $K_C$.
|
|
\end{block}
|
|
\begin{itemize}
|
|
\item The spec allows 128 bits for $K_i$, but most carriers use only 64.
|
|
\item The spec allow 64 bits for $K_C$, but most carriers use only 54.
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{GSM Security -- Intentional Weaknesses}
|
|
\begin{block}{Intentional Weakness}
|
|
Security features are optional
|
|
\end{block}
|
|
\begin{itemize}
|
|
\item Authentication is optional
|
|
\item A5/0 means no ciphering at all and all handsets support it
|
|
\item TMSIs are optional
|
|
\item A3/A8 is selected by the operator, used to be COMP128
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
|
|
\subsection{Handset Bugs}
|
|
|
|
\begin{frame}{GSM Security -- Handset Bugs}
|
|
\begin{itemize}
|
|
% Other good ones? OTA-related?
|
|
\item TMSI exposure bugs compromise anonymization
|
|
\item Many handsets crash or hang when presented with erroneous message formats or sequences
|
|
\item Many features of the protocol are not widely used and therefore probably not well tested
|
|
\item Many handsets vendor specific OTA and SIM support features not subject to outside review
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\section{GSM Best Practises}
|
|
|
|
\subsection{General}
|
|
|
|
\begin{frame}{GSM Best Practices -- General}
|
|
\begin{itemize}
|
|
% We will linger on each of these points for a few minutes.
|
|
\item{Perform authentication and start ciphering as early as possible in a transaction, on the Dm channel.}
|
|
\item{Never send subscriber E.164 over Um. E.164's are the easiest kind of subscriber ID to find in public records and there's no need to tell a handset its own phone number.}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\subsection{TMSI's}
|
|
|
|
\begin{frame}{GSM Best Practices -- TMSIs}
|
|
\begin{itemize}
|
|
% We will linger on each of these points for a few minutes.
|
|
\item{Never expose IMSI and TMSI in cleartext during the same transaction. Once the IMSI/TMSI pairing is exposed, the TMSI is useless.}
|
|
\item{Reassign TMSIs frequently. If the user has the same TMSI for more than a few days, it is just as traceable as the IMSI. TMSI reassignment policies are operator-dependent and vary widely.}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\subsection{Frequency Hopping}
|
|
|
|
\begin{frame}{GSM Best Practices -- Hopping}
|
|
\begin{itemize}
|
|
% We will linger on each of these points for a few minutes.
|
|
\item Use hopping for Dm channels whenever possible. The start of a Dm transaction is never encrypted, so you use hopping to obscure it.
|
|
\item Choose cell allocation ARFCNs with wide frequency separation, if possible given your licensed frequencies. This makes whole-cell interception much more expensive.
|
|
\item Use uplink and downlink DTX and power control. This makes it more difficult to reverse-engineer hopping parameters through statistical analysis.
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Typical GSM Security Configurations}
|
|
\begin{itemize}
|
|
\item Developed world -- best practices, for the most part. These networks are about as secure as possible given the limitations of the spec.
|
|
\item Police state -- no ciphering, often no hopping. Many countries outlaw ciphering to make life easier for their domestic intelligence services. Some have two networks, one for officials and one for everyone else.
|
|
\item In Between -- ciphering traffic, but not control.
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{``Best Practice'' Example -- Aaaaa in the US}
|
|
Aaaaa follows security procedures typical of large GSM carriers in the US \& EU.
|
|
\begin{itemize}
|
|
\item Immediate assignment is to a hopping SDCCH
|
|
\item Immediate authentication, then ciphering
|
|
\item Second assignment is to encrypted, hopping TCH
|
|
\item TMSIs are typically reassigned several times each day.
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{``Worst Practices'' Example -- Bbbbb Mobile in the US}
|
|
Bbbbb is a US iDEN network, not GSM but with very similar L2 \& L3
|
|
protocols. These same procedures are used by GSM carriers an many parts of the
|
|
world.
|
|
\begin{itemize}
|
|
\item Immediate assignment is to a non-hopping SDCCH.
|
|
\item No authentication or encryption.
|
|
\item Second assignment is to a non-hopping TCH, often on C0.
|
|
\item TMSIs are stable for days or even weeks at a time.
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\section{Lawful Intercept}
|
|
|
|
\begin{frame}{Lawful Intercept}
|
|
\small{
|
|
\begin{itemize}
|
|
\item Security flaw deliberately designed into all carrier-grade telecom systems.
|
|
\item Required by law in most markets (US CELEA, UK RIPA, EU 17 Jan 1995 resolution).
|
|
\item Allows intercepting party to access call traffic at the switching center.
|
|
\item In principle, a law enforcement agency petitions a court for an order to get access to specific traffic.
|
|
\item Lawful intercept features have been exploited by attackers to eavesdrop on high-profile individuals (Athens 2004-2005).
|
|
\end{itemize}
|
|
}
|
|
\end{frame}
|
|
|
|
\begin{frame}{With lawful intercept, why bother with Um?}
|
|
\begin{block}{Why not just get a warrant and tap the core network?}
|
|
\begin{itemize}
|
|
\item Maybe you are operating in \emph{someone else's} country
|
|
\item Maybe you cannot trust the telco or its employees
|
|
\item Maybe you need tactical flexibility
|
|
\item Maybe you just forgot all about the rule of law
|
|
% Mexico story.
|
|
\end{itemize}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
|
|
|
|
\part{Passive Interception and Handset Geolocation}
|
|
|
|
\begin{frame}{Part III -- Passive Interception and Geolocation}
|
|
\tableofcontents
|
|
% You might wish to add the option [pausesections]
|
|
\end{frame}
|
|
|
|
\section{Passive Interception}
|
|
|
|
\begin{frame}{Example -- Smith-Myers}
|
|
\begin{figure}[h]
|
|
\centering
|
|
\includegraphics[width=85mm]{CSM88xxg.pdf}
|
|
\caption{A typical passive intercept radio}
|
|
\end{figure}
|
|
\end{frame}
|
|
|
|
\subsection{The A5 Obsession}
|
|
|
|
\begin{frame}{The A5 Obsession}
|
|
\begin{itemize}
|
|
\item Many discussions of passive intercept quickly devolve to A5 tutorials and not much else.
|
|
\item In the many applications, A5 is a non-issue.
|
|
\begin{itemize}
|
|
\item Maybe telco doesn't use ciphering.
|
|
\item Maybe the attacker knows $K_i$
|
|
\item Maybe the attacker can obtain $K_C$ from the SIM
|
|
\item Recording the encrypted data and later providing the same challenge to the phone by means of an IMSI-Catcher can also recover the $K_C$
|
|
\end{itemize}
|
|
\item Just decoding speech is of little practical value without the control messages.
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Publicized A5 Attacks}
|
|
\begin{itemize}
|
|
\item Academic cryptoanalysis of A5/1 cipher: EC1997, FSE2000, Crypto 2003, SAC 2005, ...
|
|
\item Commercial A5/1 crackers exist in intelligence agencies
|
|
\item Attacks based on a code book attack, mapping from known output to secret state
|
|
\item First community project to compute rainbow tables in 2007/2008 but never released
|
|
\item New distributed project now working with CUDA graphics cards and FPGA's
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\subsection{Uplink Intercept}
|
|
|
|
\begin{frame}{Uplink Intercept is Hard}
|
|
\begin{itemize}
|
|
\item MS uplink transmission is 10-30 dB below downlink.
|
|
\item MS is in the ground clutter, not on a tower.
|
|
\item Big antennas improve performance but draw attention.
|
|
\item Uplink intercept range is usually $<$1 km, even with good equipment, unless you have a high vantage point.
|
|
\item Uplink strongest at the edges of the BTS coverage, but then reselection and handover are problems.
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Good Demod Gives Flexibility}
|
|
\begin{itemize}
|
|
\item Multi-antenna, vector-channel.
|
|
\begin{itemize}
|
|
\item Doubling number of antennas gives 3-6 dB improvement, expanding range 30\%-70\%.
|
|
\item Greatly improves performance against multipath.
|
|
\item Improves performance against CCI.
|
|
\end{itemize}
|
|
\item Soft demodulation. GSM's rate-1/2 FEC means that you can lose 1/2 of the radio bursts and still recover data, \emph{as long as you know which half is lost}.
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\section{Geolocation}
|
|
|
|
\begin{frame}{Timing, Power and Location}
|
|
\begin{block}{Geoobservables}
|
|
\begin{itemize}
|
|
\item A geoobservable is any physical measurement that places a constraint on the geographic location of an object.
|
|
\item The GSM TA value is a geoobservable. So is the TDOA of the MS and BTS signals at the interceptor. So is an AOA estimate from a DF antenna.
|
|
\item Measurement reports of power levels from neighboring BTS units are also geoobservables, if you know their coverage areas.
|
|
\item Given enough independent geoobservables, you can estimate the location of the MS.
|
|
\end{itemize}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Direct Measurement of Geoobservables}
|
|
\begin{itemize}
|
|
\item GSM midamble can be used as a marker for parameter estimation on Um. (\emph{That's why it's there.})
|
|
\item Cross correlation with a reference training sequence can yield a TOA estimate.
|
|
\item Cross correlation between antennas in an array can yield an AOA estimate.
|
|
\item Frequency estimation can yield Doppler offset estimate, a useful geooservable for a moving receiver.
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
%\begin{frame}{TOA Measurement Example}
|
|
%Need a figure.
|
|
%\end{frame}
|
|
|
|
\subsection{Power-Scanning Direction Finding (DF)}
|
|
|
|
\begin{frame}{Power-Scanning DF}
|
|
\begin{columns}
|
|
\begin{column}{5cm}
|
|
\begin{figure}[h]
|
|
\includegraphics[width=40mm]{rohde_schwarz-gsm_df.png}
|
|
\end{figure}
|
|
\end{column}
|
|
\begin{column}{5cm}
|
|
\begin{itemize}
|
|
\item The operator waves it around watching a power meter, like something out of a wildlife program.
|
|
\item It is a crude device, but useful at very close ranges.
|
|
\end{itemize}
|
|
\end{column}
|
|
\end{columns}
|
|
\end{frame}
|
|
|
|
\subsection{AOA -- Angle of Arrival}
|
|
|
|
\begin{frame}{Doppler AOA Estimation}
|
|
\begin{figure}[h]
|
|
\centering
|
|
\includegraphics[width=70mm]{DopplerDF.jpg}
|
|
\caption{Imagine a spinning antenna}
|
|
\end{figure}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Doppler AOA Estimation}
|
|
\begin{itemize}
|
|
\item For the spinning antenna, Doppler effect produces a frequency offset that varies with the angle relative to the target. Estimate Doppler offsets and you can estimate the AOA.
|
|
\item The spinning antenna can be simulated by switching rapidly among antennas in a circular array, usually 4.
|
|
\item Accuracy is on the order of $\pm 10 \degree$, so many estimates are require to average out the errors.
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Doppler AOA Estimation}
|
|
\begin{figure}[h]
|
|
\centering
|
|
\includegraphics[width=75mm]{DatongDoppler.jpg}
|
|
\caption{Classic Datong DF1, from datongarchive.googlepages.com}
|
|
\end{figure}
|
|
\end{frame}
|
|
|
|
\begin{frame}{MUSIC AOA Estimation}
|
|
\small{
|
|
\begin{itemize}
|
|
\item Signal is received by a compact array of many precisely-placed elements.
|
|
Array response is measured at many angles in a calibration procedure.
|
|
\item AOA estimated by comparing array response to calibration data with MUSIC algorithm.
|
|
\item Calibration is sensitive to vehicle shape and antenna array mounting location. May require calibration specific to vehicle type.
|
|
\item High gain from multiple antenna elements allows estimation on very weak signals. Total processing gain of a 16-element array on a single GSM midamble is 20-23 dB.
|
|
\item Accuracy at the Cram\'er-Rao bound, generally sub-degree, even for negative SNR.
|
|
\end{itemize}
|
|
}
|
|
\end{frame}
|
|
|
|
\begin{frame}{MUSIC AOA Estimation}
|
|
\begin{figure}[h]
|
|
\centering
|
|
\includegraphics[width=90mm]{DFArrays.pdf}
|
|
\caption{\tiny{(From ``PERFORMANCE OF ROOT-MUSIC ALGORITHM USING REAL-WORLD ARRAYS'', Fabio Belloni, Andreas Richter, and Visa Koivunen.)}}
|
|
\end{figure}
|
|
\end{frame}
|
|
|
|
|
|
\begin{frame}{Typical AOA Geolocation Tool}
|
|
\begin{figure}[h]
|
|
\centering
|
|
\includegraphics[width=80mm]{AOAExample.pdf}
|
|
\caption{Display from UI-DF application}
|
|
\end{figure}
|
|
\end{frame}
|
|
|
|
\subsection{SACCH Data as Geoobservables}
|
|
|
|
\begin{frame}{SACCH Data as Geoobservables}
|
|
\begin{itemize}
|
|
\item MS reports its current TA and tx power level on every SACCH message and BTS sends commanded values on downlink.
|
|
\item The MS-BTS distance is $c$ times $1/2$ the TA, or 553 m/sym.
|
|
\item Knowing the true locations of interceptor and BTS you can also estimate interceptor-MS distance from MS-BTS TOA.
|
|
\item Watch TAs from multiple BTSs during handover for more geooservables.
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
|
|
\begin{frame}{SACCH Data as Geoobservables}
|
|
\begin{figure}[h]
|
|
\centering
|
|
\includegraphics[width=100mm]{MSGeoExample.pdf}
|
|
\end{figure}
|
|
\end{frame}
|
|
|
|
\subsection{Pitfall -- Multipath}
|
|
|
|
\begin{frame}{Geolocation Pitfall -- Multipath}
|
|
\begin{itemize}
|
|
\item Creates false images for MUSIC systems
|
|
\item Breaks Doppler systems entirely
|
|
\item Adds unknown offsets to TOA estimates
|
|
\item A serious challenge to tracking in urban areas
|
|
\item Errors often have one-sided distributions that break classical linear estimators
|
|
\item Can be mitigated with non-linear statistical techniques
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Downlink-Only Intecept}
|
|
\begin{itemize}
|
|
\item LAPDm always echos back the first message in a transaction, which always contains an unencrypted IMSI or TMSI.
|
|
\item Calling party E.164s and MT SMS.
|
|
\item DTMF echoed back in downlink acks.
|
|
\item SACCH timing and power data gives some MS location information, even in downlink.
|
|
\item BCCH/CCCH useful for network mapping.
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\section{The Identity Problem}
|
|
|
|
\begin{frame}{The Identity Problem}
|
|
\begin{itemize}
|
|
\item Intercept is useless if you cannot identify the parties.
|
|
\item 3 IDs that matter:
|
|
\begin{description}[E.164]
|
|
\item[IMSI] most stable on Um
|
|
\item[TMSI] most likely to see on Um
|
|
\item[E.164] in public records, but rarely on Um
|
|
\end{description}
|
|
\item Knowing a target's \emph{friend's} E.164 is actually more useful, since \emph{that} might appear in the downlink.
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Getting IMSI/TMSI from E.164}
|
|
\begin{itemize}
|
|
\item ``Silent paging''
|
|
\begin{enumerate}
|
|
\item Call E.164 and hang up before alerting starts.
|
|
\item Watch PCH for paging activity.
|
|
\item Repeat 1, 2 and watch for correlated IMSI or TMSI.
|
|
\end{enumerate}
|
|
\item ``Silent SMS'' -- Send type 0 SMS TPDU and watch downlink activity.
|
|
\item Wait for an MT call from a known associate's E.164 and unwind the transaction from a log.
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\section{Passive Intercept Systems}
|
|
|
|
\subsection{Small Scale}
|
|
|
|
\begin{frame}{Small Scale Systems}
|
|
\begin{itemize}
|
|
\item For intercepting a single target.
|
|
\item Ideally, at least two receivers:
|
|
\begin{enumerate}
|
|
\item One to always watch the beacon.
|
|
\item One to follow the target, hopping if needed.
|
|
\end{enumerate}
|
|
\item Portable, usually in a vehicle.
|
|
\item Interactive GUI, usually on a laptop.
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Forcing Traffic}
|
|
\begin{itemize}
|
|
\item Q: How do you intercept a multi-ARFCN BTS on a single-ARFCN interceptor?
|
|
\item A: If there's a non-hopping C0, DOS the other ARFCNs.
|
|
\begin{itemize}
|
|
\item Get a pile of cheap phones and place calls until you occupy all of the channels you can't intercept. (Be sure to use prepaid SIMs!)
|
|
\item Use narrowband jamming to block ARFCNs you can't intercept.
|
|
\end{itemize}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\subsection{Large Scale}
|
|
|
|
\begin{frame}{Large Scale Systems}
|
|
\begin{itemize}
|
|
\item Intercepting many cells at once.
|
|
\item Single wide-band radio intercepts whole carrier spectrum.
|
|
\item Many software receivers running in parallel.
|
|
\item Spews data. Output bandwidth is the sum of the backhauls.
|
|
\item Fixed installation or dedicated vehicle.
|
|
\item GUI is mostly through database tools.
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\subsection{Intercept Data Organization}
|
|
|
|
\begin{frame}{Organizing Intercept Data}
|
|
\begin{itemize}
|
|
\item Intercept system vs.\ test tool. Different applications and goals. Legal distinction of ``primary purpose''.
|
|
\item Wireshark vs.\ databases. Wireshark is a great diagnostic tool, but serious interceptors uses SQL.
|
|
\item Live audio vs.\ traffic ``corpus''. Log \emph{every} vocoder frame with the time, frame number and BTS identity.
|
|
\item Good interceptors never discard data. Field work is dangerous and expensive. Squeeze every bit and never throw anything away.
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Intercept Data Mining}
|
|
\begin{itemize}
|
|
\item Save every message, even if you can't decode it.
|
|
\item Merge databases from multiple collectors and missions.
|
|
\item Map social networks from control channel data.
|
|
\item Identify talkers by tracing call establishment.
|
|
\item Reconstruct user movements by merging databases and searching location updating operations.
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
|
|
\part{IMSI-Catchers}
|
|
|
|
\begin{frame}{Part IV -- IMSI-Catchers}
|
|
\tableofcontents
|
|
% You might wish to add the option [pausesections]
|
|
\end{frame}
|
|
|
|
\section {The False BTS}
|
|
|
|
\subsection{Basics}
|
|
|
|
\begin{frame}{False BTS Basis \#1}
|
|
\begin{block}{Problem}
|
|
The handset does not authenticate the network.
|
|
\end{block}
|
|
\begin{itemize}
|
|
\item Any device that can generate the network-side Um interface can be used to spoof a cellular carrier.
|
|
\item All you need to do is terminate L3 locally and run a partial simulation of the carrier's core network.
|
|
\item Once you overcome the technical hurdle of generating Um, the rest is depressingly easy.
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{False BTS Basis \#2}
|
|
\begin{block}{Problem}
|
|
Ciphering is optional.
|
|
\end{block}
|
|
\begin{itemize}
|
|
\item If ciphering were mandatory, it would allow the handset a means of authenticating the network Oh well...
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\subsection{History}
|
|
|
|
\begin{frame}{False BTS IP History}
|
|
\begin{itemize}
|
|
\item Patents are public records:
|
|
\begin{itemize}
|
|
\item Early Nokia work
|
|
\item R\&S EP 1051053 -- the first real IMSI-catcher patent
|
|
\end{itemize}
|
|
\item Litigation produces public records:
|
|
\begin{itemize}
|
|
\item MMI v CellXion -- lots of discussion of IMSI-catcher history, identified several IMSI-catcher developers
|
|
\item Martone v Burgess -- public identification of IMSI-catcher developers working for the US gov't
|
|
\end{itemize}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\subsection{Virtual Basestation}
|
|
|
|
\begin{frame}{R\&S ``Virtual Basestation''}
|
|
\begin{figure}[h]
|
|
\centering
|
|
\includegraphics[width=75mm]{VBTSFigure.pdf}
|
|
\caption{From EP 1051053}
|
|
\end{figure}
|
|
\end{frame}
|
|
|
|
\begin{frame}{False BTS Design Approaches}
|
|
\begin{itemize}
|
|
\item Early R\&S designs (GA 090) based on BTS emulators.
|
|
\item Standard approach: mini-BTS and laptop with T1/E1 card. Hardware similar to OpenBSC w/BS11.
|
|
\item Abis-over-IP quickly replacing T1/E1 systems (CellXion/Datong DX series). Hardware same as OpenBSC w/NanoBTS.
|
|
\item All-software BTS units with tighter L3 integration starting to appear (MRT-BTS). Software approach more similar to OpenBTS.
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\subsection{Examples}
|
|
|
|
\begin{frame}{False BTS Example -- Datong}
|
|
\begin{figure}[h]
|
|
\centering
|
|
\includegraphics[width=100mm]{DatongDX300.pdf}
|
|
\caption{From Datong brochure}
|
|
\end{figure}
|
|
\end{frame}
|
|
|
|
\begin{frame}{False BTS Example -- MRT}
|
|
\begin{figure}[h]
|
|
\centering
|
|
\includegraphics[width=100mm]{MRTBTS.pdf}
|
|
\caption{From MRT, Inc. public web pages}
|
|
\end{figure}
|
|
\end{frame}
|
|
|
|
\begin{frame}{False BTS Example -- Tecore}
|
|
\begin{figure}[h]
|
|
\centering
|
|
\includegraphics[width=100mm]{Intellijam.pdf}
|
|
\caption{From Tecore public web pages}
|
|
\end{figure}
|
|
\end{frame}
|
|
|
|
|
|
\section{Behavior}
|
|
|
|
\subsection{Cell Selection}
|
|
|
|
\begin{frame}{Cell Selection Behavior}
|
|
\begin{itemize}
|
|
\item ``Capture'' technique based on handset's BTS selection rules, GSM 03.22 4 and GSM 04.08 4.2.
|
|
\item Use the same MCC/MNC/NCC as the local GSM carrier.
|
|
\item Choose an ARFCN from the serving cell's neighbor list.
|
|
\item Ramp up power gradually to avoid congestion.
|
|
\item Can also use CRO to increase effective power advantage.
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Mobility Behavior}
|
|
\begin{itemize}
|
|
\item Based on rules of GSM 04.08 4.
|
|
\item When the handset enters a new ``location area'' it will attempt to register.
|
|
\item So the IMSI-catcher advertises LAC different from any of the other cells in the area.
|
|
\item Set timer T3212 for registrations on 6-minute intervals or change LAC to induce registration, like a broadcast ping to all camped handsets.
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\subsection{Location Update}
|
|
|
|
\begin{frame}{Key Transaction -- Location Update}
|
|
\begin{figure}[h]
|
|
\centering
|
|
\includegraphics[width=70mm]{LadderLU.pdf}
|
|
\end{figure}
|
|
\end{frame}
|
|
|
|
|
|
\begin{frame}{Location Update Options}
|
|
\begin{itemize}
|
|
\item Location update request includes IMSI or TMSI of MS, plus MCC/MNC/LAC of previous serving cell.
|
|
\item Authentication and ciphering are optional, so don't use them.
|
|
\item Can request IMSI, TMSI or IMEI during update operation.
|
|
\item Can assign a new TMSI.
|
|
\item Can accept or refuse location update attempt \emph{based on inspection of ID}.
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\subsection{Location Update Accept/Reject Tricks}
|
|
|
|
\begin{frame}{Accept/Reject Tricks}
|
|
\begin{itemize}
|
|
\item If IMSI-catcher accepts registration, the handset remains camped to IMSI-catcher and ignores real network. DOS.
|
|
\item Reject cause codes matter:
|
|
\begin{description}[not roaming in LA]
|
|
\item[illegal MS] locks handset until SIM is removed.
|
|
\item[no roaming in LA] denies service \emph{in any cell with the same LAC} until next time phone power-cycles.
|
|
\item[IMSI not in VLR] kicks the phone back to the carrier with little or no disruption.
|
|
\end{description}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{More Accept/Reject Tricks}
|
|
\begin{itemize}
|
|
\item Send an ``MM Information'' message.
|
|
\begin{itemize}
|
|
\item Set network name on the display.
|
|
\item Set the handset clock. (May allow smartphones to accept expired security certs, BTW.)
|
|
\end{itemize}
|
|
\item Query the handset GPS receiver. (More on that later.)
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\section{Demonstrations}
|
|
|
|
\begin{frame}{Location Updating Demos}
|
|
\begin{itemize}
|
|
\item Query and reject.
|
|
\item Accept and DOS.
|
|
\item Reject and lock.
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\subsection{Man-in-the-Middle}
|
|
|
|
\begin{frame}{Boy-In-the-Middle}
|
|
\begin{itemize}
|
|
\item Accept target handset registrations.
|
|
\item Allow MO call attempts, using A5/0.
|
|
\item Connect call with wireline phone or another GSM handset, as in EP1051053 figure.
|
|
\item Suppress CLID in the PSTN.
|
|
\item Collect both sides of the conversation.
|
|
\end{itemize}
|
|
% Demo
|
|
\end{frame}
|
|
|
|
\begin{frame}{Man-In-the-Middle}
|
|
\begin{itemize}
|
|
\item Accept target handset registrations.
|
|
\item Allow MO call attempts, using A5/0.
|
|
\item Connect call with VoIP carrier or ISDN.
|
|
\item \emph{Spoof} CLID in the PSTN.
|
|
\item Collect both sides of the conversation.
|
|
\end{itemize}
|
|
% Demo
|
|
\end{frame}
|
|
|
|
\subsection{Covert Call}
|
|
|
|
\begin{frame}{Covert Call -- Technique}
|
|
\begin{itemize}
|
|
\item Starts like a normal MT call setup, but user is never alerted.
|
|
\item Connection in RR and MM, but no CC/Q.931 steps.
|
|
\item Phone goes to an active TCH and transmits an idle pattern.
|
|
\item Phone is assigned a known training sequence, unique on its ARFCN, to make tracking easier.
|
|
\item BTS controls power and channel release, tracks timing advance for distance estimate.
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Covert Call -- Applications}
|
|
\begin{itemize}
|
|
\item Battery drain, by pushing tx power to maximum.
|
|
\item Handset tracking via geoobservables.
|
|
\begin{itemize}
|
|
\item Timing advance and measurement reports.
|
|
\item Midamble and idle pattern as markers for TOA \& AOA estimation.
|
|
\end{itemize}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
|
|
\begin{frame}{IMSI-Catcher with Integrated Geolocation}
|
|
\begin{figure}[h]
|
|
\centering
|
|
\includegraphics[width=100mm]{BTSGEO.pdf}
|
|
\caption{From MRT, Inc. public web pages}
|
|
\end{figure}
|
|
\end{frame}
|
|
|
|
\section{Beyond Voice Intercept}
|
|
|
|
\subsection{MT-SMS Attacks}
|
|
|
|
\begin{frame}{MT-SMS}
|
|
\begin{figure}[h]
|
|
\centering
|
|
\includegraphics[width=100mm]{MTSMS.pdf}
|
|
\end{figure}
|
|
\end{frame}
|
|
|
|
\begin{frame}{MT-SMS Attacks}
|
|
Source spoofing
|
|
\begin{itemize}
|
|
\item A false BTS can control any header field, L3-L5, including the originating addresses (user \& SMSC) and timestamps
|
|
\item Source address spoofing eliminates another security mechanism that a carrier or SIM application might use
|
|
\item Plenty of other SMS attacks, especially for smartphones, do not require a false basesation. See ``Attcking SMS'' talk later this week
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{MT-SMS Attacks -- TL-PID Types}
|
|
As described in GSM 03.40 Section 9.2.3.9
|
|
\begin{description}[Types 1-7]
|
|
\item[Type 0] like a ping for SMS. Acked, then discarded silently.
|
|
\item[Types 1-7] \emph{replace} previously stored SMS from this OA.
|
|
\item[Type 31] Page. Informs user to return call to OA.
|
|
\item[Type 61] ME Data download. Vendor-specific data, including OTA.
|
|
\item[Type 62] ``Depersonalization'', GSM 02.22 9, requires SIM keys.
|
|
\item[Type 63] SIM Data download. Carries an ENVELOPE for a SIM Toolkit application. Security is application-specific.
|
|
\end{description}
|
|
\end{frame}
|
|
|
|
\begin{frame}{MT-SMS Demos}
|
|
\end{frame}
|
|
|
|
\begin{frame}{MO-SMS}
|
|
\begin{figure}[h]
|
|
\centering
|
|
\includegraphics[width=80mm]{MOSMS.pdf}
|
|
\end{figure}
|
|
\end{frame}
|
|
|
|
\begin{frame}{MO-SMS Intercept}
|
|
\begin{itemize}
|
|
\item Accept CP-DATA from MS with RP-DATA / TP-DATA payload.
|
|
\item Respond with CP-ACK success.
|
|
\item Send CP-DATA with RP-ACK payload reporting a success or a network failure.
|
|
\item Get CP-ACK success from handset.
|
|
\item Release channel.
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\subsection{Unstructured Supplementary Service Data (USSD)}
|
|
|
|
\begin{frame}{USSD}
|
|
\begin{itemize}
|
|
\item Unstructured Supplementary Service Data, GSM 02.90.
|
|
\item Similar to SMS, but session-oriented and faster.
|
|
\item Used for interacting with core network applications \& ``value-added services'':
|
|
\begin{itemize}
|
|
\item Calling feature access and configuration.
|
|
\item Payment systems and banking.
|
|
\end{itemize}
|
|
\item Can also be used as WAP transport.
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{USSD}
|
|
\begin{figure}[h]
|
|
\centering
|
|
\includegraphics[width=80mm]{USSDGateway.pdf}
|
|
\end{figure}
|
|
\end{frame}
|
|
|
|
\subsection{Radio Resource Location Protocol (RRLP)}
|
|
|
|
\begin{frame}{RRLP}{Radio Resource Location Protocol}
|
|
\begin{itemize}
|
|
\item Radio Resource Location Protocol, GSM 04.31
|
|
\item Protocol for accessing GPS receiver in a handset.
|
|
\item Required for emergency call support in some markets.
|
|
\item Can be queried whenever there is an active Dm channel. Handset can be paged just to do RRLP. No notification to the user.
|
|
\item All privacy controls are on the network side, so if someone spoofs the network the subscriber has no privacy.
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Some GPS Background}
|
|
\begin{itemize}
|
|
\item GPS signal has 1.024 MHz bandwidth, transmitted synchronously from a fleet of MEO SVs.
|
|
\item Positioning based on TOA measurements, but you need exact SV positions, clock deviations and atmospheric data to do the calculation.
|
|
\item That information is modulated onto the GPS signal in the \emph{ephemeris} and \emph{almanac} messages.
|
|
\item However, it is possible to measure TOA even if a signal is 20~dB too weak to allow demodulation.
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
|
|
\begin{frame}{RRLP}
|
|
\begin{itemize}
|
|
\item Most RRLP attempts require GPS assistance information (almanac and ephemeris) because MS GPS antennas are tiny and the MS is usually poorly placed.
|
|
\item Some experiments with non-assisted RRLP:
|
|
\begin{itemize}
|
|
\item OpenBSC @ HAR 2009, Netherlands, 1\% success
|
|
\item OpenBTS @ Burning Man 2009, US, 0.1\% success
|
|
\end{itemize}
|
|
\item \emph{BUT} in both tests $>90$\% of handsets \emph{did} support the protocol and most failures were due to lack of assistance data. (Obviously, we need to try this again...)
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{RRLP results at HAR 2009}
|
|
\begin{figure}[h]
|
|
\centering
|
|
\includegraphics[width=80mm]{HARRRLP.jpg}
|
|
\end{figure}
|
|
\end{frame}
|
|
|
|
|
|
|
|
\part{Part V -- Jammers}
|
|
|
|
\begin{frame}{Part V -- Jammers}
|
|
\tableofcontents
|
|
% You might wish to add the option [pausesections]
|
|
\end{frame}
|
|
|
|
\section{Jammers}
|
|
|
|
\begin{frame}{Jammers}
|
|
\begin{itemize}
|
|
\item Radio interface DoS attack.
|
|
\item Useful to disrupt local communication or to disable remote-contol weapons.
|
|
\item Useful for forcing traffic though vulnerable points.
|
|
\begin{itemize}
|
|
\item Jam UMTS to force handsets to GSM.
|
|
\item Jam specific BTS units to control handovers or force traffic to compromised sites.
|
|
\end{itemize}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\subsection{Downlink Jammers}
|
|
|
|
\begin{frame}{Downlink Jammers}
|
|
\begin{itemize}
|
|
\item Downlink jamming overpowers the BTS signal at the handset.
|
|
GMSK is a robust modulation, so you must really overpower, not just interfere.
|
|
\item Downlink power levels are typically -70 to -100~dBm for normal service so you need at least -70 dBm to jam reliably.
|
|
\item A 20 W vehicle-mounted wideband jammer has a reliable range of 100-200~m in an urban area.
|
|
\item Most jammers are wideband, but single-ARFCN jamming of C0 affords much greater range at the same power levels.
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Example Jammer}
|
|
\begin{figure}[h]
|
|
\centering
|
|
\includegraphics[width=50mm]{Jammer.pdf}
|
|
\caption{\tiny{Typical generic quadband downlink jammer, probably about 10~W/band, probably made in China, probably jams a lot more than GSM.}}
|
|
\end{figure}
|
|
\end{frame}
|
|
|
|
\subsection{Uplink Jammers}
|
|
|
|
\begin{frame}{Uplink Jammers}
|
|
\begin{itemize}
|
|
\item Uplink jamming overpowers the handset signal at the BTS.
|
|
\item Narrowband jamming does not require much more power than a standard handset, just 2~W to jam from the edge of a cell.
|
|
\item Jamming the C0 makes the RACH/AGCH unusable. Also disrupts Dm channels on many BTS configurations.
|
|
\item Jams the entire serving cell. Most in-progress calls are unaffected, but no new calls can be established.
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\subsection{RACH Flood DoS}
|
|
|
|
\begin{frame}{RACH Flood DoS}
|
|
\begin{itemize}
|
|
\item A more sophisticated uplink jamming attack.
|
|
\item Mimics RACH bursts from a normal handset, but more rapidly, inducing resource exhaustion in the network.
|
|
\item Requires very little power. Peak power up to 1 W but low duty cycle.
|
|
\item See Dieter Spaar ``A Practical DOS Attack to the GSM Network'' later this week.
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
|
|
\part{Countermeasures}
|
|
|
|
\begin{frame}{Part VI -- Countermeasures}
|
|
\tableofcontents
|
|
% You might wish to add the option [pausesections]
|
|
\end{frame}
|
|
|
|
|
|
\section{Countermeasures}
|
|
|
|
\subsection{Against IMSI Catchers -- On the network side}
|
|
|
|
\begin{frame}{Operating Signature of an IMSI-Catcher}
|
|
The network operator will see:
|
|
\begin{itemize}
|
|
\item Non-existent or distant LACs and invalid TMSIs in the location updates of handsets returning to the real network.
|
|
\item Waves of heavy registration activity, especially if the IMSI-catcher is mobile or the operator is sloppy with power control.
|
|
\end{itemize}
|
|
With proper software in the BSC, a carrier might detect these symptoms automatically.
|
|
\end{frame}
|
|
|
|
\begin{frame}{IMSI-Catcher Counter-counter-measures}
|
|
\small{
|
|
To minimize the signature, the IMSI-catcher operator can:
|
|
\begin{itemize}
|
|
\item Ramp power up and down slowly at the start and end of a operating session.
|
|
\begin{itemize}
|
|
\item Slow ramp-up prevents congestion in the IMSI-catcher.
|
|
\item Slow ramp-down prevents congestion in the carrier network.
|
|
\end{itemize}
|
|
\item Accept all handsets and save reported TMSIs as the phones are captured.
|
|
\item Set LAC to match local network prior to shutdown; reassign original TMSIs in last wave of location updates.
|
|
\end{itemize}
|
|
Moving handsets still produce a signature, but a much more subtle one and none of these techniques can hide a mobile IMSI-catcher.
|
|
}
|
|
\end{frame}
|
|
|
|
\subsection{Against IMSI Catchers -- On the handset side}
|
|
|
|
\begin{frame}{Operating Signature of an IMSI-Catcher}
|
|
On most handsets, the user might notice:
|
|
\begin{itemize}
|
|
\item Short battery life
|
|
\item Encryption disabled on MO calls
|
|
\item Failed MO attempts (if there's no man-in-the-middle support)
|
|
\item Lack of MT calls
|
|
\item Frequent visits to the AGCH
|
|
\end{itemize}
|
|
...and by the time you notice any of these it is probably too late.
|
|
\end{frame}
|
|
|
|
\begin{frame}{Operating Signature of an IMSI-Catcher}
|
|
On a field test handset, the user will see:
|
|
\begin{itemize}
|
|
\item Frequent LAC change, even if you are stationary.
|
|
\item Active traffic channel with no active call.
|
|
\end{itemize}
|
|
It may not be hard to write a smartphone application to detect these conditions.
|
|
\end{frame}
|
|
|
|
\begin{frame}{IMSI-Catcher Counter-measures}
|
|
\begin{itemize}
|
|
\item Turn off your handset if you are not using it.
|
|
\item Have people call you back, with their caller ID blocked.
|
|
\item Use a field test handset and pay attention.
|
|
\item Change SIMs frequently.
|
|
\item Avoid handsets known to have TMSI retention bugs.
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\subsection{Countermeasures against A5/1 cracking}
|
|
|
|
\begin{frame}{Countermeasures against A5/1 cracking}
|
|
\begin{itemize}
|
|
\item Rolling change-over to A5/3 even in GSM networks
|
|
\begin{itemize}
|
|
\item All modern 3G phones indicate A5/3 availability even on GSM
|
|
\item So far, no networks known that use it
|
|
\end{itemize}
|
|
\item Re-keying intervals as short as possible
|
|
\begin{itemize}
|
|
\item Ensures one cracked session key will not last for long
|
|
\end{itemize}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\section{End-to-End Security}
|
|
|
|
\begin{frame}{\emph{True} Secure GSM}
|
|
\begin{itemize}
|
|
\item Application-layer encryption over CSD.
|
|
\begin{itemize}
|
|
\item Uses normal Q.931-style call control for a point-to-point raw link, then runs encrypted vocoder frames over the link.
|
|
\item Can call other like phones or a gateway service.
|
|
\end{itemize}
|
|
\item Application layer encryption with VoIP over GPRS. Lie to the VoIP network about the media type and avoid transcoding.
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Example Secure GSM Handset}
|
|
\begin{figure}[h]
|
|
\centering
|
|
\includegraphics[width=90mm]{CryptoPhone.pdf}
|
|
\caption{From GMSK website}
|
|
\end{figure}
|
|
\end{frame}
|
|
|
|
\section{The ultimate countermeasure}
|
|
|
|
\begin{frame}{An Open Source MS-side GSM stack}{And how this would help us with many of our problems}
|
|
\begin{itemize}
|
|
\item Enables user to deactivate unwanted features
|
|
\begin{itemize}
|
|
\item No support for RRLP, SIM Toolkit, Network-initiated MO call or other abominations
|
|
\item Do not answer arbitrary IMEI or IMSI inquiries without user approval
|
|
\end{itemize}
|
|
\item Enables us to implement important features
|
|
\begin{itemize}
|
|
\item Make silent SMS non-silent
|
|
\item Reliable indication when phone is transmitting or not (silent call)
|
|
\item Reliable indication if and which GSM and GPRS encryption is used
|
|
\item IMSI-Catcher detection based on statistical analysis
|
|
\item Defend against TOA/TDOA based geolocation by artificial TA increase/decrease
|
|
\end{itemize}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{An Open Source MS-side GSM stack}
|
|
\begin{itemize}
|
|
\item Unfortunately, the stack alone is not sufficient
|
|
\begin{itemize}
|
|
\item The stack needs to run on a baseband processor
|
|
\item The baseband processor needs to run in an actual phone
|
|
\item Cooperation from the industry unlikely, thus problem of deploying this stack much harder than it should be
|
|
\end{itemize}
|
|
\item Even the stack itself is a fair amount of work
|
|
\begin{itemize}
|
|
\item However, who would have thought of OpenBTS and OpenBSC coming along so quickly?
|
|
\item It clearly can be done, even with very few dedicated people
|
|
\end{itemize}
|
|
\item Don't you too want a phone that you {\em own}, not the manufacturer or operator?
|
|
\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
|
|
\end{itemize}
|
|
\item There is ongoing work for an accessible phone-side GSM L1/L2/L3 implementation
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\subsection{Where we go from here}
|
|
|
|
\begin{frame}{TODO}{Where we go from here}
|
|
\begin{itemize}
|
|
\item The basic protocol-level tools for security analysis of the GSM protocols exist
|
|
\item It is up to the security community to make use of those tools (!)
|
|
\item Don't you agree that TCP/IP security is boring?
|
|
\item Join the GSM protocol security research projects today
|
|
\item Boldly go where no man has gone before
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\subsection{Where we go from here}
|
|
|
|
\begin{frame}{Future plans}
|
|
\begin{itemize}
|
|
\item Packet data (GPRS/EDGE) support in OpenBSC
|
|
\begin{itemize}
|
|
\item GPRS is used extensively on modern smartphones
|
|
\item Enables us to play with those phones without a heavily filtered operator network
|
|
\end{itemize}
|
|
\item UMTS(3G) support in OpenBSC
|
|
\item CSD support in OpenBTS
|
|
\item Access to MS side layer 1
|
|
\item Higher-level attacks based on existing lowe layers
|
|
\begin{itemize}
|
|
\item Playing with SIM Toolkit from the operator side
|
|
\item Playing with MMS
|
|
\item More exploration of RRLP
|
|
\end{itemize}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\subsection{Further Reading}
|
|
|
|
\begin{frame}{Further Reading}
|
|
\tiny{
|
|
\begin{itemize}
|
|
\item Open source Software on a GSM protocol level
|
|
\begin{description}[OpenBSC]
|
|
\item[OpenBSC] \url{http://openbsc.gnumonks.org/}
|
|
\item[OpenBTS] \url{htto://openbts.sourceforge.net/}
|
|
\item[airprobe] \url{http://airprobe.org/}
|
|
\end{description}
|
|
\item References to GSM protocol documentation
|
|
\begin{description}[Joachim G"oller]
|
|
\item[Joachim G"oller] \url{http://www.informatik.hu-berlin.de/~goeller/}
|
|
\item[nobbi] \url{http://www.nobbi.com/}
|
|
\item[THC wiki] \url{http://wiki.thc.org/gsm}
|
|
\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}
|