import of old now defunct presentation slides svn repo

3 files changed, 613 insertions, 0 deletions

diff --git a/2010/opening_closed_domains-foi2010/opening_closed_domains.pdf b/2010/opening_closed_domains-foi2010/opening_closed_domains.pdf
new file mode 100644
index 0000000..a8bd9f2
--- /dev/null
+++ b/2010/opening_closed_domains-foi2010/opening_closed_domains.pdf
diff --git a/2010/opening_closed_domains-foi2010/opening_closed_domains.snm b/2010/opening_closed_domains-foi2010/opening_closed_domains.snm
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/2010/opening_closed_domains-foi2010/opening_closed_domains.snm
diff --git a/2010/opening_closed_domains-foi2010/opening_closed_domains.tex b/2010/opening_closed_domains-foi2010/opening_closed_domains.tex
new file mode 100644
index 0000000..11182de
--- /dev/null
+++ b/2010/opening_closed_domains-foi2010/opening_closed_domains.tex
@@ -0,0 +1,613 @@
+% $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}
+
+% 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{Opening Closed Domains}
+
+\subtitle
+{To boldly go where no Free Software has gone before}
+
+\author{Harald Welte}
+
+\institute
+{gnumonks.org\\gpl-violations.org\\hmw-consulting.de\\OpenPCD, OpenMoko, OpenBSC, airprobe, OsmocomBB}
+% - Use the \inst command only if there are several affiliations.
+% - Keep it simple, no one is interested in your street address.
+
+\date[FOI/2010] % (optional, should be abbreviation of conference name)
+{FOI, May 2010, Varazdin/Croatia}
+% - 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{Free Software}
+% 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
+  % 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 + playing with Linux since 1994
+	\item Kernel / bootloader / driver / firmware development since 1999
+	\item IT security specialist, focus on network protocol security
+	\item Some board-level Electrical Engineering
+	\item Expert on Free Software licensing (gpl-violations.org)
+\end{itemize}
+\end{frame}
+
+\section{The FOSS success story}
+
+\subsection{FOSS is successful}
+
+\begin{frame}{FOSS is successful}
+Free and Open Source Software is successful
+\begin{itemize}
+	\item As a general purpose Operating System
+	\item In the Internet and Intranet server market, data centers
+	\item Networking infrastructure (routers, switches, WiFi AP)
+	\item Workstation / Desktop Market
+	\item Now Netbooks and MID's
+\end{itemize}
+Common denominator: (Inter)networked device
+\end{frame}
+
+\begin{frame}{Linux/FOSS and the Internet}
+\begin{itemize}
+	\item Imagine the state of the Linux kernel or other FOSS community without the Internet
+	\item Imagine working on a FOSS project without Internet access
+	\item Imagine even using a typical Linux system without Internet access (apt-get / yum / ...)
+\end{itemize}
+Thus, the current state of FOSS cannot be explained without the success of the Internet as communication and distribution medium.
+\end{frame}
+
+
+\begin{frame}{Why FOSS?}
+
+\begin{itemize}
+	\item Education
+	\begin{itemize}
+		\item Learning by reading the source code 
+	\end{itemize}
+	\pause
+	\item Security
+	\begin{itemize}
+		\item Review the source for back-doors, exploitable bugs, ...
+	\end{itemize}
+	\pause
+	\item Modification
+	\begin{itemize}
+		\item Experiments, Rapid prototyping, test of new ideas
+	\end{itemize}
+	\pause
+	\item Research possible for anyone
+	\pause
+	\item No vendor lock-in
+\end{itemize}
+\end{frame}
+
+\begin{frame}{So everything is great?}
+\begin{itemize}
+	\item We have multiple FOSS OS kernels
+	\item We have thousands of FOSS application programs
+	\item But: Many areas of computing typically have no FOSS at all, e.g.
+	\begin{itemize}
+		\item RFID protocols
+		\item DECT protocols
+		\item GSM/UMTS/CDMA protocols
+	\end{itemize}
+	\item Why those three examples?
+	\begin{itemize}
+		\item communications infrastructure is vital for everyone
+		\item big interest in verifiable/auditable privacy and security
+	\end{itemize}
+\end{itemize}
+\end{frame}
+
+\subsection{Why no FOSS in RFID, DECT and GSM}
+
+\begin{frame}{Why do you think there no FOSS?}{In RFID DECT and GSM}
+\begin{itemize}
+	\item No Open specifications for the protocols?
+	\pause
+	\begin{itemize}
+		\item WRONG: They're all publicly available to anyone
+	\end{itemize}
+	\pause
+	\item Too close to the hardware for FOSS developers
+	\pause
+	\begin{itemize}
+		\item WRONG: Look at FOSS softmac WiFi drivers
+	\end{itemize}
+	\pause
+	\item Hardware comes without specs
+	\pause
+	\begin{itemize}
+		\item TRUE, but look at reverse engineered 3D drivers
+	\end{itemize}
+	\pause
+	\item Too complex for FOSS developers
+	\pause
+	\begin{itemize}
+		\item WRONG, look at image processing or a TCP/IP protocol stack
+	\end{itemize}
+\end{itemize}
+\end{frame}
+
+\begin{frame}{Why there really is no FOSS?}{In RFID DECT and GSM}
+\begin{itemize}
+	\item RFID, DECT and GSM are hardware industry dominated areas
+	\begin{itemize}
+		\item If you think the software industry took 10-15 years to realize the benefits of FOSS, try to imagine how long it will take the hardware and semiconductor industry
+	\end{itemize}
+	\item Semiconductor industry actively keeping customers out and ensure their own turf is as big as possible
+	\item Chicken-and-egg Problem
+	\begin{itemize}
+		\item Too little people know about the protocol
+		\item Too little people are able to work on FOSS for it
+		\item Too little FOSS in that area
+		\item Nobody can experiment with / learn from FOSS -> Too little people know about the protocol
+	\end{itemize}
+\end{itemize}
+\end{frame}
+
+\begin{frame}{Why did I care?}
+\begin{itemize}
+	\item because I use cordless phones, cell-phones and RFID
+	\item because I know and am used to the benefits of FOSS for 15 years
+	\item because I don't see why I should give up that freedom when leaving the PC world
+\end{itemize}
+\end{frame}
+
+\begin{frame}{What could be done about that?}
+\begin{itemize}
+	\item Tackle those cases, one by one
+	\item Even a single person or a small group of people can make a huge difference
+	\item None of the projects that were started to change this involved more than a handful of people
+	\item There are no limits other than those of your mind!
+\end{itemize}
+\end{frame}
+
+
+\section{Case studies}
+
+\subsection{RFID}
+
+\begin{frame}{Why my interest in RFID?}
+\begin{itemize}
+	\item In November 2005, the German federal government has started to issue electronic passports with RFID interface.
+	\item All other EU member states were mandated to start issuing such passports no later than January 2007
+	\item Passports with RF interface raise lots of security questions
+	\begin{itemize}
+		\item Can you track/identify a person?
+		\item Can you determine his nationality?
+		\item Is the crypto used sufficient to prevent forgeries?
+	\end{itemize}
+	\item Thus, in 2005 I realized: FOSS for RFID protocol + ePassport application is needed
+\end{itemize}
+\end{frame}
+
+\begin{frame}{RFID products}{commercially available readers}
+\begin{itemize}
+	\item There are many RFID readers, some even with Linux drivers
+	\item All the protocol logic typically happens inside reader firmware
+	\item Application programmer presented with high-level API (PC/SC)
+	\item No way of doing actual practical protocol-level security research
+\end{itemize}
+\end{frame}
+
+\begin{frame}{RFID products}{Semiconductors}
+\begin{itemize}
+	\item Inside a reader, you need to somehow implement the radio layer
+	\item Typically, for mass-produced products, you use integrated circuits
+	\item The early RFID ASICs were dumb transceivers with no protocol logic
+	\item ASIC Documentation for NXP RC5xx {\em almost} openly available as 40-bit {\em encrypted} PDF
+	\item Some readers export those ASIC registers to PC software and run protocol stack in proprietary software
+\end{itemize}
+\end{frame}
+
+\begin{frame}{Project librfid}
+\begin{itemize}
+	\item Project librfid was born
+	\item The first FOSS protocol stack for RFID protocols
+	\begin{itemize}
+		\item ISO 14443-1,2,3,4 (specification public)
+		\item ISO 15693 (specification public)
+		\item Mifare Classic (vendor-specific proprietary system)
+	\end{itemize}
+	\item Mainly written by one person!
+\end{itemize}
+\end{frame}
+
+\begin{frame}{More FOSS for RFID}{OpenPCD}
+OpenPCD
+\begin{itemize}
+	\item Project OpenPCD developed an open hardware RFID reader
+	\item FOSS firmware, cross-compiled with avr-gcc, installed with FOSS flashing tools
+	\item librfid used as protocol stack either inside reader firmware or on host PC
+	\item R\&D done by three people!
+\end{itemize}
+OpenPICC
+\begin{itemize}
+	\item Project OpenPICC developed an open hardware RFID simulator
+	\item R\&D by three people in their spare time!
+\end{itemize}
+\end{frame}
+
+\begin{frame}{More FOSS for RFID}{OpenPCD}
+\begin{itemize}
+	\item Various groups started RFID security research on proprietary RFID standards
+	\begin{itemize}
+		\item Wrong security claims by RFID industry could be revealed as part of the Mifare Classic CRYPTO-1 reverse engineering in 2006
+		\item Industry was forced to introduce and use components with higher security
+		\item Still, e-payment and access control systems all over the world rely on broken-by-design, proprietary and small-keysize Mifare Classic CRYPTO1.  They deserve to be hacked, and the responsible IT managers deserve to be fired.
+		\item Watch 26C3 in four weeks: Yet another proprietary insecure system will die.
+	\end{itemize}
+\end{itemize}
+\end{frame}
+
+\subsection{DECT}
+
+\begin{frame}{DECT systems}{What they are}
+\begin{itemize}
+	\item DECT means Digital European Cordless Telephony
+	\item Is a standard used in large parts of the world for cordless telephony
+	\item Standardized at the ETSI, documents available to everyone
+	\item Authentication and Encryption algorithms kept secret
+	\item Typically, all you can buy is a black-box appliance consisting of phone + base station
+\end{itemize}
+\end{frame}
+
+\begin{frame}{DECT beyond just simple cordless phones}
+\begin{itemize}
+	\item DECT always supported the transmission of data, e.g. ISDN payloads
+	\item At some point, people wanted to use their DECT handset with VoIP
+	\item Companies started to sell PCMCIA, USB and PCI DECT adapters
+	\item DECT protocol stack is running inside proprietary windows software
+	\item DECT encryption implemented inside the DECT chipset silicon
+\end{itemize}
+\end{frame}
+
+\begin{frame}{First FOSS for DECT}
+\begin{itemize}
+	\item In order to do research on DECT, Open Source is needed
+	\item Group (later called deDECTed.org) formed doing reverse engineering of windows drivers
+	\item Started to implement FOSS driver for the hardware and Receive-only processing of DECT protocol stack
+	\item Was used by cryptographers as a toolbox to demonstrate that the DECT Security is not worth the paper it is printed on
+	\begin{itemize}
+		\item Problems in the protocol specification
+		\item Problems in the implementations (16bit random numbers?!?)
+	\end{itemize}
+\end{itemize}
+\end{frame}
+
+\begin{frame}{More FOSS for DECT}
+\begin{itemize}
+	\item Patrick McHardy (netfilter/iptables maintainer) starts a Linux kernel DECT stack
+	\item His experience in Linux kernel networking enables him to write a true Linux network stack for the DECT protocol
+	\item git://git.kernel.org/pub/scm/linux/kernel/git/kaber/dect-2.6.git
+	\item Written by one person!
+\end{itemize}
+\end{frame}
+
+\subsection{GSM}
+
+\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 Billing
+		\item Network planning / deployment / servicing
+	\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
+	\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
+	\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}
+
+\begin{frame}{OpenBSC}{A FOSS GSM protocol stack implementation}
+\begin{itemize}
+	\item OpenBSC implements {\em GSM network in a box}
+	\begin{itemize}
+		\item BSC, MSC, HLR, AuC, ...
+		\item You can use a BTS + OpenBSC and run your own network
+	\end{itemize}
+	\item Commercial systems with same functionality sell for >~50,000 USD
+	\begin{itemize}
+		\item Did you also hear the rumors about 100-man-years intellectual property in a GSM stack?
+	\end{itemize}
+	\item Developed by three people in their spare time!
+\end{itemize}
+\end{frame}
+
+\begin{frame}{OpenBTS}{A different GSM protocol stack implementation}
+\begin{itemize}
+	\item Open implementation of Um L1 \& L2, an all-software BTS.
+	\item L1/L2 design based on an object-oriented dataflow approach.
+	\item Includes L3 RR functions normally found in BSC.
+	\item Uses SIP PBX for MM and CC functions, eliminating the conventional GSM network.  L3 is like an ISDN/SIP gateway.
+	\item Intended for use in low-cost and rapidly-deployed communications networks, but can be used for experiments.
+	\item Written by two people!
+\end{itemize}
+\end{frame}
+
+\begin{frame}{airprobe}{A GSM receiver / protocol analyzer}
+\begin{itemize}
+	\item {\em airprobe} is a collection of Um protocol analyzer tools using the USRP software defined radio
+	\item A number of different Um receiver implementations
+	\begin{description}[gsm-receiver]
+		\item[gssm] One of the two early Um receiver implementations (M\&M clock recovery)
+		\item[gsmsp] The other early Um receiver implementation
+		\item[gsm-tvoid] For a long time the Um receiver with best performance
+		\item[gsm-receiver] The latest generation of Um receiver
+	\end{description}
+	\item Today, gsm-receiver seems to be the most popular choice
+\end{itemize}
+\end{frame}
+
+\begin{frame}{OsmocomBB}{A telephone-side GSM baseband firmware}
+\begin{itemize}
+	\item {\em OsmocomBB} is a FOSS implementation of GSM protocols for the mobile phone
+	\item Implemented in portable C with drivers for one TI baseband chipset
+	\item Current features include
+	\begin{itemize}
+		\item Passive protocol-analysis and protocol sniffing
+		\item Determine operating parameters of any GSM network, including its cell configuration, use of encryption, use of TMSI, etc.
+		\item Transmit arbitrary data to any GMS cell/network
+	\end{itemize}
+	\item Will serve as foundation for security analysis tools for the GSM air interface
+\end{itemize}
+\end{frame}
+
+
+\begin{frame}{What has GSM FOSS shown?}
+\begin{itemize}
+	\item We can now do real-world demonstration of GSM weaknesses
+	\begin{itemize}
+		\item Lack of mutual authentication
+		\item Silent calls to turn phones into permanently transmitting beacons
+		\item RRLP to inquire the GPS fix of any phone
+	\end{itemize}
+	\item We can make people aware of the dangers those features have
+	\item Hopefully, public pressure will force the industry to change
+\end{itemize}
+\end{frame}
+
+\section{Summary}
+
+\subsection{What we've learned}
+
+\begin{frame}{Summary}{What we've learned}
+\begin{itemize}
+	\item There are many areas which the benefits of FOSS have not yet reached
+	\item Nonetheless, those systems are used by billions of people every day
+	\item Without independent research, security flaws will never be removed
+	\item Small projects with few dedicated developers can make a huge impact
+\end{itemize}
+\end{frame}
+
+\subsection{Get involved!}
+
+\begin{frame}{Get involved!}
+\begin{itemize}
+	\item Boldly go where no (FOSS) man has gone before
+	\item Don't be deterred by people who say it's impossible
+	\item What are you waiting for?
+	\item Would you rather become the worlds 10,000th application security expert or the worlds 100th GSM protocol security expert?
+	\item Help us to get some sense into the semiconductor industry.
+\end{itemize}
+\end{frame}
+
+\subsection{Knowledge is power}
+
+\begin{frame}{Knowledge is power}
+\begin{itemize}
+	\item Educate yourself
+	\item Never underestimate {\em learning by doing}
+	\item Educate others about 
+	\begin{itemize}
+		\item How every-day technology like cellphones really work
+		\item What is the true security and privacy level of those systems
+	\end{itemize}
+\end{itemize}
+\end{frame}
+
+\begin{frame}{Where to go?}{Areas that need openness}
+\begin{itemize}
+	\item 3G (UMTS) protocol stack
+	\item GSM telephone side GSM stack
+	\item What about DAB, DMB-T
+	\item DVB-S encapsulated Internet downlink
+	\item TETRA being deployed in multiple European countries
+	\item CDMA / CDMA2000
+	\pause
+	\item ... and this is just in the communications protocol sector!
+\end{itemize}
+\end{frame}
+
+\end{document}