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
|
\section{OsmocomBB Project}
\begin{frame}{A GSM phone baseband processor}
\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}
\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}
\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}
|