import of old now defunct presentation slides svn repo

34 files changed, 2834 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
diff --git a/2013/mobsec-cso2013/mobsec.pdf b/2013/mobsec-cso2013/mobsec.pdf
new file mode 100644
index 0000000..9fcc4ce
--- /dev/null
+++ b/2013/mobsec-cso2013/mobsec.pdf
diff --git a/2013/mobsec-cso2013/mobsec.snm b/2013/mobsec-cso2013/mobsec.snm
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/2013/mobsec-cso2013/mobsec.snm
diff --git a/2013/mobsec-cso2013/mobsec.tex b/2013/mobsec-cso2013/mobsec.tex
new file mode 100644
index 0000000..9e04f9a
--- /dev/null
+++ b/2013/mobsec-cso2013/mobsec.tex
@@ -0,0 +1,487 @@
+% $Header: /cvsroot/latex-beamer/latex-beamer/solutions/conference-talks/conference-ornate-20min.en.tex,v 1.7 2007/01/28 20:48:23 tantau Exp $
+
+\documentclass{beamer}
+
+\usepackage{url}
+\makeatletter
+\def\url@leostyle{%
+  \@ifundefined{selectfont}{\def\UrlFont{\sf}}{\def\UrlFont{\tiny\ttfamily}}}
+\makeatother
+%% Now actually use the newly defined style.
+\urlstyle{leo}
+
+
+% This file is a solution template for:
+
+% - Talk at a conference/colloquium.
+% - Talk length is about 20min.
+% - Style is ornate.
+
+
+
+% Copyright 2004 by Till Tantau <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)
+}
+
+
+\usepackage[english]{babel}
+% or whatever
+
+\usepackage[latin1]{inputenc}
+% or whatever
+
+\usepackage{times}
+\usepackage[T1]{fontenc}
+% Or whatever. Note that the encoding and the font should match. If T1
+% does not look nice, try deleting the line with the fontenc.
+
+
+\title{Structural deficits in Telco security}
+
+%\subtitle {community based Free / Open Source Software for communications}
+
+\author{Harald Welte <hwelte@hmw-consulting.de>}
+
+\institute
+{gnumonks.org\\hmw-consulting.de\\sysmocom GmbH}
+% - Use the \inst command only if there are several affiliations.
+% - Keep it simple, no one is interested in your street address.
+
+\date[] % (optional, should be abbreviation of conference name)
+{March 21, 2013 / CSO}
+% - 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{Communications}
+% 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}
+
+\begin{frame}{Outline}
+  \tableofcontents[hideallsubsections]
+  % You might wish to add the option [pausesections]
+\end{frame}
+
+
+% Structuring a talk is a difficult task and the following structure
+% may not be suitable. Here are some rules that apply for this
+% solution: 
+
+% - Exactly two or three sections (other than the summary).
+% - At *most* three subsections per section.
+% - Talk about 30s to 2min per frame. So there should be between about
+%   15 and 30 frames, all told.
+
+% - A conference audience is likely to know very little of what you
+%   are going to talk about. So *simplify*!
+% - In a 20min talk, getting the main ideas across is hard
+%   enough. Leave out details, even if it means being less precise than
+%   you think necessary.
+% - If you omit details that are vital to the proof/implementation,
+%   just say so once. Everybody will be happy with that.
+
+\begin{frame}{About the speaker}
+\begin{itemize}
+	\item Linux Kernel / bootloader / driver / firmware developer since 1999
+	\item IT security expert, focus on network protocol security
+	\item Former core developer of Linux packet filter netfilter/iptables
+	\item Board-level Electrical Engineering
+	\item Always looking for interesting protocols (RFID, DECT, GSM)
+	\item OpenEXZ, OpenPCD, Openmoko, OpenBSC, OsmocomBB, OsmoSGSN
+	\item consulting/freelancing + sysmocom GmbH for custom-tailored GSM solutoins
+\end{itemize}
+\end{frame}
+
+\begin{frame}{Disclaimer}
+\begin{itemize}
+	\item This presentation is not intended to insult any participant
+	\item No companies or individuals will be named
+	\item However, the collective failure of the mobile industry
+		cannot be ignored, sorry.
+	\item Many of the issues we have today could have been avoided
+		extremely easily, there really is no excuse...
+\end{itemize}
+\end{frame}
+
+\section{Symptoms}
+
+\begin{frame}{Telco vs. Internet-driven IT security}
+mobile industry today has security practieses and procedures of the 20th century
+\begin{itemize}
+	\item no proper incident response on RAN/CN
+	\item no procedures for quick roll-out of new sw releases
+	\item no requirements for software-upgradeability
+	\item no interaction with hacker community
+	\item no packet filtering / DPI / IDS on signalling traffic
+	\item active hostility towards operators who want to do pentesting
+	\item attempts to use legal means to stop researchers from publishing their findings
+\end{itemize}
+this sounds like medieval times. We are in 2012 ?!?
+\end{frame}
+
+\subsection{Real-world quotes}
+
+\begin{frame}{Real-world quotes}
+The following slides indicate some quotes that I have heard over the
+last couple of years from my contacts inside the mobile industry.  They
+are not made up!
+\end{frame}
+
+
+\begin{frame}{Quote: Disclosure of Ki/K/OPC}
+"we are sending our IMSI+Key lists as CSV files to the SIM card supplier in China"
+\end{frame}
+
+\begin{frame}{Quote: RRLP}
+"RRLP? What is that? We never heard about it!"
+\end{frame}
+
+\begin{frame}{Quote: SIM OTA keys}
+"we have no clue what remote accessible (OTA) features our sim cards have or what kind of keys were used during provisioning"
+\end{frame}
+
+\begin{frame}{Quote: Malformed}
+"we have never tried to intentionally send any malformed message to any of our equipment"
+\end{frame}
+
+\begin{frame}{Quote: Roaming}
+"We are seeing TCAP/MAP related attacks/fraud from Operator XYZ in Pakistan.  However, it is more important that European travellers can roam into their network than it is for Pakistanis to roam into our network.  Can you see while the roaming agreement was only suspended for two days?"
+\end{frame}
+
+\begin{frame}{Quote: SIGTRAN IPsec}
+"we are unable to mandate from our roaming partners that SIGTRAN links shall always go through IPsec - we don't even know how to facilitate safe distribution of certificates between operators"
+\end{frame}
+
+\begin{frame}{Quote: NodeB / IPsec}
+"We mandated IPsec to be used for all of the (e)NodeB back-haul in our tender, the supplier still shipped equipment that didn't comply to it.  Do you think the CEO is going to cancel the contract with them for that?"
+\end{frame}
+
+\begin{frame}{Quote: Government / independent study}
+"Govt: We put out a tender for a study on overal operator network security in our country.  Everyone who put in a bid is economically affiliated or dependent on one of the operators or equipment suppliers, so we knew the results were not worth much."
+\end{frame}
+
+\begin{frame}{Quote: Technical Staff}
+"15 years ago we still had staff that understood all those details.  But today, you know, those experts are expensive - we laid them off."
+\end{frame}
+
+\begin{frame}{Quote: Baseband chip vendor}
+"We have no clue what version of our protocol stack with what modifications are shipped in which particular phones, or if/when the phone makers distribute updates to the actual phone population"
+\end{frame}
+
+%we live in a world where
+%	operators regularly don't fully understand the equipment they use
+%	"The frequencies of the mircrowave back-haul links are a trade secret of the operator
+%	operators are compltely dependent and live at the merit of few equipment suppliers
+%	suppliers have spent decades of achieving as little mix+match compatibility as possible
+%	huge conflict of interest between operators and suppliers
+%		selling new hardware vs. updating software of old units
+%	extreme disconnect between technical merits of certain changes/features and prices / licensing
+%		charge a six-digit EUR amount for the A5/3 upgrade for each BSC, despite the fact that it is the BTS that changes, not the BSC!
+
+\subsection{Algorithm nightmares}
+
+\begin{frame}{The A5/2 desaster}{Brief history}
+\begin{itemize}
+	\item August 2003: Barkan/Biham/Keller paper on instant ciphertext-only cryptanalysis of A5/2
+	\item April 2006: GSMA initiative to withdraw A5/2. Resistance {\em mainly from north america}.
+	\item October 2006: SA WG3 formally requests removal of A5/2 from spec
+	\item July 2007: Almost all operators have moved to A5/1
+	\item As long as phones support A5/2, semi-active down-grade attacks against A5/1 can be implemented!
+\end{itemize}
+Three years incident response to update the spec!  I'm not even talking
+about the time to update all equipment or until old equipment will be
+fully phased out.
+\end{frame}
+
+\begin{frame}{The A5/1 desaster}{history repeats itself}
+The industry did not learn from the A5/2 incident. History repeated
+itself:
+\begin{itemize}
+	\item Kc generation was not changed between A5/1,2,3
+	\item as long as phones support A5/1, A5/3 can be broken with
+		semi-active down-grade attacks just like A5/2 -> A5/1
+		before
+	\item There is still no way to disable algorithms of devices in
+		the field, not even by flags on the SIM card
+\end{itemize}
+How can an entire industy be so resilient against learning?
+\end{frame}
+
+\begin{frame}{The A5/3 desaster}{Nobody cares to implement it}
+\begin{itemize}
+	\item May 2002: A5/3 spec first released. Target: supported in handsets and networks in 2004.
+	\item May 2007: SA WG3: lack of BSS vendors supporting A5/3 (5 years later!!!)
+	\item January 2009: First discussions with phone makers on A5/3 interop tests
+	\item November 2009: 10 handsets from 7 manufacturers being tested on a live A5/3 network
+\end{itemize}
+After the track record of A5/2 and A5/3, they seem to be on a {\em fast track} to improve.
+\end{frame}
+
+\begin{frame}{The overall algorithm desaster}
+\begin{itemize}
+	\item Advances in security require algorithms to be replaced and key lengths to grow
+	\item Nobody in the GSM world seems to have realized such a basic cryptographic truth
+	\item Infrastruture vendors reluctant to make algorithms software-upgradeable. They'd rather sell ten-thousands of new BTSs
+	\item Operators never made it a requirement to do in-field algorithm upgrades.  Why would they?
+	\item Internet analogy: Who would ever want to use more than 40-bit RC4 encryption in his SSL implementation and upgrade that?
+\end{itemize}
+\end{frame}
+
+\begin{frame}{2009: GSMA starts to think}
+\begin{itemize}
+	\item November 2009, 3GPP TSG SA3 WG, GSMA Liaison Report: {\em
+			The meeting considered the need to ensure that
+			future infrastructure algorithm updates will be
+			exclusively software based}
+	\item About one decade too late for anyone with even remote
+		knowledge of real-world cryptographic deployment
+	\item Six years after the A5/2 cryptanalysis paper
+	\item Seven years after A5/3 has been specified
+\end{itemize}
+\end{frame}
+
+
+\begin{frame}{ETSI/3GPP security working group(s)}
+\begin{itemize}
+	\item seem to have done excellent work
+	\item nobody seemed to care about what they say
+	\item A5/4 (128bit) was originally supposed to come together with A5/3 in 2004
+	\begin{itemize}
+		\item has been put back as it would affect handset software (so what? there are only about 6 implementations out there. How hard is it to update all 6?)
+		is the only solution of fixing semi-active downgrade attacks
+	\end{itemize}
+	\item UMTS AKA over GERAN
+	\begin{itemize}
+		\item good idea, but where is the SIM card flag that tells the phone about mutual auth being mandatory?
+	\end{itemize}
+	\item Great ideas seem to fall short of being thought-through to
+		the end, and nobody implements them in a timely manner
+		anyway
+\end{itemize}
+\end{frame}
+
+\section{Causes / Reasons}
+
+\begin{frame}{Telco vs. Internet}
+still remember the days of analog modems, UUCP, BBSs, Usenet?
+\begin{itemize}
+	\item the culture gap between Internet vs. Telco has always existed
+	\item it didn't change much during the last decades
+	\item analogy: The "IBM priests" mainframes vs. personal computing in 1970ies/1980ies
+	\item IETF vs. ITU
+	\item open participation vs. closed club
+\end{itemize}
+\end{frame}
+
+\subsection{Change of power divide between Operators and Vendors}
+
+\begin{frame}{Evolving GSM specification process}
+\begin{itemize}
+	\item At CEPT, it was government officials of postal/comms ministry equipment vendors didn't even have the right to propose something
+	\item At ETSI, equipment vendors got onto the table Over time, shift of power from operators to equipment manufacturers
+	\item At 3GPP, today we see way too little operator input in standardization
+	\item Interest of users seems completely absent
+	\begin{itemize}
+		\item neither professional users (companies worried about industrial espionage, government users, ...)
+		\item nor consumers in form of consumer protection, privacy, data protection or other organizations seems to be missing completely
+	\end{itemize}
+	\item standardization process primarily serves the interest of equipment vendors to get their patented technology into widespread adoption to drive IP licensing revenue
+\end{itemize}
+\end{frame}
+
+\begin{frame}{Evolution of operators}
+\begin{itemize}
+	\item classic operator: Does everything in-house
+	\item common today: Outsource everything
+	\begin{itemize}
+		\item billing
+		\item network administration / operation / servicing
+		\item network planning
+	\end{itemize}
+	\item outsourcing to whom?
+	\begin{itemize}
+		\item to the equipment suppliers
+		\item am I the only one seing a conflict of interests here?
+	\end{itemize}
+\end{itemize}
+\end{frame}
+
+\subsection{Lack of Open Source Implementations}
+
+\begin{frame}{Research in TCP/IP/Ethernet}
+Assume you want to do some research in the TCP/IP/Ethernet
+communications area,
+\begin{itemize}
+	\item you use off-the-shelf hardware (x86, Ethernet card)
+	\item you start with the Linux / *BSD stack
+	\item you add the instrumentation you need
+	\item you make your proposed modifications
+	\item you do some testing
+	\item you write your paper / proof-of-concept and publish the results
+\end{itemize}
+\end{frame}
+
+\begin{frame}{Research in (mobile) communications}
+Assume it is before 2009 (before OpenBSC/OsmocomBB) and you want to do some research in mobile comms
+\begin{itemize}
+	\item there is no FOSS implementation of any of the protocols or
+		functional entities
+	\item almost no university has a test lab with the required
+		equipment.  And if they do, it is black boxes that you
+		cannot modify according to your research requirements
+	\item you turn away at that point, or you cannot work on really
+		exciting stuff
+	\item only chance is to partner with commercial company, who
+		puts you under NDAs and who wants to profit from your
+		research
+\end{itemize}
+\end{frame}
+
+\begin{frame}{GSM/3G vs. Internet}
+\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 very few closed-source protocol stack implementations
+		\item GSM chipset makers never release any hardware documentation
+	\end{itemize}
+\end{itemize}
+\end{frame}
+
+\section{Proposed Solution}
+
+\begin{frame}{Testing/Auditing just like in the IP world}
+\begin{itemize}
+	\item Learn and adapt from the Internet security world
+	\item Encourage all kinds of testing and audits rather than prevent them
+	\item Fuzzing+Pentesting all protocols on all levels
+\end{itemize}
+\begin{itemize}
+	\item I'm not aware of any of the well-known GSM/GPRS security researchers having been invited to equipment vendors to do sophisticated testing/attacks/audit
+	\item That's inefficient use of existing skills!
+\end{itemize}
+\end{frame}
+
+\begin{frame}{Change the way of thinking}
+\begin{itemize}
+	\item Give up the idea that certain interfaces are not exposed
+	\item TCAP/MAP/CAP are exposed to anyone with SCCP (SS7) access
+	\item This includes all government agencies world-wide, as they can easily force domestic operators to give them access!
+	\item Governments / regulators should put strong security requirements on domestic operators to secure those interfaces against attacks
+	\item This is critical infrastructure that the general public, industry and even government/administration increasingly relies on
+	\item Multiple lines of defences, not one or zero
+\end{itemize}
+\end{frame}
+
+\begin{frame}{Specifications / Testing}
+\begin{itemize}
+	\item If specs require any tests, they are {\em functional} specs
+	\item I've never seen requirements to test for invalid / intentionally malformed messages
+	\item Actively provide equipment (access) to academia and research, invite researchers to test/break things
+\end{itemize}
+\end{frame}
+
+\begin{frame}{Skill building}
+\begin{itemize}
+	\item We need more teaching/training in academia to generate independent experts, without vendor affiliation
+	\item Theoretic lectures are boring. Practical experiments / lab exercises required to get students excited / interested
+	\item Very few universities have been provided with sufficient equipment to run / experiment / play with their own GSM/3G networks
+	\item As long as it is much easier to research TCP/IP than mobile protocols, majority of the brain power will focus on TCP/IP
+	\item Open Source implementations are critical for experiments!
+\end{itemize}
+\end{frame}
+
+\begin{frame}{Less monoculture}
+\begin{itemize}
+	\item Very few equipment vendors and protocol stack vendors
+	\item Even less vendors of ASN.1 / CSN.1 code generators
+	\item Finding an exploitable bug in one of the 2-3 major ASN.1
+		code generators will permit you to exploit pretty much
+		any equipment independent of the vendor
+\end{itemize}
+\end{frame}
+
+\begin{frame}{Procedures / incident response}
+\begin{itemize}
+	\item start to adopt scheme like CVE, vulnerability databases
+	\item be prepared to rapidly roll out updates to all elements in
+		the operator infrastructure
+	\item have specs that require sufficient spare FPGA / DSP / CPU
+		/ RAM resources in hardware to ensure
+		software-upgradability of components
+\end{itemize}
+\end{frame}
+
+\begin{frame}{Engagement with the security community}
+\begin{itemize}
+	\item Actively engage academic and individual security researchers
+	\item Sueing them is not a solution, this has been tried in the 1990ies in the PC/Software industry
+	\item If you don't provide researchers inexpensive/available hardware, they have to break femtocells and other devices in order to do their legitimate research
+	\item Compare with gaming consoles exploits: All of them have been broken by people who wanted to run Linux and custom software on them.  Only PS3 survived much longer, as they provided such means to the users from day 1 (and later removed it, requiring to break the PS3, too)
+\end{itemize}
+\end{frame}
+
+\begin{frame}{Thanks}
+Thanks for your attention.  I hope we have time for Q\&A.
+\end{frame}
+
+
+\end{document}
diff --git a/2013/osmocom-coscup2013/bts_tree_full.jpg b/2013/osmocom-coscup2013/bts_tree_full.jpg
new file mode 100644
index 0000000..6b5c5e8
--- /dev/null
+++ b/2013/osmocom-coscup2013/bts_tree_full.jpg
diff --git a/2013/osmocom-coscup2013/c123_pcb.jpg b/2013/osmocom-coscup2013/c123_pcb.jpg
new file mode 100644
index 0000000..a9f24fc
--- /dev/null
+++ b/2013/osmocom-coscup2013/c123_pcb.jpg
diff --git a/2013/osmocom-coscup2013/ezcap_top.jpg b/2013/osmocom-coscup2013/ezcap_top.jpg
new file mode 100644
index 0000000..d504471
--- /dev/null
+++ b/2013/osmocom-coscup2013/ezcap_top.jpg
diff --git a/2013/osmocom-coscup2013/osmo-e1-xcvr.jpg b/2013/osmocom-coscup2013/osmo-e1-xcvr.jpg
new file mode 100644
index 0000000..8802e08
--- /dev/null
+++ b/2013/osmocom-coscup2013/osmo-e1-xcvr.jpg
diff --git a/2013/osmocom-coscup2013/osmocom-overview.pdf b/2013/osmocom-coscup2013/osmocom-overview.pdf
new file mode 100644
index 0000000..654bce5
--- /dev/null
+++ b/2013/osmocom-coscup2013/osmocom-overview.pdf
diff --git a/2013/osmocom-coscup2013/osmocom-overview.snm b/2013/osmocom-coscup2013/osmocom-overview.snm
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/2013/osmocom-coscup2013/osmocom-overview.snm
diff --git a/2013/osmocom-coscup2013/osmocom-overview.tex b/2013/osmocom-coscup2013/osmocom-overview.tex
new file mode 100644
index 0000000..d691b90
--- /dev/null
+++ b/2013/osmocom-coscup2013/osmocom-overview.tex
@@ -0,0 +1,575 @@
+% $Header: /cvsroot/latex-beamer/latex-beamer/solutions/conference-talks/conference-ornate-20min.en.tex,v 1.7 2007/01/28 20:48:23 tantau Exp $
+
+\documentclass{beamer}
+
+\usepackage{url}
+\makeatletter
+\def\url@leostyle{%
+  \@ifundefined{selectfont}{\def\UrlFont{\sf}}{\def\UrlFont{\tiny\ttfamily}}}
+\makeatother
+%% Now actually use the newly defined style.
+\urlstyle{leo}
+
+
+% This file is a solution template for:
+
+% - Talk at a conference/colloquium.
+% - Talk length is about 20min.
+% - Style is ornate.
+
+
+
+% Copyright 2004 by Till Tantau <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)
+}
+
+
+\usepackage[english]{babel}
+% or whatever
+
+\usepackage[latin1]{inputenc}
+% or whatever
+
+\usepackage{times}
+\usepackage[T1]{fontenc}
+% Or whatever. Note that the encoding and the font should match. If T1
+% does not look nice, try deleting the line with the fontenc.
+
+
+\title{osmocom.org - FOSS for mobile comms}
+
+\subtitle
+{community based Free / Open Source Software for communications}
+
+\author{Harald Welte <laforge@gnumonks.org>}
+
+\institute
+{gnumonks.org\\hmw-consulting.de\\sysmocom GmbH}
+% - Use the \inst command only if there are several affiliations.
+% - Keep it simple, no one is interested in your street address.
+
+\date[] % (optional, should be abbreviation of conference name)
+{August 3, 2013 / COSCUP / Taipei}
+% - 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{Communications}
+% 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}
+
+\begin{frame}{Outline}
+  \tableofcontents[hideallsubsections]
+  % You might wish to add the option [pausesections]
+\end{frame}
+
+
+% Structuring a talk is a difficult task and the following structure
+% may not be suitable. Here are some rules that apply for this
+% solution: 
+
+% - Exactly two or three sections (other than the summary).
+% - At *most* three subsections per section.
+% - Talk about 30s to 2min per frame. So there should be between about
+%   15 and 30 frames, all told.
+
+% - A conference audience is likely to know very little of what you
+%   are going to talk about. So *simplify*!
+% - In a 20min talk, getting the main ideas across is hard
+%   enough. Leave out details, even if it means being less precise than
+%   you think necessary.
+% - If you omit details that are vital to the proof/implementation,
+%   just say so once. Everybody will be happy with that.
+
+\begin{frame}{About the speaker}
+\begin{itemize}
+	\item Using + toying with Linux since 1994
+	\item Kernel / bootloader / driver / firmware development since 1999
+	\item IT security expert, focus on network protocol security
+	\item Former core developer of Linux packet filter netfilter/iptables
+	\item Board-level Electrical Engineering
+	\item Always looking for interesting protocols (RFID, DECT, GSM)
+	\item OpenEXZ, OpenPCD, Openmoko, OpenBSC, OsmocomBB, OsmoSGSN
+\end{itemize}
+\end{frame}
+
+
+\section{Researching communications systems}
+
+\subsection{The Rolle of FOSS}
+
+\begin{frame}{Research in TCP/IP/Ethernet}
+Assume you want to do some research in the TCP/IP/Ethernet
+communications area,
+\begin{itemize}
+	\item you use off-the-shelf hardware (x86, Ethernet card)
+	\item you start with the Linux / *BSD stack
+	\item you add the instrumentation you need
+	\item you make your proposed modifications
+	\item you do some testing
+	\item you write your paper and publish the results
+\end{itemize}
+\end{frame}
+
+\begin{frame}{Research in (mobile) communications}
+Assume it is before 2009 (before Osmocom) and you want to do some research in mobile comms
+\begin{itemize}
+	\item there is no FOSS implementation of any of the protocols or
+		functional entities
+	\item almost no university has a test lab with the required
+		equipment.  And if they do, it is black boxes that you
+		cannot modify according to your research requirements
+	\item you turn away at that point, or you cannot work on really
+		exciting stuff
+	\item only chance is to partner with commercial company, who
+		puts you under NDAs and who wants to profit from your
+		research
+\end{itemize}
+\end{frame}
+
+\begin{frame}{GSM/3G vs. Internet}
+\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}
+
+\begin{frame}{GSM is more than phone calls}
+Listening to phone calls is boring...
+\begin{itemize}
+	\item Machine-to-Machine (M2M) communication
+	\begin{itemize}
+		\item BMW can unlock/open your car via GSM
+		\item Alarm systems often report via GSM
+		\item Smart Metering (Utility companies)
+		\item GSM-R / European Train Control System
+		\item Vending machines report that their cash box is full
+		\item Control if wind-mills supply power into the grid
+		\item Transaction numbers for electronic banking
+	\end{itemize}
+\end{itemize}
+\end{frame}
+
+\section{The Osmocom project}
+
+\begin{frame}{Osmocom / osmocom.org}
+\begin{itemize}
+	\item Osmocom == Open Soruce Mobile Communications
+	\item Classic collaborative, community-driven FOSS project
+	\item Gathers creative people who want to explore this
+		industry-dominated closed mobile communications world
+	\item communication via mailing lists, IRC
+	\item soure code in git, information in trac/wiki
+	\item http://osmocom.org/
+\end{itemize}
+\end{frame}
+
+\subsection{Osmocom sub-projects}
+
+\begin{frame}{OpenBSC}
+\begin{itemize}
+	\item first Osmocom project
+	\item Implements GSM A-bis interface towards BTS
+	\item Primarily supports sysmoBTS and ip.access nanoBTS
+	\item Limited support for some Siemens, Ericsson and Nokia BTS models
+	\item can implement only BSC function (osmo-bsc) or a fully
+		autonomous self-contained GSM network (osmo-nitb) that
+		requires no external MSC/VLR/AUC/HLR/EIR
+	\item deployed in > 200 installations world-wide, commercial and
+		research
+\end{itemize}
+\end{frame}
+
+\begin{frame}{First OpenBSC test installation (HAR 2009)}
+\begin{figure}[h]
+\centering
+\includegraphics[width=60mm]{bts_tree_full.jpg}
+\end{figure}
+\end{frame}
+
+\begin{frame}{OpenBSC use cases}
+\begin{itemize}
+	\item can be used either as pure BSC (A-over-IP)
+	\begin{itemize}
+		\item suitable for operators with existing core (MSC/VLR/HLR/AUC)
+		\item easy integration into existing infrastructure
+	\end{itemize}
+	\item or as NITB (network in the box)
+	\begin{itemize}
+		\item suitable for private / autonomous small networks (PBX style)
+		\item no dependency on any other external component
+		\item connect to the outside via ISDN or VoIP (using
+			linux call router)
+		\item off-shore drilling rigs, underground mining, alternative to PMR
+	\end{itemize}
+\end{itemize}
+\end{frame}
+
+
+\begin{frame}{OsmoSGSN / OpenGGSN}
+\begin{itemize}
+	\item extends the OpenBSC based network from GSM to GPRS/EDGE by
+		implementing the classic SGSN and GGSN functional
+		entities
+	\item OpenGGSN existed already, but was abandoned by original
+		author
+	\item Works only with BTSs that provides Gb interface, like
+		sysmoBTS or nanoBTS
+	\item Suitable for research only, not production ready
+\end{itemize}
+\end{frame}
+
+\begin{frame}{OsmoSGSN / OpenGGSN use cases}
+\begin{itemize}
+	\item Testing of M2M devices using your own BTS+SGSN+GGSN
+	\item Mobile malware research (analyze cellular data traffic of
+		apps)
+	\item Any type of GPRS related research
+	\item Teaching, training on mobile data protocols/interfaces
+		(RLC, MAC, LLC, SNDCP, BSSGP, NS, GTP, etc.)
+\end{itemize}
+\end{frame}
+
+\begin{frame}{OsmocomBB}
+\begin{itemize}
+	\item Full baseband processor firmware implementation of a mobile phone (MS)
+	\item We re-use existing phone hardware and re-wrote the L1, L2,
+		L3 and higher level logic
+	\item Higher layers reuse code from OpenBSC wherever possible
+	\item Used in a number of universities and other research contexts
+\end{itemize}
+\begin{figure}[h]
+\centering
+\includegraphics[width=50mm]{c123_pcb.jpg}
+\end{figure}
+\end{frame}
+
+\begin{frame}{OsmocomBB use cases}
+\begin{itemize}
+	\item Applied security research on Infrastructure
+	\begin{itemize}
+		\item Fuzzing / exploiting of protocol parsers on network side
+		\item RACH denial of service
+		\item Check if networks use random padding
+		\item Detect IMSI catchers or other fals base stations
+		\item Assess GSM network (operator) security level
+	\end{itemize}
+	\item Study + learn how a GSM stack / phone work
+	\item Protocol tracing of your own transactions with the network
+\end{itemize}
+\end{frame}
+
+\begin{frame}{OsmoBTS}
+\begin{itemize}
+	\item OpenBSC/OsmoNITB takes care of BTS and higher elements
+	\item OsmoBTS implements a BTS with A-bis/IP back-haul to OpenBSC
+	\item Developed primarily for sysmoBTS hardware
+	\item Support for other hardware is ongoing in the community
+\end{itemize}
+\end{frame}
+
+\begin{frame}{OsmocomTETRA}
+\begin{itemize}
+	\item SDR implementation of a TETRA radio-modem (PHY/MAC)
+	\item Rx is fully implemented, Tx only partial
+	\item Can be used for air interface interception
+	\item Accompanied by wireshark dissectors for the TETRA protocol
+		stack
+\end{itemize}
+\end{frame}
+
+\begin{frame}{OsmocomTETRA use cases}
+\begin{itemize}
+	\item Analysis/assessment of TETRA network security
+	\item Learn how TETRA works on teh lowest levels (L1, MAC, L3)
+	\item Protocol analysis / sniffing / intercepting unencrypted networks
+\end{itemize}
+\end{frame}
+
+\begin{frame}{OsmocomGMR}
+\begin{itemize}
+	\item ETSI GMR (Geo Mobile Radio) is "GSM for satellites"
+	\item GMR-1 used by Thuraya satellite network
+	\item OsmocomGMR implements SDR based radiomodem + PHY/MAC (Rx)
+	\item Partial wireshark dissectors for the protocol stack
+	\item Reverse engineered implementation of GMR-A5 crypto
+	\item Speech codec is proprietary, still needs reverse engineering
+\end{itemize}
+\end{frame}
+
+\begin{frame}{OsmocomGMR use cases}
+\begin{itemize}
+	\item Analysis/assessment of GMR/Thuraya security (there is none)
+	\item Learn and understnad how satellite telephony L1 and protocol work
+	\item Actual interception of SMS + data
+	\item Voice still difficult due to proprietary undocumented codec
+\end{itemize}
+\end{frame}
+
+\begin{frame}{OsmocomDECT}
+\begin{itemize}
+	\item ETSI DECT (Digital European Cordless Telephony) is used in
+		millions of cordless phones
+	\item deDECTed.org project started with open source protocol
+		analyzers and demonstrated many vulnerabilities
+	\item OsmocomDECT is an implementation of the DECT hardware
+		drivers and protocols for the Linux kernel
+	\item Integrates with Asterisk
+\end{itemize}
+\end{frame}
+
+\begin{frame}{OsmocomOP25}
+\begin{itemize}
+	\item APCO25 is Professional PMR system used in the US
+	\item Can be compared to TETRA in Europe
+	\item OsmocomOP25 is again SDR receiver + protocol analyzer
+	\item Use cases like OsmocomTETRA
+\end{itemize}
+\end{frame}
+
+\begin{frame}{OsmoSDR}
+\begin{itemize}
+	\item small, low-power / low-cost USB SDR hardware
+	\item higher bandwidth than FunCubeDonglePro
+	\item much lower cost than USRP
+	\item Open Hardware
+	\item Developer units available
+\end{itemize}
+\begin{figure}[h]
+\centering
+\includegraphics[width=70mm]{osmosdr.jpg}
+\end{figure}
+\end{frame}
+
+\begin{frame}{rtl-sdr}
+\begin{itemize}
+	\item re-purpose a USD 20 DVB-T USB dongle based on Realtek chipset
+	\item deactivate/bypass DVB-T demodulator / MPEG decoder
+	\item pass baseband samples via high-speed USB into PC
+	\item no open hardware,  but Free Software
+\end{itemize}
+\begin{figure}[h]
+\centering
+\includegraphics[width=70mm]{ezcap_top.jpg}
+\end{figure}
+\end{frame}
+
+\begin{frame}{OsmocomSIMTRACE}
+\begin{itemize}
+	\item Hardware protocol tracer for SIM - phone interface
+	\item Wireshark protocol dissector for SIM-ME protocol (TS 11.11)
+	\item Can be used for SIM Application development / analysis
+	\item Also capable of SIM card emulation and man-in-the-middle attacks
+\end{itemize}
+\begin{figure}[h]
+\centering
+\includegraphics[width=60mm]{simtrace_and_phone.jpg}
+\end{figure}
+\end{frame}
+
+\begin{frame}{Osmo-E1-Xcvr}
+\begin{itemize}
+	\item Open hardware project for interfacing E1 lines with
+		microcontrollers
+	\item So far no software/firmware yet, stay tuned!
+\end{itemize}
+\begin{figure}[h]
+\centering
+\includegraphics[width=60mm]{osmo-e1-xcvr.jpg}
+\end{figure}
+\end{frame}
+
+\begin{frame}{osmo\_ss7, osmo\_map, signerl}
+\begin{itemize}
+	\item Erlang-language SS7 implementation (MTP3, SCCP, TCAP, MAP)
+	\item SIGTRAN variants (M2PA, M2UA, M3UA and SUA)
+	\item Enables us to interface with GSM/UMTS inter-operator core network
+	\item Already used in production in some really nasty
+		special-purpose protocol translators (think of NAT for
+		SS7)
+\end{itemize}
+\end{frame}
+
+\begin{frame}{osmo\_ss7, osmo\_map, signerl use cases}
+\begin{itemize}
+	\item Implement GSM/3G core network elements (HLR, SCF, etc.)
+	\item Applications that interact with GSM/3G core network
+		elements
+	\item Mostly useful for small MVNOs or other operators who have
+		requirements that cannot be fulfilled with off-the-shelf
+		proprietary equipment.
+\end{itemize}
+\end{frame}
+
+\begin{frame}{More Osmocom projects}
+\begin{itemize}
+	\item Have a look at http://git.osmcoom.org/
+	\item 79 public git repositories / projects at this point
+	\item way too many to cover here in this talk
+	\item Often RTFS, no manual/docs
+\end{itemize}
+\end{frame}
+
+\section{Non-osmocom projects}
+
+\begin{frame}{The OpenBTS Um - SIP bridge}
+\begin{itemize}
+	\item OpenBTS is a SDR implementation of GSM Um radio interface
+	\item directly bridges to SIP/RTP, no A-bis/BSC/A/MSC
+	\item suitable for research on air interface, but very different
+		from traditional GSM networks
+	\item work is being done to make it interoperable with OpenBSC
+\end{itemize}
+\end{frame}
+
+\begin{frame}{airprobe.org}
+\begin{itemize}
+	\item SDR implementation of Um sniffer
+	\item suitable for receiving GSM Um downlink and uplink
+	\item predates all of the other projects
+	\item more or less abandoned at this point
+\end{itemize}
+\end{frame}
+
+\begin{frame}{UmTRX}
+\begin{itemize}
+	\item SDR hardware, specifically for GSM Um air interface
+	\item can be used with OpenBTS and soon: OsmoTRX / OsmoBTS
+	\item Oepen Hardware Design
+	\item http://code.google.com/p/umtrx/
+\end{itemize}
+\end{frame}
+
+\begin{frame}{xgoldmon}
+\begin{itemize}
+	\item extract all GSM/GPRS and even 3G protocol messages from
+		your Samsung Galaxy 2, Galaxy 3, Note 2, Nexus phone via USB
+	\item feed them into your PC running xgoldmon
+	\item forward them from xgoldmon via GSMTAP into wireshark
+	\item https://github.com/2b-as/xgoldmon
+\end{itemize}
+\end{frame}
+
+\begin{frame}{sysmocom GmbH}{systems for mobile communications}
+\begin{itemize}
+	\item small company, started by two Osmocom developers in Berlin
+	\item provides commercial R\&d and support for professional
+		users of Osmocom software
+	\item develops + sells products like sysmoBTS (inexpensive,
+		small-form-factor, OpenBSC compatible BTS)
+	\item runs a small webshop for Osmocom related hardware items
+		like SIMtrace
+\end{itemize}
+\end{frame}
+
+
+\subsection{Future projects}
+
+\begin{frame}{Where do we go from here?}
+\begin{itemize}
+	\item Dieter Spaar has been working with 3G NodeBs (Ericsson,
+		Nokia) to be able to run our own RNC
+	\item Research into intercepting microwave back-haul links
+	\item Research into GPS simulation / transmission / faking
+	\item Port of OsmocomBB to other baseband chips
+	\item Low-level control from Free Software on a 3G/3.5G phone
+	\item Re-using femtocells in creative ways
+	\item Proprietary PMR systems
+\end{itemize}
+\end{frame}
+
+\begin{frame}{Call for contributions}
+\begin{itemize}
+	\item Don't you agree that classic Internet/TCP/IP is boring and
+		has been researched to death?
+	\item There are many more communications systems out there
+	\item Never trust the industry, they only care about selling
+		their stuff
+	\item Lets democratize access to those communication systems
+	\item Become a contributor or developer today!
+	\item Join our mailing lists, use/improve our code
+	\item for OsmocomBB you only need a EUR 20 phone to start
+\end{itemize}
+\end{frame}
+
+\begin{frame}{Thanks}
+I'd like to thank the many Osmocom developers and contributors,
+especially
+\begin{itemize}
+	\item Dieter Spaar
+	\item Holger Freyther
+	\item Andreas Eversberg
+	\item Sylvain Munaut
+	\item On-Waves e.h.f
+\end{itemize}
+\end{frame}
+
+
+\begin{frame}{Thanks}
+Thanks for your attention.  I hope we have time for Q\&A.
+\end{frame}
+
+
+\end{document}
diff --git a/2013/osmocom-coscup2013/osmosdr.jpg b/2013/osmocom-coscup2013/osmosdr.jpg
new file mode 100644
index 0000000..730b579
--- /dev/null
+++ b/2013/osmocom-coscup2013/osmosdr.jpg
diff --git a/2013/osmocom-coscup2013/simtrace_and_phone.jpg b/2013/osmocom-coscup2013/simtrace_and_phone.jpg
new file mode 100644
index 0000000..3fddf27
--- /dev/null
+++ b/2013/osmocom-coscup2013/simtrace_and_phone.jpg
diff --git a/2013/osmocom-hitcon2013/bts_tree_full.jpg b/2013/osmocom-hitcon2013/bts_tree_full.jpg
new file mode 100644
index 0000000..6b5c5e8
--- /dev/null
+++ b/2013/osmocom-hitcon2013/bts_tree_full.jpg
diff --git a/2013/osmocom-hitcon2013/c123_pcb.jpg b/2013/osmocom-hitcon2013/c123_pcb.jpg
new file mode 100644
index 0000000..a9f24fc
--- /dev/null
+++ b/2013/osmocom-hitcon2013/c123_pcb.jpg
diff --git a/2013/osmocom-hitcon2013/osmo-e1-xcvr.jpg b/2013/osmocom-hitcon2013/osmo-e1-xcvr.jpg
new file mode 100644
index 0000000..8802e08
--- /dev/null
+++ b/2013/osmocom-hitcon2013/osmo-e1-xcvr.jpg
diff --git a/2013/osmocom-hitcon2013/osmocom-security.pdf b/2013/osmocom-hitcon2013/osmocom-security.pdf
new file mode 100644
index 0000000..ff6d1bb
--- /dev/null
+++ b/2013/osmocom-hitcon2013/osmocom-security.pdf
diff --git a/2013/osmocom-hitcon2013/osmocom-security.snm b/2013/osmocom-hitcon2013/osmocom-security.snm
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/2013/osmocom-hitcon2013/osmocom-security.snm
diff --git a/2013/osmocom-hitcon2013/osmocom-security.tex b/2013/osmocom-hitcon2013/osmocom-security.tex
new file mode 100644
index 0000000..7eed4f4
--- /dev/null
+++ b/2013/osmocom-hitcon2013/osmocom-security.tex
@@ -0,0 +1,700 @@
+% $Header: /cvsroot/latex-beamer/latex-beamer/solutions/conference-talks/conference-ornate-20min.en.tex,v 1.7 2007/01/28 20:48:23 tantau Exp $
+
+\documentclass{beamer}
+
+\usepackage{url}
+\makeatletter
+\def\url@leostyle{%
+  \@ifundefined{selectfont}{\def\UrlFont{\sf}}{\def\UrlFont{\tiny\ttfamily}}}
+\makeatother
+%% Now actually use the newly defined style.
+\urlstyle{leo}
+
+
+% This file is a solution template for:
+
+% - Talk at a conference/colloquium.
+% - Talk length is about 20min.
+% - Style is ornate.
+
+
+
+% Copyright 2004 by Till Tantau <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)
+}
+
+
+\usepackage[english]{babel}
+% or whatever
+
+\usepackage[latin1]{inputenc}
+% or whatever
+
+\usepackage{times}
+\usepackage[T1]{fontenc}
+% Or whatever. Note that the encoding and the font should match. If T1
+% does not look nice, try deleting the line with the fontenc.
+
+
+\title{osmocom.org - FOSS for mobile comms}
+
+\subtitle
+{Free Software Tools for GSM Security Research}
+
+\author{Harald Welte <laforge@gnumonks.org>}
+
+\institute
+{osmocom.org\\sysmocom GmbH}
+% - Use the \inst command only if there are several affiliations.
+% - Keep it simple, no one is interested in your street address.
+
+\date[] % (optional, should be abbreviation of conference name)
+{July 20, HITCON 2013 / Taipei}
+% - 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{Communications}
+% 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}
+
+\begin{frame}{Outline}
+  \tableofcontents[hideallsubsections]
+  % You might wish to add the option [pausesections]
+\end{frame}
+
+
+% Structuring a talk is a difficult task and the following structure
+% may not be suitable. Here are some rules that apply for this
+% solution: 
+
+% - Exactly two or three sections (other than the summary).
+% - At *most* three subsections per section.
+% - Talk about 30s to 2min per frame. So there should be between about
+%   15 and 30 frames, all told.
+
+% - A conference audience is likely to know very little of what you
+%   are going to talk about. So *simplify*!
+% - In a 20min talk, getting the main ideas across is hard
+%   enough. Leave out details, even if it means being less precise than
+%   you think necessary.
+% - If you omit details that are vital to the proof/implementation,
+%   just say so once. Everybody will be happy with that.
+
+\section{Introduction}
+
+\subsection{About}
+
+\begin{frame}{About the speaker}
+\begin{itemize}
+	\item Linux Kernel / bootloader / driver / firmware development since 1999
+	\item IT security expert, focus on network protocol security
+	\item Former core developer of Linux packet filter netfilter/iptables
+	\item Board-level Electrical Engineering
+	\item Always looking for interesting protocols (RFID, DECT, GSM)
+	\item OpenEXZ, OpenPCD, Openmoko, OpenBSC, OsmocomBB, OsmoSGSN
+\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}
+
+
+\section{Researching communications systems}
+
+\begin{frame}{Telco vs. Internet-driven IT security}
+mobile industry today has security practieses and procedures of the 20th century
+\begin{itemize}
+	\item no proper incident response on RAN/CN
+	\item no procedures for quick roll-out of new sw releases
+	\item no requirements for software-upgradeability
+	\item no interaction with hacker community
+	\item no packet filtering / DPI / IDS on signalling traffic
+	\item active hostility towards operators who want to do pentesting
+	\item attempts to use legal means to stop researchers from publishing their findings
+\end{itemize}
+this sounds like medieval times. We are in 2012 ?!?
+\end{frame}
+
+\subsection{Real-world quotes}
+
+\begin{frame}{Real-world quotes}
+The following slides indicate some quotes that I have heard over the
+last couple of years from my contacts inside the mobile industry.  They
+are not made up!
+\end{frame}
+
+
+\begin{frame}{Quote: Disclosure of Ki/K/OPC}
+"we are sending our IMSI+Key lists as CSV files to the SIM card supplier in China"
+\end{frame}
+
+\begin{frame}{Quote: RRLP}
+"RRLP? What is that? We never heard about it!"
+\end{frame}
+
+\begin{frame}{Quote: SIM OTA keys}
+"we have no clue what remote accessible (OTA) features our sim cards have or what kind of keys were used during provisioning"
+\end{frame}
+
+\begin{frame}{Quote: Malformed}
+"we have never tried to intentionally send any malformed message to any of our equipment"
+\end{frame}
+
+\begin{frame}{Quote: Roaming}
+"We are seeing TCAP/MAP related attacks/fraud from Operator XYZ in Pakistan.  However, it is more important that European travellers can roam into their network than it is for Pakistanis to roam into our network.  Can you see while the roaming agreement was only suspended for two days?"
+\end{frame}
+
+\begin{frame}{Quote: SIGTRAN IPsec}
+"we are unable to mandate from our roaming partners that SIGTRAN links shall always go through IPsec - we don't even know how to facilitate safe distribution of certificates between operators"
+\end{frame}
+
+\begin{frame}{Quote: NodeB / IPsec}
+"We mandated IPsec to be used for all of the (e)NodeB back-haul in our tender, the supplier still shipped equipment that didn't comply to it.  Do you think the CEO is going to cancel the contract with them for that?"
+\end{frame}
+
+\begin{frame}{Quote: Government / independent study}
+"Govt: We put out a tender for a study on overal operator network security in our country.  Everyone who put in a bid is economically affiliated or dependent on one of the operators or equipment suppliers, so we knew the results were not worth much."
+\end{frame}
+
+\begin{frame}{Quote: Technical Staff}
+"15 years ago we still had staff that understood all those details.  But today, you know, those experts are expensive - we laid them off."
+\end{frame}
+
+\begin{frame}{Quote: Baseband chip vendor}
+"We have no clue what version of our protocol stack with what modifications are shipped in which particular phones, or if/when the phone makers distribute updates to the actual phone population"
+\end{frame}
+
+
+\subsection{The Rolle of FOSS}
+
+\begin{frame}{Research in TCP/IP/Ethernet}
+Assume you want to do some research in the TCP/IP/Ethernet
+communications area,
+\begin{itemize}
+	\item you use off-the-shelf hardware (x86, Ethernet card)
+	\item you start with the Linux / *BSD stack
+	\item you add the instrumentation you need
+	\item you make your proposed modifications
+	\item you do some testing
+	\item you write your paper and publish the results
+\end{itemize}
+\end{frame}
+
+\begin{frame}{Research in (mobile) communications}
+Assume it is before 2009 (before Osmocom) and you want to do some research in mobile comms
+\begin{itemize}
+	\item there is no FOSS implementation of any of the protocols or
+		functional entities
+	\item almost no university has a test lab with the required
+		equipment.  And if they do, it is black boxes that you
+		cannot modify according to your research requirements
+	\item you turn away at that point, or you cannot work on really
+		exciting stuff
+	\item only chance is to partner with commercial company, who
+		puts you under NDAs and who wants to profit from your
+		research
+\end{itemize}
+\end{frame}
+
+\begin{frame}{GSM/3G vs. Internet}
+\begin{itemize}
+	\item Observation
+	\begin{itemize}
+		\item Both GSM/3G and TCP/IP protocol specs are publicly available
+		\item The Internet protocol stack (Ethernet/Wifi/TCP/IP) receives lots of scrutiny
+		\item GSM networks are as widely deployed as the Internet
+		\item Yet, GSM/3G protocols receive no such scrutiny!
+	\end{itemize}
+	\item There are reasons for that:
+	\begin{itemize}
+		\item GSM industry is extremely closed (and closed-minded)
+		\item Only about 4 closed-source protocol stack implementations
+		\item GSM chipset makers never release any hardware documentation
+	\end{itemize}
+\end{itemize}
+\end{frame}
+
+\subsection{The closed GSM industry}
+
+\begin{frame}{The closed GSM industry}{Handset manufacturing side}
+\begin{itemize}
+	\item Only very few companies build GSM/3.5G baseband chips today
+	\begin{itemize}
+		\item Those companies buy the operating system kernel and the protocol stack from third parties
+	\end{itemize}
+	\item Only very few handset makers are large enough to become a customer
+	\begin{itemize}
+		\item Even they only get limited access to hardware documentation
+		\item Even they never really get access to the firmware source
+	\end{itemize}
+\end{itemize}
+\end{frame}
+
+\begin{frame}{The closed GSM industry}{Network manufacturing side}
+\begin{itemize}
+	\item Only very few companies build GSM network equipment
+	\begin{itemize}
+		\item Basically only Ericsson, Nokia-Siemens, Alcatel-Lucent and Huawei
+		\item Exception: Small equipment manufacturers for picocell / nanocell / femtocells / measurement devices and law enforcement equipment
+	\end{itemize}
+	\item Only operators buy equipment from them
+	\item Since the quantities are low, the prices are extremely high
+	\begin{itemize}
+		\item e.g. for a BTS, easily 10-40k EUR
+	\end{itemize}
+\end{itemize}
+\end{frame}
+
+\begin{frame}{The closed GSM industry}{Operator side}
+\begin{itemize}
+	\item Operators are mainly banks today
+	\item Typical operator outsources
+	\begin{itemize}
+		\item Network planning / deployment / servicing
+		\item Even Billing!
+	\end{itemize}
+	\item Operator just knows the closed equipment as shipped by manufacturer
+	\item Very few people at an operator have knowledge of the protocol beyond what's needed for operations and maintenance
+\end{itemize}
+\end{frame}
+
+\begin{frame}{GSM is more than phone calls}
+Listening to phone calls is boring...
+\begin{itemize}
+	\item Machine-to-Machine (M2M) communication
+	\begin{itemize}
+		\item BMW can unlock/open your car via GSM
+		\item Alarm systems often report via GSM
+		\item Smart Metering (Utility companies)
+		\item GSM-R / European Train Control System
+		\item Vending machines report that their cash box is full
+		\item Control if wind-mills supply power into the grid
+		\item Transaction numbers for electronic banking
+	\end{itemize}
+\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}{The closed GSM industry}{My self-proclaimed mission}
+Mission: Bring TCP/IP/Internet security knowledge to GSM
+\begin{itemize}
+	\item Create tools to enable independent/public IT Security community to examine GSM
+	\item Try to close the estimated 10 year gap between the state of security technology on the Internet vs. GSM networks
+	\begin{itemize}
+		\item Industry thinks in terms of {\em walled garden} and {\em phones behaving like specified}
+		\item No proper incident response strategies!
+		\item No packet filters, firewalls, intrusion detection on GSM protocol level
+		\item General public assumes GSM networks are safer than Internet
+	\end{itemize}
+\end{itemize}
+\end{frame}
+
+\section{Bootstrapping Osmocom}
+
+\begin{frame}
+To actually do research on GSM, we need
+\begin{itemize}
+	\item detailed knowledge on the architecture and protocol stack
+	\item suitable hardware (there's no PHY/MAC only device like
+		Ethernet MAC)
+	\item a Free / Open Source Software implementation of at least
+		parts of the protocol stack
+\end{itemize}
+\end{frame}
+
+\begin{frame}{Bootstrapping GSM Research}{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 Publicly 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}{Bootstrapping GSM research}{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 BTS equipment is available, much easier/faster progress
+	\end{itemize}
+\end{itemize}
+\end{frame}
+
+\begin{frame}{Bootstrapping GSM research}{The bootstrapping process}
+\begin{itemize}
+	\item Read GSM specs (> 1000 PDF documents, each hundreds of pages)
+	\item Gradually grow knowledge about the protocols
+	\item Obtain actual GSM network equipment (BTS)
+	\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 Osmocom project}
+
+\begin{frame}{Osmocom / osmocom.org}
+\begin{itemize}
+	\item Osmocom == Open Soruce Mobile Communications
+	\item Classic collaborative, community-driven FOSS project
+	\item Gathers creative people who want to explore this
+		industry-dominated closed mobile communications world
+	\item communication via mailing lists, IRC
+	\item soure code in git, information in trac/wiki
+	\item http://osmocom.org/
+\end{itemize}
+\end{frame}
+
+\subsection{Osmocom sub-projects}
+
+\begin{frame}{OpenBSC}
+\begin{itemize}
+	\item first Osmocom project
+	\item Implements GSM A-bis interface towards BTS
+	\item Supports Siemens, ip.access, Ericsson, Nokia and sysmocom BTS
+	\item can implement only BSC function (osmo-bsc) or a fully
+		autonomous self-contained GSM network (osmo-nitb) that
+		requires no external MSC/VLR/AUC/HLR/EIR
+	\item deployed in > 200 installations world-wide, commercial and
+		research
+\end{itemize}
+\end{frame}
+
+\begin{frame}{OpenBSC test installation}
+\begin{figure}[h]
+\centering
+\includegraphics[width=60mm]{bts_tree_full.jpg}
+\end{figure}
+\end{frame}
+
+\begin{frame}{OsmoSGSN / OpenGGSN}
+\begin{itemize}
+	\item extends the OpenBSC based network from GSM to GPRS/EDGE by
+		implementing the classic SGSN and GGSN functional
+		entities
+	\item OpenGGSN existed already, but was abandoned by original
+		author
+	\item Works only with BTSs that provides Gb interface, like
+		ip.access nanoBTS
+	\item Suitable for research only, not production ready
+\end{itemize}
+\end{frame}
+
+\begin{frame}{OsmocomBB}
+\begin{itemize}
+	\item Full baseband processor firmware implementation of a mobile phone (MS)
+	\item We re-use existing phone hardware and re-wrote the L1, L2,
+		L3 and higher level logic
+	\item Higher layers reuse code from OpenBSC wherever possible
+	\item Used in a number of universities and other research contexts
+\end{itemize}
+\begin{figure}[h]
+\centering
+\includegraphics[width=50mm]{c123_pcb.jpg}
+\end{figure}
+\end{frame}
+
+\begin{frame}{OsmocomTETRA}
+\begin{itemize}
+	\item SDR implementation of a TETRA radio-modem (PHY/MAC)
+	\item Rx is fully implemented, Tx only partial
+	\item Can be used for air interface interception
+	\item Accompanied by wireshark dissectors for the TETRA protocol
+		stack
+\end{itemize}
+\end{frame}
+
+\begin{frame}{OsmocomGMR}
+\begin{itemize}
+	\item ETSI GMR (Geo Mobile Radio) is "GSM for satellites"
+	\item GMR-1 used by Thuraya satellite network
+	\item OsmocomGMR implements SDR based radiomodem + PHY/MAC (Rx)
+	\item Partial wireshark dissectors for the protocol stack
+	\item Reverse engineered implementation of GMR-A5 crypto
+	\item Speech codec is proprietary, still needs reverse engineering
+\end{itemize}
+\end{frame}
+
+\begin{frame}{OsmocomDECT}
+\begin{itemize}
+	\item ETSI DECT (Digital European Cordless Telephony) is used in
+		millions of cordless phones
+	\item deDECTed.org project started with open source protocol
+		analyzers and demonstrated many vulnerabilities
+	\item OsmocomDECT is an implementation of the DECT hardware
+		drivers and protocols for the Linux kernel
+	\item Integrates with Asterisk
+\end{itemize}
+\end{frame}
+
+\begin{frame}{OsmocomOP25}
+\begin{itemize}
+	\item APCO25 is Professional PMR system used in the US
+	\item Can be compared to TETRA in Europe
+	\item OsmocomOP25 is again SDR receiver + protocol analyzer
+\end{itemize}
+\end{frame}
+
+\begin{frame}{OsmoSDR}
+\begin{itemize}
+	\item small, low-power / low-cost USB SDR hardware
+	\item higher bandwidth than FunCubeDonglePro
+	\item much lower cost than USRP
+	\item Open Hardware
+	\item Board available to developers only (Firmware not finished)
+\end{itemize}
+\begin{figure}[h]
+\centering
+\includegraphics[width=70mm]{osmosdr.jpg}
+\end{figure}
+\end{frame}
+
+\begin{frame}{OsmocomSIMTRACE}
+\begin{itemize}
+	\item Hardware protocol tracer for SIM - phone interface
+	\item Wireshark protocol dissector for SIM-ME protocol (TS 11.11)
+	\item Can be used for SIM Application development / analysis
+	\item Also capable of SIM card emulation and man-in-the-middle attacks
+\end{itemize}
+\begin{figure}[h]
+\centering
+\includegraphics[width=60mm]{simtrace_and_phone.jpg}
+\end{figure}
+\end{frame}
+
+\begin{frame}{osmo-e1-xcvr}
+\begin{itemize}
+	\item Open hardware project for interfacing E1 lines with
+		microcontrollers
+	\item So far no software/firmware yet, stay tuned!
+\end{itemize}
+\begin{figure}[h]
+\centering
+\includegraphics[width=60mm]{osmo-e1-xcvr.jpg}
+\end{figure}
+\end{frame}
+
+\begin{frame}{osmo-bts-amp}
+\begin{itemize}
+	\item Open hardware project for a 2W PA, LNA and ceramic
+		duplexer to amplify small BTSs like ip.access nanoBTS
+	\item 2W may sound little, but from 200mW it's a factor of 10
+	\item Still much less than a regular macro cell, but more than a
+		picocell for indoor coverage
+	\item Scheamtics and Gerber files for the hardware available openly
+	\item small and compact form factor compared to large/bulky cavity duplexers
+\end{itemize}
+\end{frame}
+
+\begin{frame}{OsmoCOS}
+\begin{itemize}
+	\item Smartcards such as SIM/USIM cards, but actually any type
+		of chip/smartcards you can normally buy are proprietary
+		and closed, as chip makers never release manuals
+	\item Even if you write your own Card Operating System (COS),
+		normally you would have to put it in mask ROM, requiring
+		six or seven digit quantities as it basically would be
+		your own version of the silicon.
+	\item Thus, so far, all Smart Cards (even the OpenPGP Smart
+		Card) run proprietary software inside
+\end{itemize}
+\end{frame}
+
+\begin{frame}{OsmoCOS}
+\begin{itemize}
+	\item We found a Chinese smarcard chip maker (ChipCity) that
+		provided the programming manual to their chip without
+		NDA.  It has no ROM, but 256 kByte Flash and a known
+		ARM7TDMI core.
+	\item We started to write some low-level code like hardware
+		drivers and can now work on our own Card Operating
+		System
+	\item Progress is slow, due to many other projects and few
+		contributors
+\end{itemize}
+\end{frame}
+
+
+\begin{frame}{osmo\_ss7, osmo\_map, signerl}
+\begin{itemize}
+	\item Erlang-language SS7 implementation (MTP3, SCCP, TCAP, MAP)
+	\item Sigtran variants (M2PA, M2UA, M3UA and SUA)
+	\item Enables us to interface with GSM/UMTS inter-operator core network
+	\item Already used in production in some really nasty
+		special-purpose protocol translators (think of NAT for
+		SS7)
+\end{itemize}
+\end{frame}
+
+\subsection{Non-osmocom projects}
+
+\begin{frame}{The OpenBTS Um - SIP bridge}
+\begin{itemize}
+	\item OpenBTS is a SDR implementation of GSM Um radio interface
+	\item directly bridges to SIP/RTP, no A-bis/BSC/A/MSC
+	\item suitable for research on air interface, but very different
+		from traditional GSM networks
+	\item work is being done to make it interoperable with OpenBSC
+\end{itemize}
+\end{frame}
+
+\begin{frame}{airprobe.org}
+\begin{itemize}
+	\item SDR implementation of Um sniffer
+	\item suitable for receiving GSM Um downlink and uplink
+	\item predates all of the other projects
+	\item more or less abandoned at this point
+\end{itemize}
+\end{frame}
+
+\begin{frame}{sysmocom GmbH}{systems for mobile communications}
+\begin{itemize}
+	\item small company, started by two Osmocom developers in Berlin
+	\item provides commercial R\&d and support for professional
+		users of Osmocom software
+	\item develops its own producst like sysmoBTS (inexpensive,
+		small-form-factor, OpenBSC compatible BTS)
+	\item runs a small webshop for Osmocom related hardware like
+		OsmocomBB compatible phones, SIMtrace, etc.
+\end{itemize}
+\end{frame}
+
+
+\subsection{Future projects}
+
+\begin{frame}{Where do we go from here?}
+\begin{itemize}
+	\item Dieter Spaar has been working with 3G NodeBs (Ericsson,
+		Nokia) to be able to run our own RNC
+	\item Research into intercepting microwave back-haul links
+	\item Research into GPS simulation / transmission / faking
+	\item Port of OsmocomBB to other baseband chips
+	\item Low-level control from Free Software on a 3G/3.5G phone
+	\item Re-using femtocells in creative ways
+	\item Proprietary PMR systems
+\end{itemize}
+\end{frame}
+
+\begin{frame}{Call for contributions}
+\begin{itemize}
+	\item Don't you agree that classic Internet/TCP/IP is boring and
+		has been researched to death?
+	\item There are many more communications systems out there
+	\item Never trust the industry, they only care about selling
+		their stuff
+	\item Lets democratize access to those communication systems
+	\item Become a contributor or developer today!
+	\item Join our mailing lists, use/improve our code
+	\item for OsmocomBB you only need a EUR 20 phone to start
+\end{itemize}
+\end{frame}
+
+\begin{frame}{Thanks}
+I'd like to thank the many Osmocom developers and contributors,
+especially
+\begin{itemize}
+	\item Dieter Spaar
+	\item Holger Freyther
+	\item Andreas Eversberg
+	\item Sylvain Munaut
+	\item On-Waves e.h.f
+	\item NETZING AG
+\end{itemize}
+\end{frame}
+
+
+\begin{frame}{Thanks}
+Thanks for your attention.  I hope we have time for Q\&A.
+\end{frame}
+
+
+\end{document}
diff --git a/2013/osmocom-hitcon2013/osmosdr.jpg b/2013/osmocom-hitcon2013/osmosdr.jpg
new file mode 100644
index 0000000..730b579
--- /dev/null
+++ b/2013/osmocom-hitcon2013/osmosdr.jpg
diff --git a/2013/osmocom-hitcon2013/simtrace_and_phone.jpg b/2013/osmocom-hitcon2013/simtrace_and_phone.jpg
new file mode 100644
index 0000000..3fddf27
--- /dev/null
+++ b/2013/osmocom-hitcon2013/simtrace_and_phone.jpg