osmocombb - free software gsm baseband … network security introduction security problems and the...

GSM/3G Network Security IntroductionSecurity Problems and the Baseband

OsmocomBB ProjectSummary

OsmocomBBFree Software GSM baseband firmware for security analysis

Harald Welte

gnumonks.orggpl-violations.org

OpenBSCairprobe.org

hmw-consulting.de

DeepSec 2010, November 2010, Vienna/Austria

Harald Welte OsmocomBB



Outline

1 GSM/3G Network Security Introduction

2 Security Problems and the Baseband

3 OsmocomBB Project

4 Summary




About the speaker

Using + playing with Linux since 1994Kernel / bootloader / driver / firmware development since1999IT security expert, focus on network protocol securityCore developer of Linux packet filter netfilter/iptablesBoard-level Electrical EngineeringAlways looking for interesting protocols (RFID, DECT,GSM)




The closed GSM industrySecurity implicationsThe GSM networkThe GSM protocols

GSM/3G protocol security

ObservationBoth GSM/3G and TCP/IP protocol specs are publiclyavailableThe Internet protocol stack (Ethernet/Wifi/TCP/IP) receiveslots of scrutinyGSM networks are as widely deployed as the InternetYet, GSM/3G protocols receive no such scrutiny!

There are reasons for that:GSM industry is extremely closed (and closed-minded)Only about 4 closed-source protocol stack implementationsGSM chipset makers never release any hardwaredocumentation





The closed GSM industryHandset manufacturing side

Only very few companies build GSM/3.5G baseband chipstoday

Those companies buy the operating system kernel and theprotocol stack from third parties

Only very few handset makers are large enough tobecome a customer

Even they only get limited access to hardwaredocumentationEven they never really get access to the firmware source





The closed GSM industryNetwork manufacturing side

Only very few companies build GSM network equipmentBasically only Ericsson, Nokia-Siemens, Alcatel-Lucent andHuaweiException: Small equipment manufacturers for picocell /nanocell / femtocells / measurement devices and lawenforcement equipment

Only operators buy equipment from themSince the quantities are low, the prices are extremely high

e.g. for a BTS, easily 10-40k EUR





The closed GSM industryOperator side

Operators are mainly banks todayTypical operator outsources

BillingNetwork planning / deployment / servicing

Operator just knows the closed equipment as shipped bymanufacturerVery few people at an operator have knowledge of theprotocol beyond what’s needed for operations andmaintenance





The closed GSM industrySecurity implications

The security implications of the closed GSM industry are:Almost no people who have detailed technical knowledgeoutside the protocol stack or GSM network equipmentmanufacturersNo independent research on protocol-level security

If there’s security research at all, then only theoretical (likethe A5/2 and A5/1 cryptanalysis)Or on application level (e.g. mobile malware)

No open source protocol implementationswhich are key for making more people learn about theprotocolswhich enable quick prototyping/testing by modifying existingcode





Security analysis of GSMHow would you get started?

If you were to start with GSM protocol level security analysis,where and how would you start?

On the network side?Difficult since equipment is not easily available andnormally extremely expensiveHowever, network is very modular and has manystandardized/documented interfacesThus, if equipment is available, much easier/faster progressHas been done in 2008/2009: Project OpenBSC





Security analysis of GSMHow would you get started?

If you were to start with GSM protocol level security analysis,where and how would you start?

On the handset side?Difficult since GSM firmware and protocol stacks are closedand proprietaryEven if you want to write your own protocol stack, the layer1 hardware and signal processing is closed andundocumented, tooKnown attempts

The TSM30 project as part of the THC GSM projectmados, an alternative OS for Nokia DTC3 phones

none of those projects successful so far





Security analysis of GSMThe bootstrapping process

Read GSM specs day and night (> 1000 PDF documents)Gradually grow knowledge about the protocolsObtain actual GSM network equipment (BTS, MS tester, ...)Try to get actual protocol traces as examplesStart a complete protocol stack implementation fromscratchFinally, go and play with GSM protocol security





The GSM network





GSM network components

The BSS (Base Station Subsystem)MS (Mobile Station): Your phoneBTS (Base Transceiver Station): The cell towerBSC (Base Station Controller): Controlling up to hundredsof BTS

The NSS (Network Sub System)MSC (Mobile Switching Center): The central switchHLR (Home Location Register): Database of subscribersAUC (Authentication Center): Database of authenticationkeysVLR (Visitor Location Register): For roaming usersEIR (Equipment Identity Register): To block stolen phones





GSM network interfaces

Um: Interface between MS and BTSthe only interface that is specified over radio

A-bis: Interface between BTS and BSCA: Interface between BSC and MSCB: Interface between MSC and other MSC

