1 files changed, 543 insertions, 0 deletions
diff --git a/2015/hardwear_io/keynote.tex.bak b/2015/hardwear_io/keynote.tex.bak
new file mode 100644
index 0000000..f27a4de
--- /dev/null
+++ b/2015/hardwear_io/keynote.tex.bak
@@ -0,0 +1,543 @@
+
+\newcommand{\degree}{\ensuremath{^\circ}}
+%\documentclass[handout]{beamer}
+\documentclass{beamer}
+
+% This file is a solution template for:
+
+% - Talk at a conference/colloquium.
+% - Talk length is about 20min.
+% - Style is ornate.
+
+
+
+% Copyright 2004 by Till Tantau <tantau@users.sourceforge.net>.
+%
+% In principle, this file can be redistributed and/or modified under
+% the terms of the GNU Public License, version 2.
+%
+% However, this file is supposed to be a template to be modified
+% for your own needs. For this reason, if you use this file as a
+% template and not specifically distribute it as part of a another
+% package/program, I grant the extra permission to freely copy and
+% modify this file as you see fit and even to delete this copyright
+% notice. 
+
+
+\mode<presentation>
+{
+  \usetheme{CambridgeUS}
+  \usecolortheme{whale}
+
+%\setbeamercolor{titlelike}{parent=palette primary,fg=black}
+\setbeamercolor{frametitle}{use=block title,fg=black,bg=block title.bg!10!bg}
+% from beamercolorthemeorchid.sty to make it look more like warsaw
+\setbeamercolor{block title}{use=structure,fg=white,bg=structure.fg!75!black}
+\setbeamercolor{block title alerted}{use=alerted text,fg=white,bg=alerted text.fg!75!black}
+\setbeamercolor{block title example}{use=example text,fg=white,bg=example text.fg!75!black}
+
+\setbeamercolor{block body}{parent=normal text,use=block title,bg=block title.bg!10!bg}
+\setbeamercolor{block body alerted}{parent=normal text,use=block title alerted,bg=block title alerted.bg!10!bg}
+\setbeamercolor{block body example}{parent=normal text,use=block title example,bg=block title example.bg!10!bg}
+
+
+
+  % or ...
+
+  %\setbeamercovered{transparent}
+  % or whatever (possibly just delete it)
+}
+
+\mode<handout>{
+	\usepackage{misc/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, tabsize=8}
+
+
+\title{Telecom Security - lessons learned (or not)?}
+
+\subtitle{Personal review on the last 7 years}
+
+\author{Harald~Welte}
+
+\institute{hardwear.io 2015 Keynote}
+
+% - Use the \inst command only if there are several affiliations.
+% - Keep it simple, no one is interested in your street address.
+
+\date[October 2015] % (optional, should be abbreviation of conference name)
+%{DeepSec Conference, November 2011, Vienna/Austria}
+% - Either use conference name or its abbreviation.
+% - Not really informative to the audience, more for people (including
+%   yourself) who are reading the slides online
+
+\subject{GSM}
+% This is only inserted into the PDF information catalog. Can be left
+% out. 
+
+
+
+% If you have a file called "university-logo-filename.xxx", where xxx
+% is a graphic format that can be processed by latex or pdflatex,
+% resp., then you can add a logo as follows:
+
+% \pgfdeclareimage[height=0.5cm]{university-logo}{university-logo-filename}
+% \logo{\pgfuseimage{university-logo}}
+
+
+
+% Delete this, if you do not want the table of contents to pop up at
+% the beginning of each subsection:
+%\AtBeginSubsection[]
+%{
+%  \begin{frame}<beamer>{Outline}
+%    \tableofcontents[currentsection,currentsubsection]
+%  \end{frame}
+%}
+
+
+% If you wish to uncover everything in a step-wise fashion, uncomment
+% the following command: 
+
+%\beamerdefaultoverlayspecification{<+->}
+
+
+\begin{document}
+
+\begin{frame}
+  \titlepage
+\end{frame}
+
+
+% Structuring a talk is a difficult task and the following structure
+% may not be suitable. Here are some rules that apply for this
+% solution: 
+
+% - Exactly two or three sections (other than the summary).
+% - At *most* three subsections per section.
+% - Talk about 30s to 2min per frame. So there should be between about
+%   15 and 30 frames, all told.
+
+% - A conference audience is likely to know very little of what you
+%   are going to talk about. So *simplify*!
+% - In a 20min talk, getting the main ideas across is hard
+%   enough. Leave out details, even if it means being less precise than
+%   you think necessary.
+% - If you omit details that are vital to the proof/implementation,
+%   just say so once. Everybody will be happy with that.
+
+\begin{frame}{About}
+\begin{itemize}
+	\item Linux Kernel / bootloader / driver / firmware developer since 1999
+	\item Former core developer of Linux packet filter netfilter/iptables
+	\item Comms / Network Security beyond TCP/IP
+	\begin{itemize}
+		\item OpenPCD, librfid, libmtrd, OpenBeacon
+		\item deDECTed.org project
+		\item Openmoko - FOSS smartphone with focus on security + owner device control
+		\item OpenBSC as network-side FOSS GSM Stack
+		\item OsmocomBB - device-side GSM protocol stack + baseband firmware
+	\end{itemize}
+	\item practical security research / testing on baseband side and
+		telecom infrastrucuture side
+	\item running a small team at sysmocom GmbH in Berlin, building
+		custom tailored mobile communications technology
+\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{Hardware Security?  Embedded Security?}
+
+\begin{frame}{Terminology / Perspective}
+\begin{itemize}
+	\item Many people speak about {\em hardware security} but mean {\em embedded systems security}
+	\item Embedded systems today (Android, etc.) are more complex
+		than PCs 10 years ago, so that's not primarily hardware security
+		but classic software security
+	\item Actual hardware security (tamper protection, avoiding
+		information leakage via side-channels, preventing
+		glitching, ...) is a very narrow topic, too
+	\item There's a lot of deeply-embedded firmware in between, what
+		I consider the area in biggest need of attention.
+\end{itemize}
+\end{frame}
+
+\section{Telecom Security}
+
+\begin{frame}{Mobile / Telecom Security}
+Main areas:
+\begin{itemize}
+	\item Phone-side baseband security
+	\item Air interface security
+	\item Radio Access Network Security
+	\item Back-haul network security
+	\item Core network security
+	\item Interconnect security
+\end{itemize}
+\end{frame}
+
+\begin{frame}{Phone-side baseband securty}
+\begin{itemize}
+	\item Since 2009, there are accessible tools to run your own
+		GSM/GPRS network to attack phones (OsmoBTS, OpenBSC,
+		OsmoSGSN, etc.)
+	\item baseband exploiting via malformed air interface messages
+		has been shown multiple times during the lat 5 years
+		(Ralf-Philipp Weinmann, others)
+	\item some stack/chip vendors started large-scale security code
+		audits, but by far not the entire industry
+	\item Still 100\% closed/proprietary environment with very
+		limited amount of research/attacks
+	\item Summary: Some improvement, but a long way to go
+\end{itemize}
+\end{frame}
+
+\begin{frame}{Air interface secrity}
+\begin{itemize}
+	\item Some operators have rolled out A5/3 encryption
+	\item Spec is broken and permits semi-active down-grade attacks
+	\item Industry took 7 years from A5/3 specification to first
+		interop test -> fail.
+	\item Summary: Nice try, but way too late and way too little
+\end{itemize}
+\end{frame}
+
+\begin{frame}{Radio Access Network Security}
+\begin{itemize}
+	\item Still no standard practise to do penetration testing ond
+BTS, NodeB, eNodeB
+	\item Equipment makers putting pressure on operator to cancel
+		already scheduled penetration tests!
+	\item Sometimes there are very basic / superficial tests as part
+		of a tender
+	\item No single known/documented/public case where an operator
+		or a equipment maker consistently pen-tested all of
+		their equipment
+	\item Summary: No visible change from 7 years ago
+\end{itemize}
+\end{frame}
+
+\begin{frame}{Core Network Security}
+\begin{itemize}
+	\item See Radio Access Netwok Security
+	\item Occasional pen-testing is performed and reveals horrible
+		implementation bugs in affected equipment
+		(MSC/VLR/HLR/SGSN)
+	\item Summary: No visible change from 7 years ago
+\end{itemize}
+As all core network elements are software implementatiosn these days,
+this is 100\% a software security topic!
+\end{frame}
+
+\begin{frame}{Interconnect Security}
+\begin{itemize}
+	\item Still no standard practise to have packet filter /
+		firewall / IDS / IPS like functionality for SS7/SIGTRAN
+		intefaces
+	\item I don't know of any operator who has any idea about what
+		actually is happening on their roaming interfaces
+	\item No matter how many clearly suspicious/malicous messages
+		you get from a roaming/interconnect partner, it triggers
+		no alarm
+	\item Only fraud gets detected from a certain scale onwards and
+		triggers investigation
+	\item Summary: No visible change from 7 years ago
+\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 / firewalls 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 2015 ?!?
+\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}
+
+\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}
+
+\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{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 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}{Long-term maintenance/upgradability}
+\begin{itemize}
+	\item Just having the capability for secure upgrades is only the
+		start
+	\item manufacturers need to commit to {\em decades} of security
+		fixes and updates for infrastructure parts that are
+		often used ten years and more.
+	\item unless that's required from befoe the purchase, they won't
+		do it
+	\item source code escrow mandatory in case of manufacturers
+		going out of business
+	\item Operators need to bring those requirements to their tenders!
+\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}{Summary}
+\begin{itemize}
+	\item A lot of tools are available for 7 years now
+	\item They have not been used as much as they could
+	\item Operators and Equipment makors still largely ignorant of
+		the problems
+	\item We are still at the tip of the iceberg
+\end{itemize}
+\end{frame}
+
+\begin{frame}{Thanks}
+Thanks for your attention.  I hope we have time for Q\&A.
+\end{frame}
+
+
+
+
+\end{document}