path: root/2013/gsmsec-tpe2013/gsmsec.tex

\documentclass{beamer}

\mode<presentation>
{
  \usetheme{Warsaw}
  % or ...

  \setbeamercovered{transparent}
  % or whatever (possibly just delete it)
}

\mode<handout>{
	\usepackage{handoutWithNotes}
	\pgfpagesuselayout{2 on 1 with notes landscape}[a4paper,border shrink=5mm]
	\usecolortheme{seahorse}
}

% ensure the page number is printed in front of the author name in the footer 
\newcommand*\oldmacro{}
\let\oldmacro\insertshortauthor% save previous definition
\renewcommand*\insertshortauthor{%
  \leftskip=.3cm% before the author could be a plus1fill ...
  \insertframenumber\,/\,\inserttotalframenumber\hfill\oldmacro}

\usepackage[english]{babel}
\usepackage[latin1]{inputenc}
\usepackage{times}
\usepackage[T1]{fontenc}

\usepackage{subfigure}
\usepackage{hyperref}
\usepackage{textcomp,listings}
%\usepackage{german}
\lstset{basicstyle=\scriptsize\ttfamily, upquote}

\title{GSM Security Problems}

%\subtitle{and other GSM related fun}

\author{Harald~Welte}

\institute{osmocom.org\\hmw-consulting.de\\sysmocom.de}

% - Use the \inst command only if there are several affiliations.
% - Keep it simple, no one is interested in your street address.

\date[Julyh 2013] % (optional, should be abbreviation of conference name)
{July 2013, TSC TIB, Taipei/TAIWAN}
% - Either use conference name or its abbreviation.
% - Not really informative to the audience, more for people (including
%   yourself) who are reading the slides online

\subject{GSM Security}
% This is only inserted into the PDF information catalog. Can be left
% out. 

\begin{document}

\begin{frame}
  \titlepage
\end{frame}


\section{Introduction}


\begin{frame}{About Harald Welte}{hwelte@hmw-consulting.de}
\begin{itemize}
	\item Linux Kernel, bootloader, driver, firmware developmer 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
	\item Founder and key developer of OsmocomBB project
	\item Co-founder of sysmocom - systems for mobile communications GmbH
\end{itemize}
\end{frame}

\begin{frame}{About Osmocom.org}{Open Source MObile COMmunications}
\begin{itemize}
	\item community-driven project to implement communcation systems
		on protocol and/or radio level
	\item many sub-projects, including
	\begin{itemize}
		\item OsmocomBB (telephone-side GSM stack)
		\item OpenBSC (OsmoNITB, OsmoBSC, network-side GSM stack)
		\item OsmoSGSN and OpenGGSN (network-side GPRS+EDGE)
		\item OsmocomTETRA (TETRA PMR receiver/decoder)
		\item OsmocomGMR (GMR satellite telephony decoder)
		\item OsmocomDECT (DECT cordless telephony)
		\item OsmocomSIMTRACE (SIM protocol tracer hardware)
		\item OsmocomSDR (SDR receiver hardware)
	\end{itemize}
\end{itemize}
\end{frame}

\begin{frame}{Legal Disclaimer}
\begin{itemize}
	\item GSM operates in licensed spectrum
	\item Operating any transmitter in the GSM frequency bands requires a license from the respective regulatory authority
	\item Interference with commercial cellular operators is often a fellony and punishable as a crime
	\item It is the users responsibility to configure OpenBSC and BTS equipment in a way that complies with the law
\end{itemize}
\end{frame}

\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 may cause temporary disruptions in service, unsolicited text messages or other annoyances
\item Not all of the software used to demonstrate security weaknesses is part of the normal OpenBTS or OpenBSC distributions
\end{itemize}
\end{frame}

\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}



\begin{frame}{Threat Models}
\begin{itemize}
	\item GSM is a massively distributed network with many interfaces
	\item Some interfaces are exposed completley public, others not
	\item Attack vectors and threat models depend on who you are
\end{itemize}
\end{frame}

\subsection{Security if you are an Operator}

