summaryrefslogtreecommitdiff
path: root/2010/osmocombb-hashdays2010/osmocombb-security.tex
blob: 76c53cd979c1313b1b0a706801d4cfea7db17f99 (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
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
% $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}

\usepackage{url}
\makeatletter
\def\url@leostyle{%
  \@ifundefined{selectfont}{\def\UrlFont{\sf}}{\def\UrlFont{\tiny\ttfamily}}}
\makeatother
%% Now actually use the newly defined style.
\urlstyle{leo}


% 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{OsmocomBB}

\subtitle
{Free Software GSM baseband firmware for security analysis}

\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[hashdays 2010] % (optional, should be abbreviation of conference name)
{Hashdays 2010, November 2010, Lucerne/Switzerland}
% - 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{GSM Security}
% 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[hideallsubsections]
  % 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 expert, focus on network protocol security
	\item Core developer of Linux packet filter netfilter/iptables
	\item Board-level Electrical Engineering
	\item Always looking for interesting protocols (RFID, DECT, GSM)
\end{itemize}
\end{frame}

\section{GSM/3G Network Security Introduction}

\begin{frame}{GSM/3G protocol security}
\begin{itemize}
	\item Observation
	\begin{itemize}
		\item Both GSM/3G and TCP/IP protocol specs are publicly available
		\item The Internet protocol stack (Ethernet/Wifi/TCP/IP) receives lots of scrutiny
		\item GSM networks are as widely deployed as the Internet
		\item Yet, GSM/3G protocols receive no such scrutiny!
	\end{itemize}
	\item There are reasons for that:
	\begin{itemize}
		\item GSM industry is extremely closed (and closed-minded)
		\item Only about 4 closed-source protocol stack implementations
		\item GSM chipset makers never release any hardware documentation
	\end{itemize}
\end{itemize}
\end{frame}

\subsection{The closed GSM industry}

\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}

\subsection{Security implications}

\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 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
		\item Has been done in 2008/2009: Project OpenBSC
	\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}{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, MS tester, ...)
	\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}

\subsection{The GSM network}

\begin{frame}{The GSM network}
  \begin{figure}[h]
  \centering
  \includegraphics[width=100mm]{gsm_network.png}
  \end{figure}
\end{frame}

\begin{frame}{GSM network components}
  \begin{itemize}
    \item The BSS (Base Station Subsystem)
    \begin{itemize}
      \item MS (Mobile Station): Your phone
      \item BTS (Base Transceiver Station): The {\em cell tower}
      \item BSC (Base Station Controller): Controlling up to hundreds of BTS
    \end{itemize}
    \item The NSS (Network Sub System)
    \begin{itemize}
      \item MSC (Mobile Switching Center): The central switch
      \item HLR (Home Location Register): Database of subscribers
      \item AUC (Authentication Center): Database of authentication keys
      \item VLR (Visitor Location Register): For roaming users
      \item EIR (Equipment Identity Register): To block stolen phones
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}{GSM network interfaces}
  \begin{itemize}
    \item Um: Interface between MS and BTS
    \begin{itemize}
	\item the only interface that is specified over radio
    \end{itemize}
    \item A-bis: Interface between BTS and BSC
    \item A: Interface between BSC and MSC
    \item B: Interface between MSC and other MSC
  \end{itemize}
  GSM networks are a prime example of an asymmetric distributed network,
  very different from the end-to-end transparent IP network.
\end{frame}


\subsection{The GSM protocols}

\begin{frame}{GSM network protocols}{On the Um interface}
  \begin{itemize}
    \item Layer 1: Radio Layer, TS 04.04
    \item Layer 2: LAPDm, TS 04.06
    \item Layer 3: Radio Resource, Mobility Management, Call Control: TS 04.08
    \item Layer 4+: for USSD, SMS, LCS, ...
  \end{itemize}
\end{frame}

\section{Security Problems and the Baseband}

\subsection{Theory}

\begin{frame}{Known GSM security problems}{Scientific papers, etc}
\begin{itemize}
	\item No mutual authentication between phone and network
	\begin{itemize}
		\item leads to rogue network attacks
		\item leads to man-in-the-middle attacks
		\item is what enables IMSI-catchers
	\end{itemize}
	\item Weak encryption algorithms
	\item Encryption is optional, user does never know when it's active or not
	\item DoS of the RACH by means of channel request flooding
	\item RRLP (Radio Resource Location Protocol)
	\begin{itemize}
		\item the network can obtain GPS fix or even raw GSM data from the phone
		\item combine that with the network not needing to authenticate itself
	\end{itemize}
