614 lines
21 KiB
TeX
614 lines
21 KiB
TeX
% $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}
|