GSM networks are a prime example of an asymmetricdistributed network, very different from the end-to-endtransparent IP network.





GSM network protocolsOn the Um interface

Layer 1: Radio Layer, TS 04.04Layer 2: LAPDm, TS 04.06Layer 3: Radio Resource, Mobility Management, CallControl: TS 04.08Layer 4+: for USSD, SMS, LCS, ...




TheoryThe Baseband

Known GSM security problemsScientific papers, etc

No mutual authentication between phone and networkleads to rogue network attacksleads to man-in-the-middle attacksis what enables IMSI-catchers

Weak encryption algorithmsEncryption is optional, user does never know when it’sactive or notDoS of the RACH by means of channel request floodingRRLP (Radio Resource Location Protocol)

the network can obtain GPS fix or even raw GSM data fromthe phonecombine that with the network not needing to authenticateitself




TheoryThe Baseband

Known GSM security problemsThe Baseband side

GSM protocol stack always runs in a so-called basebandprocessor (BP)What is the baseband processor

Typically ARM7 (2G/2.5G phones) or ARM9 (3G/3.5Gphones)

Runs some RTOS (often Nucleus, sometimes L4)No memory protection between tasks

Some kind of DSP, model depends on vendorRuns the digital signal processing for the RF Layer 1Has hardware peripherals for A5 encryption

The software stack on the baseband processoris written in C and assemblylacks any modern security features (stack protection,non-executable pages, address space randomization, ..)




TheoryThe Baseband

A GSM Baseband Chipset

CALYPSODigital Baseband

DSPMCUSRAMMask ROMUART, SPI, I2C

TWL3025ABB

BSP

USP

TSP

BULBDL

AntennaSwitch

ASM4532

TRF6151

TransceiverMixersVCOPLL

RF3166

RF PA

TSP

GSM

DCS/PCS

GSM

DCS

PCS

RFCLK

I/Q Analog

CLK13M

AFC Analog

TSP Parallel

TSP Serial

CLK32K

GS

M

DC

S/PC

S

APC Analog

I/Q Digital

SPI

http://laforge.gnumonks.org/papers/gsm_phone-anatomy-latest.pdf





TheoryThe Baseband

Requirements for GSM security analysis

What do we need for protocol-level security analysis?A GSM MS-side baseband chipset under our controlA Layer1 that we can use to generate arbitrary L1 framesA Layer2 protocol implementation that we can use + modifyA Layer3 protocol implementation that we can use + modify

None of those components existed, so we need to create them!




TheoryThe Baseband

A GSM baseband under our control

The two different DIY approachesBuild something using generic components (DSP, CPU,ADC, FPGA)

No reverse engineering requiredA lot of work in hardware design + debuggingHardware will be low-quantity and thus expensive

Build something using existing baseband chipsetReverse engineering or leaked documents requiredLess work on the ’Layer 0’Still, custom hardware in low quantity




TheoryThe Baseband

A GSM baseband under our control

Alternative ’lazy’ approachRe-purpose existing mobile phone

Hardware is known to be workingNo prototyping, hardware revisions, etc.Reverse engineering requiredHardware drivers need to be writtenBut: More time to focus on the actual job: Protocol software

Searching for suitable phonesAs cheap as possibleReadily available: Many people can play with itAs old/simple as possible to keep complexity lowBaseband chipset with lots of leaked information




TheoryThe Baseband

Baseband chips with leaked information

Texas Instruments CalypsoDBB Documentation on cryptome.org and other sitesABB Documentation on Chinese phone developer websitesSource code of GSM stack / drivers was on sf.net (tsm30project)End of life, no new phones with Calypso since about 2008No cryptographic checks in bootloader

Mediatek MT622x chipsetsLots of Documentation on Chinese sitesSDK with binary-only GSM stack libraries on Chinese sites95 million produced/sold in Q1/2010

Initial choice: TI Calypso (GSM stack source available)




OsmocomBB IntroductionOsmocomBB ArchitectureOsmocomBB SoftwareOsmocomBB Hardware SupportOsmocomBB Project Status

OsmocomBB Introduction

Project was started only in January 2010 (9 months ago!)Implementing a GSM baseband software from scratchThis includes

GSM MS-side protocol stack from Layer 1 through Layer 3Hardware drivers for GSM Baseband chipsetSimple User Interface on the phone itselfVerbose User Interface on the PC

Note about the strange project nameOsmocom = Open Source MObile COMmunicationBB = Base Band





OsmocomBB Software Architecture

Reuse code from OpenBSC where possible (libosmocore)We build libosmocore both for phone firmware and PC

Initially run as little software in the phoneDebugging code on your host PC is so much easierYou have much more screen real-estateHardware drivers and Layer1 run in the phoneLayer2, 3 and actual phone application / MMI on PCLater, L2 and L3 can me moved to the phone