\begin{frame}{If you are an operator}
\begin{itemize}
	\item The subscriber is a potential attacker
	\begin{itemize}
		\item may want to commit fraud
		\item may want to DoS or otherwise impact your network
		\item may be violating your terms of services (VoIP, SIMboxes)
		\item SIM card cloning
	\end{itemize}
	\item A third party is a potential attacker
	\begin{itemize}
		\item only as much as a subscriber (see above)
		\item SS7 based fraud (SMS spam, etc.)
		\item eavesdropping on Um, Abis/microwave, SS7 etc. is
mostly to invide subscriber privacy.  Not primarliy an operator concern!
	\end{itemize}
\end{itemize}
\end{frame}

\subsection{Security if you are a Subscriber}

\begin{frame}{If you are a subscriber}
\begin{itemize}
	\item The operator is a potential threat
	\begin{itemize}
		\item detailed location profiles about subscriber
		\item access to all plain-text communication
		\item untrusted operator SIM card tied into your phone
	\end{itemize}
	\item A third party is a potential threat
	\begin{itemize}
		\item eavesdropping on the radio interface
		\item eavesdropping on microwave back-haul
		\item intelligence based on SS7 queries on the worldwide SS7 network
		\item mobile malware on your phone, on your SIM
	\end{itemize}
	\item Governments are a potential threat
	\begin{itemize}
		\item access to all data (location, CDR) at the operator
		\item actively performing air interface attacks (IMSI catcher, etc)
		\item lawful intercept at the core network
	\end{itemize}
\end{itemize}
\end{frame}

\subsection{Security if you are a Government}

\begin{frame}{If you are a government}
\begin{itemize}
	\item The operator is a potential threat
	\begin{itemize}
		\item mostly because operator has all CDRs, location
profiles and access to content of communication.  An informant at the
operator could coopeate with foreign governments or criminal groups
		\item security of the private operator affects your security
		\item operator wants to maximize profits, not subscriber :security
	\end{itemize}
	\item Other governments are a potential threat
	\begin{itemize}
		\item eavesdropping on the air interface or microwave back-haul
		\item active attacks on the air interface
		\item mobile malware on phone or SIM cards
		\item SS7 based intelligence (location, etc.) from worldwide SS7 network
	\end{itemize}
	\item Criminal organizations are a potential threat
	\begin{itemize}
		\item the same as {\em Other governments} above
	\end{itemize}
\end{itemize}
\end{frame}

\subsection{The GSM network -- Overview}

\begin{frame}{The GSM network}
  \begin{figure}[h]
  \centering
  \includegraphics[width=100mm]{gsm_network.png}
  \end{figure}
\end{frame}

\begin{frame}{GSM network components}
  \begin{itemize}
    \item The BSS (Base Station Subsystem)
    \begin{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}


\section{GSM security problems}

\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}

\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}


\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 64bit variant of UMTS cipher for GSM
		\item[A5/4] is the 128bit variant of the UMTS cipher for GSM
		\item[A5/5..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}{GSM uses symmetric session keys}
\includegraphics[bb=0in 0in 12in 6in,clip,width=5.3in,page=12]{nohl-slides-14.pdf}
\end{frame}

\subsection{GSM Security -- Design Flaws + Oversights}

\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}


\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 some carriers allegedly use only 64.
	\item The spec allow 64 bits for $K_C$, but some carriers evidently 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}


\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}

\subsection{GSM security research}

\begin{frame}{GSM/3G protocol level security}
\begin{itemize}
	\item Observation
	\begin{itemize}
		\item Both GSM/3G and TCP/IP protocol specs are publicly available
		\item The Internet protocol stack (Ethernet/Wifi/TCP/IP) receives lots of scrutiny
		\item GSM networks are as widely deployed as the Internet
		\item Yet, GSM/3G protocols receive no such scrutiny!
	\end{itemize}
	\item There are reasons for that:
	\begin{itemize}
		\item GSM industry is extremely closed (and closed-minded)
		\item Only about 4 closed-source protocol stack implementations
		\item GSM chip set makers never release any hardware documentation
	\end{itemize}
