% $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}