summaryrefslogtreecommitdiff
path: root/2010/opening_closed_domains-foi2010/opening_closed_domains.tex
diff options
context:
space:
mode:
Diffstat (limited to '2010/opening_closed_domains-foi2010/opening_closed_domains.tex')
-rw-r--r--2010/opening_closed_domains-foi2010/opening_closed_domains.tex613
1 files changed, 613 insertions, 0 deletions
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}
personal git repositories of Harald Welte. Your mileage may vary