\end{itemize}
\end{frame}

\begin{frame}{The closed GSM industry}{Handset manufacturing side}
\begin{itemize}
	\item Only very few companies build GSM/3.5G baseband chips today
	\begin{itemize}
		\item Those companies buy the operating system kernel and the protocol stack from third parties
	\end{itemize}
	\item Only very few handset makers are large enough to become a customer
	\begin{itemize}
		\item Even they only get limited access to hardware documentation
		\item Even they never really get access to the firmware source
	\end{itemize}
\end{itemize}
\end{frame}

\begin{frame}{The closed GSM industry}{Network manufacturing side}
\begin{itemize}
	\item Only very few companies build GSM network equipment
	\begin{itemize}
		\item Basically only Ericsson, Nokia-Siemens, Alcatel-Lucent and Huawei
		\item Exception: Small equipment manufacturers for picocell / nanocell / femtocells / measurement devices and law enforcement equipment
	\end{itemize}
	\item Only operators buy equipment from them
	\item Since the quantities are low, the prices are extremely high
	\begin{itemize}
		\item e.g. for a BTS, easily 10-40k EUR
		\item minimal network using standard components definitely in the 100,000s of EUR range
	\end{itemize}
\end{itemize}
\end{frame}

\begin{frame}{The closed GSM industry}{Operator side}
From my experience with Operators (prove me wrong!)
\begin{itemize}
	\item Operators are mainly finance + marketing today
	\item Many operators outsources
	\begin{itemize}
		\item Network servicing / deployment, even planning
		\item Other aspects of business like Billing
	\end{itemize}
	\item Operator just knows the closed equipment as shipped by manufacturer
	\item Very few people at an operator have knowledge of the protocol beyond what's needed for operations and maintenance
\end{itemize}
\end{frame}

\begin{frame}{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}

\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}

\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}

\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}


\subsection{Behavior}

\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}

\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}

\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}

\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 wireline phone, VoIP carrier, ISDN or another GSM handset
	\item \emph{Spoof} CLID in the PSTN
	\item Collect both sides of the conversation
\end{itemize}
% Demo
\end{frame}

\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{Security beyond the Um interface}

\subsection{The GSM network -- RAN backhaul}

\begin{frame}{Backhaul security}
In classic GSM, 
\begin{itemize}
	\item design goal: provide same confidentiality/security as wired telephony
	\item wired telephony networks typically run without any encryption
	\item encryption is only on Um, i.e. between MS and BTS
	\item backhaul interface (Abis on BTS-BSC link) originally designed to run over E1
	\item backhaul between BTS and BSC has no encryption
	\item attacker requires physical access to E1 line in wired E1
\end{itemize}
\end{frame}

\begin{frame}{Backhaul security}
Running A-bis backhaul over microwave
\begin{itemize}
	\item E1 over microwave radio typically unencrypted (e.g. MINI-LINK)
	\item tuning into microwave links relatively easy
	\begin{itemize}
		\item side-lobes of microwave antenna
		\item propagation of signal beyond receiving antenna
		\item main obstacle: proprietary coding/synchronization of microwave link
	\end{itemize}
	\item passive eavesdropping of backhaul link provides easy option to full signalling and traffic 
\end{itemize}
\end{frame}

\subsection{SIM card security}

\begin{frame}{The Subscriber Identity Module (SIM)}
\begin{itemize}
	\item Basic idea was to store cryptographic identity of subscriber inside smart card
	\item User can thus migrate identity from one device to another
	\item User can furthermore use different SIM in same device (e.g. local prepaid SIM while travelling)
	\item Original SIM card design mostly ISO 7816-4 filesystem and single command to execute A3/A8 algorithm inside card
	\begin{itemize}
		\item This could even be done in logic, no processor required
	\end{itemize}
\end{itemize}
\end{frame}

\begin{frame}{The modern SIM}
The modern SIM is an entirely different beast
\begin{itemize}
	\item Cryptographic processor smart card
	\begin{itemize}
		\item Symmetric cryptography such as DES, 3DES, AES
		\item Public key cryptography such as RSA, ECC
	\end{itemize}
	\item Java Card including a small Java VM and Java RE
	\item Multiple application support
	\item Ability to download applications (Applets) into card