\end{itemize}
\end{frame}

\subsection{The Baseband}

\begin{frame}{Known GSM security problems}{The Baseband side}
\begin{itemize}
	\item GSM protocol stack always runs in a so-called baseband processor (BP)
	\item What is the baseband processor
	\begin{itemize}
		\item Typically ARM7 (2G/2.5G phones) or ARM9 (3G/3.5G phones)
		\begin{itemize}
			\item Runs some RTOS (often Nucleus, sometimes L4)
			\item No memory protection between tasks
		\end{itemize}
		\item Some kind of DSP, model depends on vendor
		\begin{itemize}
			\item Runs the digital signal processing for the RF Layer 1
			\item Has hardware peripherals for A5 encryption
		\end{itemize}
	\end{itemize}
	\item The software stack on the baseband processor
	\begin{itemize}
		\item is written in C and assembly
		\item lacks any modern security features (stack protection, non-executable pages, address space randomization, ..)
	\end{itemize}
\end{itemize}
\end{frame}

\begin{frame}{A GSM Baseband Chipset}
  \begin{figure}[h]
  \centering
  \includegraphics[width=100mm]{calypso-block.pdf}
  \end{figure}
  \url{http://laforge.gnumonks.org/papers/gsm_phone-anatomy-latest.pdf}
\end{frame}

\begin{frame}{Requirements for GSM security analysis}
What do we need for protocol-level security analysis?
\begin{itemize}
	\item A GSM MS-side baseband chipset under our control
	\item A Layer1 that we can use to generate arbitrary L1 frames
	\item A Layer2 protocol implementation that we can use + modify
	\item A Layer3 protocol implementation that we can use + modify
\end{itemize}
None of those components existed, so we need to create them!
\end{frame}

\begin{frame}{A GSM baseband under our control}
The two different DIY approaches
\begin{itemize}
	\item Build something using generic components (DSP, CPU, ADC, FPGA)
	\begin{itemize}
		\item No reverse engineering required
		\item A lot of work in hardware design + debugging
		\item Hardware will be low-quantity and thus expensive
	\end{itemize}
	\item Build something using existing baseband chipset
	\begin{itemize}
		\item Reverse engineering or leaked documents required
		\item Less work on the 'Layer 0'
		\item Still, custom hardware in low quantity
	\end{itemize}
\end{itemize}
\end{frame}

\begin{frame}{A GSM baseband under our control}
Alternative 'lazy' approach
\begin{itemize}
	\item Re-purpose existing mobile phone
	\begin{itemize}
		\item Hardware is known to be working
		\item No prototyping, hardware revisions, etc.
		\item Reverse engineering required
		\item Hardware drivers need to be written
		\item But: More time to focus on the actual job: Protocol software
	\end{itemize}
	\item Searching for suitable phones
	\begin{itemize}
		\item As cheap as possible
		\item Readily available: Many people can play with it
		\item As old/simple as possible to keep complexity low
		\item Baseband chipset with lots of leaked information
	\end{itemize}
\end{itemize}
\end{frame}

\begin{frame}{Baseband chips with leaked information}
\begin{itemize}
	\item Texas Instruments Calypso
	\begin{itemize}
		\item DBB Documentation on cryptome.org and other sites
		\item ABB Documentation on Chinese phone developer websites
		\item Source code of GSM stack / drivers was on sf.net (tsm30 project)
		\item End of life, no new phones with Calypso since about 2008
		\item No cryptographic checks in bootloader
	\end{itemize}
	\item Mediatek MT622x chipsets
	\begin{itemize}
		\item Lots of Documentation on Chinese sites
		\item SDK with binary-only GSM stack libraries on Chinese sites
		\item 95 million produced/sold in Q1/2010
	\end{itemize}
\end{itemize}
Initial choice: TI Calypso (GSM stack source available)
\end{frame}


\section{OsmocomBB Project}

\subsection{OsmocomBB Introduction}

\begin{frame}{OsmocomBB Introduction}
\begin{itemize}
	\item Project was started only in January 2010 (9 months ago!)
	\item Implementing a GSM baseband software from scratch
	\item This includes
	\begin{itemize}
		\item GSM MS-side protocol stack from Layer 1 through Layer 3
		\item Hardware drivers for GSM Baseband chipset
		\item Simple User Interface on the phone itself
		\item Verbose User Interface on the PC
	\end{itemize}
	\item Note about the strange project name
	\begin{itemize}
		\item Osmocom = Open Source MObile COMmunication
		\item BB = Base Band
	\end{itemize}
\end{itemize}
\end{frame}

\subsection{OsmocomBB Architecture}

\begin{frame}{OsmocomBB Software Architecture}
\begin{itemize}
	\item Reuse code from OpenBSC where possible (libosmocore)
	\begin{itemize}
		\item We build libosmocore both for phone firmware and PC
	\end{itemize}
	\item Initially run as little software in the phone
	\begin{itemize}
		\item Debugging code on your host PC is so much easier
		\item You have much more screen real-estate
		\item Hardware drivers and Layer1 run in the phone
		\item Layer2, 3 and actual phone application / MMI on PC
		\item Later, L2 and L3 can me moved to the phone
	\end{itemize}
\end{itemize}
\end{frame}

\begin{frame}{OsmocomBB Software Interfaces}
\begin{itemize}
	\item Interface between Layer1 and Layer2 called L1CTL
	\begin{itemize}
		\item Fully custom protocol as there is no standard
		\item Implemented as message based protocol over Sercomm/HDLC/RS232
	\end{itemize}
	\item Interface between Layer2 and Layer3 called RSLms
	\begin{itemize}
		\item In the GSM network, Um Layer2 terminates at the BTS but is controlled  by the BSC
		\item Reuse this GSM 08.58 Radio Signalling Link
		\item Extend it where needed for the MS case
	\end{itemize}
\end{itemize}
\end{frame}

\subsection{OsmocomBB Software}

\begin{frame}{OsmocomBB Target Firmware}
\begin{itemize}
	\item Firmware includes software like
	\begin{itemize}
		\item Drivers for the Ti Calypso Digital Baseband (DBB)
		\item Drivers for the Ti Iota TWL3025 Analog Baseband (ABB)
		\item Drivers for the Ti Rita TRF6151 RF Transceiver
		\item Drivers for the LCD/LCM of a number of phones
		\item CFI flash driver for NOR flash
		\item GSM Layer1 synchronous/asynchronous part
		\item Sercomm - A HDLC based multiplexer for the RS232 to host PC
	\end{itemize}
\end{itemize}
\end{frame}

\begin{frame}{OsmocomBB Host Software}
\begin{itemize}
	\item Current working name: layer23
	\item Includes
	\begin{itemize}
		\item Layer 1 Control (L1CTL) protocol API
		\item GSM Layer2 implementation (LAPDm)
		\item GSM Layer3 implementation (RR/MM/CC)
		\item GSM Cell (re)selection
		\item SIM Card emulation
		\item Supports various 'apps' depending on purpose
	\end{itemize}
\end{itemize}
\end{frame}

\subsection{OsmocomBB Hardware Support}

\begin{frame}{OsmocomBB Supported Hardware}
\begin{itemize}
	\item Baseband Chipsets
	\begin{itemize}
		\item TI Calypso/Iota/Rita
		\item Some early research being done on Mediatek (MTK) MT622x
	\end{itemize}
	\item Actual Phones
	\begin{itemize}
		\item Compal/Motorola C11x, C12x, C13x, C14x and C15x models
		\item Most development/testing on C123 and C155
		\item GSM modem part of Openmoko Neo1973 and Freerunner
	\end{itemize}
	\item All those phones are simple feature phones built on a ARM7TDMI based DBB
\end{itemize}
\end{frame}

\begin{frame}{The Motorola/Compal C123}
 \begin{figure}[h]
  \centering
  \includegraphics[width=100mm]{c123_pcb.jpg}
  \end{figure}
\end{frame}


\subsection{OsmocomBB Project Status}

\begin{frame}{OsmocomBB Project Status: Working}
\begin{itemize}
	\item Hardware Drivers for Calypso/Iota/Rita very complete
	\item Drivers for Audio/Voice signal path
	\item Layer1 
	\begin{itemize}
		\item Power measurements 
		\item Carrier/bit/TDMA synchronization
		\item Receive and transmit of normal bursts on SDCCH
		\item Transmit of RACH bursts
		\item Automatic Rx gain control (AGC)
		\item Frequency Hopping
	\end{itemize}
	\item Layer2 UI/SABM/UA frames and ABM mode
	\item Layer3 Messages for RR / MM / CC
	\item Cell (re)selection according GSM 03.22
\end{itemize}
\end{frame}

\begin{frame}{OsmocomBB Project Status: Working (2/2)}
OsmocomBB can now do GSM Voice calls (08/2010)
\begin{itemize}
	\item Very Early Assignment + Late Assignment
	\item A3/A8 Authentication of SIM
	\item A5/1 + A5/2 Encryption
	\item Full Rate (FR) and Enhanced Full Rate (EFR) codec
\end{itemize}
\end{frame}

\begin{frame}{OsmocomBB Project Status: Not working}
\begin{itemize}
	\item Fully-fledged SIM card reader inside phone (WIP)
	\item Layer1 
	\begin{itemize}
		\item Automatic Tx power control (APC)
		\item Neighbor Cell Measurements
		\item In-call hand-over to other cells
	\end{itemize}
	\item Actual UI on the phone
	\item Circuit Switched Data (CSD) calls
	\item GPRS (packet data)
	\item No Type Approval for the stack!
\end{itemize}
\end{frame}

\begin{frame}{OsmocomBB Project Status: Executive Summary}
\begin{itemize}
	\item We can establish control/signalling channels to both hopping and non-hopping GSM cells
	\begin{itemize}
		\item Control over synthesizer means we can even go to GSM-R band
	\end{itemize}
	\item We can send arbitrary data on those control channels
	\begin{itemize}
		\item RR messages to BSC
		\item MM/CC messages to MSC
		\item SMS messages to MSC/SMSC
	\end{itemize}
	\item TCH (Traffic Channel) support for voice calls
	\begin{itemize}
		\item Dieter Spaar and Andreas Eversberg have made multiple 20 minute call with current master branch
		\item Some people have tried alpha code on real networks for real 30+ minute calls!
	\end{itemize}
\end{itemize}
\end{frame}


\section{Summary}

\subsection{What we've learned}

\begin{frame}{Summary}{What we've learned}
\begin{itemize}
	\item The GSM industry is making security analysis very difficult
	\item It is well-known that the security level of the GSM stacks is very low
	\item We now have multiple solutions for sending arbitrary protocol data
	\begin{itemize}
		\item From a rogue network to phones (OpenBSC, OpenBTS)
		\item From an A-bis proxy to the network or the phones
		\item From custom GSM phone baseband firmware to the network
	\end{itemize}
\end{itemize}
\end{frame}

\subsection{Where we go from here}

\begin{frame}{TODO}{Where we go from here}
\begin{itemize}
	\item The basic tools for fuzzing mobile networks are available
	\item No nice interface/integration from OsmocomBB to scapy yet
	\item It is up to the security community to make use of those tools (!)
	\item Don't you too think that TCP/IP security is boring
	\item Join the GSM protocol security research projects
	\item Boldly go where no man has gone before
\end{itemize}
\end{frame}

\subsection{Further Reading}

\begin{frame}{Thanks}
I would like to express my thanks to
\begin{itemize}
	\item The OsmocomBB development team, most notably
	\begin{itemize}
		\item Dieter Spaar (invaluable dedication to this project!)
		\item Andreas Eversberg (layer 3, cell selection, etc.)
		\item Sylvain Munaut (layer1, dsp, misc.)
	\end{itemize}
	\item Other developers working on Open Source GSM stuff
	\begin{itemize}
		\item g3gg0 (MADos)
		\item David Burgess, Harvind Simra (OpenBTS)
		\item Holger Freythehr (OpenBSC)
	\end{itemize}
\end{itemize}
\end{frame}

\begin{frame}{Further Reading}
\begin{itemize}
	\item \url{http://laforge.gnumonks.org/papers/gsm_phone-anatomy-latest.pdf}
	\item \url{http://bb.osmocom.org/}
	\item \url{http://openbsc.gnumonks.org/}
	\item \url{http://openbts.sourceforge.net/}
	\item \url{http://airprobe.org/}
\end{itemize}
\end{frame}

\end{document}
personal git repositories of Harald Welte. Your mileage may vary