14 files changed, 1072 insertions, 0 deletions
diff --git a/2013/gsmsec-tpe2013/BTSGEO.pdf b/2013/gsmsec-tpe2013/BTSGEO.pdf
new file mode 100644
index 0000000..97a7fbe
--- /dev/null
+++ b/2013/gsmsec-tpe2013/BTSGEO.pdf
diff --git a/2013/gsmsec-tpe2013/DatongDX300.pdf b/2013/gsmsec-tpe2013/DatongDX300.pdf
new file mode 100644
index 0000000..13f581c
--- /dev/null
+++ b/2013/gsmsec-tpe2013/DatongDX300.pdf
diff --git a/2013/gsmsec-tpe2013/Intellijam.pdf b/2013/gsmsec-tpe2013/Intellijam.pdf
new file mode 100644
index 0000000..551e886
--- /dev/null
+++ b/2013/gsmsec-tpe2013/Intellijam.pdf
diff --git a/2013/gsmsec-tpe2013/LadderLU.pdf b/2013/gsmsec-tpe2013/LadderLU.pdf
new file mode 100644
index 0000000..e3f7894
--- /dev/null
+++ b/2013/gsmsec-tpe2013/LadderLU.pdf
diff --git a/2013/gsmsec-tpe2013/MRTBTS.pdf b/2013/gsmsec-tpe2013/MRTBTS.pdf
new file mode 100644
index 0000000..296b2ab
--- /dev/null
+++ b/2013/gsmsec-tpe2013/MRTBTS.pdf
diff --git a/2013/gsmsec-tpe2013/VBTSFigure.pdf b/2013/gsmsec-tpe2013/VBTSFigure.pdf
new file mode 100644
index 0000000..f77fb1e
--- /dev/null
+++ b/2013/gsmsec-tpe2013/VBTSFigure.pdf
diff --git a/2013/gsmsec-tpe2013/bladox-turbosim.jpg b/2013/gsmsec-tpe2013/bladox-turbosim.jpg
new file mode 100644
index 0000000..02b6372
--- /dev/null
+++ b/2013/gsmsec-tpe2013/bladox-turbosim.jpg
diff --git a/2013/gsmsec-tpe2013/gsm_network.png b/2013/gsmsec-tpe2013/gsm_network.png
new file mode 100644
index 0000000..c5f6399
--- /dev/null
+++ b/2013/gsmsec-tpe2013/gsm_network.png
diff --git a/2013/gsmsec-tpe2013/gsmsec.pdf b/2013/gsmsec-tpe2013/gsmsec.pdf
new file mode 100644
index 0000000..7bf9672
--- /dev/null
+++ b/2013/gsmsec-tpe2013/gsmsec.pdf
diff --git a/2013/gsmsec-tpe2013/gsmsec.snm b/2013/gsmsec-tpe2013/gsmsec.snm
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/2013/gsmsec-tpe2013/gsmsec.snm
diff --git a/2013/gsmsec-tpe2013/gsmsec.tex b/2013/gsmsec-tpe2013/gsmsec.tex
new file mode 100644
index 0000000..ccd6c10
--- /dev/null
+++ b/2013/gsmsec-tpe2013/gsmsec.tex
@@ -0,0 +1,1072 @@
+
+\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}
diff --git a/2013/gsmsec-tpe2013/nohl-slides-14.pdf b/2013/gsmsec-tpe2013/nohl-slides-14.pdf
new file mode 100644
index 0000000..884f455
--- /dev/null
+++ b/2013/gsmsec-tpe2013/nohl-slides-14.pdf
diff --git a/2013/gsmsec-tpe2013/rebelsim2.jpg b/2013/gsmsec-tpe2013/rebelsim2.jpg
new file mode 100644
index 0000000..0ba6247
--- /dev/null
+++ b/2013/gsmsec-tpe2013/rebelsim2.jpg
diff --git a/2013/gsmsec-tpe2013/simtrace_and_phone.jpg b/2013/gsmsec-tpe2013/simtrace_and_phone.jpg
new file mode 100644
index 0000000..7c53de2
--- /dev/null
+++ b/2013/gsmsec-tpe2013/simtrace_and_phone.jpg