From fca59bea770346cf1c1f9b0e00cb48a61b44a8f3 Mon Sep 17 00:00:00 2001 From: Harald Welte Date: Sun, 25 Oct 2015 21:00:20 +0100 Subject: import of old now defunct presentation slides svn repo --- .../opening_closed_domains.tex | 598 +++++++++++++++++++++ 1 file changed, 598 insertions(+) create mode 100644 2009/opening_closed_domains-fossin2009/opening_closed_domains.tex (limited to '2009/opening_closed_domains-fossin2009/opening_closed_domains.tex') diff --git a/2009/opening_closed_domains-fossin2009/opening_closed_domains.tex b/2009/opening_closed_domains-fossin2009/opening_closed_domains.tex new file mode 100644 index 0000000..f2c9126 --- /dev/null +++ b/2009/opening_closed_domains-fossin2009/opening_closed_domains.tex @@ -0,0 +1,598 @@ +% $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 . +% +% 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 +{ + \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\\Examples: RFID, DECT, GSM} + +\subtitle +{A hackers journey through technology} + +\author{Harald Welte} + +\institute +{gnumonks.org\\gpl-violations.org\\OpenBSC\\airprobe.org\\hmw-consulting.de} +% - Use the \inst command only if there are several affiliations. +% - Keep it simple, no one is interested in your street address. + +\date[foss.in/2009] % (optional, should be abbreviation of conference name) +{FOSS.in conference, December 2009, Bangalore/India} +% - 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}{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 backdoors, 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 engineerd 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, cellphones 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 avaiable 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 proprietay 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 sytstems 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 romours 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}{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} -- cgit v1.2.3