OsmocomBB Software Interfaces

Interface between Layer1 and Layer2 called L1CTLFully custom protocol as there is no standardImplemented as message based protocol overSercomm/HDLC/RS232

Interface between Layer2 and Layer3 called RSLmsIn the GSM network, Um Layer2 terminates at the BTS butis controlled by the BSCReuse this GSM 08.58 Radio Signalling LinkExtend it where needed for the MS case





OsmocomBB Target Firmware

Firmware includes software likeDrivers for the Ti Calypso Digital Baseband (DBB)Drivers for the Ti Iota TWL3025 Analog Baseband (ABB)Drivers for the Ti Rita TRF6151 RF TransceiverDrivers for the LCD/LCM of a number of phonesCFI flash driver for NOR flashGSM Layer1 synchronous/asynchronous partSercomm - A HDLC based multiplexer for the RS232 tohost PC





OsmocomBB Host Software

Current working name: layer23Includes

Layer 1 Control (L1CTL) protocol APIGSM Layer2 implementation (LAPDm)GSM Layer3 implementation (RR/MM/CC)GSM Cell (re)selectionSIM Card emulationSupports various ’apps’ depending on purpose





OsmocomBB Supported Hardware

Baseband ChipsetsTI Calypso/Iota/RitaSome early research being done on Mediatek (MTK)MT622x

Actual PhonesCompal/Motorola C11x, C12x, C13x, C14x and C15xmodelsMost development/testing on C123 and C155GSM modem part of Openmoko Neo1973 and Freerunner

All those phones are simple feature phones built on aARM7TDMI based DBB





The Motorola/Compal C123





OsmocomBB Project Status: Working

Hardware Drivers for Calypso/Iota/Rita very completeDrivers for Audio/Voice signal pathLayer1

Power measurementsCarrier/bit/TDMA synchronizationReceive and transmit of normal bursts on SDCCHTransmit of RACH burstsAutomatic Rx gain control (AGC)Frequency Hopping

Layer2 UI/SABM/UA frames and ABM modeLayer3 Messages for RR / MM / CCCell (re)selection according GSM 03.22





OsmocomBB Project Status: Working (2/2)

OsmocomBB can now do GSM Voice calls (08/2010)Very Early Assignment + Late AssignmentA3/A8 Authentication of SIMA5/1 + A5/2 EncryptionFull Rate (FR) and Enhanced Full Rate (EFR) codec





OsmocomBB Project Status: Not working

Layer1Neighbor Cell MeasurementsIn-call hand-over to other cells

Actual UI on the phoneCircuit Switched Data (CSD) callsGPRS (packet data)No Type Approval for the stack!





OsmocomBB Project Status: Executive Summary

We can establish control/signalling channels to bothhopping and non-hopping GSM cells

Control over synthesizer means we can even go to GSM-Rband

We can send arbitrary data on those control channelsRR messages to BSCMM/CC messages to MSCSMS messages to MSC/SMSC

TCH (Traffic Channel) support for voice callsDieter Spaar and Andreas Eversberg have made multiple20 minute call with current master branchSome people have tried alpha code on real networks forreal 30+ minute calls!




What we’ve learnedWhere we go from hereFurther Reading

SummaryWhat we’ve learned

The GSM industry is making security analysis very difficultIt is well-known that the security level of the GSM stacks isvery lowWe now have multiple solutions for sending arbitraryprotocol data

From a rogue network to phones (OpenBSC, OpenBTS)From an A-bis proxy to the network or the phonesFrom custom GSM phone baseband firmware to thenetwork





TODOWhere we go from here

The basic tools for fuzzing mobile networks are availableNo nice interface/integration from OsmocomBB to scapyyetIt is up to the security community to make use of thosetools (!)Don’t you too think that TCP/IP security is boringJoin the GSM protocol security research projectsBoldly go where no man has gone before





Thanks

I would like to express my thanks toThe OsmocomBB development team, most notably

Dieter Spaar (invaluable dedication to this project!)Andreas Eversberg (layer 3, cell selection, etc.)Sylvain Munaut (layer1, dsp, misc.)

Other developers working on Open Source GSM stuffg3gg0 (MADos)David Burgess, Harvind Simra (OpenBTS)Holger Freythehr (OpenBSC)





Further Reading


http://bb.osmocom.org/

http://openbsc.gnumonks.org/

http://openbts.sourceforge.net/

http://airprobe.org/



http://bb.osmocom.org/

http://openbsc.gnumonks.org/

http://openbts.sourceforge.net/

http://airprobe.org/

osmocombb - free software gsm baseband … network security introduction security problems and the...

Documents