summaryrefslogtreecommitdiff
path: root/2010/opening_closed_domains-foi2010/opening_closed_domains.tex
blob: 11182dee71107c08c3fb48339fc2c0d188b5d463 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
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