Open Source Network Elements for Security Analysis of Mobile Networks ===================================================================== :author: Harald Welte :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!)