\end{itemize}
\end{frame}


\begin{frame}{SIM Application Toolkit (SAT)}
\begin{itemize}
	\item Ability for card to run applications that have UI on the phone
	\begin{itemize}
		\item Display menu items on-screen
		\item Get user input from keypad/touch-screen
	\end{itemize}
	\item Described in TS 11.14 and 11.11
\end{itemize}
\end{frame}

\begin{frame}{SAT -- Proactive SIM}
The {\em Proactive SIM} features
\begin{itemize}
	\item Sending a short message
	\item Setting up a voice call
	\item Playback of a tone in earpiece
	\item Providing location information from ME to SIM
	\item Have ME execute timers on behalf of SIM
	\item Sending DTMF to network
	\item Running an AT command received from SIM, sending result back to SIM
	\item Ask ME to launch browser to SIM-provided URL
\end{itemize}
\end{frame}

\begin{frame}{SAT -- Call and SMS Control}
\begin{itemize}
	\item ME passes MO call setup attempts to SIM for approval
	\item SIM can then
	\begin{itemize}
		\item approve or decline the MO call
		\item modify the call details such as phone number
		\item replace the call with USSD message
	\end{itemize}
	\item ME passes USSD requests similar to Call Control
	\item Similar mechanism exists for all MO SMS	
\end{itemize}
\end{frame}

\begin{frame}{SAT -- Provide local information}
The SIM can inquire the ME about
\begin{itemize}
	\item MCC / MNC / LAC / Cell ID
	\item IMEI of ME
	\item Network Measurement Results
	\item BCCH channel list
	\item Date, Time, Timezone
	\item ME language setting
	\item Timing Advance
\end{itemize}
\end{frame}

\begin{frame}{SAT -- Event download}
The SIM is notified by ME about certain events such as
\begin{itemize}
	\item Call Connected / Disconnected
	\item Location Status (Location Area change)
	\item User activity (keyboard input)
	\item Idle screen available
	\item Browser termination
\end{itemize}
\end{frame}

\begin{frame}{SAT - Data download}
\begin{itemize}
	\item Enables Operator to exchange arbitrary data with the SIM
	\item Could be RFM (Remote File Management)
	\begin{itemize}
		\item Read or modify phone book entries
		\item Even change the IMSI of the SIM (!)
	\end{itemize}
	\item In case of Java Card, can be download of card applets
	\begin{itemize}
		\item Applets are stored permanently on SIM
		\item Can later use SAT procedures to interact with ME
		\item TS 03.19 specifies Java API to access SAT from Java RE
	\end{itemize}
\end{itemize}
\end{frame}


\begin{frame}{SAT - Data download}
SAT Data Download can happen via
\begin{itemize}
	\item via SMS or Cell Broadcast
	\begin{itemize}
		\item Uses TS 03.40 TP-PID {\em SIM DATA Download}
		\item ME forwards such SMS to the SIM in {\tt ENVELOPE} APDU
		\item Response from SIM is sent back as MO-SMS or DELIVERY REPORT
	\end{itemize}
	\item via BIP (Bearer Independent Protocol)
	\begin{itemize}
		\item Dedicated CSD call between network and SIM
		\item GPRS session between network and SIM
	\end{itemize}
\end{itemize}
\end{frame}

\begin{frame}{SAT - Data download}{Data download security}
\begin{itemize}
	\item GSM TS 03.48 specifies secure messaging for data download
	\item Includes replay protection
	\item Supports DES and 3DES
	\item SMS chaining for long commands / large data
\end{itemize}
\end{frame}

%%%%%%
\begin{frame}{SIM card abuse by hostile operator}
\begin{itemize}
	\item Even if the phone might be considered trusted, the SIM card is owned and controlled by the operator
	\item Using SAT features, the operator can control many aspects of the phone
	\item Examples
	\begin{itemize}
		\item Remotely reading address book / stored SMS
		\item Monitor user behavior (browser termination, idle screen, ...)
		\item Ask phone to establish packet data session
	\end{itemize}
