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
|
Open Source Network Elements for Security Analysis of Mobile Networks
=====================================================================
:author: Harald Welte <hwelte@sysmocom.de>
:copyright: sysmocom - s.f.m.c. GmbH (License: CC-BY-SA)
:backend: slidy
:max-width: 45em
//:data-uri:
//:icons:
== What this talk is about
[role="incremental"]
* Importance of 3GPP network elements as FOSS for security research
* Applied Protocol Archeology since 2008
* Current Status and working areas
* Doing all of that on top of Linux (in userspace)
== Running your own Internet-style network
[role="incremental"]
* use off-the-shelf hardware (x86, Ethernet card)
* use any random Linux distribution
* configure Linux kernel TCP/IP network stack
** enjoy fancy features like netfilter/iproute2/tc
* use apache/lighttpd/nginx on the server
* use Firefox/chromium/konqueor/lynx on the client
* do whatever analysis/research/testing on any part of the stack
== Doing security research on it
[role="incremental"]
* FOSS implementations are key to any type of research
* ability to study not only the interfaces but actual code
* ability to test against other (proprietary) implementations
* ability to modify the code in any way needed to behave 'different
from spec', or in ways not originally intended in the spec
== Running your own GSM network
Until 2009 the situation looked like this:
* go to Ericsson/Huawei/ZTE/Nokia/Alcatel/...
* spend lots of time convincing them that you're an eligible customer
* spend a six-digit figure for even the most basic full network
* end up with black boxes you can neither study nor improve
[role="incremental"]
- WTF?
- I've grown up with FOSS and the Internet. I know a better world.
== Why no cellular FOSS?
- both cellular (2G/3G/4G) and TCP/IP/HTTP protocol specs are publicly
available for decades. Can you believe it?
- Internet protocol stacks have lots of FOSS implementations
- cellular protocol stacks have no FOSS implementations for the
first almost 20 years of their existence?
[role="incremental"]
- it's the classic conflict
* classic circuit-switched telco vs. the BBS community
* ITU-T/OSI/ISO vs. Arpanet and TCP/IP
== Enter Osmocom
In 2008, some people started to write FOSS for GSM
- to boldly go where no FOSS hacker has gone before
[role="incremental"]
** where protocol stacks are deep
** and acronyms are plentiful
** we went from `bs11-abis` to `bsc_hack` to 'OpenBSC'
** many other related projects were created
** finally leading to the 'Osmocom' umbrella project
== Classic GSM network architecture
image::Gsm_structures.svg[width=850]
== Osmocom GSM components
image::osmocom-gsm.svg[width=850]
== Classic GSM network as digraph
[graphviz]
----
digraph G {
rankdir=LR;
MS0 [label="MS"]
MS1 [label="MS"]
MS2 [label="MS"]
MS3 [label="MS"]
BTS0 [label="BTS"]
BTS1 [label="BTS"]
MSC [label="MSC/VLR"]
HLR [label="HLR/AUC"]
MS0->BTS0 [label="Um"]
MS1->BTS0 [label="Um"]
MS2->BTS1 [label="Um"]
MS3->BTS1 [label="Um"]
BTS0->BSC [label="Abis"]
BTS1->BSC [label="Abis"]
BSC->MSC [label="A"]
MSC->HLR [label="C"]
MSC->EIR [label="F"]
MSC->SMSC
}
----
== Simplified OsmoNITB GSM network
[graphviz]
----
digraph G {
rankdir=LR;
MS0 [label="MS"]
MS1 [label="MS"]
MS2 [label="MS"]
MS3 [label="MS"]
BTS0 [label="BTS"]
BTS1 [label="BTS"]
MS0->BTS0 [label="Um"]
MS1->BTS0 [label="Um"]
MS2->BTS1 [label="Um"]
MS3->BTS1 [label="Um"]
BTS0->BSC [label="Abis"]
BTS1->BSC [label="Abis"]
subgraph cluster_nitb {
label = "OsmoNITB";
BSC
MSC [label="MSC/VLR"]
HLR [label="HLR/AUC"]
BSC->MSC [label="A"]
MSC->HLR [label="C"]
MSC->EIR [label="F"]
MSC->SMSC;
}
}
----
which further reduces to the following minimal setup:
[graphviz]
----
digraph G {
rankdir=LR;
MS0 [label="MS"]
BTS0 [label="BTS"]
MS0->BTS0 [label="Um"]
BTS0->BSC [label="Abis"]
BSC [label="OsmoNITB"];
}
----
So our minimal setup is a 'Phone', a 'BTS' and 'OsmoNITB'.
== Which BTS to use?
* Proprietary BTS of classic vendor
** Siemens BS-11 is what we started with
** Nokia, Ericsson, and others available 2nd hand
* 'OsmoBTS' software implementation, running with
** Proprietary HW + PHY (DSP): 'sysmoBTS', or
** General purpose SDR (like USRP) + 'OsmoTRX'
We assume a sysmoBTS in the following slides
== OsmoBTS Overview
image::osmo-bts.svg[]
* Implementation of GSM BTS
* supports variety of hardware/PHY options
** `osmo-bts-sysmo`: BTS family by sysmocom
** `osmo-bts-trx`: Used with 'OsmoTRX' + general-purpose SDR
** `osmo-bts-octphy`: Octasic OCTBTS hardware / OCTSDR-2G PHY
** `osmo-bts-litecell15`: Nutaq Litecell 1.5 hardware/PHY
== Extending the network with GPRS
Now that GSM is working, up to the next challenge!
* Classic GSM is circuit-switched only
* Packet switched support introduced first with GPRS
* GPRS adds new network elements (PCU, SGSN, GGSN)
* tunnel for external packet networks like IP/Internet
* tunnel terminates in MS and on GGSN
== Extending the network with GPRS support
[graphviz]
----
digraph G {
rankdir=LR;
MS0 [label="MS"]
MS1 [label="MS"]
MS2 [label="MS"]
MS3 [label="MS"]
BTS0 [label="BTS"]
BTS1 [label="BTS"]
MSC [label="MSC/VLR"]
HLR [label="HLR/AUC"]
MS0->BTS0 [label="Um"]
MS1->BTS0 [label="Um"]
MS2->BTS1 [label="Um"]
MS3->BTS1 [label="Um"]
BTS0->BSC [label="Abis"]
BTS1->BSC [label="Abis"]
BSC->MSC [label="A"]
MSC->HLR [label="C"]
MSC->EIR [label="F"]
MSC->SMSC
BTS0->PCU
subgraph cluster_gprs {
label = "GPRS Add-On"
PCU->SGSN [label="Gb"]
SGSN->GGSN [label="GTP"]
}
}
----
* 'PCU': Packet Control Unit. Runs RLC+MAC
* 'SGSN': Serving GPRS Support Node (like VLR/MSC)
* 'GGSN': Gateway GPRS Support Node (terminates tunnels)
== GPRS Protocol Stack
image::gprs_user_stack.svg[width=850]
== Simplified OsmoNITB network with GPRS
[graphviz]
----
digraph G {
rankdir=LR;
MS0 [label="MS"]
BTS0 [label="OsmoBTS"]
BSC [label="OsmoNITB"]
PCU [label="OsmoPCU"]
SGSN [label="OsmoSGSN"]
GGSN [label="OpenGGSN"]
MS0->BTS0 [label="Um"]
BTS0->BSC [label="Abis"]
BTS0->PCU
subgraph cluster_gprs {
label = "GPRS Add-On"
PCU->SGSN [label="Gb"]
SGSN->GGSN [label="GTP"]
}
}
----
* 'OsmoPCU' is co-located with 'OsmoBTS'
** connects over unix-domain PCU socket to BTS
* 'OsmoSGSN' can run on any Linux machine
* 'OpenGGSN' can run on any Linux machine
** `tun` device is used for tunnel endpoints
* circuit-switched and packet-switched networks are completely separate
We need to configure those additional components to provide GPRS
services.
== Simplified OsmoNITB network with GPRS
image::osmocom-gprs.svg[width=750]
//* show IP addresses at nodes
//* show GSM functional elements, Osmocom programs and hardware
== Protocol tracing of cellular interfaces
* many cellular protocols/interfaces are not specified over IP or Ethernet
** e.g. the radio interface (Um) is clearly
* Osmocom 'GSMTAP' to the rescue
** encapsulate non-IP protocols inside GSMTAP (inside UDP/IP)
** forward them over net-device ('lo' as fall-back)
** 'wireshark' can then capture them using regular packet socket
** 'wireshark' was extended with related dissectors
** any and every GSM network interface can be analyzed now
** was extended for TETRA, GMR, UMTS, LTE, ...
== Osmocom beyond GSM/GPRS RAN + NITB
* Telephone-side GSM protocol stack 'OsmocomBB'
** circuit-switched GSM only. No GPRS/EDGE/3G/4G!
* Smalltalk implementation of SIGTRAN + TCAP/MAP
* Erlang implementation of SIGTRAN + TCAP/MAP
* Lots of special-purpose protocol mangling
** `bsc-nat` to introduce NAT-like functionality on A (BSSAP/BSSMAP)
** `mgw-nat` to transparently re-write MAP/ISUP/SCCP
* GSMTAP pseudo-header for feeding non-IP protocols into wireshark
* SIM card protocol tracer hardware + software ('SIMtrace')
* Lots of non-GSM projects from hardware to protocol stacks (TETRA, GMR, DECT, OP25)
* check http://git.osmocom.org/ for full project list
== So... I heard about OpenBTS?
* OpenBTS is completely unrelated to the Osmocom stack
* was independently developed by David Burgess & Harvind Simra
** Kestrel Signal Processing -> Range Networks
* doesn't follow GSM system architecture at all
** no Abis, BSC, PCU, SGSN, GGSN
* is a bridge of the GSM air interface (Um) to SIP
* Osmocom follows classic GSM interfaces / system architecture
** if you research GSM beyond the radio interface, Osmocom offers an
implementation closer to real operator networks
* 'OsmoTRX' forked 'OpenBTS' SDR code to use 'OsmoBTS' with SDR hardware
== What about FOSS 2.75G (EDGE)
* EDGE extends GPRS with higher data rates
** 8PSK instead of GMSK modulation
** lots of new MAC/RLC features (larger windows, incremental redundancy)
** No changes required in 'OmsoSGSN' and 'OsmoGGSN'
* 'OsmoPCU' is extended with initial EDGE support
* First working beta release was made in late January 2016
** continues to make rapid progress ever since
== What about FOSS 3G (UMTS/WCDMA)
* UMTS very similar to GSM/GPRS in principle
** still, almost every interface and protocol stack has changed
** all elements have been renamed -> more acronyms to learn
* UMTS is ridiculously complex, particular PHY + Layer 2
** however, control plane L3 (MM/CC/CM/SM/GMM) mostly the same
* Implementing all of that from scratch is a long journey
* We've already reached 'Peak 3G'
* Osmocom 3G support strategy
** Implement Iu interface in NITB and SGSN
** Implement HNB-GW to offer Iuh interface
** Use existing femtocell / small cell hardware with proprietary PHY, RLC and MAC
** Status: Started in October 2015, WIP. Overall completion > 50%.
== Classic UMTS Architecture
image::640px-UMTS_structures.png[width=800]
(UMTS Structure by Tsaitgaist - icons from Gnome)
== Classic UMTS Architecture
image::nodeb_hnb.png[width=800]
(nodeB and Home nodeB by Tsaitgaist - icons from Gnome)
== Differences NodeB to hNodeB
* hNodeB is basically a NodeB with a RNC built-in
* all lower-level protocols are implemented in the RNC
* only RANAP is exposed
* Iuh interface is similar to Iu-CS/Iu-PS
* Iu interface is at much lower level.
* Compared with GSM: Iu = Abis, Iuh = A
== Wy work with hNodeB instead of NodeB?
* UMTS is not a single telephony system but a set of re-configurable
building blocks to create any type of telephony system.
* complexity at every level, particularly the lower levels
* using hNodeB interface / stack (Iuh), we can avoid having to worry
about RLC/MAC, RRC, HNBAP, etc.
* many femtocells implement Iuh
* quite some small cells also implement Iuh
== Iuh: Avoiding complexity of the RNC
speaking of UMTS access stratum complexity...
image::umts_channel_mapping.png[width=900]
wouldn't you want to avoid that, too?
== How to support UMTS from OsmoNITB, OsmoSGSN
* Separation of MSC-part from NITB, generating Osmo-MSS
** OsmoBSC already implements BSC-side A interface, we need to add
MSC-side A interface
* UMTS AKA support as library, link into OsmoMSS and OsmoSGSN
* RANAP protocol support in a library, also linked into OsmoMSS and OsmoSGSN
* NITB: support 'subscriber_connection' over A (BSSMAP/BSSAP) and over RANAP
* SGSN: support 'mm_context' over Gb (LLC/BSSGP/NS) or over RANAP
== Osmocom 3G Network Architecture
[graphviz]
----
digraph G {
rankdir=LR;
MS0 [label="UE"]
MS1 [label="UE"]
MS2 [label="UE"]
MS3 [label="UE"]
HNBGW [label="HNB-GW"]
MS0->BTS0 [label="Uu"]
MS1->BTS0 [label="Uu"]
MS2->BTS1 [label="Uu"]
MS3->BTS1 [label="Uu"]
subgraph cluster_hnb0 {
label = "hNodeB"
BTS0 [label="NodeB"]
RNC0 [label="RNC"]
BTS0->RNC0
}
subgraph cluster_hnb1 {
label = "hNodeB"
BTS1 [label="NodeB"]
RNC1 [label="RNC"]
BTS1->RNC1
}
subgraph cluster_cscn {
label = "OsmoCSCN (ex-NITB)"
MSC [label="MSC/VLR"]
HLR [label="HLR/AUC"]
MSC->HLR [label="C"]
MSC->EIR [label="F"]
MSC->SMSC
}
RNC0->HNBGW [label="Iuh"]
RNC1->HNBGW [label="Iuh"]
HNBGW->MSC [label="IuCS"]
HNBGW->SGSN [label="IuPS"]
SGSN->GGSN [label="GTP"]
}
----
further simplified:
[graphviz]
----
digraph G {
rankdir=LR;
MS0 [label="UE"]
MS1 [label="UE"]
HNBGW [label="HNB-GW"]
MS0->BTS0 [label="Uu"]
MS1->BTS1 [label="Uu"]
BTS0 [label="hNodeB"]
BTS1 [label="hNodeB"]
BTS0->HNBGW [label="Iuh"]
BTS1->HNBGW [label="Iuh"]
HNBGW->OsmoCSCN [label="IuCS"]
HNBGW->OsmoSGSN [label="IuPS"]
OsmoSGSN->OpenGGSN [label="GTP"]
}
----
== Osmocom 3G Network Status
Existing as of March 2016:
* 'HNBAP', 'RUA', 'RANAP' protocol implementations
* 'osmo-hnbgw' converting Iuh to Iu-CS and Iu-PS
* 'OsmoSGSN' with IuPS interface
* 'OsmoCSCN' with IuCS interface
TODO:
* HLR/AUC extension for UMTS AKA
* testing, testing, testing
* actual voice handling (so far, signalling + packet data only)
== Outlook on FOSS 4G (LTE)
* LTE has nothing in common with 2G/3G
* various FOSS activities
** 'OpenAirInterface' has some code for a software eNodeB
*** but they switched from GPLv3 to 'non-free' license :(
** 'srsLTE' (main focus on UE side, but large parts usable for eNodeB side)
** 'OpenLTE' is another active FOSS project
* No Osmocom involvement so far
** team is small, project scope of cellular infrastructure is gigantic
** most customer funding currently still on GSM/GPRS/EDGE
** if we'd start today, we'd start implementing MME + S-GW and use
existing LTE cells, similar to the 3G strategy
== Summary
[role="incremental"]
* FOSS implementations of protocol stacks and functional elements are
'vital for security research'
* Traditional Telcos + Equipment vendors do not contribute to this :(
* Existing implementations done by enthusiasts only, on extremely
tight budgets and resources
* Existing implementations are decades behind
* Result: Security research is often decades behind
* 'If we want to advance Cellular security research, we need to
advance FOSS implementations!'
== The End
* so long, and thanks for all the fish
* I hope you have questions!
* have fun exploring mobile technologies using Osmocom
* interested in working with more acronyms? Come join the project!
* Check out http://openbsc.osmocom.org/ and openbsc@lists.osmocom.org
== Thanks to
* the entire Osmocom team for what they have achieved
** notably Dieter Spaar, Holger Freyther, Andreas Eversberg, Sylvain Munaut
* last but not least: CEPT for making the GSM specs English
** (the official language of CEPT is french!)
|