\end{itemize}
\end{frame}

\begin{frame}{SIM card re-programming by attacker}
\begin{itemize}
	\item If the SIM is not properly secured (auth + encryption keys, ...) a third party attacker can send SAT envelope SMS to the card and install resident Java applets
	\item The attacker can then
	\begin{itemize}
		\item Obtain detailed location information and send it via SMS
		\item Intercept/log outgoing calls
		\item Sending copies of incoming + outgoing SMS elsewhere
	\end{itemize}
	\item Even using SIM card channel to exploit baseband stack is feasible
\end{itemize}
\end{frame}

\begin{frame}{SIM card proxy / MITM by attacker}
As soon as an attacker has temporary physical access to a phone, he can
\begin{itemize}
	\item Insert a proxy-SIM between real SIM and phone
	\item Do everything a Java applet could do, but even with a securely configured SIM as he does not modify the existing SIM
	\item Sniff current Kc and send it out e.g. via SMS or even UDP/TCP packets over GPRS
	\item ... by only using standard interfaces that are common among all phones (as opposed to baseband software hacking which is very model-specific)
\end{itemize}
Most users would never notice this as they rarely check their SIM slot
\end{frame}

%%%%%%

\begin{frame}{Defending against SIM based attacks}
\begin{itemize}
	\item SIM cards are Operator issued, Ki is on the SIM
	\begin{itemize}
		\item SIM card can thus not be replaced, but original SIM must be used
	\end{itemize}
	\item Configure telephone to not store contacts or SMS on SIM
	\item Communication between SIM and ME is not encrypted/authenticated
	\item Solution: Proxy SIM between SIM and ME to break STK / OTA
	\begin{itemize}
		\item Filter all STK/OTA/Proactive commands like ENVELOPE
		\item Indicate lack of STK support to ME (EF.Phase)
	\end{itemize}
\end{itemize}
\end{frame}

\begin{frame}{Proxy SIM with firewall}
\begin{itemize}
	\item There are no known commercial products that implement STK/OTA filtering
	\item But there are a number of shim SIM cards that are plugged between SIM and SIM slot
	\item Most of them are used for SIM unlocking modern phones
	\item Some vendors produce freely (re)programmable proxy SIMs:
\end{itemize}
\begin{figure}[h]
\subfigure{\includegraphics[width=40mm]{bladox-turbosim.jpg}}
\subfigure{\includegraphics[width=25mm]{rebelsim2.jpg}}
	   \caption{Bladox TurboSIM (AVR) and RebelSIM II (8051)}
	   %\caption{Bladox Turbo SIM (AVR)}}
\end{figure}
\end{frame}

\subsection{Osmocom SIMtrace}

\begin{frame}{Analyzing SIM toolkit applications is hard}
\begin{itemize}
	\item Regular end-user phone does not give much debugging
	\item SIM card itself has no debug interface for printing error messages, warnings, etc.
	\item However, as SIM-ME interface is unencrypted, sniffing / tracing is possible
	\item Commercial / proprietary solutions exist, but are expensive (USD 5,000 and up)
	\item Technically, sniffing smard card interfaces is actually very simple
\end{itemize}
\end{frame}

\begin{frame}{Introducing Osmocom SIMtrace}
\begin{itemize}
	\item Osmocom SIMtrace is a passive (U)SIM-ME communication sniffer
	\item Insert SIM adapter cable into actual phone
	\item Insert (U)SIM into SIMtrace hardware
	\item SIMtrace hardware provides USB interface to host PC
	\item {\tt simtrace} host PC program encapsulates APDU in GSMTAP
	\item GSMTAP is sent via UDP to localhost
	\item wireshark dissector for GSM TS 11.11 decodes APDUs
\end{itemize}
\end{frame}

\begin{frame}{Osmocom SIMtrace Hardware}
\begin{figure}[h]
	\centering
	\includegraphics[width=85mm]{simtrace_and_phone.jpg}
\end{figure}
\end{frame}

\end{document}