diff options
Diffstat (limited to '2010')
134 files changed, 18384 insertions, 0 deletions
diff --git a/2010/easycard-ccc2010/easycard.pdf b/2010/easycard-ccc2010/easycard.pdf Binary files differnew file mode 100644 index 0000000..e5e98ba --- /dev/null +++ b/2010/easycard-ccc2010/easycard.pdf diff --git a/2010/easycard-ccc2010/easycard.tex b/2010/easycard-ccc2010/easycard.tex new file mode 100644 index 0000000..e3975a1 --- /dev/null +++ b/2010/easycard-ccc2010/easycard.tex @@ -0,0 +1,486 @@ +% $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{Reverse Engineering a real-world RFID payment system} + +\subtitle +{How the EasyCard allows you to print your own digital money} + +\author{Harald Welte} + +\institute +{hmw-consulting.de\\gnumonks.org\\gpl-violations.org\\osmocom.org} +% - Use the \inst command only if there are several affiliations. +% - Keep it simple, no one is interested in your street address. + +\date[27c3] % (optional, should be abbreviation of conference name) +{27th CCC Congress, December 2010, Berlin/Germany} +% - 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{RFID 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 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) + \item Open Source hardware/firmware/software for RFID: librfid, OpenPCD, OpenPICC +\end{itemize} +\end{frame} + +\section{The EasyCard system} + +\subsection{Introducing the EasyCard} + +\begin{frame}{Travelling to Taipei} +Starting from 2006, I was doing a lot of freelancing work for companies in +Taiwan, resulting in numerous business trips to the capital Taipei. As soon +as you use public transport, you notice they are using an RFID based system +called EasyCard. + +This was just after having worked extensively on the {\bf OpenPCD} RFID +reader and {\bf OpenPICC} RFID tag simulator. + +However, work kept me too busy to ever have a look at the EasyCard until 2010. +\end{frame} + +\begin{frame}{What is this EasyCard?} + \begin{figure}[h] + \centering + \includegraphics[width=100mm]{easycard_wikipedia.png} + \end{figure} +\end{frame} + +\begin{frame}{EasyCard}{One of Asia's most popular electronic payment systems} +\begin{itemize} + \item EasyCard is used in Taiwan, mostly in the capital Taipei + \item Originally deployed in 2001 + \item More than 18 million issued cards + \item Initially a payment system for public transport + \begin{itemize} + \item Taipei metro (MRT) + \item Taipei public bus + \end{itemize} + \item Similar to many other systems like Oystercard +\end{itemize} +\end{frame} + +\subsection{EasyCard for Public Transport} + +\begin{frame}{EasyCard as payment in public transport} + \begin{figure}[h] + \centering + \includegraphics[width=100mm]{easycard_transport.png} + \end{figure} +\end{frame} + +\begin{frame}{EasyCard sale, recharge and refund} +\begin{itemize} + \item Cards are purchased at vending machines located in every subway station + \begin{itemize} + \item Price is 500 NTD: 400 NTD value, 100 NTD deposit + \item Payment is made in cash + \item Thus, no credit card / account number linking a person to a card + \end{itemize} + \item Full refund of the account balance and the deposit can be made at a cashier + \item Adding value to the card is made by the same machines that sell the cards +\end{itemize} +\end{frame} + +\begin{frame}{Threat analysis / Fraud potential} +\begin{itemize} + \item It is publicly known that EasyCard uses NXP MiFARE + \item MiFARE {\em Classic} has been broken in various ways before, ranging from eavesdropping attacks to card-only attacks. + \item However, the card itself is only one element in the security chain + \item EasyCard using MiFARE does not by itself mean that the EasyCard system is broken +\end{itemize} +\end{frame} + +\begin{frame}{Online or Offline validation} +\begin{itemize} + \item EasyCard could have been a relatively safe system, if + \begin{itemize} + \item the value was not stored on the card but in the back-end + \item all transactions would inquire the back-end and not only the card + \end{itemize} + \item I never really bothered to do much analysis, considering that all you could get is fraudulent free rides for public transport (which are cheap anyway) +\end{itemize} +\end{frame} + + +\subsection{April 2010: EasyCard as means of payment} + +\begin{frame}{EasyCard for payment in stores} +\begin{itemize} + \item In 2009, the government creates laws for stored-value cards as means of payment + \item In early 2010, use of the EasyCard is extended beyond public transport + \begin{itemize} + \item you can store up to 10,000 NTD (~ 240 EUR) on the card + \item the card is accepted at lots of stores (mostly big brands) + \end{itemize} + \item The attack incentive is much higher: Not only free metro rides, but suddenly you can buy basically any goods available in the largest department stores +\end{itemize} +\end{frame} + + +\begin{frame}{EasyCard as payment in stores} + \begin{figure}[h] + \centering + \includegraphics[width=100mm]{easycard_stores.png} + \end{figure} +\end{frame} + +\section{Analyzing the EasyCard} + +\begin{frame}{What is MiFARE classic?} +\begin{itemize} + \item A 13.56 MHz RFID card system based on ISO 14443 (1,2,3) + \item 1024 or 4096 bits of storage, divided in sectors and blocks + \item Uses proprietary 48bit cipher (CRYPTO1) + \item Manufacturer and customers {\em really believed} in Security by obscurity ?!? + \item Nobody should ever have used it for any application requiring security + \item Weaknesses first published at 24C3 by Henryk Ploetz and Karsten Nohl +\end{itemize} +\end{frame} + +\subsection{Recovering the MiFARE keys} + +\begin{frame}{Analyzing the EasyCard} +\begin{itemize} + \item First step: Verify it it indeed MIFARE classic + \begin{itemize} + \item Can be done by applying ISO1443-1/2 air interface and ISO14443-3 anti-collision procedure and checking the result values + \end{itemize} + \item Next step: Recovering the keys + \begin{itemize} + \item many cards have one ore more sectors using the default manufacturer keys + \item if one sector key is known, breaking the other keys is fast/easy by means of a publicized existing attack + \item EasyCard uses custom keys for all sector, no success + \end{itemize} +\end{itemize} +\end{frame} + +\begin{frame}{Recovering the keys} +\begin{itemize} + \item As all keys are unknown, the card-only {\em Dark Side} attack (Nicolas T. Courtios) was used + \item Open Source {\tt MFCUK} (MiFare Classic Universal toolKit) program implements the attack + \item All hardware required is a RFID reader supported by libnfc (EUR 30) + \item All A and B keys for all sectors have been recovered within 3 hours + \begin{itemize} + \item Attack time could be much shorter if proxmark with very tight timing control was used + \end{itemize} +\end{itemize} +\end{frame} + +\subsection{Understanding card content} + +\begin{frame}{Extracting raw content} +\begin{itemize} + \item Once the keys are known, the full data content of the card can be dumped + \item Free Software {\tt nfc-mfclassic} program (part of {\tt libnfc}) was used + \item All hardware required is a RFID reader supported by libnfc (EUR 30) +\end{itemize} +\end{frame} + +\begin{frame}{Re-engineering the data format} +\begin{itemize} + \item The raw card content is not of much use unless it can be interpreted + \item Individual transactions need to be made, raw card dumps acquired before/after each transaction + \item Analysis of modifications caused by single transaction allow conclusions on data format + \item Repeat this with transactions like + \begin{itemize} + \item entering a metro station + \item leaving a metro station + \item recharging the card + \item purchasing something using the card + \end{itemize} +\end{itemize} +\end{frame} + +\subsection{EasyCard data format} + +\begin{frame}{Sector 2: EasyCard balance} +\begin{itemize} + \item MIFARE value blocks are intended for counters that can be incremented/decremented by different keys + \item The actual counter value is stored three times (inverted/non-inverted) for safety + \item EasyCard uses MIFARE value block in sector 2 + \item The value 1:1 represents the account balance of the card in NTD +\end{itemize} +\end{frame} + +\begin{frame}{Sectors 3 through 5: Transaction Log} +\begin{itemize} + \item Each 16-byte block in sectors 3 through 5 contains one transaction log record + \item Each record contains + \begin{itemize} + \item Transaction ID, Cost, Remaining Balance, MRT Station code, RFID reader ID + \item Transaction Type (Entering/leaving MRT, re-entering / connecting MRT, purchase, recharge + \item Timestamp is a 32bt unix time() format (seconds since January 1st 1970). However, it refers to CST instead of UTC + \end{itemize} +\end{itemize} +\end{frame} + +\begin{frame}{How to decode the MRT Station Code} +\begin{itemize} + \item Transaction log record contains MRT station code + \item How to know which station name corresponds to the numeric code? + \begin{itemize} + \item Option A: visit each of them and take a EasyCard raw dump + \item Option B: visit the MRT homepage, point mouse at a specific station on the map and look at the URL: It contains the same ID! + \end{itemize} +\end{itemize} +\end{frame} + +\begin{frame}{EasyCard MRT station codes} + \begin{figure}[h] + \centering + \includegraphics[width=105mm]{easycard_mrt_station_number.png} + \end{figure} +\end{frame} + + +\begin{frame}{Sector 7: Last MRT entry/exit record} +\begin{itemize} + \item Block 2 (Offset 0x1e0) contains a record describing the last MRT station that was entered + \begin{itemize} + \item Byte 4 contains the MRT station code + \item Bytes 9..12 contain a timestamp + \end{itemize} + \item Block 1 (Offset 0xd0) contains a similar record describing the last MRT station that was left + \item It is assumed that this information is used to compute the distance (and thus fee) to be paid for the current ride, as well as the discount that is made when switching from MRT to bus. +\end{itemize} +\end{frame} + +\begin{frame}{Sector 15: Maximum daily spending} +\begin{itemize} + \item Block 2 (offset 0x3e0) contains a record keeping track of the amount of money spent on a single day + \begin{itemize} + \item Bytes 0..10 are unknown (all zero) + \item Byte 11 contains the day of the month + \item Byte 12 contains an unknown value (0x3d on all tested cards) + \item Byte 13..14 contains the sum of all purchases on the indicated day + \end{itemize} + \item This is used to impose a daily spending limit of NTD 3,000. +\end{itemize} +\end{frame} + +\section{Tampering with the EasyCard} + +\begin{frame}{Tampering with the EasyCard} +\begin{itemize} + \item After recovering keys + understanding the format, tampering with the card is easy + \item Testing purchases with tampered card permits validation of the offline vs. online question + \item Possible manipulations + \begin{itemize} + \item Decreasing the value on the card + \item Increasing the value on the card + \item Bypassing the daily spending limit + \end{itemize} +\end{itemize} +\end{frame} + +\subsection{Decreasing the value of the card} + +\begin{frame}{Decreasing the value of the card} +\begin{itemize} + \item Make a purchase in a store that accepts the EasyCard + \item Find the transaction log entry and increase the cost of the purchase + \item Decrement the value block storing the card balance by the same amount + \begin{itemize} + \item Make sure you get the value block modifications right (inverted, non-inverted, backup copy) + \end{itemize} + \item Alter the {\em amount spent per day} (Sector 15) to reflect increased amount +\end{itemize} +\end{frame} + +\begin{frame}{Decreasing the value of the card} +\begin{itemize} + \item A card was manipulated accordingly + \item The card behaved like expected, i.e. + \begin{itemize} + \item it had less value remaining + \item it was still possible to use it in stores and public transport + \item the artificially removed money could not be spent + \item the card could still be re-charged at recharge machines, without ever recovering the artificially removed amount + \end{itemize} +\end{itemize} +\end{frame} + +\subsection{Increasing the value of the card} + +\begin{frame}{Increasing the value of the card} +\begin{itemize} + \item Make a purchase in a store that accepts the EasyCard + \item Find the transaction log entry and {\bf decrease} the cost of the purchase + \item Increment the value block storing the card balance by the same amount + \begin{itemize} + \item Make sure you get the value block modifications right (inverted, non-inverted, backup copy) + \end{itemize} + \item Alter the {\em amount spent per day} (Sector 15) to reflect reduced amount +\end{itemize} +\end{frame} + +\begin{frame}{Increasing the value of the card} +\begin{itemize} + \item A card was manipulated accordingly + \item The card behaved like expected, i.e. + \begin{itemize} + \item it had more value remaining + \item it was possible to use it in stores and public transport + \item the artificially removed money could all be spent (!) + \item the card could still be re-charged at recharge machines, without ever loosing the artificially added amount + \end{itemize} +\end{itemize} +{\bf NOTE:} The artificially added money was immediately added by recharging the card at a recharge machine. The amount stored on the card has been reduced by the previously added amount. No fraud was committed! +\end{frame} + +\subsection{easytool} + +\begin{frame}{Introducing {\tt easytool}} +\begin{itemize} + \item Information regarding the data format of the card implemented as C header file / structs + \item C program {\tt easytool} created to decode cards contents + \item Later, code to decrement/increment amount was added + \item Tool has not been released publicly + \item Read-only version of the tool might be released soon +\end{itemize} +\end{frame} + + +\begin{frame}{Summary} +\begin{itemize} + \item Using MIFARE classic or any RFID system based on security by obscurity is irresponsible + \item Extending a MIFARE classic based public transport payment system to general payment system in the year 2010 is nothing but ignorant, clueless and a sign of gross negligence + \item Government regulartors should mandate the use of publicly and independently audited and reviewed security technology. Security by obscurity is not an answer to any problem. +\end{itemize} +\end{frame} + +\begin{frame}{Thanks} +I would like to express my thanks to +\begin{description}[Henryk Ploetz, Karsten Nohl, starbug] + \item[Brita and Milosch Meriac] for OpenPCD and OpenPICC + \item[Henryk Ploetz, Karsten Nohl, starbug] for their work on CRYPTO1 + \item[Jonathan Westhues] for his work on Proxmark + \item[Nethemba] for implementing the nested key attack in MFOC + \item[Roel Verdult] for libnfc + \item[Nicolas T. Courtois] for his {\em darkside} paper + \item[Andrei Costin] for his MFCUK implementation of the {\em darkside} paper +\end{description} +\end{frame} + +\end{document} diff --git a/2010/easycard-ccc2010/easycard_mrt_station_number.png b/2010/easycard-ccc2010/easycard_mrt_station_number.png Binary files differnew file mode 100644 index 0000000..e5a03e6 --- /dev/null +++ b/2010/easycard-ccc2010/easycard_mrt_station_number.png diff --git a/2010/easycard-ccc2010/easycard_stores.png b/2010/easycard-ccc2010/easycard_stores.png Binary files differnew file mode 100644 index 0000000..f6ea23b --- /dev/null +++ b/2010/easycard-ccc2010/easycard_stores.png diff --git a/2010/easycard-ccc2010/easycard_transport.png b/2010/easycard-ccc2010/easycard_transport.png Binary files differnew file mode 100644 index 0000000..ce230e9 --- /dev/null +++ b/2010/easycard-ccc2010/easycard_transport.png diff --git a/2010/easycard-ccc2010/easycard_wikipedia.png b/2010/easycard-ccc2010/easycard_wikipedia.png Binary files differnew file mode 100644 index 0000000..72944f7 --- /dev/null +++ b/2010/easycard-ccc2010/easycard_wikipedia.png diff --git a/2010/gpl_compliance-openfoundry2010/abstract.txt b/2010/gpl_compliance-openfoundry2010/abstract.txt new file mode 100644 index 0000000..91f3463 --- /dev/null +++ b/2010/gpl_compliance-openfoundry2010/abstract.txt @@ -0,0 +1,14 @@ +GNU GPL Compliance in Embedded Devices + +GNU/Linux is a the most popular choice of an Operating System in many areas +of Embedded computing. It can be found in embedded networking equipment, +personal navigation systems, media players, mobile phones to print servers, +NAS, in-flight entertainment systems and even bicycle ergometers. + +Using the Linux kernel and other GPL licensed software is a convenient and +especially inexpensive choice. However, it is still copyrighted software +subject to a license: The GNU General Public License. + +The presentation will look at typical GPL violations in the embedded market +and how they could have easily been avoided by little extra effort in +product development. diff --git a/2010/gpl_compliance-openfoundry2010/handoutWithNotes.sty b/2010/gpl_compliance-openfoundry2010/handoutWithNotes.sty new file mode 100644 index 0000000..e25e965 --- /dev/null +++ b/2010/gpl_compliance-openfoundry2010/handoutWithNotes.sty @@ -0,0 +1,466 @@ +% Copyright 2009 by Guido Diepen <guido@guidodiepen.nl> +% Parts provided by Edson Valle +% +% This file may be distributed and/or modified +% +% 1. under the LaTeX Project Public License and/or +% 2. under the GNU Public License. +% +% Changelog +% 20091108 - Added "2 on 1 with notes landscape" layout, provided by Edson Valle +% 20091104 - Added "3 on 1 with notes" layout +% 20091104 - Added "2 on 1 with notes" layout +% 20091104 - Added "1 on 1 with notes landscape" layout, provided by Edson Valle +% 20090101 - Initial Version + +\RequirePackage{pgfpages} + \pgfpagesdeclarelayout{1 on 1 with notes portrait} { + \edef\pgfpageoptionheight{\the\paperwidth} + \edef\pgfpageoptionwidth{\the\paperheight} + \edef\pgfpageoptionborder{0pt} + } + { + \setkeys{pgfpagesuselayoutoption}{portrait} + \pgfpagesphysicalpageoptions + {% + logical pages=2,% + physical height=\pgfpageoptionheight,% + physical width=\pgfpageoptionwidth,% +% last logical shipout=3% + last logical shipout=1% + } + + \pgfpageslogicalpageoptions{1} + {% + scale=1.5, + center=\pgfpoint{.5\pgfphysicalwidth}{.73\pgfphysicalheight}% + }% + + + + \pgfpageslogicalpageoptions{2} + {% + border shrink=\pgfpageoptionborder,% + resized width=\pgfphysicalwidth,% + resized height=\pgfphysicalheight,% + center=\pgfpoint{.5\pgfphysicalwidth}{.25\pgfphysicalheight},% + copy from=2 + }% + + \AtBeginDocument{ + \newbox\notesbox + \setbox\notesbox=\vbox{ + \hsize=.85\paperwidth + \vskip-1in\hskip-1in\vbox{ + \vskip1cm + Notes\vskip5mm + \hrule width\paperwidth\vskip5mm + \hrule width\paperwidth\vskip5mm + \hrule width\paperwidth\vskip5mm + \hrule width\paperwidth\vskip5mm + \hrule width\paperwidth\vskip5mm + \hrule width\paperwidth\vskip5mm + \hrule width\paperwidth\vskip5mm + \hrule width\paperwidth\vskip5mm + \hrule width\paperwidth\vskip5mm + \hrule width\paperwidth\vskip5mm + \hrule width\paperwidth\vskip5mm + \hrule width\paperwidth\vskip5mm + \hrule width\paperwidth\vskip5mm + \hrule width\paperwidth\vskip5mm + \hrule width\paperwidth} + } + \pgfpagesshipoutlogicalpage{2}\copy\notesbox + + + } + } + + \pgfpagesdeclarelayout{1 on 1 with notes landscape} { + \edef\pgfpageoptionheight{\the\paperwidth} + \edef\pgfpageoptionwidth{\the\paperheight} + \edef\pgfpageoptionborder{0pt} + } + { + \setkeys{pgfpagesuselayoutoption}{landscape} + \pgfpagesphysicalpageoptions + {% + logical pages=2,% + physical height=\pgfpageoptionheight,% + physical width=\pgfpageoptionwidth,% +% last logical shipout=3% + last logical shipout=1% + } + + \pgfpageslogicalpageoptions{1} + {% + scale=1.2, + center=\pgfpoint{.3\pgfphysicalwidth}{.5\pgfphysicalheight}% + }% + + + + \pgfpageslogicalpageoptions{2} + {% + border shrink=\pgfpageoptionborder,% + resized width=.45\pgfphysicalwidth,% + resized height=.45\pgfphysicalheight,% + center=\pgfpoint{.78\pgfphysicalwidth}{.6\pgfphysicalheight},% + copy from=2 + }% + + \AtBeginDocument{ + \newbox\notesbox + \setbox\notesbox=\vbox{ + \hsize=\paperwidth + \vskip-1in\hskip-1in\vbox{ + \vskip1cm + Notes\vskip1cm + \hrule width\paperwidth\vskip1cm + \hrule width\paperwidth\vskip1cm + \hrule width\paperwidth\vskip1cm + \hrule width\paperwidth\vskip1cm + \hrule width\paperwidth\vskip1cm + \hrule width\paperwidth\vskip1cm + \hrule width\paperwidth\vskip1cm + \hrule width\paperwidth\vskip1cm + \hrule width\paperwidth\vskip1cm + \hrule width\paperwidth\vskip1cm + \hrule width\paperwidth\vskip1cm + \hrule width\paperwidth} + } + \pgfpagesshipoutlogicalpage{2}\copy\notesbox + + + } + } + + \pgfpagesdeclarelayout{4 on 1 with notes} { + \edef\pgfpageoptionheight{\the\paperheight} + \edef\pgfpageoptionwidth{\the\paperwidth} + \edef\pgfpageoptionborder{0pt} + } + { + \pgfpagesphysicalpageoptions + {% + logical pages=8,% + physical height=\pgfpageoptionheight,% + physical width=\pgfpageoptionwidth,% +% last logical shipout=3% + last logical shipout=4% + } + + \pgfpageslogicalpageoptions{1} + {% + scale=.70, + center=\pgfpoint{.25\pgfphysicalwidth}{.875\pgfphysicalheight}% + }% + \pgfpageslogicalpageoptions{2} + {% + scale=.70, + center=\pgfpoint{.25\pgfphysicalwidth}{.625\pgfphysicalheight}% + }% + + \pgfpageslogicalpageoptions{3} + {% + scale=.70, + center=\pgfpoint{.25\pgfphysicalwidth}{.375\pgfphysicalheight}% + }% + + \pgfpageslogicalpageoptions{4} + {% + scale=.70, + center=\pgfpoint{.25\pgfphysicalwidth}{.125\pgfphysicalheight}% + }% + + + + + + + + + \pgfpageslogicalpageoptions{5} + {% + border shrink=\pgfpageoptionborder,% + resized width=.5\pgfphysicalwidth,% + resized height=.3333\pgfphysicalheight,% + center=\pgfpoint{.75\pgfphysicalwidth}{.875\pgfphysicalheight},% + copy from=5 + }% + \pgfpageslogicalpageoptions{6} + {% + border shrink=\pgfpageoptionborder,% + resized width=.5\pgfphysicalwidth,% + resized height=.3333\pgfphysicalheight,% + center=\pgfpoint{.75\pgfphysicalwidth}{.625\pgfphysicalheight},% + copy from=6 + }% + \pgfpageslogicalpageoptions{7} + {% + border shrink=\pgfpageoptionborder,% + resized width=.5\pgfphysicalwidth,% + resized height=.3333\pgfphysicalheight,% + center=\pgfpoint{.75\pgfphysicalwidth}{.375\pgfphysicalheight},% + copy from=7 + }% + \pgfpageslogicalpageoptions{8} + {% + border shrink=\pgfpageoptionborder,% + resized width=.5\pgfphysicalwidth,% + resized height=.3333\pgfphysicalheight,% + center=\pgfpoint{.75\pgfphysicalwidth}{.125\pgfphysicalheight},% + copy from=8 + }% + \AtBeginDocument{ + \newbox\notesbox + \setbox\notesbox=\vbox{ + \hsize=\paperwidth + \vskip-1in\hskip-1in\vbox{ + \vskip1cm + Notes\vskip1cm + \hrule width\paperwidth\vskip1cm + \hrule width\paperwidth\vskip1cm + \hrule width\paperwidth\vskip1cm + \hrule width\paperwidth\vskip1cm + \hrule width\paperwidth\vskip1cm + \hrule width\paperwidth\vskip1cm + \hrule width\paperwidth} + } + \pgfpagesshipoutlogicalpage{5}\copy\notesbox + \pgfpagesshipoutlogicalpage{6}\copy\notesbox + \pgfpagesshipoutlogicalpage{7}\copy\notesbox + \pgfpagesshipoutlogicalpage{8}\copy\notesbox + } + } + + + + \pgfpagesdeclarelayout{2 on 1 with notes} { + \edef\pgfpageoptionheight{\the\paperheight} + \edef\pgfpageoptionwidth{\the\paperwidth} + \edef\pgfpageoptionborder{0pt} + } + { + \pgfpagesphysicalpageoptions + {% + logical pages=4,% + physical height=\pgfpageoptionheight,% + physical width=\pgfpageoptionwidth,% +% last logical shipout=3% + last logical shipout=2% + } + + \pgfpageslogicalpageoptions{1} + {% + scale=.70, + center=\pgfpoint{.25\pgfphysicalwidth}{.67\pgfphysicalheight}% + }% + \pgfpageslogicalpageoptions{2} + {% + scale=.70, + center=\pgfpoint{.25\pgfphysicalwidth}{.33\pgfphysicalheight}% + }% + + + \pgfpageslogicalpageoptions{3} + {% + border shrink=\pgfpageoptionborder,% + resized width=.5\pgfphysicalwidth,% + resized height=.5\pgfphysicalheight,% + center=\pgfpoint{.75\pgfphysicalwidth}{.67\pgfphysicalheight},% + copy from=3 + }% + \pgfpageslogicalpageoptions{4} + {% + border shrink=\pgfpageoptionborder,% + resized width=.5\pgfphysicalwidth,% + resized height=.5\pgfphysicalheight,% + center=\pgfpoint{.75\pgfphysicalwidth}{.33\pgfphysicalheight},% + copy from=4 + }% + + \AtBeginDocument{ + \newbox\notesbox + \setbox\notesbox=\vbox{ + \hsize=\paperwidth + \vskip-1in\hskip-1in\vbox{ + \vskip1cm + Notes\vskip1cm + \hrule width\paperwidth\vskip1cm + \hrule width\paperwidth\vskip1cm + \hrule width\paperwidth\vskip1cm + \hrule width\paperwidth\vskip1cm + \hrule width\paperwidth\vskip1cm + \hrule width\paperwidth\vskip1cm + \hrule width\paperwidth} + } + \pgfpagesshipoutlogicalpage{3}\copy\notesbox + \pgfpagesshipoutlogicalpage{4}\copy\notesbox + } + } + + + \pgfpagesdeclarelayout{3 on 1 with notes} { + \edef\pgfpageoptionheight{\the\paperheight} + \edef\pgfpageoptionwidth{\the\paperwidth} + \edef\pgfpageoptionborder{0pt} + } + { + \pgfpagesphysicalpageoptions + {% + logical pages=6,% + physical height=\pgfpageoptionheight,% + physical width=\pgfpageoptionwidth,% +% last logical shipout=3% + last logical shipout=3% + } + + \pgfpageslogicalpageoptions{1} + {% + scale=.70, + center=\pgfpoint{.25\pgfphysicalwidth}{.82\pgfphysicalheight}% + }% + \pgfpageslogicalpageoptions{2} + {% + scale=.70, + center=\pgfpoint{.25\pgfphysicalwidth}{.50\pgfphysicalheight}% + }% + \pgfpageslogicalpageoptions{3} + {% + scale=.70, + center=\pgfpoint{.25\pgfphysicalwidth}{.18\pgfphysicalheight}% + }% + + + \pgfpageslogicalpageoptions{4} + {% + border shrink=\pgfpageoptionborder,% + resized width=.5\pgfphysicalwidth,% + resized height=.5\pgfphysicalheight,% + center=\pgfpoint{.75\pgfphysicalwidth}{.82\pgfphysicalheight},% + copy from=4 + }% + \pgfpageslogicalpageoptions{5} + {% + border shrink=\pgfpageoptionborder,% + resized width=.5\pgfphysicalwidth,% + resized height=.5\pgfphysicalheight,% + center=\pgfpoint{.75\pgfphysicalwidth}{.50\pgfphysicalheight},% + copy from=5 + }% + \pgfpageslogicalpageoptions{6} + {% + border shrink=\pgfpageoptionborder,% + resized width=.5\pgfphysicalwidth,% + resized height=.5\pgfphysicalheight,% + center=\pgfpoint{.75\pgfphysicalwidth}{.18\pgfphysicalheight},% + copy from=6 + }% + + \AtBeginDocument{ + \newbox\notesbox + \setbox\notesbox=\vbox{ + \hsize=\paperwidth + \vskip-1in\hskip-1in\vbox{ + \vskip1cm + Notes\vskip1cm + \hrule width\paperwidth\vskip1cm + \hrule width\paperwidth\vskip1cm + \hrule width\paperwidth\vskip1cm + \hrule width\paperwidth\vskip1cm + \hrule width\paperwidth\vskip1cm + \hrule width\paperwidth\vskip1cm + \hrule width\paperwidth} + } + \pgfpagesshipoutlogicalpage{4}\copy\notesbox + \pgfpagesshipoutlogicalpage{5}\copy\notesbox + \pgfpagesshipoutlogicalpage{6}\copy\notesbox + } + } + + + + + + \pgfpagesdeclarelayout{2 on 1 with notes landscape} { + \edef\pgfpageoptionheight{\the\paperheight} + \edef\pgfpageoptionwidth{\the\paperwidth} + \edef\pgfpageoptionborder{0pt} + } + { + \setkeys{pgfpagesuselayoutoption}{landscape} + \pgfpagesphysicalpageoptions + {% + logical pages=4,% + physical height=\pgfpageoptionheight,% + physical width=\pgfpageoptionwidth,% +% last logical shipout=3% + last logical shipout=2% + } + + \pgfpageslogicalpageoptions{1} + {% + scale=1, + center=\pgfpoint{.3\pgfphysicalwidth}{.75\pgfphysicalheight}% + }% + \pgfpageslogicalpageoptions{2} + {% + scale=1, + center=\pgfpoint{.3\pgfphysicalwidth}{.25\pgfphysicalheight}% + }% + + + + \pgfpageslogicalpageoptions{3} + {% + border shrink=\pgfpageoptionborder,% + resized width=.7\pgfphysicalwidth,% + resized height=.4\pgfphysicalheight,% + center=\pgfpoint{.75\pgfphysicalwidth}{.3\pgfphysicalheight},% + copy from=3 + }% + + \pgfpageslogicalpageoptions{4} + {% + border shrink=\pgfpageoptionborder,% + resized width=.7\pgfphysicalwidth,% + resized height=.4\pgfphysicalheight,% + center=\pgfpoint{.75\pgfphysicalwidth}{.8\pgfphysicalheight},% + copy from=4 + }% + + \AtBeginDocument{ + \newbox\notesbox + \setbox\notesbox=\vbox{ + \hsize=\paperwidth + \vskip-1in\hskip-1in\vbox{ + \vskip1cm + Notes\vskip1cm + \hrule width\paperwidth\vskip1cm + \hrule width\paperwidth\vskip1cm + \hrule width\paperwidth\vskip1cm + \hrule width\paperwidth\vskip1cm + \hrule width\paperwidth\vskip1cm + \hrule width\paperwidth\vskip1cm + %\hrule width\paperwidth\vskip1cm + %\hrule width\paperwidth\vskip1cm + \hrule width\paperwidth\vskip1cm + \hrule width\paperwidth\vskip1cm + \hrule width\paperwidth\vskip1cm + \hrule width\paperwidth} + } + \pgfpagesshipoutlogicalpage{3}\copy\notesbox + \pgfpagesshipoutlogicalpage{4}\copy\notesbox + + + } + } + + + + + + + + diff --git a/2010/gpl_compliance-openfoundry2010/license_compliance.pdf b/2010/gpl_compliance-openfoundry2010/license_compliance.pdf Binary files differnew file mode 100644 index 0000000..b5cc83d --- /dev/null +++ b/2010/gpl_compliance-openfoundry2010/license_compliance.pdf diff --git a/2010/gpl_compliance-openfoundry2010/license_compliance.tex b/2010/gpl_compliance-openfoundry2010/license_compliance.tex new file mode 100644 index 0000000..3209e92 --- /dev/null +++ b/2010/gpl_compliance-openfoundry2010/license_compliance.tex @@ -0,0 +1,571 @@ +% $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} +\documentclass[handout]{beamer} + +% 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} + \setbeamercovered{transparent} % or whatever (possibly just delete it) +} + +\mode<handout>{ + \usepackage{handoutWithNotes} + \pgfpagesuselayout{4 on 1 with notes}[a4paper,border shrink=5mm] + \usecolortheme{seahorse} +} + +% ensure the page number is printed in front of the author name in the footer +\newcommand*\oldmacro{} +\let\oldmacro\insertshortauthor% save previous definition +\renewcommand*\insertshortauthor{% + \leftskip=.3cm% before the author could be a plus1fill ... + \insertframenumber\,/\,\inserttotalframenumber\hfill\oldmacro} + + +\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{Free/Open Source Software License Compliance} + +\subtitle{With specific focus on GNU GPL} + +\author{Harald Welte} + +\institute +{gpl-violations.org\\gnumonks.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[OSSF 2010] % (optional, should be abbreviation of conference name) +{Academia Sinica, December 2010} +% - 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{Embedded Linux} +% 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 + % 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 development since 1999 +\item IT security expert, focus on network protocol security +\item Board-level Electrical Engineering +\item System-level Software for PPC, ARM, x86 +\item IANAL, but companies not complying with the license forced me to spend lots of time with legal issues +\end{itemize} +\end{frame} + + +\section{FOSS Licenses} + +\subsection{Free Software and Copyleft} + +\begin{frame}{Free Software}{Definition by the FSF} + % - A title should summarize the slide in an understandable fashion + % for anyone how does not follow everything on the slide itself. + Free Software has to ensure the following key freedoms: + \begin{itemize} + \item + Freedom to use the software for any purpose + \item + Freedom to make copies "to help your neighbor" + \item + Freedom to study its functionality (source code) + \item + Freedom to fix it yourself (make modifications) + \end{itemize} +\end{frame} + +\begin{frame}{Copyleft}{A concept to ensure Freedom} + Copyleft is an idea to use copyright to ensure Software Freedoms + \begin{itemize} + \item Use/claim copyright on the software + \item Create a license that is permissive enough for the 4 Freedoms + \item However, put some conditions/obligations in the license + \begin{itemize} + \item ensure the source code will always be available + \item ensure nobody is able to remove the 4 Freedoms from the software + \end{itemize} + \item Use that license for the software. + \end{itemize} +\end{frame} + +\subsection{The GNU GPL} + +\begin{frame}{The GNU GPL}{An implementation of Copyleft} +The GNU General Public License (GPL) +\begin{itemize} + \item is a Copyleft Free Software License + \item assures the original author that his work will always have the freedoms + \item establishes a level of fairness: You can use my code, if you share your additions back with us. + \item is a big motivation factor for many community members +\end{itemize} +\end{frame} + +\begin{frame}{Revisiting the GPLv2 License Terms} +The GNU GPLv2 +\begin{itemize} + \item Regulates distribution, not use (running the program) + \item Allows distribution of source code and modified source code, if + \begin{itemize} + \item The license is mentioned + \item A copy of the license text accompanies each copy + \end{itemize} + \item Allows distribution of or modified binaries, if + \begin{itemize} + \item The license is mentioned + \item A copy of the license text accompanies each copy + \item The source code is either included with the copy, or a written offer is made on how the source can be obtained. + \end{itemize} +\end{itemize} +\end{frame} + +\begin{frame}{Complete Corresponding Source Code}{As required by GPLv2} +\dots complete source code means all the source code for all modules it (the software) contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. +\begin{itemize} + \item For a C language program, this means + \begin{itemize} + \item Source Code + \item Makefiles + \item compile-time configuration (e.g. kernel .config) + \end{itemize} + \item General rule + \begin{itemize} + \item Intent of the license is to enable the user to run modified versions of the program + \item If you provide everything needed for that, there will be no discussion + \end{itemize} +\end{itemize} +\end{frame} + +\begin{frame}{Modifications of GPL'd source code}{The details that matter} +\begin{itemize} + \item In the GPL, it does not matter if you have modified the GPL'd program or if you ship it unmodified. + \item You always have to provide the source code! + \item If you modify the source code, your changes have to be visible/identifiable + \item For practical reasons, I suggest shipping original upstream tarball + a diff/patch with your changes +\end{itemize} +\end{frame} + +\subsection{GPL - Compatible source code offer} + +\begin{frame}{Complete + Corresponding Source}{For every Release you make} +\begin{itemize} +\item Whenever you {\em distribute} GPL licensed software, the license applies. This includes + \begin{itemize} + \item Actual sale of a physical embedded device with the software in flash + \item Download of a firmware update as a file from a website + \item Shipping of firmware updates on physical storage + \item Distribution of firmware updates e.g. by over-the-air mechanisms in DVB-S or other networks + \end{itemize} +\item Every time, the conditions of the license have to be fulfilled (mention there's software under GPL, include full license text, include or offer complete corresponding source code +\item For every release you ever ship (even beta release if it ever is shipped only to one customer), you need the {\em complete corresponding} source code. +\end{itemize} +\end{frame} + +\subsection{GPL - Derivative Works} + +\begin{frame}{Derivative Works}{Keeping it clean} +Derivative works are a question of copyright law, not the GPL +\begin{itemize} +\item whenever you couple a GPL and a non-GPL program tightly (e.g. static/dynamic linking), you're entering a legal grey area +\item there is little or no precedent on derivative works of software +\item you're violating the intention of the author. If he wanted you to link from proprietary programs, he would have used LGPL +\item try to work {\em with} the community, rather than against it +\end{itemize} +\end{frame} + +\begin{frame}{Intermission} +Take a break, go one step back +\begin{itemize} +\item The License is not a means to itself +\item Intent of the license is to make sure people can modify + enhance the product +\item The more open your product is, the less you have to worry +\item Using Linux + FOSS without enabling community to modify+enhance is cheating! +\item Try to make friends of the developer community, not enemies! +\end{itemize} +\end{frame} + +\begin{frame}{License compliance is not an afterthought} +Complying with the license terms is relatively easy {\em if} you consider the license terms {\em before} starting R\&D +\begin{itemize} +\item you can integrate building source releases in your build process +\item you can decide which software can be combined given the license terms +\end{itemize} +\end{frame} + +\begin{frame}{License compliance is not an afterthought} +Achieving license compliance after shipping the product is very hard +\begin{itemize} +\item lack of good engineering practise could mean old source code is gone +\item engineers working on the product might have left the company +\item you and your customers are under a lot of time pressure (legal threat) +\item you might have already shipped a derivative work to GPLd software and now have to release parts that you originally wanted to keep proprietary +\end{itemize} +\end{frame} + +\section{Linux and the Embedded Market} + +\subsection{Linux-based systems everywhere} + +\begin{frame}{Linux and Free Software (FOSS) everywhere} +\begin{figure}[h] +\centering +\includegraphics[width=100mm]{linux_netfilter_singapore_entertainment.jpg} +\end{figure} +\end{frame} + +\begin{frame}{Areas of Embedded Linux} +\begin{itemize} +\item Embedded Network Devices (DSL-Modem, Router, WiFi-AP, NAS) +\item Telecommunications equipment (Switch, DSLAM, ...) +\item In-flight / In-vehicle entertainment +\item Personal Navigation Devices (Tomtom GO) +\item Mobile Phones (EZX, MAGX, Android, LiMo, WebOS) +\item PoS terminals, ATMs, Payphones +\item Digital Media Players, Set-Top-Boxes, Video Recorder +\item Exercycles + Fitness Gear +\item Building automation + control +\item VoIP telephones, VoIP switches, PBX +\item e-Ink readers, Tablet computers, MIDs +\end{itemize} +\end{frame} + +\subsection{Embedded Linux supply chain} + +\begin{frame}{Embedded Linux Supply Chain} +In a typical case, the supply chain consists minimal of +\begin{itemize} +\item The silicon maker of the SoC containing the core that runs Linux +\item The supplier of the reference design / board for that SoC +\item The ODM building an actual circuit board using that SoC +\item The OEM selling the product under his brand in the target market +\end{itemize} +\end{frame} + +\begin{frame}{Embedded Linux Supply Chain} +Situation can be further complicated by +\begin{itemize} +\item A 3rd party supplier of the BSP / SDK for the SoC or reference board +\item Multiple companies involved on the ODM or OEM side (building parts of a product, later integration into the real product e.g. IVE for a car) +\item 3rd party suppliers of application programs (which might use FOSS) +\end{itemize} +\end{frame} + +\begin{frame}{Embedded Linux Supply Chain} +Problems in the supply chain: +\begin{itemize} +\item OEM has no clue what kind of software ODM put into the product +\item ODM has limited technical skill and has no clue what BSP provider did +\item End user buys a product with license/copyright violations and has no clue + \begin{itemize} + \item who the entities in the supply chain are + \item who actually caused the license/copyright violation + \end{itemize} +\end{itemize} +\end{frame} + +\subsection{GPL - Embedded Systems} + +\begin{frame}{GPL and Embedded Systems}{Interpreting the meaning} +\begin{itemize} +\item The GNU GPLv2 was written for the GNU project, at the time this project was +working on replacing individual application programs on top of a proprietary +UNIX operating system kernel. +\item scripts used to control compilation and installation + \begin{itemize} + \item Intent: To enable the user to modify + run modified versions + \item In case of embedded systems, the "scripts used to control installation" include the software required for installing the program onto the target device + \end{itemize} +\end{itemize} +\end{frame} + +\begin{frame}{GPL and Embedded DRM}{Sometimes called Tivo-ization} +\begin{itemize} +\item Some companies want to lock down their Linux-based system, by + \begin{itemize} + \item Cryptographic verification of bootloader by ROM loader + \item Cryptographic verification of kernel image by bootloader\dots + \end{itemize} +\item This is problematic from a GPL point of view, since + \begin{itemize} + \item You are depriving the user from practically exercising his right to run modified versions of the program + \item Thus, violation not of the GPLv2 wording, but likely of the GPL's intention + \item Legal outcome unclear, different scholars have different opinions, also depends on jurisdiction + \end{itemize} +\item GPLv3 makes this intent explicit in the license text +\end{itemize} +\end{frame} + +\section{GPL Violations and License Enforcement} + +\subsection{GPL Violations and Business Risks} + +\begin{frame}{GPL Violations} +\begin{itemize} +\item GPL violations are not new, just like GPL licensed software is not new +\item However, increased popularity of GNU/Linux based systems increase GPL violations +\item Today, many more people and companies unfamiliar with the history and values of Free Software start using and (re)distributing FOSS +\end{itemize} +\end{frame} + +\begin{frame}{Business Risk of GPL Violations}{Or: How to convince your managers} +If you ship a product that is incompliant to the GNU GPL, +\begin{itemize} +\item you are committing a copyright infringement not different from shipping a product with unlicensed copies of MS Windows +\item you can face civil and criminal charges in court +\item civil charges include (German jurisdiction) + \begin{itemize} + \item immediate cease + desist (halt of product sales) + \item information of which quantity of the product has been sold to whom + \item damages for lost revenue (see dual licensing) + \end{itemize} +\item civil charges can also be filed against every distributor/store/importer +\end{itemize} +\end{frame} + +\subsection{GPL Enforcement} + +\begin{frame}{Early GPL Enforcement} +\begin{itemize} +\item The Free Software Foundation (FSF) has alway been doing GPL enforcement on software {\em of which they are the copyright holder} + \begin{itemize} + \item They do so quietly, without much public notice + \item The quiet route sometimes leads to lengthy negotiations + \item The FSF only holds copyright on some Free Software programs + \end{itemize} +\end{itemize} +\end{frame} + +\begin{frame}{The Linksys WRT54G case} +During 2003, the Linksys WRT54G case drew a lot of attention +\begin{itemize} + \item Linksys was selling 802.11 WLAN Access Points and Routers + \item Lots of GPL licensed software embedded into the device, including Linux, uClibc, busybox, iptables + \item FSF-led alliance took their usual {\em quiet} approach + \item Linksys bought itself a lot of time + \begin{itemize} + \item Some sources were released two months later + \item Full GPL compliance only achieved four months later + \end{itemize} +\end{itemize} +\end{frame} + +\begin{frame}{Aftermath of the Linksys case} +\begin{itemize} + \item Some developers were not happy with the Linksys case + \begin{itemize} + \item Linksys didn't loose anything by not complying from the beginning + \item Four months delay is a long time given short product lifetimes + \end{itemize} + \item More embedded devices started to use Linux and other FOSS + \item The netfilter/iptables project started to do their own enforcement + \begin{itemize} + \item Using German copyright law against German subsidiary of vendor + \item Using direct legal / copyright based approach + \end{itemize} + \item The gpl-violations.org was later established +\end{itemize} +\end{frame} + +\begin{frame}{GPL Enforcement by the Community} +\begin{itemize} + \item The GPL is a Copyright License + \item GPL enforcement is thus Copyright enforcement + \item Copyright enforcement can normally only be done by copyright holders! + \item Alternative (less tested) legal approaches + \begin{itemize} + \item Competition / Anti-Trust law (by a GPL-abiding competitor) + \item Consumer protection (The product without source code is incomplete) + \end{itemize} +\end{itemize} +\end{frame} + +\begin{frame}{GPL Enforcement Requirements} +\begin{itemize} + \item Clean copyright situation + \begin{itemize} + \item Who wrote which (part of a) software + \item Was the copyright transferred to an employer? + \end{itemize} + \item Evidence for the violation + \begin{itemize} + \item Test purchase of the software on storage medium + \item Detailed screenshots of download side, downloaded software images + \item Evidence shows no notice of GPL or source code availability/offer + \end{itemize} + \item Copyright holders who want to do enforcement +\end{itemize} +\end{frame} + +\begin{frame}{GPL Enforcement by the Community} +\begin{itemize} + \item Authors/Developers of a project need to care about entities that violate their license + \item Legal options in case of a violation + \begin{itemize} + \item One or multiple copyright holders do their own enforcement + \item Copyright transfer to an entity that does enforcement + \begin{itemize} + \item Free Software Foundation + \item http://conservancy.softwarefreedom.org/ + \item Fiduciary License Agreement with the FSF Europe + \end{itemize} + \end{itemize} +\end{itemize} +\end{frame} + +\subsection{gpl-violations.org} + +\begin{frame}{The gpl-violations.org work} +\begin{itemize} + \item Use all legal means necessary to bring infringing product in compliance + \item We only act where we hold copyright (Linux kernel) + \item We typically only act within Europe, mostly in Germany + \item Success so far + \begin{itemize} + \item More than 100 amicable agreements as results of settlements + \item More than 5 preliminary injunctions halting sales of products until compliance + \item Multiple actual court cases with court verdict + \end{itemize} +\end{itemize} +\end{frame} + +\begin{frame}{The gpl-violations.org work}{Typical enforcement timeline} +\begin{itemize} + \item Customer of product sends a report about GPL violation + \begin{itemize} + \item There is no GPL license text and/or no source code or written offer + \end{itemize} + \item We do reverse engineering and make test purchase + \item After confirming the violation, send legal warning notice to vendor + \begin{itemize} + \item Tight deadline for complying with the GPL and signing a declaration to cease and desist + \end{itemize} + \item If no declaration is signed, we + \begin{itemize} + \item contract technical expert to do a study + \item apply for a preliminary injunction + \end{itemize} + \item If cease-desist is signed and license compliance reached: + \begin{itemize} + \item Resolve how the vendor can ensure already manufactured products are compliant + \end{itemize} +\end{itemize} +\end{frame} + +\begin{frame}{The gpl-violations.org legal cases} +Commonly-known cases that actually went to court +\begin{itemize} + \item April 2004: Preliminary injunction against Sitecom + \item May 2004: Sitecom appeal case turned down by court + \item April 2005: Preliminary injunction against Fortinet + \item September 2006: Court case against D-Link +\end{itemize} +... all of those cases have been won +\end{frame} + + + +%\subsection*{Outlook} + +\begin{frame}{Outlook} + Outlook + \begin{itemize} + \item + Blatant GPL violations in embedded devices are declining, but are likely to continue due to lack of skill or negligence. + \item + We'll see more {\em derivative works} types of GPL violations, and we'll see actual legal enforcement and precedent in this area over the next years. + \item + Stronger copyright protection demanded by content industry will also mean stronger protection for FOSS licenses. Imagine GPL enforcement with {\em three strikes} law in France ?!? + \end{itemize} +\end{frame} + +\end{document} diff --git a/2010/gpl_compliance-openfoundry2010/license_compliance2.pdf b/2010/gpl_compliance-openfoundry2010/license_compliance2.pdf Binary files differnew file mode 100644 index 0000000..88d5039 --- /dev/null +++ b/2010/gpl_compliance-openfoundry2010/license_compliance2.pdf diff --git a/2010/gpl_compliance-openfoundry2010/license_compliance4.pdf b/2010/gpl_compliance-openfoundry2010/license_compliance4.pdf Binary files differnew file mode 100644 index 0000000..4eddda1 --- /dev/null +++ b/2010/gpl_compliance-openfoundry2010/license_compliance4.pdf diff --git a/2010/gpl_compliance-openfoundry2010/linux_netfilter_singapore_entertainment.jpg b/2010/gpl_compliance-openfoundry2010/linux_netfilter_singapore_entertainment.jpg Binary files differnew file mode 100644 index 0000000..91b839f --- /dev/null +++ b/2010/gpl_compliance-openfoundry2010/linux_netfilter_singapore_entertainment.jpg diff --git a/2010/gpl_enforcement-coscup2010/abstract.txt b/2010/gpl_enforcement-coscup2010/abstract.txt new file mode 100644 index 0000000..91f3463 --- /dev/null +++ b/2010/gpl_enforcement-coscup2010/abstract.txt @@ -0,0 +1,14 @@ +GNU GPL Compliance in Embedded Devices + +GNU/Linux is a the most popular choice of an Operating System in many areas +of Embedded computing. It can be found in embedded networking equipment, +personal navigation systems, media players, mobile phones to print servers, +NAS, in-flight entertainment systems and even bicycle ergometers. + +Using the Linux kernel and other GPL licensed software is a convenient and +especially inexpensive choice. However, it is still copyrighted software +subject to a license: The GNU General Public License. + +The presentation will look at typical GPL violations in the embedded market +and how they could have easily been avoided by little extra effort in +product development. diff --git a/2010/gpl_enforcement-coscup2010/gpl_enforcement.pdf b/2010/gpl_enforcement-coscup2010/gpl_enforcement.pdf Binary files differnew file mode 100644 index 0000000..c652a8c --- /dev/null +++ b/2010/gpl_enforcement-coscup2010/gpl_enforcement.pdf diff --git a/2010/gpl_enforcement-coscup2010/gpl_enforcement.snm b/2010/gpl_enforcement-coscup2010/gpl_enforcement.snm new file mode 100644 index 0000000..e69de29 --- /dev/null +++ b/2010/gpl_enforcement-coscup2010/gpl_enforcement.snm diff --git a/2010/gpl_enforcement-coscup2010/gpl_enforcement.tex b/2010/gpl_enforcement-coscup2010/gpl_enforcement.tex new file mode 100644 index 0000000..5aa3080 --- /dev/null +++ b/2010/gpl_enforcement-coscup2010/gpl_enforcement.tex @@ -0,0 +1,421 @@ +% $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} + +% 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{GNU GPL License Compliance} + +\subtitle +{With specific focus on Embedded Devices} + +\author{Harald Welte} + +\institute +{gpl-violations.org\\gnumonks.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[COSCUP 2010] % (optional, should be abbreviation of conference name) +{COSCUP 2010} +% - 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{Embedded Linux} +% 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 + % 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 development since 1999 +\item IT security expert, focus on network protocol security +\item Board-level Electrical Engineering +\item System-level Software for PPC, ARM, x86 +\item IANAL, but companies not complying with the license forced me to spend lots of time with legal issues +\end{itemize} +\end{frame} + + +\section{FOSS Licenses} + +\subsection{Free Software and Copyleft} + +\begin{frame}{Free Software}{Definition by the FSF} + % - A title should summarize the slide in an understandable fashion + % for anyone how does not follow everything on the slide itself. + Free Software has to ensure the following key freedoms: + \begin{itemize} + \item + Freedom to use the software for any purpose + \item + Freedom to make copies "to help your neighbor" + \item + Freedom to study its functionality (source code) + \item + Freedom to fix it yourself (make modifications) + \end{itemize} +\end{frame} + +\begin{frame}{Copyleft}{A concept to ensure Freedom} + Copyleft is an idea to use copyright to ensure Software Freedoms + \begin{itemize} + \item Use/claim copyright on the software + \item Create a license that is permissive enough for the 4 Freedoms + \item However, put some conditions/obligations in the license + \begin{itemize} + \item ensure the source code will always be available + \item ensure nobody is able to remove the 4 Freedoms from the software + \end{itemize} + \item Use that license for the software. + \end{itemize} +\end{frame} + +\subsection{The GNU GPL} + +\begin{frame}{The GNU GPL}{An implementation of Copyleft} +The GNU General Public License (GPL) +\begin{itemize} + \item is a Copyleft Free Software License + \item assures the original author that his work will always have the freedoms + \item establishes a level of fairness: You can use my code, if you share your additions back with us. + \item is a big motivation factor for many community members +\end{itemize} +\end{frame} + +\begin{frame}{Revisiting the GPLv2 License Terms} +The GNU GPLv2 +\begin{itemize} + \item Regulates distribution, not use (running the program) + \item Allows distribution of source code and modified source code, if + \begin{itemize} + \item The license is mentioned + \item A copy of the license text accompanies each copy + \end{itemize} + \item Allows distribution of or modified binaries, if + \begin{itemize} + \item The license is mentioned + \item A copy of the license text accompanies each copy + \item The source code is either included with the copy, or a written offer is made on how the source can be obtained. + \end{itemize} +\end{itemize} +\end{frame} + +\begin{frame}{Complete Corresponding Source Code}{As required by GPLv2} +\dots complete source code means all the source code for all modules it (the software) contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. +\begin{itemize} + \item For a C language program, this means + \begin{itemize} + \item Source Code + \item Makefiles + \item compile-time configuration (e.g. kernel .config) + \end{itemize} + \item General rule + \begin{itemize} + \item Intent of the license is to enable the user to run modified versions of the program + \item If you provide everything needed for that, there will be no discussion + \end{itemize} +\end{itemize} +\end{frame} + +\begin{frame}{Modifications of GPL'd source code}{The details that matter} +\begin{itemize} + \item In the GPL, it does not matter if you have modified the GPL'd program or if you ship it unmodified. + \item You always have to provide the source code! + \item If you modify the source code, your changes have to be visible/identifiable + \item For practical reasons, I suggest shipping original upstream tarball + a diff/patch with your changes +\end{itemize} +\end{frame} + +\subsection{GPL - Compatible source code offer} + +\begin{frame}{Complete + Corresponding Source}{For every Release you make} +\begin{itemize} +\item Whenever you {\em distribute} GPL licensed software, the license applies. This includes + \begin{itemize} + \item Actual sale of a physical embedded device with the software in flash + \item Download of a firmware update as a file from a website + \item Shipping of firmware updates on physical storage + \item Distribution of firmware updates e.g. by over-the-air mechanisms in DVB-S or other networks + \end{itemize} +\item Every time, the conditions of the license have to be fulfilled (mention there's software under GPL, include full license text, include or offer complete corresponding source code +\item For every release you ever ship (even beta release if it ever is shipped only to one customer), you need the {\em complete corresponding} source code. +\end{itemize} +\end{frame} + +\subsection{GPL - Derivative Works} + +\begin{frame}{Derivative Works}{Keeping it clean} +Derivative works are a question of copyright law, not the GPL +\begin{itemize} +\item whenever you couple a GPL and a non-GPL program tightly (e.g. static/dynamic linking), your're entering a legal grey area +\item there is little or no precedent on derivative works of software +\item you're violating the intention of the author. If he wanted you to link from proprietary programs, he would have used LGPL +\item try to work {\em with} the community, rather than against it +\end{itemize} +\end{frame} + +\begin{frame}{Intermission} +Take a break, go one step back +\begin{itemize} +\item The License is not a means to itself +\item Intent of the license is to make sure people can modify + enhance the product +\item The more open your product is, the less you have to worry +\item Using Linux + FOSS without enabling community to modify+enhance is cheating! +\item Try to make friends of the developer community, not enemies! +\end{itemize} +\end{frame} + +\begin{frame}{License compliance is not an afterthought} +Complying with the license terms is relatively easy {\em if} you consider the license terms {\em before} starting R\&D +\begin{itemize} +\item you can integrate building source releases in your build process +\item you can decide which software can be combined given the license terms +\end{itemize} +\end{frame} + +\begin{frame}{License compliance is not an afterthought} +Achieving license compliance after shipping the product is very hard +\begin{itemize} +\item lack of good engineering practise could mean old source code is gone +\item engineers working on the product might have left the company +\item you and your customers are under a lot of time pressure (legal threat) +\item you might have already shipped a derivative work to GPLd software and now have to release parts that you originally wanted to keep proprietary +\end{itemize} +\end{frame} + +\section{Linux and the Embedded Market} + +\subsection{Linux-based systems everywhere} + +\begin{frame}{Linux and Free Software (FOSS) everywhere} +\begin{figure}[h] +\centering +\includegraphics[width=100mm]{linux_netfilter_singapore_entertainment.jpg} +\end{figure} +\end{frame} + +\begin{frame}{Areas of Embedded Linux} +\begin{itemize} +\item Embedded Network Devices (DSL-Modem, Router, WiFi-AP, NAS) +\item Telecommunications equipment (Switch, DSLAM, ...) +\item In-flight / In-vehicle entertainment +\item Personal Navigation Devices (Tomtom GO) +\item Mobile Phones (EZX, MAGX, Android, LiMo, WebOS) +\item PoS terminals, ATMs, Payphones +\item Digital Media Players, Set-Top-Boxes, Video Recorder +\item Exercycles + Fitness Gear +\item Building automation + control +\item VoIP telephones, VoIP switches, PBX +\item e-Ink readers, Tablet computers, MIDs +\end{itemize} +\end{frame} + +\subsection{Embedded Linux supply chain} + +\begin{frame}{Embedded Linux Supply Chain} +In a typical case, the supply chain consists minimal of +\begin{itemize} +\item The silicon maker of the SoC containig the core that runs Linux +\item The supplier of the reference design / board for that SoC +\item The ODM building an actual circuit board using that SoC +\item The OEM selling the product under his brand in the target market +\end{itemize} +\end{frame} + +\begin{frame}{Embedded Linux Supply Chain} +Situation can be further complicated by +\begin{itemize} +\item A 3rd party supplier of the BSP / SDK for the SoC or reference board +\item Multiple companies involved on the ODM or OEM side (building parts of a product, later integration into the real product e.g. IVE for a car) +\item 3rd party suppliers of application programs (which might use FOSS) +\end{itemize} +\end{frame} + +\begin{frame}{Embedded Linux Supply Chain} +Problems in the supply chain: +\begin{itemize} +\item OEM has no clue what kind of software ODM put into the product +\item ODM has limited technical skill and has no clue what BSP provider did +\item End user buys a product with license/copyright violations and has no clue + \begin{itemize} + \item who the entities in the supply chain are + \item who actually caused the license/copyright violation + \end{itemize} +\end{itemize} +\end{frame} + +\subsection{GPL - Embedded Systems} + +\begin{frame}{GPL and Embedded Systems}{Interpreting the meaning} +\begin{itemize} +\item The GNU GPLv2 was written for the GNU project, at the time this project was +working on replacing individual application programs on top of a proprietary +UNIX operating system kernel. +\item scripts used to control compilation and installation + \begin{itemize} + \item Intent: To enable the user to modify + run modified versions + \item In case of embedded systems, the "scripts used to control installation" include the software required for installing the program onto the target device + \end{itemize} +\end{itemize} +\end{frame} + +\begin{frame}{GPL and Embedded DRM}{Sometimes called Tivo-ization} +\begin{itemize} +\item Some companies want to lock down their Linux-based system, by + \begin{itemize} + \item Cryptographic verification of bootloader by ROM loader + \item Cryptographic verification of kernel image by bootloader\dots + \end{itemize} +\item This is problematic from a GPL point of view, since + \begin{itemize} + \item You are depriving the user from practically exercising his right to run modified versions of the program + \item Thus, violation not of the GPLv2 wording, but likely of the GPL's intention + \item Legal outcome unclear, different scholars have different opinions, also depends on jurisdiction + \end{itemize} +\item GPLv3 makes this intent explicit in the license text +\end{itemize} +\end{frame} + +\section{GPL Violations and License Enforcement} + +\subsection{GPL Violations} + +\begin{frame}{GPL Violations} +\begin{itemize} +\item GPL violations are not new, just like GPL licensed software is not new +\item However, increased popularity of GNU/Linux based systems increase GPL violations +\item Today, many more people and companies unfamiliar with the history and values of Free Software start using and (re)distributing FOSS +\end{itemize} +\end{frame} + +\subsection{Business Risk of GPL Violations} + +\begin{frame}{Business Risk of GPL Violations}{Or: How to convince your managers} +If you ship a product that is incompliant to the GNU GPL, +\begin{itemize} +\item you are committing a copyright infringement not different from shipping a product with unlicensed copies of MS Windows +\item you can face civil and criminal charges in court +\item civil charges include (German jurisdiction) + \begin{itemize} + \item immediate cease + desist (halt of product sales) + \item information of which quantity of the product has been sold to whom + \item damages for lost revenue (see dual licensing) + \end{itemize} +\item civil charges can also be filed against every distributor/store/importer +\end{itemize} +\end{frame} + +\subsection*{Outlook} + +\begin{frame}{Outlook} + Outlook + \begin{itemize} + \item + Blatant GPL violations in embedded devices are declining, but are likely to continue due to lack of skill or negligence. + \item + We'll see more {\em derivative works} types of GPL violations, and we'll see actual legal enforcement and precedent in this area over the next years. + \item + Stronger copyright protection demanded by content industry will also mean stronger protection for FOSS licenses. Imagine GPL enforcement with {\em three strikes} law in France ?!? + \end{itemize} +\end{frame} + +\end{document} diff --git a/2010/gpl_enforcement-coscup2010/linux_netfilter_singapore_entertainment.jpg b/2010/gpl_enforcement-coscup2010/linux_netfilter_singapore_entertainment.jpg Binary files differnew file mode 100644 index 0000000..91b839f --- /dev/null +++ b/2010/gpl_enforcement-coscup2010/linux_netfilter_singapore_entertainment.jpg diff --git a/2010/gpl_enforcement-dc2010/abstract.txt b/2010/gpl_enforcement-dc2010/abstract.txt new file mode 100644 index 0000000..58a6226 --- /dev/null +++ b/2010/gpl_enforcement-dc2010/abstract.txt @@ -0,0 +1 @@ +What can the community do to enforce GPL violations? diff --git a/2010/gpl_enforcement-dc2010/gpl_enforcement.pdf b/2010/gpl_enforcement-dc2010/gpl_enforcement.pdf Binary files differnew file mode 100644 index 0000000..af7740f --- /dev/null +++ b/2010/gpl_enforcement-dc2010/gpl_enforcement.pdf diff --git a/2010/gpl_enforcement-dc2010/gpl_enforcement.snm b/2010/gpl_enforcement-dc2010/gpl_enforcement.snm new file mode 100644 index 0000000..e69de29 --- /dev/null +++ b/2010/gpl_enforcement-dc2010/gpl_enforcement.snm diff --git a/2010/gpl_enforcement-dc2010/gpl_enforcement.tex b/2010/gpl_enforcement-dc2010/gpl_enforcement.tex new file mode 100644 index 0000000..cb065cd --- /dev/null +++ b/2010/gpl_enforcement-dc2010/gpl_enforcement.tex @@ -0,0 +1,455 @@ +% $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} + +% 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{GNU GPL License Enforcements} + +\subtitle +{What the community can do to enforce the GPL} + +\author{Harald Welte} + +\institute +{gpl-violations.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[DORS/CLUC 2010] % (optional, should be abbreviation of conference name) +{DORS/CLUC 2010, May 2010, Zagreb/Croatia} +% - 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{Embedded Linux} +% 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 + % 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 development since 1999 +\item IT security specialist, focus on network protocol security +\item Board-level Electrical Engineering +\item System-level Software for PPC, ARM, x86 +\item IANAL, but companies not complying with the license forced me to spend lots of time with legal issues +\end{itemize} +\end{frame} + +\section{FOSS Licenses} + +\subsection{Free Software and Copyleft} + +\begin{frame}{Free Software}{Definition by the FSF} + % - A title should summarize the slide in an understandable fashion + % for anyone how does not follow everything on the slide itself. + Free Software has to ensure the following key freedoms: + \begin{itemize} + \item + Freedom to use the software for any purpose + \item + Freedom to make copies "to help your neighbor" + \item + Freedom to study its functionality (source code) + \item + Freedom to fix it yourself (make modifications) + \end{itemize} +\end{frame} + +\begin{frame}{Copyleft}{A concept to ensure Freedom} + Copyleft is an idea to use copyright to ensure Software Freedoms + \begin{itemize} + \item Use/claim copyright on the software + \item Create a license that is permissive enough for the 4 Freedoms + \item However, put some conditions/obligations in the license + \begin{itemize} + \item ensure the source code will always be available + \item ensure nobody is able to remove the 4 Freedoms from the software + \end{itemize} + \item Use that license for the software. + \end{itemize} +\end{frame} + +\subsection{The GNU GPL} + +\begin{frame}{The GNU GPL}{An implementation of Copyleft} +The GNU General Public License (GPL) +\begin{itemize} + \item is a Copyleft Free Software License + \item assures the original author that his work will always have the freedoms + \item establishes a level of fairness: You can use my code, if you share your additions back with us. + \item is a big motivation factor for many community members +\end{itemize} +\end{frame} + +\begin{frame}{Revisiting the GPLv2 License Terms} +The GNU GPLv2 +\begin{itemize} + \item Regulates distribution, not use (running the program) + \item Allows distribution of source code and modified source code, if + \begin{itemize} + \item The license is mentioned + \item A copy of the license text accompanies each copy + \end{itemize} + \item Allows distribution of or modified binaries, if + \begin{itemize} + \item The license is mentioned + \item A copy of the license text accompanies each copy + \item The source code is either included with the copy, or a written offer is made on how the source can be obtained. + \end{itemize} +\end{itemize} +\end{frame} + +\begin{frame}{Complete Corresponding Source Code}{As required by GPLv2} +\dots complete source code means all the source code for all modules it (the software) contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. +\begin{itemize} + \item For a C language program, this means + \begin{itemize} + \item Source Code + \item Makefiles + \item compile-time configuration (e.g. kernel .config) + \end{itemize} + \item General rule + \begin{itemize} + \item Intent of the license is to enable the user to run modified versions of the program + \item If you provide everything needed for that, there will be no discussion + \end{itemize} +\end{itemize} +\end{frame} + +\begin{frame}{Modifications of GPL'd source code}{The details that matter} +\begin{itemize} + \item In the GPL, it does not matter if you have modified the GPL'd program or if you ship it unmodified. + \item You always have to provide the source code! + \item If you modify the source code, your changes have to be visible/identifiable + \item For practical reasons, I suggest shipping original upstream tarball + a diff/patch with your changes +\end{itemize} +\end{frame} + +\subsection{GPL - Embedded Systems} + +\begin{frame}{GPL and Embedded Systems}{Interpreting the meaning} +\begin{itemize} +\item The GNU GPLv2 was written for the GNU project, at the time this project was +working on replacing individual application programs on top of a proprietary +UNIX operating system kernel. +\item scripts used to control compilation and installation + \begin{itemize} + \item Intent: To enable the user to modify + run modified versions + \item In case of embedded systems, the "scripts used to control installation" include the software required for installing the program onto the target device + \end{itemize} +\end{itemize} +\end{frame} + +\begin{frame}{GPL and Embedded DRM}{Sometimes called Tivo-ization} +\begin{itemize} +\item Some companies want to lock down their Linux-based system, by + \begin{itemize} + \item Cryptographic verification of bootloader by ROM loader + \item Cryptographic verification of kernel image by bootloader\dots + \end{itemize} +\item This is problematic from a GPL point of view, since + \begin{itemize} + \item You are depriving the user from practically exercising his right to run modified versions of the program + \item Thus, violation not of the GPLv2 wording, but likely of the GPL's intention + \item Legal outcome unclear, different scholars have different opinions, also depends on jurisdiction + \end{itemize} +\item GPLv3 makes this intent explicit in the license text +\end{itemize} +\end{frame} + +\subsection{GPL - Compatible source code offer} + +\begin{frame}{Complete + Corresponding Source}{For every Release you make} +\begin{itemize} +\item Whenever you {\em distribute} GPL licensed software, the license applies. This includes + \begin{itemize} + \item Actual sale of a physical embedded device with the software in flash + \item Download of a firmware update as a file from a website + \item Shipping of firmware updates on physical storage + \item Distribution of firmware updates e.g. by over-the-air mechanisms in DVB-S or other networks + \end{itemize} +\item Every time, the conditions of the license have to be fulfilled (mention there's software under GPL, include full license text, include or offer complete corresponding source code +\item For every release you ever ship (even beta release if it ever is shipped only to one customer), you need the {\em complete corresponding} source code. +\end{itemize} +\end{frame} + +\subsection{GPL - Derivative Works} + +\begin{frame}{Derivative Works}{Keeping it clean} +Derivative works are a question of copyright law, not the GPL +\begin{itemize} +\item whenever you couple a GPL and a non-GPL program tightly (e.g. static/dynamic linking), your're entering a legal grey area +\item there is little or no precedent on derivative works of software +\item you're violating the intention of the author. If he wanted you to link from proprietary programs, he would have used LGPL +\item try to work {\em with} the community, rather than against it +\end{itemize} +\end{frame} + + +\section{GPL Violations and License Enforcement} + +\subsection{GPL Violations} + +\begin{frame}{GPL Violations} +\begin{itemize} +\item GPL violations are not new, just like GPL licensed software is not new +\item However, increased popularity of GNU/Linux based systems increase GPL violations +\item Today, many more people and companies unfamiliar with the history and values of Free Software start using and (re)distributing FOSS +\end{itemize} +\end{frame} + +\subsection{Business Risk of GPL Violations} + +\begin{frame}{Business Risk of GPL Violations}{Or: How to convince your managers} +If you ship a product that is incompliant to the GNU GPL, +\begin{itemize} +\item you are committing a copyright infringement not different from shipping a product with unlicensed copies of MS Windows +\item you can face civil and criminal charges in court +\item civil charges include (German jurisdiction) + \begin{itemize} + \item immediate cease + desist (halt of product sales) + \item information of which quantity of the product has been sold to whom + \item damages for lost revenue (see dual licensing) + \end{itemize} +\item civil charges can also be filed against every distributor/store/importer +\end{itemize} +\end{frame} + +\subsection{GPL Enforcement} + +\begin{frame}{Early GPL Enforcement} +\begin{itemize} +\item The Free Software Foundation (FSF) has alway been doing GPL enforcement on software {\em of which they are the copyright holder} + \begin{itemize} + \item They do so quietly, without much public notice + \item The quiet route sometimes leads to lengthy negotiations + \item The FSF only holds copyright on some Free Software programs + \end{itemize} +\end{itemize} +\end{frame} + +\begin{frame}{The Linksys WRT54G case} +During 2003, the Linksys WRT54G case drew a lot of attention +\begin{itemize} + \item Linksys was selling 802.11 WLAN Access Points and Routers + \item Lots of GPL licensed software embedded into the device, including Linux, uClibc, busybox, iptables + \item FSF-led alliance took their usual {\em quiet} approach + \item Linksys bought itself a lot of time + \begin{itemize} + \item Some sources were released two months later + \item Full GPL compliance only achieved four months later + \end{itemize} +\end{itemize} +\end{frame} + +\begin{frame}{Aftermath of the Linksys case} +\begin{itemize} + \item Some developers were not happy with the Linksys case + \begin{itemize} + \item Linksys didn't loose anything by not complying from the beginning + \item Four months delay is a long time given short product lifetimes + \end{itemize} + \item More embedded devices started to use Linux and other FOSS + \item The netfilter/iptables project started to do their own enforcement + \begin{itemize} + \item Using German copyright law against German subsidiary of vendor + \item Using direct legal / copyright based approach + \end{itemize} + \item The gpl-violations.org was later established +\end{itemize} +\end{frame} + +\begin{frame}{GPL Enforcement by the Community} +\begin{itemize} + \item The GPL is a Copyright License + \item GPL enforcement is thus Copyright enforcement + \item Copyright enforcement can normally only be done by copyright holders! + \item Alternative (less tested) legal approaches + \begin{itemize} + \item Competition / Anti-Trust law (by a GPL-abiding competitor) + \item Consumer protection (The product without source code is incomplete) + \end{itemize} +\end{itemize} +\end{frame} + +\begin{frame}{GPL Enforcement Requirements} +\begin{itemize} + \item Clean copyright situation + \begin{itemize} + \item Who wrote which (part of a) software + \item Was the copyright transferred to an employer? + \end{itemize} + \item Evidence for the violation + \begin{itemize} + \item Test purchase of the software on storage medium + \item Detailed screenshots of download side, downloaded software images + \item Evidence shows no notice of GPL or source code availability/offer + \end{itemize} + \item Copyright holders who want to do enforcement +\end{itemize} +\end{frame} + +\begin{frame}{GPL Enforcement by the Community} +\begin{itemize} + \item Authors/Developers of a project need to care about entities that violate their license + \item Legal options in case of a violation + \begin{itemize} + \item One or multiple copyright holders do their own enforcement + \item Copyright transfer to an entity that does enforcement + \begin{itemize} + \item Free Software Foundation + \item http://conservancy.softwarefreedom.org/ + \item Fiduciary License Agreement with the FSF Europe + \end{itemize} + \end{itemize} +\end{itemize} +\end{frame} + +\subsection{gpl-violations.org} + +\begin{frame}{The gpl-violations.org work} +\begin{itemize} + \item Use all legal means neccessarry to bring infringing product in compliance + \item We only act where we hold copyright (Linux kernel) + \item We typically only act within Europe, mostly in Germany + \item Success so far + \begin{itemize} + \item More than 100 amicable agreements as results of settlements + \item More than 5 preliminary injunctions halting sales of products until compliance + \item Multiple actual court cases with court verdict + \end{itemize} +\end{itemize} +\end{frame} + +\section*{Summary} + +\subsection*{Summary} + +\begin{frame}{Summary} + % Keep the summary *very short*. + \begin{itemize} + \item + GPL compliance is not difficult if you think about the problem when you start product development. + \item + A large part of the task can be automatized by using a proper build system. + \item + There are questionable legal {\em grey areas}. To minimize the risk, I'd try to stay out of them. + \end{itemize} +\end{frame} + +\subsection*{Outlook} + +\begin{frame}{Outlook} + Outlook + \begin{itemize} + \item + Blatant GPL violations in embedded devices are declining, but are likely to continue due to lack of skill or negligence. + \item + We'll see more {\em derivative works} types of GPL violations, and we'll see actual legal enforcement and precedent in this area over the next years. + \item + Stronger copyright protection demanded by content industry will also mean stronger protection for FOSS licenses. Imagine GPL enforcement with "three strikes" law in France ?!? + \end{itemize} +\end{frame} + +\end{document} + + diff --git a/2010/gsm-deepsec2010/abstract.txt b/2010/gsm-deepsec2010/abstract.txt new file mode 100644 index 0000000..38eb15b --- /dev/null +++ b/2010/gsm-deepsec2010/abstract.txt @@ -0,0 +1,55 @@ +Deepsec 2010 GSM Security Workshop +====================================================================== + + +* attacks from malicious phone + * RACH DoS using OsmocomBB + * IMSI DETACH flood + * L2 fuzzing + * BSC fuzzing using RR messages + * MSC fuzzing using MM / CC messages + * use 'emergency call' RACH but then regular SETUP +* passive attacks + * GSM intercept using airprobe + * extended GSM intercept with A5/1 decryption + +* best security practises when deploying GSM + * TMSI reallocation as often as possible + * VLR large enough to never expire VLR records + * offer A5/3 + * don't offer A5/2 + * randomized padding of L2 frames + * encrypted/authenticated backhaul + * heuristics-based IMSI DETACH protection or DETACH disable + * use 'late assignment' of TCH + * use SMS over GPRS whenever possible + * do SDCCH-reassignment on CS-SMS + * always use frequency hopping over wide spectrum + * make SI5/SI6 on SACCH less predictable + * offer GEA3 and use whenever possible + + +In recent years, we have seen a significant increase of research in GSM +protocol-level and cryptographic security attacks: The existing theoretical +weaknesses of A5/1 have been implemented and proven as practical, rainbow +tables have been computed and distributed widely on the internet. A new +open-source GSM baseband software facilitates fine-grained control over all +information sent from a malicious user, enabling protocol fuzzing and flooding +attacks. + +However, the publicly available attack tools are hard to use, and it is +difficult to reproduce the published attacks and assess how easy it is to +perform which type of attack on GSM networks. + +This two-day workshop will re-visit all GSM security features and their +publicly know weaknesses. It will introduce and demonstrate the various +publicly available attack tools; Workshop participants will be trained +by the creators of the attack tools on how to use them against actual GSM +networks. + +After extensive hands-on sessions performing the various attacks, +counter-measures will be presented, followed by a discussion of the best +current practises for configuring a secure-as-possible GSM network. + +The target audience of this workshop is GSM network operators and IT security +consultants in the telecommunications industry. diff --git a/2010/gsm_foss-mt2010/OBTSBM2010.jpg b/2010/gsm_foss-mt2010/OBTSBM2010.jpg Binary files differnew file mode 100644 index 0000000..7759978 --- /dev/null +++ b/2010/gsm_foss-mt2010/OBTSBM2010.jpg diff --git a/2010/gsm_foss-mt2010/bts_tree_full.jpg b/2010/gsm_foss-mt2010/bts_tree_full.jpg Binary files differnew file mode 100644 index 0000000..6b5c5e8 --- /dev/null +++ b/2010/gsm_foss-mt2010/bts_tree_full.jpg diff --git a/2010/gsm_foss-mt2010/c123_pcb.jpg b/2010/gsm_foss-mt2010/c123_pcb.jpg Binary files differnew file mode 100644 index 0000000..a9f24fc --- /dev/null +++ b/2010/gsm_foss-mt2010/c123_pcb.jpg diff --git a/2010/gsm_foss-mt2010/calypso-block.pdf b/2010/gsm_foss-mt2010/calypso-block.pdf Binary files differnew file mode 100644 index 0000000..27f8be8 --- /dev/null +++ b/2010/gsm_foss-mt2010/calypso-block.pdf diff --git a/2010/gsm_foss-mt2010/gsm_foss.pdf b/2010/gsm_foss-mt2010/gsm_foss.pdf Binary files differnew file mode 100644 index 0000000..4048816 --- /dev/null +++ b/2010/gsm_foss-mt2010/gsm_foss.pdf diff --git a/2010/gsm_foss-mt2010/gsm_foss.snm b/2010/gsm_foss-mt2010/gsm_foss.snm new file mode 100644 index 0000000..e69de29 --- /dev/null +++ b/2010/gsm_foss-mt2010/gsm_foss.snm diff --git a/2010/gsm_foss-mt2010/gsm_foss.tex b/2010/gsm_foss-mt2010/gsm_foss.tex new file mode 100644 index 0000000..fa26c86 --- /dev/null +++ b/2010/gsm_foss-mt2010/gsm_foss.tex @@ -0,0 +1,177 @@ + +\newcommand{\degree}{\ensuremath{^\circ}} +%\documentclass[handout]{beamer} +\documentclass{beamer} + +% 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) +} + +\mode<handout>{ + \usepackage{handoutWithNotes} + \pgfpagesuselayout{2 on 1 with notes landscape}[a4paper,border shrink=5mm] + \usecolortheme{seahorse} +} + +% ensure the page number is printed in front of the author name in the footer +\newcommand*\oldmacro{} +\let\oldmacro\insertshortauthor% save previous definition +\renewcommand*\insertshortauthor{% + \leftskip=.3cm% before the author could be a plus1fill ... + \insertframenumber\,/\,\inserttotalframenumber\hfill\oldmacro} + +\usepackage[english]{babel} +\usepackage[latin1]{inputenc} +\usepackage{times} +\usepackage[T1]{fontenc} + +\usepackage{subfigure} +\usepackage{hyperref} +\usepackage{textcomp,listings} +%\usepackage{german} +\lstset{basicstyle=\scriptsize\ttfamily, upquote} + +% \title{GSM Air Interface Security} +\title{Free / Open Source Software for GSM} %Hashdays 2010 title + +%\subtitle{and other GSM related fun} + +\author{Harald~Welte} + +\institute{gnumonks.org\\OpenBSC\\airprobe.org\\osmocom.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[December 2010] % (optional, should be abbreviation of conference name) +{December 2010, Taiwan} +% - 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} +% 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} + + +% 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. + +%\include{part-introduction} + +\part{Open Source GSM Tools} + +\begin{frame}{Part I - Open Source GSM Tools} +\tableofcontents +\end{frame} + +\include{section-openbsc} +\include{section-openbts} +\include{section-osmocombb} +\include{section-wireshark} +\include{section-simtrace} + +\include{part-mtk} + +\part{Summary} + +\section{Summary} + +\section{Further Reading} + +\begin{frame}{Further Reading} +\tiny{ +\begin{itemize} + \item Open source Software on a GSM protocol level + \begin{description}[OsmocomBB] + \item[OpenBSC] \url{http://openbsc.osmocom.org/} + \item[OpenBTS] \url{http://openbts.org/} + \item[OsmocomBB] \url{http://bb.osmocom.org/} + \item[airprobe] \url{http://airprobe.org/} + \end{description} + \item A5 security related publications + \begin{description}[] + \item[A5 public] \url{http://groups.google.com/group/uk.telecom/msg/ba76615fef32ba32} + \item[Biham2003] \url{http://cryptome.org/gsm-crack-bbk.pdf} + \item[Biham2006] \url{http://www.cs.technion.ac.il/users/wwwb/cgi-bin/tr-get.cgi/2006/CS/CS-2006-07.pdf} + \item[HAR2009] \url{https://har2009.org/program/attachments/119_GSM.A51.Cracking.Nohl.pdf} + \item[rainbow tables] \url{http://reflextor.com/trac/a51/wiki} + \end{description} +\end{itemize} +} +\end{frame} + +\end{document} diff --git a/2010/gsm_foss-mt2010/gsm_foss.vrb b/2010/gsm_foss-mt2010/gsm_foss.vrb new file mode 100644 index 0000000..d917a88 --- /dev/null +++ b/2010/gsm_foss-mt2010/gsm_foss.vrb @@ -0,0 +1,13 @@ +\frametitle {OpenBTS USRP Clocking}\framesubtitle {Kalibrator Example} +\begin{block}{Example of running {\tt kal}} +\begin{lstlisting} +[openBTS@openBTS kal-0.2]# ./kal -f 946600000 -u +USRP side: B +FPGA clock: 52000000 +Decimation: 192 +Antenna: RX2 +Sample rate: 270833.343750 +average [min, max] (range, stddev) -2197.789062 [-2431, -1843] (588, 146.761444) +\end{lstlisting} +\end{block} +The value {\bf -2198 should be used as FREQOFF constant in Transceiver/USRPDevice.cpp} diff --git a/2010/gsm_foss-mt2010/openbsc_host.jpg b/2010/gsm_foss-mt2010/openbsc_host.jpg Binary files differnew file mode 100644 index 0000000..10c575d --- /dev/null +++ b/2010/gsm_foss-mt2010/openbsc_host.jpg diff --git a/2010/gsm_foss-mt2010/part-mtk.tex b/2010/gsm_foss-mt2010/part-mtk.tex new file mode 100644 index 0000000..17baffc --- /dev/null +++ b/2010/gsm_foss-mt2010/part-mtk.tex @@ -0,0 +1,101 @@ +% Day 2 +\part{How MTK could use GSM FOSS} + +\begin{frame}{Part II - MTK and Free / Open Source Software} +\tableofcontents +\end{frame} + +\section{Open Source GSM tools for Debugging + Testing} + +\begin{frame}{Possible use cases for OpenBSC} +OpenBSC or OpenBTS in R\&D +\begin{itemize} + \item Inexpensive simulation of GSM network for R\&D + \item Flexible since any aspect can be modified by altering source code + \item Complex and more exotic parts of GSM protocol spec can be tested + \item Much more functionality than CMD 55 / Racal 6103 or similar + \item Ability to send malformed L3 messages (fuzzing) for MTK MS stack security improvement +\end{itemize} +\end{frame} + +\begin{frame}{Other GSM tools} +\begin{itemize} + \item airprobe: Tracing of Um air interface + \item SIMtrace: Tracing of SIM card interface +\end{itemize} +\end{frame} + +\begin{frame}{General advantages of FOSS based solution} +\begin{itemize} + \item MTK has full access to source code + \item New features can be added on any level of the protocol stack + \item No dependency on a single supplier + \item Lower cost means available to more MTK engineers + \item Lower cost means available to more MTK customers (factory testing, field tests with OEM customers, ...) +\end{itemize} +\end{frame} + +\section{Single-Core Android smart phone} + +\begin{frame}{MTK feature phone vs. smart phone} +\begin{itemize} + \item MTK's advantage so far: Low cost sigle-core feature phone + \begin{itemize} + \item Baseband processor runs Nucleus, GSM stack, UI and rich application stack (Camera, H.264, GPRS, TCP/IP, ...) + \item Other suppliers have to use dual core + \end{itemize} + \item However, MTKs Nucleus based OS has custom/proprietary APIs + \item Not many 3rd party applications can be installed on the phone + \item Android, iPhone, Windows Mobile have standard API / environment + \item Thus, MTK needs to offer 'standard' smart phone solution +\end{itemize} +\end{frame} + +\begin{frame}{Proposal: Single core Android smart phone} +\begin{itemize} + \item Android, WinMobile, etc. have dual-core architecture + \begin{itemize} + \item GSM/3G protocol stack on baseband processor + \item UI + applications on application processor + \end{itemize} + \item If MTK now goes for Android smart phone, why go dual core? + \begin{itemize} + \item Simply port L1 code into Linux kernel (IRQ/FIQ driven) + \item Make sure you follow the GPL and release L1 as Open Source + \item Run your L2/L3/L4 as proprietary userspace process on Linux + \end{itemize} + \item Single-core Android phone has less ARM core licensing cost and less silicon size +\end{itemize} +\end{frame} + +\section{Linux development and the community} + +\begin{frame}{SoC vendors and Linux ports} +\begin{itemize} + \item A number of SoC vendors have been used with Linux for many years + \item Port of Linux / BSP has originally been done by 3rd party or community + \item SoC vendors started to become more active in the last 5 years + \item Original: Create port, ship it to customer, done. + \item SoC customers end up with vendor-specific code +\end{itemize} +\end{frame} + +\begin{frame}{Disadvantages of vendor ports} +\begin{itemize} + \item Fast progress in mainline Linux kernel development + \item Customers want latest kernel for latest features / performance + \item Vendor port (not in mainline) always behind mainline + \item Porting out-of-mainline vendor port into new mainline is lots of work + \item Customers end up with old vendor-specific code +\end{itemize} +\end{frame} + +\begin{frame}{SoC vendors need to include their port mainline} +\begin{itemize} + \item Major SoC vendors now work together with mainline developers + \item Support SoC in latest mainline developer version + \item Actively submit port into mainline Linux kernel + \item Port in mainline stays automatically current/up-to-date + \item Continued maintenance effort is shared by all parties +\end{itemize} +\end{frame} diff --git a/2010/gsm_foss-mt2010/part-security.tex b/2010/gsm_foss-mt2010/part-security.tex new file mode 100644 index 0000000..d5b7fbd --- /dev/null +++ b/2010/gsm_foss-mt2010/part-security.tex @@ -0,0 +1,146 @@ +% Day 2 +\part{Security Research} +\section{Researching GSM/3G security} + +\subsection{An interesting observation} + +\begin{frame}{GSM/3G protocol level 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 chip set makers never release any hardware documentation + \end{itemize} +\end{itemize} +\end{frame} + +\subsection{The closed GSM industry -- Handset side} + +\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} + +\subsection{The closed GSM industry -- Network side} + +\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 + \item minimal network using standard components definitely in the 100,000s of EUR range + \end{itemize} +\end{itemize} +\end{frame} + +\begin{frame}{The closed GSM industry}{Operator side} +From my experience with Operators (prove me wrong!) +\begin{itemize} + \item Operators are mainly finance + marketing today + \item Many operators outsources + \begin{itemize} + \item Network servicing / deployment, even planning + \item Other aspects of business like Billing + \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} + +\begin{frame}{GSM networks are victim and source of attacks on user privacy} +\includegraphics[bb=0in 0in 12in 6in,clip,width=5.3in,page=7]{nohl-slides-14.pdf} +\end{frame} + +\begin{frame}{Network operator and manufacturer can install software on a phone} +\includegraphics[bb=0in 0in 12in 6in,clip,width=5.3in,page=8]{nohl-slides-14.pdf} +\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 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 Since 2010 we have a new project: {\tt OsmocomBB} + \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 Also, using SDR (software defined radio) approach, special-purpose / closed hardware can be avoided + \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 + \begin{itemize} + \item OpenBSC: Obtain actual GSM network equipment (BTS) + \item OpenBTS: Develop SDR based GSM Um Layer 1 + \end{itemize} + \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} + + diff --git a/2010/gsm_foss-mt2010/section-openbsc.tex b/2010/gsm_foss-mt2010/section-openbsc.tex new file mode 100644 index 0000000..0c1b9f4 --- /dev/null +++ b/2010/gsm_foss-mt2010/section-openbsc.tex @@ -0,0 +1,200 @@ +\section{OpenBSC} + +%\subsection{OpenBSC Introduction} + +\begin{frame}{OpenBSC software} +OpenBSC is a Open Source implementation of (not only) the BSC features +of a GSM network. +\begin{itemize} + \item Support A-bis interface over E1 and IP + \item Support for BTS vendor/model is modular, currently Siemens BS-11 and ip.access nanoBTS + \item Multiple BTS models/vendorrs can be mixed! + \item Can work as a {\em pure BSC} or as a full {\em network in a box} + \item Supports mobility management, authentication, intra-BSC hand-over, SMS, voice calls (FR/EFR/AMR) + \item GPRS + EDGE support if combined with OsmoSGSN and OpenGGSN +\end{itemize} +\end{frame} + +\begin{frame}{OpenBSC} +\begin{itemize} + \item Supports Siemens BS-11 BTS (E1) and ip.access nanoBTS (IP based) + \item Has classic 2G signalling, voice and SMS support + \item Implements various GSM protocols like + \begin{itemize} + \item A-bis RSL (TS 08.58) and OML (TS 12.21) + \item TS 04.08 Radio Resource, Mobility Management, Call Control + \item TS 04.11 Short Message Service + \end{itemize} + \item Telnet console with Cisco-style interface +\end{itemize} +\end{frame} + +\begin{frame}{OpenBSC software architecture} +\begin{itemize} + \item Implemented in pure C, similarities to Linux kernel + \begin{itemize} + \item Linked List handling, Timer API, coding style + \end{itemize} + \item Single-threaded event-loop / state machine design + \item Telnet based command line interface {\em Cisco-style} + \item Input driver abstraction (mISDN, Abis-over-IP) +\end{itemize} +\end{frame} + +\begin{frame}{OpenBSC: GSM network protocols}{The A-bis interface} + \begin{description}[Layer 4+] + \item[Layer 1] Typically E1 line, TS 08.54 + \item[Layer 2] A variant of ISDN LAPD with fixed TEI's, TS 08.56 + \item[Layer 3] OML (Organization and Maintenance Layer, TS 12.21) + \item[Layer 3] RSL (Radio Signalling Link, TS 08.58) + \item[Layer 4+] transparent messages that are sent to the MS via Um + \end{description} +\end{frame} + +%\begin{frame}{OpenBSC: How it all started} +%\begin{itemize} +% \item In 2006, I bought a Siemens BS-11 microBTS on eBay +% \begin{itemize} +% \item This is GSM900 BTS with 2 TRX at 2W output power (each) +% \item A 48kg monster with attached antenna +% \item 200W power consumption, passive cooling +% \item E1 physical interface +% \end{itemize} +% \item I didn't have much time at the time (day job at Openmoko) +% \item Started to read up on GSM specs whenever I could +% \item Bought a HFC-E1 based PCI E1 controller, has mISDN kernel support +% \item Found somebody in the GSM industry who provided protocol traces +%\end{itemize} +%\end{frame} + +%\begin{frame}{OpenBSC: Timeline} +%\begin{itemize} +% \item In November 2008, I started the development of OpenBSC +% \item In December 2008, we did a first demo at 25C3 +% \item In January 2009, we had full voice call support +% \item In June 2009, I started with actual security related stuff +% \item In August 2009, we had the first field test with 2BTS and > 860 phones +%\end{itemize} +%\end{frame} + +\begin{frame}{OpenBSC: Field Test at HAR2009} +\begin{figure}[h] +\subfigure{\includegraphics[width=5cm]{bts_tree_full.jpg}} +\subfigure{\includegraphics[width=5cm]{openbsc_host.jpg}} +\end{figure} +\end{frame} + + +\subsection{OpenBSC Network In The Box} + +\begin{frame}{OpenBSC in NITB mode}{Network In a Box Mode} +The {\tt bsc\_hack} program +\begin{itemize} + \item implements the A-bis interface towards any number of BTS + \item provides most typical features of a GSM network in one software + \item no need for MSC, AuC, HLR, VLR, EIR, ... + \begin{itemize} + \item HLR/VLR as SQLite3 table + \item Authentication + Ciphering support + \item GSM voice calls, MO/MT SMS + \item Hand-over between all BTS + \item Multiple Location Areas within one BSC + \end{itemize} +\end{itemize} +\end{frame} + +\begin{frame}{OpenBSC NITB features} +OpenBSC NITB features +\begin{itemize} + \item Run a small GSM network with 1-n BTS and OpenBSC + \item No need for MSC/HLR/AUC/... + \item No need for your own SIM cards (unless crypto/auth rqd) + \item Establish signalling and voice channels + \item Make incoming and outgoing voice calls between phones + \item Send/receive SMS between phones + \item Connect to ISDN PBX or public ISDN via Linux Call Router +\end{itemize} +\end{frame} + +\begin{frame}{OpenBSC in NITB mode}{Network In a Box Mode} +The {\tt bsc\_hack} program +\begin{itemize} + \item does not implement any other GSM interfaces apart from A-bis + \item no SS7 / TCAP / MAP based protocols + \item no integration (roaming) with existing traditional GSM networks + \item wired telephony interfacing with ISDN PBX {\tt lcr} (Linux Call Router) + \item Has been tested with up to 800 subscribers on 5 BTS + \item Intended for R\&D use or private PBX systems +\end{itemize} +\end{frame} + +\begin{frame}{OpenBSC LCR integration}{Interfacing with wired telephony} +OpenBSC (NITB mode) can be linked into Linux Call Router ({\tt lcr}) +\begin{itemize} + \item OpenBSC is compiled as libbsc.a + \item libbsc.a includes full OpenBSC NITB mod code + \item linking the library into {\tt lcr} results in GSM {\em line interfaces} to become available inside {\tt lcr} + \item OpenBSC no longer takes care of call control, but simply hands everything off to {\tt lcr} + \item Dialling plan, etc. is now configure in {\tt lcr} like for any other wired phones +\end{itemize} +\end{frame} + +\subsection{OpenBSC BSC-only mode} + +\begin{frame}{OpenBSC in BSC-only mode} +The {\tt osmo-bsc} program +\begin{itemize} + \item behaves like a classic GSM BSC + \item uses SCCP-Lite (ip.access multipex) to any SoftMSC like ADC + \item used in production/commercial deployments (~ 75 BSCs) + \item mainly intended to replace proprietary BSC in traditional GSM networks +\end{itemize} +\end{frame} + +\begin{frame}<handout:0>{OpenBSC} + Demonstration +\end{frame} + +\subsection{OpenBSC GPRS support} + +\begin{frame}{GPRS and OpenBSC} +\begin{itemize} + \item The BSC doesn't really do anything related to GPRS + \item GPRS implemented in separate SGSN and GGSN nodes + \item GPRS uses its own Gb interface to RAN, independent of A-bis + \item OpenBSC can configure the nanoBTS for GPRS+EDGE support via OML + \item Actual SGSN and GGSN implemented as OsmoSGSN and OpenGGSN programs +\end{itemize} +\end{frame} + +\begin{frame}{OsmoSGSN} +The Osmocom SGSN program implements +\begin{itemize} + \item basic/minimal SGSN functionality + \item the Gb interface (NS/BSSGP/LLC/SNDCP) + \item mobility management, session management +\end{itemize} +It's a work in progress, many missing features +\begin{itemize} + \item no HLR integration yet + \item no paging coordination with MSC/BSC + \item no encryption support yet +\end{itemize} +\end{frame} + +\begin{frame}{OpenGGSN} +\begin{itemize} + \item GPL licensed Linux program implementing GGSN node + \item Implements GTP-U protocol between SGSN and GGSN + \item User-configurable range/pool of IPv4 addresses for MS + \item Uses {\tt tun} device for terminating IP tunnel from MS + \item provides GTP implementation as libgtp + \item Experimental patches for IPv6 support +\end{itemize} +\end{frame} + +%\begin{frame}<handout:0>{OpenBSC + OpenGGSN + OsmoSGSN} +% Demonstration +%\end{frame} + +% FIXME: include slide showing full OpenBSC+OsmoSGSN+OpenGGSN network diff --git a/2010/gsm_foss-mt2010/section-openbts.tex b/2010/gsm_foss-mt2010/section-openbts.tex new file mode 100644 index 0000000..3675e85 --- /dev/null +++ b/2010/gsm_foss-mt2010/section-openbts.tex @@ -0,0 +1,140 @@ +\subsection{OpenBTS} + +\begin{frame}{What is OpenBTS?} +\begin{itemize} + \item is {\em NOT} a BTS in the typical GSM sense + \item is better described as a GSM-Um to SIP gateway + \item implements the GSM Um (air interface) as SDR + \item uses the USRP hardware as RF interface + \item does not implement any of BSC, MSC, HLR, etc. + \item bridges the GSM Layer3 protocol onto SIP + \item uses SIP switch (like Asterisk) for switching calls + SMS + \item is developed as C++ program and runs on Linux + MacOS +\end{itemize} +\end{frame} + +\begin{frame}{What is OpenBTS?} +\begin{itemize} + \item Open implementation of Um L1 \& L2, an all-software BTS. + \item L1/L2 design based on an object-oriented dataflow approach. + \item Includes L3 RR functions normally found in BSC. + \item Uses SIP PBX for MM and CC functions, eliminating the conventional GSM network. L3 is like an ISDN/SIP gateway. + \item Intended for use in low-cost and rapidly-deployed communications networks, but can be used for experiments (including by Chris Pagent at Def Con). +\end{itemize} +\end{frame} + +\begin{frame}{OpenBTS Hardware} +OpenBTS supports the following SDR hardware +\begin{itemize} + \item Ettus USRP(1) with two RFX 900 or RFX 1800 daughter boards + \begin{itemize} + \item Modification for external clock input recommended + \item External 52 MHz precision clock recommended + \end{itemize} + \item Kestrel Signal Processing / Range Networks custom radio + \item Close Haul Communications / GAPfiller (work in progress) + \item Ported to other radios by other clients. +\end{itemize} +\end{frame} + + +\begin{frame}{OpenBTS History + Tests} +\begin{itemize} + \item Started work in Aug 2007, first call in Jan 2008, first SMS in Dec 2008. + \item First public release in September 2008, assigned to FSF in Oct 2008. + \item Ran 3-sector 3-TRX system with 10,000-20,000 handsets at Sept 2009 Burning Man event in Nevada. + \item Ran 2-sector 5-TRX system with 40,000 handsets at Sept 2010 Burning Man event in Nevada. + \item Release 2.5 is about 13k lines of C++. + \item Part of GNU Radio project, distributed under AGPLv3. + \item Range Networks launched in Sept 2010 to produce commercial products and distributions. +\end{itemize} +\end{frame} + + +\begin{frame}{Burning Man 2010 Tower Base} +\begin{figure}[h] + \centering + \includegraphics[width=85mm]{OBTSBM2010.jpg} +\end{figure} +\end{frame} + +%\subsection{Clocking} +% +%\begin{frame}{OpenBTS USRP Clocking}{Clock Stability} +%\begin{itemize} +% \item USRP has regular XO (Crystal Oscillator) with 20ppm accuracy +% \item GSM requires 20ppb carrier clock accuracy +% \item possible solutions +% \begin{itemize} +% \item use external VCTCXO clocking module +% \item use external OCXO clocking module +% \item use a software calibration program comparing USRP XO with real GSM BTS carrier clocks +% \end{itemize} +% \item due to clock multiplication, absolute error in GSM1800 is higher than in GSM900 +%\end{itemize} +%\end{frame} + + +%\begin{frame}{OpenBTS USRP Clocking}{64 MHz vs. 52 MHz clock} +%\begin{itemize} +% \item The USRP master clock is 64 Mhz +% \item In GSM, all clocks are derived from 13 MHz +% \item Thus, a poly-phase re-sampler is part of SDR software +% \item Alternative: use 52 MHz (13 MHz * 4) external clock +% \item OpenBTS has two transceiver programs, one for each 64 MHz and 52 MHz +% \begin{itemize} +% \item Make sure to never use the wrong transceiver for your clock! +% \end{itemize} +%\end{itemize} +%\end{frame} + +%\begin{frame}{OpenBTS USRP Clocking}{Software Calibration} +%Basic idea: Use real GSM cell as clock source +%\begin{itemize} +% \item Implemented by the {\em Kalibrator} ({\tt kal}) program +% \item Acquire the FCCH burst of a real GSM cell +% \item Measure the clock difference between USRP XO and that cell +% \item Use the computed error as offset to USRP up/downconverter +% \item However, temperature and other drift will make clocks go out of sync over time +% \item Can only be used if a real-world GSM network is within range +%\end{itemize} +%\end{frame} + +%\begin{frame}[fragile]{OpenBTS USRP Clocking}{Kalibrator Example} +%\begin{block}{Example of running {\tt kal}} +%\begin{lstlisting} +%[openBTS@openBTS kal-0.2]# ./kal -f 946600000 -u +%USRP side: B +%FPGA clock: 52000000 +%Decimation: 192 +%Antenna: RX2 +%Sample rate: 270833.343750 +%average [min, max] (range, stddev) -2197.789062 [-2431, -1843] (588, 146.761444) +%\end{lstlisting} +%\end{block} +%The value {\bf -2198 should be used as FREQOFF constant in Transceiver/USRPDevice.cpp} +%\end{frame} + + +%\begin{frame}<handout:0>{OpenBTS} +% Demonstration +%\end{frame} + + +%\begin{frame}{OpenMS} +%\begin{itemize} +% \item Subscriber side stack based on OpenBTS. +% \item Called MS, but just a BTS stack with data flows reversed and a different RR control logic. +% \item Behavior is more like a passive interceptor that can also transmit. +% \item Release 1.0 supports non-hopping multi-ARFCN networks. +% \item Most L3 control logic provided by the end user. +% \item A platform for +% \begin{itemize} +% \item passive interceptors +% \item custom subscriber-side applications +% \item environment analysis +% \item intelligent jamming +% \end{itemize} +%\end{itemize} +%\end{frame} + diff --git a/2010/gsm_foss-mt2010/section-osmocombb.tex b/2010/gsm_foss-mt2010/section-osmocombb.tex new file mode 100644 index 0000000..07ff2f4 --- /dev/null +++ b/2010/gsm_foss-mt2010/section-osmocombb.tex @@ -0,0 +1,282 @@ +\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 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) +\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} diff --git a/2010/gsm_foss-mt2010/section-simtrace.tex b/2010/gsm_foss-mt2010/section-simtrace.tex new file mode 100644 index 0000000..75aed46 --- /dev/null +++ b/2010/gsm_foss-mt2010/section-simtrace.tex @@ -0,0 +1,39 @@ +\section{Osmocom SIMtrace} + +\subsection{Debugging SIM drivers and STK apps} + +\begin{frame}{Debugging SIM toolkit applications is hard} +\begin{itemize} + \item Regular end-user phone does not give much debugging + \item SIM card itself has no debug interface for printing error messages, warnings, etc. + \item However, as SIM-ME interface is unencrypted, sniffing / tracing is possible + \item Commercial / proprietary solutions exist, but are expensive +\end{itemize} +\end{frame} + +\subsection{Osmocom SIMtrace Introduction} + +\begin{frame}{Introducing Osmocom SIMtrace} +\begin{itemize} + \item Osmocom SIMtrace is a passive (U)SIM-ME communication sniffer + \item Insert SIM adapter into actual phone + \item Insert (U)SIM into SIMtrace hardware + \item SIMtrace hardware provides USB interface to host PC + \item {\tt simtrace} program on PC encapsulates APDU in GSMTAP + \item GSMTAP is sent via UDP to localhost + \item wireshark dissector for GSM TS 11.11 decodes APDUs +\end{itemize} +\end{frame} + +\subsection{Osmocom SIMtrace Hardware} + +\begin{frame}{Osmocom SIMtrace Hardware} +\begin{itemize} + \item Hardware is based around AT91SAM7S controller + \item SAM7S Offers two ISO 7816-3 compatible USARTs + \item USARTs can be clock master (SIM reader) or slave (SIM card) + \item Open Source Firmware on SAM7S implementing APDU sniffing + \item Auto-bauding depending CLK signal, PPS supported + \item Only prototype hardware right, but will be manufactured in Q1/2011 +\end{itemize} +\end{frame} diff --git a/2010/gsm_foss-mt2010/section-wireshark.tex b/2010/gsm_foss-mt2010/section-wireshark.tex new file mode 100644 index 0000000..588b4ab --- /dev/null +++ b/2010/gsm_foss-mt2010/section-wireshark.tex @@ -0,0 +1,61 @@ +\section{wireshark Protocol Analyzer} + +\begin{frame}{The wireshark protocol analyzer} +\begin{itemize} + \item Software protocol analyzer for plethora of protocols + \item Portable, works on most flavors of Unix and Windows + \item Decode, display, search and filter packets with configurable level of detail + \item Over 1000 protocol decoders + \item Over 86000 display filters + \item Live capturing from many different network media + \item Import files from other capture programs + \item Used to be called ethereal, but is now called wireshark +\item \url{http://www.wireshark.org/} +\item \url{http://www.wireshark.org/download/docs/user-guide-a4.pdf} +\end{itemize} +\end{frame} + +\begin{frame}{The wireshark protocol analyzer} +GSM protocol dissectors in wireshark +\begin{itemize} + \item TCP/IP (transport layer for Abis/IP) + \item E1 Layer 2 (LAPD) + \item GSM Um Layer 2 (LAPDm) + \item GSM Layer 3 (RR, MM, CC) + \item A-bis Layer 3 (RSL) + \begin{itemize} + \item A-bis OML for Siemens and ip.access in OpenBSC git + \end{itemize} + \item GSMTAP pseudo-header (airprobe, OpenBTS, OsmocomBB) +\end{itemize} +\end{frame} + +\begin{frame}{wireshark integration in OsmocomBB} +\begin{itemize} + \item OsmocomBB L1 runs on phone + \item OsmocomBB L23 runs on host PC + \item OsmocomBB L23 encapsulates 23byte L2 message in GSMTAP + \item GSMTAP includes information not present in L2, such as + \begin{itemize} + \item ARFCN, Timeslot + \item GSM Frame Number + \item Rx Signal Level / SNR + \end{itemize} + \item OsmocomBB L23 sends GSMTAP message over UDP socket + \item wireshark captures UDP packet like any UDP/IP +\end{itemize} +\end{frame} + +\begin{frame}{wireshark integration in OpenBTS and airprobe} +\begin{itemize} + \item airprobe software runs on host PC + \item implements Rx-only GSM L1 as SDR + \item airprobe L23 encapsulates 23byte L2 message in GSMTAP + \item wireshark captures UDP packet like any UDP/IP + \item OpenBTS wireshark intergration similar, but for Rx + Tx +\end{itemize} +\end{frame} + +\begin{frame}<handout:0>{The wireshark protocol analyzer} + Demonstration +\end{frame} diff --git a/2010/gsm_phone-anatomy/calypso-block.eps b/2010/gsm_phone-anatomy/calypso-block.eps new file mode 100644 index 0000000..01ed57a --- /dev/null +++ b/2010/gsm_phone-anatomy/calypso-block.eps @@ -0,0 +1,832 @@ +%!PS-Adobe-3.0 EPSF-3.0 +%%Creator: cairo 1.8.10 (http://cairographics.org) +%%CreationDate: Wed Apr 14 00:28:53 2010 +%%Pages: 1 +%%BoundingBox: 0 0 787 276 +%%DocumentData: Clean7Bit +%%LanguageLevel: 2 +%%EndComments +%%BeginProlog +/cairo_eps_state save def +/dict_count countdictstack def +/op_count count 1 sub def +userdict begin +/q { gsave } bind def +/Q { grestore } bind def +/cm { 6 array astore concat } bind def +/w { setlinewidth } bind def +/J { setlinecap } bind def +/j { setlinejoin } bind def +/M { setmiterlimit } bind def +/d { setdash } bind def +/m { moveto } bind def +/l { lineto } bind def +/c { curveto } bind def +/h { closepath } bind def +/re { exch dup neg 3 1 roll 5 3 roll moveto 0 rlineto + 0 exch rlineto 0 rlineto closepath } bind def +/S { stroke } bind def +/f { fill } bind def +/f* { eofill } bind def +/B { fill stroke } bind def +/B* { eofill stroke } bind def +/n { newpath } bind def +/W { clip } bind def +/W* { eoclip } bind def +/BT { } bind def +/ET { } bind def +/pdfmark where { pop globaldict /?pdfmark /exec load put } + { globaldict begin /?pdfmark /pop load def /pdfmark + /cleartomark load def end } ifelse +/BDC { mark 3 1 roll /BDC pdfmark } bind def +/EMC { mark /EMC pdfmark } bind def +/cairo_store_point { /cairo_point_y exch def /cairo_point_x exch def } def +/Tj { show currentpoint cairo_store_point } bind def +/TJ { + { + dup + type /stringtype eq + { show } { -0.001 mul 0 cairo_font_matrix dtransform rmoveto } ifelse + } forall + currentpoint cairo_store_point +} bind def +/cairo_selectfont { cairo_font_matrix aload pop pop pop 0 0 6 array astore + cairo_font exch selectfont cairo_point_x cairo_point_y moveto } bind def +/Tf { pop /cairo_font exch def /cairo_font_matrix where + { pop cairo_selectfont } if } bind def +/Td { matrix translate cairo_font_matrix matrix concatmatrix dup + /cairo_font_matrix exch def dup 4 get exch 5 get cairo_store_point + /cairo_font where { pop cairo_selectfont } if } bind def +/Tm { 2 copy 8 2 roll 6 array astore /cairo_font_matrix exch def + cairo_store_point /cairo_font where { pop cairo_selectfont } if } bind def +/g { setgray } bind def +/rg { setrgbcolor } bind def +/d1 { setcachedevice } bind def +%%EndProlog +11 dict begin +/FontType 42 def +/FontName /f-0-0 def +/PaintType 0 def +/FontMatrix [ 1 0 0 1 0 0 ] def +/FontBBox [ 0 0 0 0 ] def +/Encoding 256 array def +0 1 255 { Encoding exch /.notdef put } for +Encoding 1 /uni0043 put +Encoding 2 /uni0041 put +Encoding 3 /uni004C put +Encoding 4 /uni0059 put +Encoding 5 /uni0050 put +Encoding 6 /uni0053 put +Encoding 7 /uni004F put +Encoding 8 /uni0054 put +Encoding 9 /uni0057 put +Encoding 10 /uni0033 put +Encoding 11 /uni0030 put +Encoding 12 /uni0032 put +Encoding 13 /uni0035 put +Encoding 14 /uni0042 put +Encoding 15 /uni0055 put +Encoding 16 /uni0044 put +Encoding 17 /uni006E put +Encoding 18 /uni0074 put +Encoding 19 /uni0065 put +Encoding 20 /uni0061 put +Encoding 21 /uni0077 put +Encoding 22 /uni0069 put +Encoding 23 /uni0063 put +Encoding 24 /uni0068 put +Encoding 25 /uni004D put +Encoding 26 /uni0034 put +Encoding 27 /uni0052 put +Encoding 28 /uni0046 put +Encoding 29 /uni0036 put +Encoding 30 /uni0031 put +Encoding 31 /uni0072 put +Encoding 32 /uni0073 put +Encoding 33 /uni0076 put +Encoding 34 /uni0078 put +Encoding 35 /uni0056 put +Encoding 36 /uni0020 put +Encoding 37 /uni0047 put +Encoding 38 /uni002F put +Encoding 39 /uni004B put +Encoding 40 /uni0049 put +Encoding 41 /uni0051 put +Encoding 42 /uni006C put +Encoding 43 /uni006F put +Encoding 44 /uni0067 put +/CharStrings 45 dict dup begin +/.notdef 0 def +/uni0043 1 def +/uni0041 2 def +/uni004C 3 def +/uni0059 4 def +/uni0050 5 def +/uni0053 6 def +/uni004F 7 def +/uni0054 8 def +/uni0057 9 def +/uni0033 10 def +/uni0030 11 def +/uni0032 12 def +/uni0035 13 def +/uni0042 14 def +/uni0055 15 def +/uni0044 16 def +/uni006E 17 def +/uni0074 18 def +/uni0065 19 def +/uni0061 20 def +/uni0077 21 def +/uni0069 22 def +/uni0063 23 def +/uni0068 24 def +/uni004D 25 def +/uni0034 26 def +/uni0052 27 def +/uni0046 28 def +/uni0036 29 def +/uni0031 30 def +/uni0072 31 def +/uni0073 32 def +/uni0076 33 def +/uni0078 34 def +/uni0056 35 def +/uni0020 36 def +/uni0047 37 def +/uni002F 38 def +/uni004B 39 def +/uni0049 40 def +/uni0051 41 def +/uni006C 42 def +/uni006F 43 def +/uni0067 44 def +end readonly def +/sfnts [ +<00010000000a008000030020636d61700223f2f9000021a8000000986376742000691d390000 +2240000001fe6670676d7134766a00002440000000ab676c79668236ed47000000ac000020fc +68656164f30fc2be000024ec00000036686865610cb8067e0000252400000024686d7478dc9a +166400002548000000b46c6f63610002f714000025fc000000b86d617870049a0671000026b4 +00000020707265703b07f100000026d40000056800020066fe96046605a400030007001a400c +04fb0006fb0108057f0204002fc4d4ec310010d4ecd4ec301311211125211121660400fc7303 +1bfce5fe96070ef8f272062900010073ffe3052705f000190036401a0da10eae0a951101a100 +ae04951791118c1a07190d003014101a10fcec32ec310010e4f4ecf4ec10eef6ee30b40f1b1f +1b02015d01152e0123200011100021323637150e01232000111000213216052766e782ff00fe +f00110010082e7666aed84feadfe7a0186015386ed0562d55f5efec7fed8fed9fec75e5fd348 +48019f01670168019f470000000200100000056805d50002000a00c240410011010004050402 +1105050401110a030a0011020003030a0711050406110505040911030a08110a030a42000307 +95010381090509080706040302010009050a0b10d4c4173931002f3ce4d4ec1239304b535807 +1005ed0705ed071005ed0705ed071008ed071005ed071005ed071008ed5922b2200c01015d40 +420f010f020f070f080f005800760070008c000907010802060309041601190256015802500c +67016802780176027c0372047707780887018802800c980299039604175d005d090121013301 +230321032302bcfeee0225fe7be50239d288fd5f88d5050efd1903aefa2b017ffe8100000001 +00c90000046a05d500050025400c0295008104011c033a00040610fcecec31002fe4ec304009 +300750078003800404015d133311211521c9ca02d7fc5f05d5fad5aa0001fffc000004e705d5 +00080094402803110405040211010205050402110302080008011100000842020300af060207 +0440051c0040070910d4e4fce4123931002fec3239304b5358071005ed071008ed071008ed07 +1005ed5922b2000a01015d403c05021402350230023005300846024002400540085102510551 +086502840293021016011a031f0a2601290337013803400a670168037803700a9f0a0d5d005d +03330901330111231104d9019e019bd9fdf0cb05d5fd9a0266fcf2fd3902c7000000000200c9 +0000048d05d500080013003a40180195100095098112100a0802040005190d3f11001c090414 +10fcec32fcec11173931002ff4ecd4ec30400b0f151f153f155f15af1505015d011133323635 +342623252132041514042b0111230193fe8d9a9a8dfe3801c8fb0101fefffbfeca052ffdcf92 +878692a6e3dbdde2fda800010087ffe304a205f00027007e403c0d0c020e0b021e1f1e080902 +070a021f1f1e420a0b1e1f0415010015a11494189511049500942591118c281e0a0b1f1b0700 +221b190e2d071914222810dcc4ecfcece4111239393939310010e4f4e4ec10eef6ee10c61117 +39304b535807100eed11173907100eed1117395922b20f2901015db61f292f294f29035d0115 +2e012322061514161f011e0115140421222627351e013332363534262f012e01353424333216 +044873cc5fa5b377a67ae2d7feddfee76aef807bec72adbc879a7be2ca0117f569da05a4c537 +36807663651f192bd9b6d9e0302fd04546887e6e7c1f182dc0abc6e4260000020073ffe305d9 +05f0000b00170023401306951200950c91128c1809190f33031915101810fcecfcec310010e4 +f4ec10ee300122001110003332001110002720001110002120001110000327dcfefd0103dcdc +0101feffdc013a0178fe88fec6fec5fe870179054cfeb8fee5fee6feb80148011a011b0148a4 +fe5bfe9efe9ffe5b01a40162016201a500000001fffa000004e905d50007004a400e06029500 +81040140031c0040050810d4e4fce431002ff4ec3230014bb00a5458bd000800400001000800 +08ffc03811373859401300091f00100110021f071009400970099f09095d0321152111231121 +0604effdeecbfdee05d5aafad5052b0000010044000007a605d5000c017b4049051a0605090a +09041a0a09031a0a0b0a021a01020b0b0a061107080705110405080807021103020c000c0111 +00000c420a050203060300af0b080c0b0a09080605040302010b07000d10d4cc173931002f3c +ec32321739304b5358071005ed071008ed071008ed071005ed071008ed071005ed0705ed0710 +08ed5922b2000e01015d40f206020605020a000a000a120a2805240a200a3e023e05340a300a +4c024d05420a400a59026a026b05670a600a7b027f027c057f05800a960295051d0700090208 +03000406050005000601070408000807090009040a0a0c000e1a0315041508190c100e200421 +052006200720082309240a250b200e200e3c023a033504330530083609390b3f0c300e460046 +014a0240044505400542064207420840084009440a4d0c400e400e58025608590c500e660267 +03610462056006600760086409640a640b770076017b02780377047405790679077708700878 +0c7f0c7f0e860287038804890585098a0b8f0e97049f0eaf0e5b5d005d133309013309013301 +2309012344cc013a0139e3013a0139cdfe89fefec5fec2fe05d5fb1204eefb1204eefa2b0510 +faf000000001009cffe3047305f000280070402e0015130a86091f862013a0150da00993061c +a020932391068c15a329161c13000314191c2620101c03141f09062910fc4bb016544bb01454 +5b58b90009ffc03859c4c4d4ecf4ec11173939310010ece4f4e4ec10e6ee10ee10ee10ee1112 +3930014009641e611f6120642104005d011e0115140421222627351e013332363534262b0135 +33323635342623220607353e01333204151406033f91a3fed0fee85ec76a54c86dbec7b9a5ae +b6959ea39853be7273c959e6010c8e03251fc490ddf22525c33132968f8495a67770737b2426 +b42020d1b27cab0000020087ffe3048f05f0000b00170023401306a01200a00c91128c18091c +0f1e031c151b1810fcecf4ec310010e4f4ec10ee300122021110123332121110022732001110 +00232200111000028b9c9d9d9c9d9d9d9dfb0109fef7fbfbfef701090550fecdfeccfecdfecd +0133013301340133a0fe73fe86fe87fe73018d0179017a018d00000100960000044a05f0001c +009a4027191a1b03181c11050400110505044210a111940da014910400a00200100a02010a1c +171003061d10fc4bb015544bb016545b4bb014545b58b90003ffc03859c4d4ecc0c011123931 +002fec32f4ecf4ec304b5358071005ed0705ed11173959220140325504560556077a047a0576 +1b87190704000419041a041b051c74007606751a731b741c82008619821a821b821ca800a81b +115d005d25211521353600373e0135342623220607353e01333204151406070600018902c1fc +4c73018d33614da7865fd3787ad458e80114455b19fef4aaaaaa7701913a6d974977964243cc +3132e8c25ca5701dfeeb00000001009effe3046405d5001d005e4023041a071186101d1aa007 +14a010890d02a000810d8c07a41e171c010a031c000a10061e10fc014bb016544bb014545b58 +b90010ffc038594bb00f5458b9001000403859c4d4ec10c4ee310010e4e4f4ec10e6ee10fec4 +10ee1112393013211521113e0133320015140021222627351e0133323635342623220607dd03 +19fda02c582cfa0124fed4feef5ec3685ac06badcacaad51a15405d5aafe920f0ffeeeeaf1fe +f52020cb3130b69c9cb624260000000300c9000004ec05d5000800110020004340231900950a +0995128101950aad1f110b080213191f05000e1c1605191c2e09001c12042110fcec32fcecd4 +ec111739393931002fececf4ec10ee3930b20f2201015d011121323635342623011121323635 +34262325213216151406071e01151404232101930144a39d9da3febc012b94919194fe0b0204 +e7fa807c95a5fef0fbfde802c9fddd878b8c850266fe3e6f727170a6c0b189a21420cb98c8da +000100b2ffe3052905d50011004040160802110b0005950e8c09008112081c0a38011c004112 +10fc4bb0105458b90000ffc03859ecfcec310010e432f4ec11393939393001b61f138f139f13 +035d133311141633323635113311100021200011b2cbaec3c2aecbfedffee6fee5fedf05d5fc +75f0d3d3f0038bfc5cfedcfed6012a012400000200c9000005b005d500080011002e40150095 +09810195100802100a0005190d32001c09041210fcecf4ec113939393931002fecf4ec30b260 +1301015d0111332000111000212521200011100029010193f40135011ffee1fecbfe42019f01 +b20196fe68fe50fe61052ffb770118012e012c0117a6fe97fe80fe7efe960000000100ba0000 +0464047b001300364019030900030e0106870e11b80cbc0a010208004e0d09080b461410fcec +32f4ec31002f3ce4f4c4ec1112173930b46015cf1502015d0111231134262322061511231133 +153e013332160464b87c7c95acb9b942b375c1c602a4fd5c029e9f9ebea4fd870460ae6564ef +00010037000002f2059e0013003840190e05080f03a9001101bc08870a0b0809020400081012 +0e461410fc3cc4fc3cc432393931002fecf43cc4ec3211393930b2af1501015d011121152111 +14163b01152322263511233533110177017bfe854b73bdbdd5a28787059efec28ffda0894e9a +9fd202608f013e00000000020071ffe3047f047b0014001b00704024001501098608880515a9 +0105b90c01bb18b912b80c8c1c1b1502081508004b02120f451c10fcecf4ecc4111239310010 +e4f4ece410ee10ee10f4ee1112393040293f1d701da01dd01df01d053f003f013f023f153f1b +052c072f082f092c0a6f006f016f026f156f1b095d71015d0115211e0133323637150e012320 +00111000333200072e0123220607047ffcb20ccdb76ac76263d06bfef4fec70129fce20107b8 +02a5889ab90e025e5abec73434ae2a2c0138010a01130143feddc497b4ae9e000002007bffe3 +042d047b000a002500bc4027191f0b17090e00a91706b90e1120861fba1cb923b8118c170c00 +1703180d09080b1f030814452610fcecccd4ec323211393931002fc4e4f4fcf4ec10c6ee10ee +11391139123930406e301d301e301f3020302130223f27401d401e401f402040214022501d50 +1e501f50205021502250277027851d871e871f8720872185229027a027f0271e301e301f3020 +3021401e401f40204021501e501f50205021601e601f60206021701e701f70207021801e801f +80208021185d015d0122061514163332363d01371123350e0123222635343633213534262322 +0607353e0133321602bedfac816f99b9b8b83fbc88accbfdfb0102a79760b65465be5af3f002 +33667b6273d9b4294cfd81aa6661c1a2bdc0127f8b2e2eaa2727fc0000010056000006350460 +000c01eb404905550605090a0904550a0903550a0b0a025501020b0b0a061107080705110405 +080807021103020c000c011100000c420a050203060300bf0b080c0b0a09080605040302010b +07000d10d44bb00a544bb011545b4bb012545b4bb013545b4bb00b545b58b900000040385901 +4bb00c544bb00d545b4bb010545b58b90000ffc03859cc173931002f3cec32321739304b5358 +071005ed071008ed071008ed071005ed071008ed071005ed0705ed071008ed59220140ff0502 +16021605220a350a49024905460a400a5b025b05550a500a6e026e05660a79027f0279057f05 +870299029805940abc02bc05ce02c703cf051d0502090306040b050a080b09040b050c150219 +0316041a051b081b09140b150c2500250123022703210425052206220725082709240a210b23 +0c390336043608390c300e460248034604400442054006400740084409440a440b400e400e56 +0056015602500451055206520750085309540a550b6300640165026a0365046a056a066a076e +09610b670c6f0e7500750179027d0378047d057a067f067a077f07780879097f097b0a760b7d +0c870288058f0e97009701940293039c049b05980698079908402f960c9f0ea600a601a402a4 +03ab04ab05a906a907ab08a40caf0eb502b103bd04bb05b809bf0ec402c303cc04ca05795d00 +5d13331b01331b013301230b012356b8e6e5d9e6e5b8fedbd9f1f2d90460fc96036afc96036a +fba00396fc6a000200c100000179061400030007002b400e06be04b100bc0205010804004608 +10fc3cec3231002fe4fcec30400b1009400950096009700905015d1333112311331523c1b8b8 +b8b80460fba00614e90000010071ffe303e7047b0019003f401b00860188040e860d880ab911 +04b917b8118c1a07120d004814451a10fce432ec310010e4f4ec10fef4ee10f5ee30400b0f1b +101b801b901ba01b05015d01152e0123220615141633323637150e0123220011100021321603 +e74e9d50b3c6c6b3509d4e4da55dfdfed6012d010655a20435ac2b2be3cdcde32b2baa242401 +3e010e0112013a230000000100ba000004640614001300344019030900030e0106870e11b80c +970a010208004e0d09080b461410fcec32f4ec31002f3cecf4c4ec1112173930b2601501015d +0111231134262322061511231133113e013332160464b87c7c95acb9b942b375c1c602a4fd5c +029e9f9ebea4fd870614fd9e6564ef00000100c90000061f05d5000c00bf4034031107080702 +11010208080702110302090a0901110a0a09420a070203080300af080b050908030201050a06 +1c043e0a1c00040d10fcecfcec11173931002f3cc4ec32111739304b5358071005ed071008ed +071008ed071005ed5922b2700e01015d405603070f080f09020a15021407130a260226072007 +260a200a3407350a69027c027b07790a80028207820a90021604010b0313011b0323012c0327 +08280934013c035608590965086a097608790981018d0395019b03145d005d13210901211123 +110123011123c9012d017d017f012dc5fe7fcbfe7fc405d5fc0803f8fa2b051ffc000400fae1 +000000020064000004a405d50002000d0081401d010d030d0003030d4200030b07a005010381 +09010c0a001c0608040c0e10dc4bb00b544bb00d545b58b9000cffc03859d43cc4ec32113931 +002fe4d43cec321239304b5358071004c9071005c9592201402a0b002a004800590069007700 +8a000716012b0026012b0336014e014f0c4f0d5601660175017a0385010d5d005d0901210333 +1133152311231121350306fe0201fe35fed5d5c9fd5e0525fce303cdfc33a8fea00160c30000 +000200c90000055405d50013001c00b14035090807030a061103040305110404034206040015 +030415950914950d810b040506031109001c160e050a191904113f140a1c0c041d10fcec32fc +c4ec1117391139393931002f3cf4ecd4ec123912391239304b5358071005ed071005ed111739 +5922b2401e01015d40427a130105000501050206030704150015011402160317042500250125 +0226032706260726082609201e3601360246014602680575047505771388068807980698071f +5d005d011e01171323032e012b01112311212016151406011133323635342623038d417b3ecd +d9bf4a8b78dcca01c80100fc83fd89fe9295959202bc16907efe68017f9662fd8905d5d6d88d +ba024ffdee8783838500000100c90000042305d50009002940120695040295008104ad080501 +07031c00040a10fcec32d4c431002fecf4ec10ee30b20f0b01015d13211521112115211123c9 +035afd700250fdb0ca05d5aafe48aafd37000002008fffe3049605f0000b0024005840241306 +000d860c00a01606a01c16a510a00c8922911c8c250c22091c191e131c03211f1b2510fcecec +f4ece4310010e4f4e4fce410ee10ee10ee111239304014cb00cb01cd02cd03cd04cb05cb0607 +a41eb21e025d015d01220615141633323635342601152e01232202033e013332001514002320 +0011100021321602a4889f9f88889f9f01094c9b4cc8d30f3bb26be10105fef0e2fefdfeee01 +50011b4c9b033bbaa2a1bbbba1a2ba0279b82426fef2feef575dfeefebe6feea018d01790162 +01a51e000000000100e10000045a05d5000a004040154203a00402a005810700a009081f061c +03001f010b10d44bb00f5458b9000100403859ecc4fcec31002fec32f4ecd4ec304b53585922 +01b40f030f04025d3721110535253311211521fe014afe990165ca014afca4aa047348b848fa +d5aa0000000100ba0000034a047b001100304014060b0700110b03870eb809bc070a06080008 +461210fcc4ec3231002fe4f4ecc4d4cc11123930b450139f1302015d012e0123220615112311 +33153e0133321617034a1f492c9ca7b9b93aba85132e1c03b41211cbbefdb20460ae66630505 +00000001006fffe303c7047b002700e7403c0d0c020e0b531f1e080902070a531f1f1e420a0b +1e1f041500860189041486158918b91104b925b8118c281e0a0b1f1b0700521b080e07081422 +452810fcc4ecd4ece4111239393939310010e4f4ec10fef5ee10f5ee121739304b535807100e +ed111739070eed1117395922b2002701015d406d1c0a1c0b1c0c2e092c0a2c0b2c0c3b093b0a +3b0b3b0c0b200020012402280a280b2a132f142f152a16281e281f292029212427860a860b86 +0c860d12000000010202060a060b030c030d030e030f03100319031a031b031c041d09272f29 +3f295f297f2980299029a029f029185d005d7101152e012322061514161f011e011514062322 +2627351e013332363534262f012e01353436333216038b4ea85a898962943fc4a5f7d85ac36c +66c661828c65ab40ab98e0ce66b4043fae282854544049210e2a99899cb62323be353559514b +50250f2495829eac1e0000000001003d0000047f0460000600fb402703110405040211010205 +050402110302060006011100000642020300bf0506050302010504000710d44bb00a5458b900 +00004038594bb014544bb015545b58b90000ffc03859c4173931002fec3239304b5358071005 +ed071008ed071008ed071005ed592201408e48026a027b027f02860280029102a40208060006 +0109030904150015011a031a0426002601290329042008350035013a033a0430084600460149 +034904460548064008560056015903590450086600660169036904670568066008750074017b +037b0475057a068500850189038904890586069600960197029a03980498059706a805a706b0 +08c008df08ff083e5d005d133309013301233dc3015e015ec3fe5cfa0460fc5403acfba00000 +0001003b000004790460000b0143404605110607060411030407070604110504010201031102 +02010b110001000a11090a0101000a110b0a0708070911080807420a070401040800bf05020a +0704010408000208060c10d44bb00a544bb00f545b4bb010545b4bb011545b58b90006004038 +594bb0145458b90006ffc03859c4d4c411173931002f3cec321739304b5358071005ed071008 +ed071008ed071005ed071005ed071008ed071008ed071005ed59220140980a04040a1a04150a +260a3d04310a55045707580a660a76017a047607740a8d04820a99049f049707920a900aa601 +a904af04a507a30aa00a1c0a03040505090a0b1a03150515091a0b2903260525092a0b200d3a +013903370534073609390b300d4903460545094a0b400d590056015902590357055606590756 +085609590b500d6f0d78017f0d9b019407ab01a407b00dcf0ddf0dff0d2f5d005d0902230901 +2309013309010464fe6b01aad9febafebad901b3fe72d9012901290460fddffdc101b8fe4802 +4a0216fe71018f00000100100000056805d5000600b740270411050605031102030606050311 +0403000100021101010042030401af0006040302000505010710d4c4173931002fec3239304b +5358071005ed071008ed071008ed071005ed5922b2500801015d406200032a03470447055a03 +7d038303070600070208040906150114021a041a052a00260126022904290525062008380033 +0133023c043c053706480045014502490449054706590056066602690469057a007601760279 +0479057506800898009706295d005d21013309013301024afdc6d301d901dad2fdc705d5fb17 +04e9fa2b00010073ffe3058b05f0001d0039402000051b0195031b950812a111ae15950e9108 +8c1e02001c1134043318190b101e10fcecfce4fcc4310010e4f4ecf4ec10fed4ee1139393025 +1121352111060423200011100021320417152e0123200011100021323604c3feb6021275fee6 +a0fea2fe75018b015e9201076f70fc8bfeeefeed011301126ba8d50191a6fd7f53550199016d +016e01994846d75f60fecefed1fed2fece25000000010000ff4202b205d50003002d4014001a +010201021a03000342029f008104020001032fc43939310010f4ec304b5358071005ed071005 +ed5922013301230208aafdf8aa05d5f96d000000000100c90000056a05d5000a00ef40280811 +05060507110606050311040504021105050442080502030300af09060501040608011c00040b +10fcec32d4c4113931002f3cec321739304b5358071004ed071005ed071005ed071004ed5922 +b2080301015d4092140201040209081602280528083702360534084702460543085502670276 +027705830288058f0894029b08e702150603090509061b031907050a030a07180328052b062a +073604360536063507300c41034004450540064007400c62036004680567077705700c8b038b +058e068f078f0c9a039d069d07b603b507c503c507d703d607e803e904e805ea06f703f805f9 +062c5d71005d711333110121090121011123c9ca029e0104fd1b031afef6fd33ca05d5fd8902 +77fd48fce302cffd31000000000100c90000019305d50003002eb700af02011c00040410fc4b +b0105458b9000000403859ec31002fec3001400d30054005500560058f059f05065d13331123 +c9caca05d5fa2b0000020073fef805d905f0000b001d0052402a1110020f010c0d0c0e010d0d +0c420f1e0c06951200951891128c0d1e0d1b0f0c0309191b33031915101e10fcecfcec113939 +1139310010c4e4f4ec10ee391239304b5358071005ed071005ed173959220122001110003332 +00111000130123270e012320001110002120001110020327dcfefd0103dcdc0101feff3f010a +f4dd212310fec5fe870179013b013a0178d1054cfeb8fee5fee6feb80148011a011b0148facf +feddef020201a50161016201a5fe5bfe9efefcfe8e00000100c100000179061400030022b700 +9702010800460410fcec31002fec30400d10054005500560057005f00506015d13331123c1b8 +b80614f9ec0000020071ffe30475047b000b0017004a401306b91200b90cb8128c1809120f51 +031215451810fcecf4ec310010e4f4ec10ee3040233f197b007b067f077f087f097f0a7f0b7b +0c7f0d7f0e7f0f7f107f117b12a019f01911015d012206151416333236353426273200111000 +232200111000027394acab9593acac93f00112feeef0f1feef011103dfe7c9c9e7e8c8c7e99c +fec8feecfeedfec70139011301140138000000020071fe56045a047b000b0028004a4023190c +1d0912861316b90f03b92623b827bc09b90fbd1a1d261900080c4706121220452910fcc4ecf4 +ec323231002fc4e4ece4f4c4ec10fed5ee1112393930b6602a802aa02a03015d013426232206 +15141633323617100221222627351e013332363d010e0123220211101233321617353303a2a5 +9594a5a59495a5b8fefefa61ac51519e52b5b439b27ccefcfcce7cb239b8023dc8dcdcc8c7dc +dcebfee2fee91d1eb32c2abdbf5b6362013a01030104013a6263aa0000000002000300000000 +001400010000000000340004002000000004000400010000f02cffff0000f000ffff10000001 +000000000006006400000000002d0000000100020003000400050006000700080009000a000b +000c000d000e000f0010001100120013001400150016001700180019001a001b001c001d001e +001f0020002100220023002400250026002700280029002a002b002c013500b800cb00cb00c1 +00aa009c01a600b800660000007100cb00a002b20085007500b800c301cb0189022d00cb00a6 +00f000d300aa008700cb03aa0400014a003300cb000000d9050200f4015400b4009c01390114 +013907060400044e04b4045204b804e704cd0037047304cd04600473013303a2055605a60556 +053903c5021200c9001f00b801df007300ba03e9033303bc0444040e00df03cd03aa00e503aa +0404000000cb008f00a4007b00b80014016f007f027b0252008f00c705cd009a009a006f00cb +00cd019e01d300f000ba018300d5009803040248009e01d500c100cb00f600830354027f0000 +0333026600d300c700a400cd008f009a0073040005d5010a00fe022b00a400b4009c00000062 +009c0000001d032d05d505d505d505f0007f007b005400a406b80614072301d300b800cb00a6 +01c301ec069300a000d3035c037103db0185042304a80448008f0139011401390360008f05d5 +019a0614072306660179046004600460047b009c00000277046001aa00e904600762007b00c5 +007f027b000000b4025205cd006600bc00660077061000cd013b01850389008f007b0000001d +00cd074a042f009c009c0000077d006f0000006f0335006a006f007b00ae00b2002d0396008f +027b00f600830354063705f6008f009c04e10266008f018d02f600cd03440029006604ee0073 +0000140000960000b707060504030201002c2010b002254964b040515820c859212d2cb00225 +4964b040515820c859212d2c20100720b00050b00d7920b8ffff5058041b0559b0051cb00325 +08b0042523e120b00050b00d7920b8ffff5058041b0559b0051cb0032508e12d2c4b505820b0 +fd454459212d2cb002254560442d2c4b5358b00225b0022545445921212d2c45442d2cb00225 +b0022549b00525b005254960b0206368208a108a233a8a10653a2d000001000000024ccc7563 +80ee5f0f3cf5001f080000000000c74a953600000000c74a9536f7d6fd330d72095500000008 +000000010000000000010000076dfe1d00000de2f7d6fa510d72000100000000000000000000 +00000000002d04cd00660596007305790010047500c904e3fffc04d300c905140087064c0073 +04e3fffa07e900440517009c05170087051700960517009e057d00c905db00b2062900c90512 +00ba0323003704ec007104e7007b068b0056023900c104660071051200ba06e700c905170064 +058f00c9049a00c90517008f051700e1034a00ba042b006f04bc003d04bc003b05790010028b +00000633007302b20000053f00c9025c00c9064c0073023900c104e500710514007100000000 +00000044000000dc000001d80000021c000002e00000036000000458000004e4000005540000 +0710000007f80000087c0000097800000a3800000ae800000b6c00000bec00000c6400000ce0 +00000db400000ee00000110400001154000011ec00001264000013600000141c000015300000 +15840000165c000016cc0000173c0000189c000019c000001b4400001c2400001c2400001ccc +00001d1800001e4000001e8800001f5400001f9000002034000020fc00010000002d0354002b +0068000c000200100099000800000415021600080004b8028040fffbfe03fa1403f92503f832 +03f79603f60e03f5fe03f4fe03f32503f20e03f19603f02503ef8a4105effe03ee9603ed9603 +ecfa03ebfa03eafe03e93a03e84203e7fe03e63203e5e45305e59603e48a4105e45303e3e22f +05e3fa03e22f03e1fe03e0fe03df3203de1403dd9603dcfe03db1203da7d03d9bb03d8fe03d6 +8a4105d67d03d5d44705d57d03d44703d3d21b05d3fe03d21b03d1fe03d0fe03cffe03cefe03 +cd9603cccb1e05ccfe03cb1e03ca3203c9fe03c6851105c61c03c51603c4fe03c3fe03c2fe03 +c1fe03c0fe03bffe03befe03bdfe03bcfe03bbfe03ba1103b9862505b9fe03b8b7bb05b8fe03 +b7b65d05b7bb03b78004b6b52505b65d40ff03b64004b52503b4fe03b39603b2fe03b1fe03b0 +fe03affe03ae6403ad0e03acab2505ac6403abaa1205ab2503aa1203a98a4105a9fa03a8fe03 +a7fe03a6fe03a51203a4fe03a3a20e05a33203a20e03a16403a08a4105a096039ffe039e9d0c +059efe039d0c039c9b19059c64039b9a10059b19039a1003990a0398fe0397960d0597fe0396 +0d03958a410595960394930e05942803930e0392fa039190bb0591fe03908f5d0590bb039080 +048f8e25058f5d038f40048e25038dfe038c8b2e058cfe038b2e038a8625058a410389880b05 +891403880b03878625058764038685110586250385110384fe038382110583fe0382110381fe +0380fe037ffe0340ff7e7d7d057efe037d7d037c64037b5415057b25037afe0379fe03780e03 +770c03760a0375fe0374fa0373fa0372fa0371fa0370fe036ffe036efe036c21036bfe036a11 +42056a530369fe03687d036711420566fe0365fe0364fe0363fe0362fe03613a0360fa035e0c +035dfe035bfe035afe0359580a0559fa03580a035716190557320356fe035554150555420354 +150353011005531803521403514a130551fe03500b034ffe034e4d10054efe034d10034cfe03 +4b4a13054bfe034a4910054a1303491d0d05491003480d0347fe0346960345960344fe034302 +2d0543fa0342bb03414b0340fe033ffe033e3d12053e14033d3c0f053d12033c3b0d053c40ff +0f033b0d033afe0339fe033837140538fa033736100537140336350b05361003350b03341e03 +330d0332310b0532fe03310b03302f0b05300d032f0b032e2d09052e10032d09032c32032b2a +25052b64032a2912052a25032912032827250528410327250326250b05260f03250b0324fe03 +23fe03220f03210110052112032064031ffa031e1d0d051e64031d0d031c1142051cfe031bfa +031a42031911420519fe031864031716190517fe031601100516190315fe0314fe0313fe0312 +11420512fe0311022d05114203107d030f64030efe030d0c16050dfe030c0110050c16030bfe +030a100309fe0308022d0508fe030714030664030401100504fe03401503022d0503fe030201 +1005022d0301100300fe0301b80164858d012b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b +2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b +2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b +2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b +2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b002b2b2b2b2b2b +2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b +2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b +2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b +2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b1d00> +] def +FontName currentdict end definefont pop +%%Page: 1 1 +%%BeginPageSetup +%%PageBoundingBox: 0 0 787 276 +%%EndPageSetup +q +0 g +2.267717 w +0 J +0 j +[] 0.0 d +4 M q 1 0 0 -1 0 275.102356 cm +737.715 156.613 m 780.234 156.613 l 780.234 99.922 l 780.234 99.922 l S Q +1.700787 w +q 1 0 0 -1 0 275.102356 cm +786.531 93.055 m 782.773 93.055 779.727 96.105 779.727 99.859 c 779.727 +103.613 782.773 106.664 786.531 106.664 c S Q +1 g +0.707 274.395 m 142.441 274.395 l 142.441 61.794 l 0.707 61.794 l 0.707 +274.395 l h +0.707 274.395 m f +0 g +1.417323 w +q 1 0 0 -1 0 275.102356 cm +0.707 0.707 m 142.441 0.707 l 142.441 213.309 l 0.707 213.309 l 0.707 +0.707 l h +0.707 0.707 m S Q +BT +16 0 0 16 2.308661 260.220464 Tm +/f-0-0 1 Tf +[<01>-1<02>1<03>133<04>-1<050607>]TJ +ET +1 g +255.723 246.122 m 340.973 246.122 l 340.973 61.927 l 255.723 61.927 l +255.723 246.122 l h +255.723 246.122 m f +0 g +1.205805 w +q 1 0 0 -1 0 275.102356 cm +255.723 28.98 m 340.973 28.98 l 340.973 213.176 l 255.723 213.176 l +255.723 28.98 l h +255.723 28.98 m S Q +BT +17.54446 0 0 16.791247 255.826791 230.241386 Tm +/f-0-0 1 Tf +<0809030a0b0c0d>Tj +9.6 0 0 9.6 259.749073 129.812069 Tm +[<0e>18<0605>]TJ +0.0416667 -3.069444 Td +<0f0605>Tj +0.0833333 -2.7862 Td +<080605>Tj +5.705271 10.248252 Td +<0e0f03>Tj +-0.0774485 1.373258 Td +<0e1003>Tj +ET +1 g +652.68 161.005 m 737.715 161.005 l 737.715 89.895 l 652.68 89.895 l +652.68 161.005 l h +652.68 161.005 m f +0 g +1.419749 w +q 1 0 0 -1 0 275.102356 cm +652.68 114.098 m 737.715 114.098 l 737.715 185.207 l 652.68 185.207 l +652.68 114.098 l h +652.68 114.098 m S Q +BT +9.6 0 0 9.6 666.850416 118.488179 Tm +/f-0-0 1 Tf +[<021112>-1<1311>-1<11>-1<14>]TJ +0 -1 Td +[<0615161217>-1<18>]TJ +16 0 0 16 654.277173 146.834639 Tm +[<0206191a0d>-1<0a0c>]TJ +ET +1 g +652.613 274.458 m 766.348 274.458 l 766.348 203.997 l 652.613 203.997 l +652.613 274.458 l h +652.613 274.458 m f +0 g +1.292092 w +q 1 0 0 -1 0 275.102356 cm +652.613 0.645 m 766.348 0.645 l 766.348 71.105 l 652.613 71.105 l +652.613 0.645 l h +652.613 0.645 m S Q +0.333333 0 0 rg +2.267717 w +q 1 0 0 -1 0 275.102356 cm +340.867 199.133 m 624.332 199.133 l 624.332 57.402 l 652.676 57.402 l S Q +0 g +640.812 223.188 m 655.68 217.723 l 640.812 212.255 l 643.188 215.485 +643.176 219.899 640.812 223.188 c h +640.812 223.188 m f* +1 0 0 rg +142.441 132.661 m 255.828 132.661 l 255.828 132.661 l f* +2.834646 w +q 1 0 0 -1 0 275.102356 cm +142.441 142.441 m 255.828 142.441 l 255.828 142.441 l S Q +0 g +157.27 125.802 m 138.688 132.634 l 157.27 139.466 l 154.301 135.434 +154.316 129.915 157.27 125.802 c h +157.27 125.802 m f* +241 139.52 m 259.582 132.688 l 241 125.856 l 243.969 129.891 243.949 +135.411 241 139.52 c h +241 139.52 m f* +0 0 1 rg +q 1 0 0 -1 0 275.102356 cm +142.441 199.133 m 255.828 199.133 l S Q +0 g +241 82.829 m 259.582 75.997 l 241 69.161 l 243.969 73.196 243.949 +78.716 241 82.829 c h +241 82.829 m f* +1 0 0 rg +142.441 104.313 m 255.828 104.313 l 255.828 104.313 l f* +q 1 0 0 -1 0 275.102356 cm +142.441 170.789 m 255.828 170.789 l 255.828 170.789 l S Q +0 g +157.27 97.454 m 138.688 104.286 l 157.27 111.122 l 154.301 107.087 +154.316 101.567 157.27 97.454 c h +157.27 97.454 m f* +241 111.177 m 259.582 104.341 l 241 97.509 l 243.969 101.544 243.949 +107.063 241 111.177 c h +241 111.177 m f* +1 g +454.254 274.395 m 567.637 274.395 l 567.637 104.313 l 454.254 104.313 l +454.254 274.395 l h +454.254 274.395 m f +0 g +1.417323 w +q 1 0 0 -1 0 275.102356 cm +454.254 0.707 m 567.637 0.707 l 567.637 170.789 l 454.254 170.789 l +454.254 0.707 l h +454.254 0.707 m S Q +BT +16 0 0 16 454.251978 260.220464 Tm +/f-0-0 1 Tf +[<081b>-1<1c>-1<1d1e>-1<0d1e>]TJ +12.8 0 0 12.8 468.42522 231.874007 Tm +[<08>146<1f>-1<1411>-1<20>-1<17>-1<1316>1<21131f>]TJ +0 -1 Td +[<191622>31<131f>-1<20>]TJ +0 -1 Td +<230107>Tj +0 -1 Td +<050303>Tj +16 0 0 16 652.677173 260.220464 Tm +[<1b1c>-1<0a>-1<1e1d>-1<1d>]TJ +12.8 0 0 12.8 666.850416 231.874007 Tm +[<1b1c>-1<24>-1<05>64<02>]TJ +9.6 0 0 9.6 118.894483 72.768489 Tm +<080605>Tj +ET +1 0 1 rg +2.267717 w +q 1 0 0 -1 0 275.102356 cm +567.637 14.883 m 652.676 14.883 l 652.676 14.883 l S Q +0 g +640.812 265.708 m 655.68 260.243 l 640.812 254.774 l 643.188 258.005 +643.176 262.419 640.812 265.708 c h +640.812 265.708 m f* +BT +9.6 0 0 9.6 595.984253 261.820464 Tm +/f-0-0 1 Tf +<250619>Tj +ET +1 0 1 rg +q 1 0 0 -1 0 275.102356 cm +567.637 29.055 m 652.676 29.055 l 652.676 29.055 l S Q +0 g +640.812 251.536 m 655.68 246.067 l 640.812 240.602 l 643.188 243.829 +643.176 248.247 640.812 251.536 c h +640.812 251.536 m f* +BT +9.6 0 0 9.6 595.984253 247.647237 Tm +/f-0-0 1 Tf +[<10010626>-1<05>-1<01>-1<06>]TJ +ET +1 0 1 rg +q 1 0 0 -1 0 275.102356 cm +652.676 128.27 m 567.637 128.27 l 567.637 128.27 l S Q +0 g +555.773 152.325 m 570.641 146.856 l 555.773 141.391 l 558.148 144.618 +558.137 149.032 555.773 152.325 c h +555.773 152.325 m f* +BT +9.6 0 0 9.6 595.984253 148.434639 Tm +/f-0-0 1 Tf +<250619>Tj +ET +1 0 1 rg +q 1 0 0 -1 0 275.102356 cm +652.676 142.441 m 567.637 142.441 l 567.637 142.441 l S Q +0 g +555.773 138.149 m 570.641 132.684 l 555.773 127.216 l 558.148 130.442 +558.137 134.86 555.773 138.149 c h +555.773 138.149 m f* +BT +9.6 0 0 9.6 595.984253 134.261409 Tm +/f-0-0 1 Tf +<100106>Tj +ET +1 0 1 rg +q 1 0 0 -1 0 275.102356 cm +652.676 156.613 m 567.637 156.613 l 567.637 156.613 l S Q +0 g +555.773 123.977 m 570.641 118.509 l 555.773 113.044 l 558.148 116.27 +558.137 120.688 555.773 123.977 c h +555.773 123.977 m f* +BT +9.6 0 0 9.6 595.984253 120.088179 Tm +/f-0-0 1 Tf +[<0501>-1<06>]TJ +-32.479004 14.930446 Td +[<1b1c>-1<01>-1<0327>]TJ +ET +1 1 0 rg +q 1 0 0 -1 0 275.102356 cm +454.254 14.883 m 142.441 14.883 l 142.441 14.883 l S Q +0 g +130.578 265.708 m 145.445 260.243 l 130.578 254.774 l 132.953 258.005 +132.941 262.419 130.578 265.708 c h +130.578 265.708 m f* +0 1 0 rg +340.867 189.356 m 454.254 189.356 l 454.254 189.356 l 454.254 189.356 l f* +q 1 0 0 -1 0 275.102356 cm +340.867 85.746 m 454.254 85.746 l 454.254 85.746 l 454.254 85.746 l S Q +0 g +352.73 183.864 m 337.863 189.333 l 352.73 194.798 l 350.355 191.571 +350.367 187.157 352.73 183.864 c h +352.73 183.864 m f* +442.391 194.845 m 457.254 189.376 l 442.391 183.911 l 444.766 187.138 +444.75 191.552 442.391 194.845 c h +442.391 194.845 m f* +BT +9.6 0 0 9.6 375.385816 192.554317 Tm +/f-0-0 1 Tf +[<2826>-1<29240211>-1<142a2b>1<2c>]TJ +ET +0 1 0 rg +q 1 0 0 -1 0 275.102356 cm +369.211 85.746 m 369.211 99.922 l 340.867 99.922 l 340.867 99.922 l S Q +0 g +363.723 177.493 m 369.191 192.356 l 374.656 177.493 l 371.43 179.868 +367.016 179.852 363.723 177.493 c h +363.723 177.493 m f* +1 1 0 rg +q 1 0 0 -1 0 275.102356 cm +142.441 43.227 m 255.828 43.227 l S Q +0 g +243.965 237.364 m 258.828 231.895 l 243.965 226.43 l 246.34 229.657 +246.324 234.071 243.965 237.364 c h +243.965 237.364 m f* +BT +9.6 0 0 9.6 180.160621 235.074007 Tm +/f-0-0 1 Tf +[<01>-1<03>1<27>-1<1e0a>-1<19>]TJ +ET +0.333333 0 0 rg +q 1 0 0 -1 0 275.102356 cm +340.867 128.27 m 454.254 128.27 l S Q +0 g +442.391 152.325 m 457.254 146.856 l 442.391 141.391 l 444.766 144.618 +444.75 149.032 442.391 152.325 c h +442.391 152.325 m f* +BT +9.6 0 0 9.6 374.012574 151.634639 Tm +/f-0-0 1 Tf +[<021c01>-1<24>-1<02>1<11>-1<14>-1<2a>1<2b2c>]TJ +ET +0 0 1 rg +q 1 0 0 -1 0 275.102356 cm +114.094 213.309 m 114.094 270 l 681.023 270 l 681.023 184.961 l S Q +0 g +675.535 78.278 m 681 93.145 l 686.469 78.278 l 683.242 80.653 678.824 +80.641 675.535 78.278 c h +675.535 78.278 m f* +BT +9.6 0 0 9.6 227.480323 8.302352 Tm +/f-0-0 1 Tf +[<080605>-1<2405>44<14>-1<1f14>-1<2a>1<2a132a>]TJ +0.166667 3.0958 Td +[<080605>-1<2406131f>-1<16142a>]TJ +ET +1 1 0 rg +q 1 0 0 -1 0 275.102356 cm +142.441 57.402 m 255.828 57.402 l S Q +0 g +243.965 223.188 m 258.828 217.723 l 243.965 212.255 l 246.34 215.485 +246.324 219.899 243.965 223.188 c h +243.965 223.188 m f* +BT +9.6 0 0 9.6 180.16062 220.90078 Tm +/f-0-0 1 Tf +[<01>-1<03>1<27>-1<0a0c>-1<27>]TJ +ET +1 0 1 rg +q 1 0 0 -1 0 275.102356 cm +709.371 71.574 m 709.371 114.094 l S Q +0 g +714.859 172.872 m 709.391 158.005 l 703.926 172.872 l 707.152 170.497 +711.57 170.509 714.859 172.872 c h +714.859 172.872 m f* +BT +0 9.6 -9.6 0 706.170093 175.181099 Tm +/f-0-0 1 Tf +<250619>Tj +ET +1 0 1 rg +q 1 0 0 -1 0 275.102356 cm +681.023 71.574 m 681.023 114.094 l S Q +0 g +686.512 172.872 m 681.047 158.005 l 675.578 172.872 l 678.805 170.497 +683.223 170.509 686.512 172.872 c h +686.512 172.872 m f* +BT +0 8.615542 -9.6 0 676.223589 162.768256 Tm +/f-0-0 1 Tf +[<10010626>-1<05>-1<01>-1<06>]TJ +ET +0 0 1 rg +q 1 0 0 -1 0 275.102356 cm +681.023 270 m 751.891 270 l 751.891 71.574 l 751.891 71.574 l S Q +0 g +685.469 5.102 m 685.469 2.598 683.438 0.567 680.934 0.567 c 678.43 +0.567 676.398 2.598 676.398 5.102 c 676.398 7.606 678.43 9.638 680.934 +9.638 c 683.438 9.638 685.469 7.606 685.469 5.102 c h +685.469 5.102 m f* +1.133858 w +q 1 0 0 -1 0 275.102356 cm +685.469 270 m 685.469 272.504 683.438 274.535 680.934 274.535 c 678.43 +274.535 676.398 272.504 676.398 270 c 676.398 267.496 678.43 265.465 +680.934 265.465 c 683.438 265.465 685.469 267.496 685.469 270 c h +685.469 270 m S Q +740.027 209.016 m 754.895 203.548 l 740.027 198.083 l 742.402 201.309 +742.387 205.727 740.027 209.016 c h +740.027 209.016 m f* +BT +9.6 0 0 9.6 375.385816 79.168489 Tm +/f-0-0 1 Tf +[<020501>-1<240211>-1<142a2b>1<2c>]TJ +ET +0 0 1 rg +2.267717 w +q 1 0 0 -1 0 275.102356 cm +199.133 199.133 m 199.133 241.652 l 482.598 241.652 l 482.598 170.789 l S Q +0 g +199.133 71.524 m 196.629 71.524 194.598 73.555 194.598 76.059 c 194.598 +78.563 196.629 80.595 199.133 80.595 c 201.637 80.595 203.668 78.563 +203.668 76.059 c 203.668 73.555 201.637 71.524 199.133 71.524 c h +199.133 71.524 m f* +1.133858 w +q 0.000000000000000061 -1 -1 -0.000000000000000061 0 275.102356 cm +203.578 -199.133 m 203.578 -196.629 201.547 -194.598 199.043 -194.598 c +196.539 -194.598 194.508 -196.629 194.508 -199.133 c 194.508 -201.637 +196.539 -203.668 199.043 -203.668 c 201.547 -203.668 203.578 -201.637 +203.578 -199.133 c h +203.578 -199.133 m S Q +477.109 92.454 m 482.578 107.317 l 488.043 92.454 l 484.816 94.829 +480.398 94.813 477.109 92.454 c h +477.109 92.454 m f* +Q +showpage +%%Trailer +count op_count sub {pop} repeat +countdictstack dict_count sub {end} repeat +cairo_eps_state restore +%%EOF diff --git a/2010/gsm_phone-anatomy/calypso-block.pdf b/2010/gsm_phone-anatomy/calypso-block.pdf Binary files differnew file mode 100644 index 0000000..27f8be8 --- /dev/null +++ b/2010/gsm_phone-anatomy/calypso-block.pdf diff --git a/2010/gsm_phone-anatomy/calypso-block.svg b/2010/gsm_phone-anatomy/calypso-block.svg new file mode 100644 index 0000000..cf7d07a --- /dev/null +++ b/2010/gsm_phone-anatomy/calypso-block.svg @@ -0,0 +1,778 @@ +<?xml version="1.0" encoding="UTF-8" standalone="no"?> +<!-- Created with Inkscape (http://www.inkscape.org/) --> + +<svg + xmlns:dc="http://purl.org/dc/elements/1.1/" + xmlns:cc="http://creativecommons.org/ns#" + xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" + xmlns:svg="http://www.w3.org/2000/svg" + xmlns="http://www.w3.org/2000/svg" + xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd" + xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape" + width="297mm" + height="210mm" + id="svg2383" + sodipodi:version="0.32" + inkscape:version="0.47 r22583" + sodipodi:docname="calypso-block.pdf" + inkscape:output_extension="org.inkscape.output.svg.inkscape" + inkscape:export-filename="/home/laforge/calypso-block.png" + inkscape:export-xdpi="90" + inkscape:export-ydpi="90" + version="1.1"> + <defs + id="defs2385"> + <marker + inkscape:stockid="CurveIn" + orient="auto" + refY="0.0" + refX="0.0" + id="CurveIn" + style="overflow:visible"> + <path + id="path3349" + d="M 4.6254930,-5.0456926 C 1.8654930,-5.0456926 -0.37450702,-2.8056926 -0.37450702,-0.045692580 C -0.37450702,2.7143074 1.8654930,4.9543074 4.6254930,4.9543074" + style="fill-rule:evenodd;stroke:#000000;stroke-width:1.0pt;marker-start:none;marker-end:none;fill:none" + transform="scale(0.6)" /> + </marker> + <marker + inkscape:stockid="DotM" + orient="auto" + refY="0.0" + refX="0.0" + id="DotM" + style="overflow:visible"> + <path + id="path3229" + d="M -2.5,-1.0 C -2.5,1.7600000 -4.7400000,4.0 -7.5,4.0 C -10.260000,4.0 -12.5,1.7600000 -12.5,-1.0 C -12.5,-3.7600000 -10.260000,-6.0 -7.5,-6.0 C -4.7400000,-6.0 -2.5,-3.7600000 -2.5,-1.0 z " + style="fill-rule:evenodd;stroke:#000000;stroke-width:1.0pt;marker-start:none;marker-end:none" + transform="scale(0.4) translate(7.4, 1)" /> + </marker> + <marker + inkscape:stockid="Arrow2Mstart" + orient="auto" + refY="0.0" + refX="0.0" + id="Arrow2Mstart" + style="overflow:visible"> + <path + id="path7719" + style="font-size:12.0;fill-rule:evenodd;stroke-width:0.62500000;stroke-linejoin:round" + d="M 8.7185878,4.0337352 L -2.2072895,0.016013256 L 8.7185884,-4.0017078 C 6.9730900,-1.6296469 6.9831476,1.6157441 8.7185878,4.0337352 z " + transform="scale(0.6) translate(0,0)" /> + </marker> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0.0" + refX="0.0" + id="Arrow2Mend" + style="overflow:visible;"> + <path + id="path3191" + style="font-size:12.0;fill-rule:evenodd;stroke-width:0.62500000;stroke-linejoin:round;" + d="M 8.7185878,4.0337352 L -2.2072895,0.016013256 L 8.7185884,-4.0017078 C 6.9730900,-1.6296469 6.9831476,1.6157441 8.7185878,4.0337352 z " + transform="scale(0.6) rotate(180) translate(0,0)" /> + </marker> + <marker + inkscape:stockid="Arrow1Send" + orient="auto" + refY="0.0" + refX="0.0" + id="Arrow1Send" + style="overflow:visible;"> + <path + id="path3179" + d="M 0.0,0.0 L 5.0,-5.0 L -12.5,0.0 L 5.0,5.0 L 0.0,0.0 z " + style="fill-rule:evenodd;stroke:#000000;stroke-width:1.0pt;marker-start:none;" + transform="scale(0.2) rotate(180) translate(6,0)" /> + </marker> + <marker + inkscape:stockid="Arrow1Mend" + orient="auto" + refY="0.0" + refX="0.0" + id="Arrow1Mend" + style="overflow:visible;"> + <path + id="path3173" + d="M 0.0,0.0 L 5.0,-5.0 L -12.5,0.0 L 5.0,5.0 L 0.0,0.0 z " + style="fill-rule:evenodd;stroke:#000000;stroke-width:1.0pt;marker-start:none;" + transform="scale(0.4) rotate(180) translate(10,0)" /> + </marker> + <marker + inkscape:stockid="TriangleOutL" + orient="auto" + refY="0.0" + refX="0.0" + id="TriangleOutL" + style="overflow:visible"> + <path + id="path3307" + d="M 5.77,0.0 L -2.88,5.0 L -2.88,-5.0 L 5.77,0.0 z " + style="fill-rule:evenodd;stroke:#000000;stroke-width:1.0pt;marker-start:none" + transform="scale(0.8)" /> + </marker> + <marker + inkscape:stockid="Arrow2Lend" + orient="auto" + refY="0.0" + refX="0.0" + id="Arrow2Lend" + style="overflow:visible;"> + <path + id="path3185" + style="font-size:12.0;fill-rule:evenodd;stroke-width:0.62500000;stroke-linejoin:round;" + d="M 8.7185878,4.0337352 L -2.2072895,0.016013256 L 8.7185884,-4.0017078 C 6.9730900,-1.6296469 6.9831476,1.6157441 8.7185878,4.0337352 z " + transform="scale(1.1) rotate(180) translate(1,0)" /> + </marker> + <marker + inkscape:stockid="Arrow1Lend" + orient="auto" + refY="0.0" + refX="0.0" + id="Arrow1Lend" + style="overflow:visible;"> + <path + id="path3188" + d="M 0.0,0.0 L 5.0,-5.0 L -12.5,0.0 L 5.0,5.0 L 0.0,0.0 z " + style="fill-rule:evenodd;stroke:#000000;stroke-width:1.0pt;marker-start:none;" + transform="scale(0.8) rotate(180) translate(12.5,0)" /> + </marker> + <inkscape:perspective + sodipodi:type="inkscape:persp3d" + inkscape:vp_x="0 : 372.04724 : 1" + inkscape:vp_y="0 : 1000 : 0" + inkscape:vp_z="1052.3622 : 372.04724 : 1" + inkscape:persp3d-origin="526.18109 : 248.03149 : 1" + id="perspective2392" /> + </defs> + <sodipodi:namedview + inkscape:document-units="mm" + pagecolor="#ffffff" + bordercolor="#666666" + borderopacity="1.0" + inkscape:pageopacity="0.0" + inkscape:pageshadow="2" + inkscape:zoom="0.96166971" + inkscape:cx="267.27075" + inkscape:cy="495.79724" + inkscape:current-layer="layer1" + id="namedview2387" + showgrid="true" + inkscape:snap-global="true" + inkscape:window-width="599" + inkscape:window-height="987" + inkscape:window-x="0" + inkscape:window-y="0" + inkscape:snap-guide="true" + inkscape:object-paths="false" + inkscape:object-nodes="false" + objecttolerance="3" + gridtolerance="10000" + inkscape:window-maximized="0"> + <inkscape:grid + type="xygrid" + id="grid2400" + visible="true" + enabled="true" + units="mm" + spacingx="5mm" + spacingy="5mm" + empspacing="2" /> + </sodipodi:namedview> + <metadata + id="metadata2389"> + <rdf:RDF> + <cc:Work + rdf:about=""> + <dc:format>image/svg+xml</dc:format> + <dc:type + rdf:resource="http://purl.org/dc/dcmitype/StillImage" /> + <dc:title></dc:title> + </cc:Work> + </rdf:RDF> + </metadata> + <g + inkscape:label="Layer 1" + inkscape:groupmode="layer" + id="layer1"> + <path + style="fill:none;stroke:#000000;stroke-width:2.83464575;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-end:url(#CurveIn)" + d="m 956.69293,230.31495 53.14957,0 0,-70.86614 0,0" + id="path22123" /> + <g + id="g12239" + transform="translate(-35.433051,2.2643947e-6)"> + <rect + y="35.433064" + x="70.866142" + height="265.74802" + width="177.16536" + id="rect7161" + style="fill:#ffffff;stroke:#000000;stroke-width:1.77165353;stroke-miterlimit:4;stroke-dasharray:none" /> + <text + sodipodi:linespacing="100%" + id="text7163" + y="53.149601" + x="72.866142" + style="font-size:20px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans;-inkscape-font-specification:Bitstream Vera Sans" + xml:space="preserve"><tspan + y="53.149601" + x="72.866142" + id="tspan7165" + sodipodi:role="line">CALYPSO</tspan><tspan + y="73.149597" + x="72.866142" + sodipodi:role="line" + id="tspan3020">Digital Baseband</tspan><tspan + y="93.149597" + x="72.866142" + sodipodi:role="line" + id="tspan3024"></tspan><tspan + y="93.149597" + x="72.866142" + sodipodi:role="line" + id="tspan3036">DSP</tspan><tspan + y="113.1496" + x="72.866142" + sodipodi:role="line" + id="tspan3026">MCU</tspan><tspan + y="133.1496" + x="72.866142" + sodipodi:role="line" + id="tspan3028">SRAM</tspan><tspan + y="153.1496" + x="72.866142" + sodipodi:role="line" + id="tspan3030">Mask ROM</tspan><tspan + y="173.1496" + x="72.866142" + sodipodi:role="line" + id="tspan3032">UART, SPI, I2C</tspan></text> + </g> + <g + id="g20347" + transform="translate(-35.433051,2.2643947e-6)"> + <rect + y="70.77356" + x="389.63159" + height="230.24446" + width="106.56361" + id="rect2406" + style="fill:#ffffff;stroke:#000000;stroke-width:1.50725651;stroke-miterlimit:4;stroke-dasharray:none" /> + <text + transform="scale(1.0221827,0.9782987)" + sodipodi:linespacing="100%" + id="text7157" + y="92.63372" + x="381.30542" + style="font-size:21.45465279px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans;-inkscape-font-specification:Bitstream Vera Sans" + xml:space="preserve"><tspan + y="92.63372" + x="381.30542" + id="tspan7159" + sodipodi:role="line">TWL3025</tspan><tspan + y="114.08837" + x="381.30542" + sodipodi:role="line" + id="tspan3038">ABB</tspan></text> + <text + sodipodi:linespacing="100%" + id="text12244" + y="216.1601" + x="394.66666" + style="font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans;-inkscape-font-specification:Bitstream Vera Sans" + xml:space="preserve"><tspan + y="216.1601" + x="394.66666" + id="tspan12246" + sodipodi:role="line">BSP</tspan></text> + <text + sodipodi:linespacing="100%" + id="text12248" + y="252.99342" + x="395.16666" + style="font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans;-inkscape-font-specification:Bitstream Vera Sans" + xml:space="preserve"><tspan + y="252.99342" + x="395.16666" + id="tspan12250" + sodipodi:role="line">USP</tspan></text> + <text + sodipodi:linespacing="100%" + id="text12252" + y="286.42783" + x="396.16666" + style="font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans;-inkscape-font-specification:Bitstream Vera Sans" + xml:space="preserve"><tspan + y="286.42783" + x="396.16666" + id="tspan12254" + sodipodi:role="line">TSP</tspan></text> + <text + sodipodi:linespacing="100%" + id="text20330" + y="163.44881" + x="464.62991" + style="font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans;-inkscape-font-specification:Bitstream Vera Sans" + xml:space="preserve"><tspan + y="163.44881" + x="464.62991" + id="tspan20332" + sodipodi:role="line">BUL</tspan></text> + <text + sodipodi:linespacing="100%" + id="text20334" + y="146.96971" + x="463.70053" + style="font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans;-inkscape-font-specification:Bitstream Vera Sans" + xml:space="preserve"><tspan + y="146.96971" + x="463.70053" + id="tspan20336" + sodipodi:role="line">BDL</tspan></text> + </g> + <g + id="g13450" + transform="translate(-35.433051,2.2643947e-6)"> + <rect + y="177.16687" + x="885.82831" + height="88.888702" + width="106.29617" + id="rect12310" + style="fill:#ffffff;stroke:#000000;stroke-width:1.77468574;stroke-miterlimit:4;stroke-dasharray:none" /> + <text + sodipodi:linespacing="100%" + id="text13440" + y="230.31496" + x="903.54333" + style="font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans;-inkscape-font-specification:Bitstream Vera Sans" + xml:space="preserve"><tspan + y="230.31496" + x="903.54333" + id="tspan13442" + sodipodi:role="line">Antenna</tspan><tspan + id="tspan13444" + y="242.31496" + x="903.54333" + sodipodi:role="line">Switch</tspan></text> + <text + sodipodi:linespacing="100%" + id="text13446" + y="194.88188" + x="887.82678" + style="font-size:20px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans;-inkscape-font-specification:Bitstream Vera Sans" + xml:space="preserve"><tspan + y="194.88188" + x="887.82678" + id="tspan13448" + sodipodi:role="line">ASM4532</tspan></text> + </g> + <rect + style="fill:#ffffff;stroke:#000000;stroke-width:1.61511528;stroke-miterlimit:4;stroke-dasharray:none" + id="rect11596" + width="142.16623" + height="88.074844" + x="850.31543" + y="35.354797" /> + <path + style="fill:none;stroke:#550000;stroke-width:2.83464575;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-end:url(#Arrow2Mend)" + d="m 460.62994,283.46456 354.33071,0 0,-177.16535 35.43307,0" + id="path21554" /> + <path + style="fill:#ff0000;fill-rule:evenodd;stroke:#ff0000;stroke-width:3.54330707;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-start:url(#Arrow2Mstart);marker-end:url(#Arrow2Mend)" + d="m 212.59845,212.59842 141.73228,0 0,0" + id="path7167" /> + <path + style="fill:none;stroke:#0000ff;stroke-width:3.54330707;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-end:url(#Arrow2Mend)" + d="m 212.59845,283.46456 141.73228,0" + id="path7171" /> + <path + style="fill:#ff0000;fill-rule:evenodd;stroke:#ff0000;stroke-width:3.54330707;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-start:url(#Arrow2Mstart);marker-end:url(#Arrow2Mend)" + d="m 212.59844,248.03149 141.73229,0 0,0" + id="path9925" /> + <g + id="g12217" + transform="translate(-35.433051,2.2643947e-6)"> + <rect + y="35.433064" + x="637.79529" + height="212.59842" + width="141.73228" + id="rect2408" + style="fill:#ffffff;stroke:#000000;stroke-width:1.77165353;stroke-miterlimit:4;stroke-dasharray:none" /> + <text + sodipodi:linespacing="125%" + id="text7153" + y="53.149601" + x="637.79529" + style="font-size:20px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans;-inkscape-font-specification:Bitstream Vera Sans" + xml:space="preserve"><tspan + id="tspan11602" + y="53.149601" + x="637.79529" + sodipodi:role="line">TRF6151</tspan></text> + <text + sodipodi:linespacing="100%" + id="text12175" + y="88.582672" + x="655.51184" + style="font-size:16px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans;-inkscape-font-specification:Bitstream Vera Sans" + xml:space="preserve"><tspan + y="88.582672" + x="655.51184" + id="tspan12177" + sodipodi:role="line">Transceiver</tspan><tspan + id="tspan12179" + y="104.58267" + x="655.51184" + sodipodi:role="line">Mixers</tspan><tspan + id="tspan12183" + y="120.58267" + x="655.51184" + sodipodi:role="line">VCO</tspan><tspan + id="tspan12181" + y="136.58267" + x="655.51184" + sodipodi:role="line">PLL</tspan></text> + </g> + <text + xml:space="preserve" + style="font-size:20px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans;-inkscape-font-specification:Bitstream Vera Sans" + x="850.39374" + y="53.149605" + id="text11598" + sodipodi:linespacing="100%"><tspan + sodipodi:role="line" + id="tspan11600" + x="850.39374" + y="53.149605">RF3166</tspan></text> + <text + xml:space="preserve" + style="font-size:16px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans;-inkscape-font-specification:Bitstream Vera Sans" + x="868.11029" + y="88.582672" + id="text12185" + sodipodi:linespacing="100%"><tspan + sodipodi:role="line" + x="868.11029" + y="88.582672" + id="tspan12193">RF PA</tspan></text> + <text + xml:space="preserve" + style="font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans;-inkscape-font-specification:Bitstream Vera Sans" + x="183.16537" + y="287.46457" + id="text12256" + sodipodi:linespacing="100%"><tspan + sodipodi:role="line" + id="tspan12258" + x="183.16537" + y="287.46457">TSP</tspan></text> + <g + id="g12268" + transform="translate(-35.433051,2.2643947e-6)"> + <path + id="path11606" + d="m 779.52756,53.149601 106.29921,0 0,0" + style="fill:none;stroke:#ff00ff;stroke-width:2.83464575;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-end:url(#Arrow2Mend)" /> + <text + sodipodi:linespacing="100%" + id="text12260" + y="51.149601" + x="814.96063" + style="font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans;-inkscape-font-specification:Bitstream Vera Sans" + xml:space="preserve"><tspan + y="51.149601" + x="814.96063" + id="tspan12262" + sodipodi:role="line">GSM</tspan></text> + </g> + <g + id="g12273" + transform="translate(-35.433051,2.2643947e-6)"> + <path + id="path12195" + d="m 779.52756,70.866136 106.29921,0 0,0" + style="fill:none;stroke:#ff00ff;stroke-width:2.83464575;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-end:url(#Arrow2Mend)" /> + <text + sodipodi:linespacing="100%" + id="text12264" + y="68.866135" + x="814.96063" + style="font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans;-inkscape-font-specification:Bitstream Vera Sans" + xml:space="preserve"><tspan + y="68.866135" + x="814.96063" + id="tspan12266" + sodipodi:role="line">DCS/PCS</tspan></text> + </g> + <g + id="g12290" + transform="translate(-35.433051,2.2643947e-6)"> + <path + id="path12197" + d="m 885.82677,194.88188 -106.29921,0 0,0" + style="fill:none;stroke:#ff00ff;stroke-width:2.83464575;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-end:url(#Arrow2Mend)" /> + <text + sodipodi:linespacing="100%" + id="text12278" + y="192.88188" + x="814.96063" + style="font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans;-inkscape-font-specification:Bitstream Vera Sans" + xml:space="preserve"><tspan + y="192.88188" + x="814.96063" + id="tspan12280" + sodipodi:role="line">GSM</tspan></text> + </g> + <g + id="g12295" + transform="translate(-35.433051,2.2643947e-6)"> + <path + id="path12165" + d="m 885.82677,212.59841 -106.29921,0 0,0" + style="fill:none;stroke:#ff00ff;stroke-width:2.83464575;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-end:url(#Arrow2Mend)" /> + <text + sodipodi:linespacing="100%" + id="text12282" + y="210.59842" + x="814.96063" + style="font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans;-inkscape-font-specification:Bitstream Vera Sans" + xml:space="preserve"><tspan + y="210.59842" + x="814.96063" + id="tspan12284" + sodipodi:role="line">DCS</tspan></text> + </g> + <g + id="g12300" + transform="translate(-35.433051,2.2643947e-6)"> + <path + id="path12199" + d="m 885.82677,230.31495 -106.29921,0 0,0" + style="fill:none;stroke:#ff00ff;stroke-width:2.83464575;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-end:url(#Arrow2Mend)" /> + <text + sodipodi:linespacing="100%" + id="text12286" + y="228.31496" + x="814.96063" + style="font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans;-inkscape-font-specification:Bitstream Vera Sans" + xml:space="preserve"><tspan + y="228.31496" + x="814.96063" + id="tspan12288" + sodipodi:role="line">PCS</tspan></text> + </g> + <g + id="g18005" + transform="translate(-35.433051,2.2643947e-6)"> + <text + sodipodi:linespacing="100%" + id="text14594" + y="49.149601" + x="425.21259" + style="font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans;-inkscape-font-specification:Bitstream Vera Sans" + xml:space="preserve"><tspan + id="tspan14598" + y="49.149601" + x="425.21259" + sodipodi:role="line">RFCLK</tspan></text> + <path + id="path14605" + d="m 637.79528,53.149601 -389.76378,0 0,0" + style="fill:none;stroke:#ffff00;stroke-width:2.83464575;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-end:url(#Arrow2Mend)" /> + </g> + <g + id="g18583" + transform="translate(-35.433051,2.2643947e-6)"> + <path + inkscape:label="#path2410" + id="path241011111" + d="m 496.06299,141.73228 141.73229,0 0,0 0,0" + style="fill:#00ff00;fill-rule:evenodd;stroke:#00ff00;stroke-width:2.83464575;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-start:url(#Arrow2Mstart);marker-end:url(#Arrow2Mend)" /> + <text + sodipodi:linespacing="100%" + id="text12167" + y="137.73228" + x="539.21259" + style="font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans;-inkscape-font-specification:Bitstream Vera Sans" + xml:space="preserve"><tspan + y="137.73228" + x="539.21259" + id="tspan12169" + sodipodi:role="line">I/Q Analog</tspan></text> + <path + id="path15170" + d="m 531.49606,141.73228 0,17.71653 -35.43307,0 0,0" + style="fill:none;stroke:#00ff00;stroke-width:2.83464575;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-start:url(#Arrow2Mstart)" /> + </g> + <g + id="g18000" + transform="translate(-35.433051,2.2643947e-6)"> + <path + id="path17431" + d="m 248.0315,88.582671 141.73228,0" + style="fill:none;stroke:#ffff00;stroke-width:2.83464575;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-end:url(#Arrow2Mend)" /> + <text + sodipodi:linespacing="100%" + id="text17996" + y="84.582672" + x="295.18109" + style="font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans;-inkscape-font-specification:Bitstream Vera Sans" + xml:space="preserve"><tspan + y="84.582672" + x="295.18109" + id="tspan17998" + sodipodi:role="line">CLK13M</tspan></text> + </g> + <g + id="g18593" + transform="translate(-35.433051,2.2643947e-6)"> + <path + id="path18010" + d="m 496.06299,194.88188 141.73229,0" + style="fill:none;stroke:#550000;stroke-width:2.83464575;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-end:url(#Arrow2Mend)" /> + <text + sodipodi:linespacing="100%" + id="text18589" + y="188.88188" + x="537.49603" + style="font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans;-inkscape-font-specification:Bitstream Vera Sans" + xml:space="preserve"><tspan + y="188.88188" + x="537.49603" + id="tspan18591" + sodipodi:role="line">AFC Analog</tspan></text> + </g> + <path + style="fill:none;stroke:#0000ff;stroke-width:2.83464575;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-end:url(#Arrow2Mend)" + d="m 177.16538,301.1811 0,70.86614 708.66141,0 0,-106.29921" + id="path19726" /> + <text + xml:space="preserve" + style="font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans;-inkscape-font-specification:Bitstream Vera Sans" + x="318.89767" + y="368.04724" + id="text20291" + sodipodi:linespacing="100%"><tspan + sodipodi:role="line" + id="tspan20293" + x="318.89767" + y="368.04724">TSP Parallel</tspan></text> + <text + xml:space="preserve" + style="font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans;-inkscape-font-specification:Bitstream Vera Sans" + x="320.89767" + y="330.89764" + id="text20295" + sodipodi:linespacing="100%"><tspan + sodipodi:role="line" + id="tspan20297" + x="320.89767" + y="330.89764">TSP Serial</tspan></text> + <g + id="g20314" + transform="translate(-35.433052,-17.716531)"> + <path + id="path20301" + d="m 248.0315,124.01574 141.73228,0" + style="fill:none;stroke:#ffff00;stroke-width:2.83464575;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-end:url(#Arrow2Mend)" /> + <text + sodipodi:linespacing="100%" + id="text20303" + y="120.01574" + x="295.18109" + style="font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans;-inkscape-font-specification:Bitstream Vera Sans" + xml:space="preserve"><tspan + id="tspan20310" + y="120.01574" + x="295.18109" + sodipodi:role="line">CLK32K</tspan></text> + </g> + <g + id="g20421" + transform="translate(-35.433051,2.2643947e-6)"> + <path + id="path12871" + d="m 956.69291,124.01574 0,53.14961" + style="fill:none;stroke:#ff00ff;stroke-width:2.83464575;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-end:url(#Arrow2Mend)" /> + <text + transform="matrix(0,-1,1,0,0,0)" + sodipodi:linespacing="100%" + id="text20402" + y="952.69293" + x="-159.44881" + style="font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans;-inkscape-font-specification:Bitstream Vera Sans" + xml:space="preserve"><tspan + y="952.69293" + x="-159.44881" + id="tspan20404" + sodipodi:role="line">GSM</tspan></text> + </g> + <g + id="g20415" + transform="translate(-35.433051,2.2643947e-6)"> + <g + id="g20410"> + <path + style="fill:none;stroke:#ff00ff;stroke-width:2.83464575;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-end:url(#Arrow2Mend)" + d="m 921.25984,124.01574 0,53.14961" + id="path12312" /> + <text + xml:space="preserve" + style="font-size:11.36807537px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans;-inkscape-font-specification:Bitstream Vera Sans" + x="-184.69075" + y="867.06183" + id="text20406" + sodipodi:linespacing="100%" + transform="matrix(0,-0.9473396,1.0555877,0,0,0)"><tspan + sodipodi:role="line" + id="tspan20408" + x="-184.69075" + y="867.06183">DCS/PCS</tspan></text> + </g> + </g> + <path + style="fill:none;stroke:#0000ff;stroke-width:2.83464575;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-start:url(#DotM);marker-end:url(#Arrow2Mend)" + d="m 885.82679,372.04724 88.58266,0 0,-248.0315 0,0" + id="path20426" /> + <text + xml:space="preserve" + style="font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans;-inkscape-font-specification:Bitstream Vera Sans" + x="503.77954" + y="279.46457" + id="text22119" + sodipodi:linespacing="100%"><tspan + sodipodi:role="line" + id="tspan22121" + x="503.77954" + y="279.46457">APC Analog</tspan></text> + <path + style="fill:none;stroke:#0000ff;stroke-width:2.83464575;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-start:url(#DotM);marker-end:url(#Arrow2Mend)" + d="m 283.46459,283.46456 0,53.14961 354.33071,0 0,-88.58268" + id="path18598" /> + <text + xml:space="preserve" + style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans" + x="258.43008" + y="206.35927" + id="text3040"><tspan + sodipodi:role="line" + id="tspan3042" + x="258.43008" + y="206.35927">I/Q Digital</tspan></text> + <text + xml:space="preserve" + style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans" + x="259.96451" + y="237.68361" + id="text3044"><tspan + sodipodi:role="line" + id="tspan3046" + x="259.96451" + y="237.68361">SPI</tspan></text> + </g> +</svg> diff --git a/2010/gsm_phone-anatomy/gsm_phone-anatomy-v0.1.pdf b/2010/gsm_phone-anatomy/gsm_phone-anatomy-v0.1.pdf Binary files differnew file mode 100644 index 0000000..b91c574 --- /dev/null +++ b/2010/gsm_phone-anatomy/gsm_phone-anatomy-v0.1.pdf diff --git a/2010/gsm_phone-anatomy/gsm_phone-anatomy-v0.2.pdf b/2010/gsm_phone-anatomy/gsm_phone-anatomy-v0.2.pdf Binary files differnew file mode 100644 index 0000000..d90ca5a --- /dev/null +++ b/2010/gsm_phone-anatomy/gsm_phone-anatomy-v0.2.pdf diff --git a/2010/gsm_phone-anatomy/gsm_phone-anatomy-v0.2.tex b/2010/gsm_phone-anatomy/gsm_phone-anatomy-v0.2.tex new file mode 100644 index 0000000..72e707c --- /dev/null +++ b/2010/gsm_phone-anatomy/gsm_phone-anatomy-v0.2.tex @@ -0,0 +1,674 @@ +\documentclass[a4paper]{article} +\usepackage[english]{babel} +\usepackage{graphicx} +\usepackage{subfigure} +\pagestyle{plain} + +%\usepackage{url} + +\setlength{\oddsidemargin}{0in} +\setlength{\evensidemargin}{0in} +\setlength{\topmargin}{0in} +\setlength{\headheight}{0in} +\setlength{\headsep}{0in} +\setlength{\textwidth}{6.5in} +\setlength{\textheight}{9.5in} +%\setlength{\parindent}{0in} +\setlength{\parskip}{0.05in} + +\begin{document} + +\title{Anatomy of contemporary GSM cellphone hardware} +\author{Harald Welte $<$laforge@gnumonks.org$>$} +\maketitle + +\begin{abstract} +%% add citation for the nubmer of gsm users and phones / carriers. +Billions of cell phones are being used every day by an almost equally large +number of users. The majority of those phones are built according to +the GSM protocol and interoperate with GSM networks of hundreds of +carriers. + +Despite being an openly published international standard, the architecture of +the GSM network and its associated protocols are only known to a relatively +small group of R\&D engineers. + +Even less public information exists about the hardware architecture of the +actual mobile phones themselves, at least as far as it relates to that part +of the phone implementing the GSM protocols and facilitating access to the +public GSM networks. + +This paper is an attempt to serve as an introductory text into the hardware +architecture of contemporary GSM mobile phone hardware anatomy. It is intended +to widen the technical background on mobile phones within the IT community. +\end{abstract} + +%\tableofcontents + +\section{Foreword} + +This document is the result of my personal research on mobile phone +hardware and system-level software throughout the last 6+ years. + +Despite my past work for Openmoko Inc., I have never been professionally +involved in any aspect of the actual GSM related hardware of any phone. +Nevertheless I have the feeling that in the wider information technology +industry, I am part of a very, very small group of people who actually +understand mobile phones down to the lowest layer. + +I hope it is useful for any systems level engineer with an interest in +understanding more about how mobile phone hardware actually works. + +There are no guarantees for accuracy or correctness of any part of the +document. I happily receive your feedback and corrections. + +\section{Is your phone smart or does it have features?} + +Initially, for the first couple of years, GSM cell phones were actual phones +with very little additional functionality. They provided everything that was +required for voice calls, as well as SIM phone book editing features. The only +additional non-features were simple improvements like the ability to use them +as an alarm clock. + +In the mid-1990s, a certain new type of devices became popular: The PDA +(personal digital assistant). They pioneered handheld computing by introducing +touch screen user interfaces and a wide range of application programs, ranging +from calendar/scheduling applications, dictionaries, exchange rate and tip +calculators, scientific calculators, accounting / finance software, etc. + +While in mobile phones the actual cellphone aspect was becoming more and more +commoditized, at some point the PDA features and functionalities were added to +phones, coining the term {\em smartphone}. At that point there was a +need to differentiate from those phones that were not-so-smart. Those +phones were then called {\em feature phones}. + +There has never been an industry-wide accepted definition of those terms, +and especially in the late 2000s, feature phones started to inherit a lot +of the functionality that was formerly only present in smartphones. + +This document will define the terms (only for the purpose of this document) +along a very clear border in hardware architecture, as will be described in the +following sections: + +\subsection{Feature Phone} + +A feature phone is a phone that runs the GSM protocol stack (the software +implementing the GSM protocol) as well as the user interface and all +applications on a single processor. For historic reasons, this +processor is known as the so-called {\em baseband processor} (BP). + +The baseband processor often exposes a serial port (or today USB) over which +the phone can be used as a terminal adapter, similar to old wireline modems. +The industry standard protocol for this interface is an AT command set - +extended and modified from how computers interfaced old wireline modems. +The AT-command interface can be connected to a computer. The computer can then +use the phone to establish data calls, send/receive short messages via SMS, +and generally remote-control the phone. + +\subsection{Smartphone} + +A smartphone is a phone that has a dedicated processor for the GSM protocol +stack, and another (potentially multi-core) general purpose processor for +the user interface and applications. This processor is known as the +{\em application processor} (AP). + +The first hardware generations of smartphones did nothing else but to put the +feature phone and a PDA into one case. The keypad and display of the baseband +processor is removed. What remains of the feature phone is a {\em GSM modem}, +controlled by AT commands sent from the AP. + +Each processor has its own memory (RAM and Flash), peripherals, clocking, etc. +So this setup is not to be confused with the symmetric multi-processor setups +like seen in the personal computer industry. + +Later generations of smartphones have exchanged the AT command interface by +various proprietary protocols. Also, the serial line was replaced by a +higher-bandwidth hardware connection such as USB, SPI or a shared memory +interface. + +Due to market pressure for ever smaller phones with ever more functions, +the industry has produced highly integrated products, uniting the AP and BP +inside one physical package. Further pressure on reducing cost and PCB +footprint has led to products where there is no need to have independent +RAM and Flash chips for AP and BP. Rather, a single RAM and Flash chip +is divided by assigning portions of the RAM and Flash to each of the two +processors. + +However, the fundamental separation between the AP and BP, each with their own +memory address space and software, remains present in all smartphones until +today. + +\section{GSM modem architecture} + +Every GSM phone, feature phone and smartphone alike, has a GSM modem interfacing +with the GSM network. + +This GSM modem consists of several parts: +\begin{itemize} +\item RF Frontend, responsible for receiving and transmitting at GSM frequency +\item Analog Baseband, responsible for modulation and demodulation +\item Digital Baseband, responsible for digital signal processing and the GSM protocol stack +\end{itemize} + +\begin{figure}[h] +\centering +\includegraphics[width=160mm]{calypso-block.pdf} +\caption{Block schematics of a TI Calypso/Iota/Rita GSM modem} +\label{reg-form} +\end{figure} + +\subsection{The RF Frontend} + +The RF Frontend is tasked with the physical receive and transmit +interface with the GSM air interface (sometimes called Um interface). + +It minimally consists of an antenna switch, GSM band filters, low-noise +amplifier (LNA) for the receive path, power amplifier for the transmit +path, a local oscillator (LO) and a mixer. + +By mixing the LO frequency with the received RF signal, it generates an +analog baseband signal that is passed to the Analog Baseband (ABB) part +of the modem. By mixing the output of the ABB with the LO frequency, it +generates a RF signal that is to be transmitted in the GSM frequency +band. + +As the receive and transmit framing has an offset of 3 TDMA frames, +there is no need for a frequency duplexer. Instead, an antenna switch +is used. The switch typically is implemented using a MEMS or diode +switch. For a quad-band phone, typically a single-pole 6-throw (SP6T) +switch is used: 4 for the four Rx bands (one for each band), and 2 for +Tx (where 850+900 and 1800+1900 each share one PA output, respectively). + +\subsubsection{RF Frontend receive path} + +The antenna picks up the GSM radio signal as it is sent from a GSM cell +(called Base Transceiver Station, BTS). The antenna signal first hits +the antenna switch, which connects the antenna with the Rx path for the +GSM band of the to-be-received radio frequency. It is then filtered by +a bandpass to block out-of-band signals before entering a low-noise +amplifier for increasing signal amplitude. + +After passing the LNA, the RF signal is mixed with a frequency generated +by the LO. Depending on the LO signal, either an intermediate frequency +(IF) or a direct baseband signal is produced. In modern GSM modems, +zero-IF designs with immediate down-conversion to analog baseband +signals are most common. + +The baseband signal is then filtered to remove unwanted images and sent +as analog I/Q signals (representing amplitude and phase) to the ABB. + +\subsubsection{RF Frontend transmit path} + +The ABB generates analog I/Q signals, which are filtered and passed +into the mixer, where they are mixed with the LO frequency and thus +up-converted to the GSM RF band. From there, they are sent to the +transmit amplifier (RF PA) for amplification. After amplification, they +traverse the antenna switch and are transmitted by the antenna. + +\subsubsection{Local Oscillator} + +The LO of a GSM modem has to be synchronized very closely to that of the +cell (BTS). To achieve the required precision, a Voltage-Controlled, +Temperature-Compensated Crystal Oscillator (VCTCXO) is used. + +Common frequencies for this VCTCXO are 26MHz or 13MHz, as the GSM bit +clock (270,833 Hz) is an integral division (/96 or /48, respectively) of +those frequencies. The tuning range of the VCTCXO is several kHz to +compensate for temperature drift. + +\subsection{The Analog Baseband (ABB)} + +The ABB part of a GSM modem is responsible to interface between the +digital domain and the analog domain of the GSM modem. + +\subsubsection{ABB Receive path} + +The analog baseband I/Q signals are potentially filtered again and +digitized by and Analog-Digital converter (ADC). The sample clocks used +are typically integral multiples of the GSM bit-clock. The sample clock +itself is derived by dividing the VCTCXO of the RF frontend. + +The digital I/Q samples are passed to the Digital Signal Processor +(DSP) in the Digital Baseband (DBB). To reduce the number of traces to +be routed on the PCB, the samples are typically sent over some kind of +synchronous serial link. + +\subsubsection{ABB Transmit path} + +There are multiple architectures found in the ABB transmit path. + +The obvious architecture is to do the inverse of the receive operation: +Transmit digital I/Q samples from the DSP to the ABB and convert +them into an analog signal that is then to be sent to the mixer of the +RF Frontend. + +However, sending a GSM signal with its GMSK modulation is much simpler +than receiving. So in order to reduce computational complexity (and +thus cost as well as power consumption) inside the DSP, the modulation +of the bits is often performed in hardware inside the ABB. + +In this design, the unmodulated GSM burst bits are sent from the DBB to +a burst buffer inside the ABB. From there, based on ROM tables and a +Digital-to-Analog converter (DAC), an analog GMSK modulated signal is +generated. + +\subsection{The Digital Baseband (DBB)} + +The digital baseband implements the actual GSM protocols from Layer1 up +to Layer3 as well as higher layers such as a user interface in the case +of the feature phone. In a smartphone, the DBB only implements a +machine interface to be used by the AP. + +A typical DBB design includes a Digital Signal Processor (DSP) for the +lower half of Layer1, and a general-purpose processor (MCU) for the +upper part of Layer1, as well as anything above. + +\subsubsection{Digital Signal Processor} + +The choice of DSP architecture largely depends on the DBB chipset +vendor. Often they already have a line of DSP cores in-house and will of +course want to reuse that in their DBB chip designs. Every major DSP +architecture can be found (TI, Analog Devices, ...). + +The DSP performs the primary tasks such as Viterbi equalization, +demodulation, decoding, forward error correction, error detection, burst +(de)interleaving. + +Of course, if actual speech data is to be communicated over the GSM +network, the DSP will also have the auxiliary task to perform the +computation of the lossy speech codec used to compress the speech. + +Communication between the DSP and MCU happens most commonly by a shared +memory interface. The shared memory contains both actual data that is +to be processed, as well as control information and parameters +describing what to be done with the respective data. + +For the receive side, the MCU will instruct the DSP to perform decoding +for a particular GSM burst type, after which the DSP will receive I/Q +samples from the ABB, perform detection/demodulation/decoding and +report the result of the operation (including any decoded data) back to +the MCU. + +For the transmit path, the MCU will present the to-be-transmitted data +and auxiliary information to the DSP, which then takes care of encoding +and sends the corresponding burst bits to the ABB (remember, most ABB +take care of the modulation to reduce DSP load). + +The detailed programming information (API) of the DSP shared memory +interface is a closely-guarded secret of the baseband chip maker and is +not commonly disclosed even to their customers (the actual phone making +companies). + +In doing so, the baseband chip makers create a close dependency between +the GSM Layer1 software (running on the MCU) driving/implementing this +API and the actual baseband chip. Whoever buys their chip will also +have to license their GSM protocol stack software. + +It is thus almost impossible for an independent software vendor to get +access to the DSP API documentation, which the author of this paper +finds extremely anti-competitive. + +\subsubsection{DSP Peripherals} + +The specifications of the GSM proprietary On-air encryption A5/1 and +A5/2 are only made available to GSM baseband chip makers who declare +their confidentiality. Implementing the algorithm in software is +apparently considered as breach of that confidentiality. Thus, the +encryption algorithms are only implemented in hardware - despite them +being reverse-engineered and publicly disclosed by cryptographers as +early as 1996. %% cite + +Thus, the DSP in a DBB commonly has a integrated peripheral implementing the A5 +encryption. + +Further integrated DSP peripherals may include a viterbi hardware accelerator, +a DMA capable serial interface to the ABB and others. + +\subsection{Baseband Processor (MCU)} + +The MCU of almost all modern GSM DBBs is a System-on-a-Chip (SoC) utilizing a +32bit ARM7TDMI core. The only notable exception are low-cost Infineon chips +like PM7870, who still use a version of their 16bit C166 core. + +Baseband chips that support 3G cellular networks often use a more powerful +ARM926 or ARM975 core as MCU. + +\subsection{MCU peripherals} + +The MCU cores have the typical set of peripherals of any ARM7 based +microcontroller, such as RTC, UARTs for RS232 and IRDA, SPI, I2C, SD/MMC card +controller, keypad scan controller, USB device, ... + +However, there are some additional peripherals that are very GSM specific: +\begin{itemize} +\item A GPRS crypto unit for the proprietary GEA family of ciphers +\item Extended power management facilities, including a timer that can calibrate the RTC clock based on the synchronized VCTCXO in order to wake-up the MCU ahead of pre-programmed events in the GSM time multiplex +\item GSM TDMA timers that can synchronize to the on-air time frames and generate interrupts to MCU and DSP +\item Software-programmable hardware state machines for sequencing GSM burst Rx or Tx in ABB and RF Frontend +\item An ISO7816 compatible smart card reader interface for the SIM card +\end{itemize} + +The programming of those peripherals is highly device-specific and there are no +industry standards. Every DBB architecture of every supplier has its own +custom register set and programming interface. + +The register-level documentation for those proprietary peripherals is (like all +documentation on DBB chipsets) closely guarded by NDAs, effectively preventing +the development of Free Software / Open Source drivers for them, unless such +documents are leaked by third parties. + +However, as opposed to the DSP API documentation, the register-level +documentation to the MCU peripherals is normally provided to the cellphone +manufacturers. + +\section{Digital Baseband Software Architecture} + +This section provides an introductory reading in the typical software +architecture as it is found on contemporary GSM digital baseband designs. + +\subsection{GSM Layer 1} + +The Layer1 (L1) software is highly device-specific, as it closely interacts +with the DSP using the shared memory DSP API, as well as the proprietary +integrated peripherals controlling the ABB and RF Frontend. + +However, there are some general observations that can be made about the L1: + +\subsubsection{L1 Synchronous part} + +The synchronous part is executed synchronously to the GSM TDMA frame clock. +Both CPU and DSP are interrupted by some hardware GSM timer every TDMA frame. + +The L1 synchronous part typically runs inside IRQ or FIQ context of the MCU, +taking care of retrieving data from and providing data to the DSP API. + +\subsubsection{L1 Asynchronous part} + +The asynchronous part is scheduled as a normal task, potentially with high +or even real-time priority. It picks up the information provided by the L1 +Sync and schedules its next actions. + +The L1 async typically communicates via a message queue with the Layer2 +above. Common primitives for L1 control are described (as non-normative parts) +of the GSM specifications. + +\subsection{GSM Layer 2} + +As opposed to L1, the GSM Layer 2 (L2) is already fully hardware independent. +It implements the LAPDm protocol as specified in GSM TS 04.06. LAPDm is a +derivative of the ISDN Layer 2 called LAPD, which in turn is a descendent +of the HDLC family of protocols. + +LAPDm takes care of providing communication channels for Layer3. Those +channels are protected from frame loss by the use of sequence numbers and +retransmissions. + +The interface to Layer3 is typically implemented by means of a message queue. + +Primitives (but no detailed protocol) for use of the Layer2 / Layer3 interface +are provided in the GSM specifications. + +\subsection{GSM Layer 3} + +GSM Layer 3 (L3) consist of sublayers for Radio Resource (RR), Mobility +Management (MM) and Call Control (CC). + +There is sufficient treatment of the GSM L3 and its sublayers in +existing texts, so there is no point in making a futile attempt +repeating that here. + +\section{Synchronization and Clocking} + +The author of this paper has been quoted saying {\em GSM is a synchronous +TDMA nightmare}. This is by no means intended as an insult to the +technology itself or to its inventors. It merely serves as evidence how +hard it is to get into the synchronous TDMA mindset, especially for +engineers who have spent most of their career in the world of packet +switched networks. + +GSM is synchronous in multiple ways between cell (BTS) and phone (MS): +\begin{itemize} +\item Synchronization of the carrier clock to tune the receiver and transmitter to the correct frequency +\item Synchronization of the bit clock in order to perform sampling at the most optimal sample intervals +\item Synchronization of the frame clock (and thus timeslots) to know when a TDMA frame and its 8 timeslots start +\item Synchronization of the TDMA multiplex to correctly (de)multiplex the logical channels that are sent over each timeslots +\end{itemize} + +As all those clocks are related to each other, they can (and should) all be +derived from the same master clock: The VCTCXO in our phone. + +\subsection{How to synchronize the VCTCXO} + +Every cell sends frequency correction bursts as part of the Frequency +Correction CHannel (FCCH), which is itself part of the BCCH, which in turn is +constantly transmitted by the BTS. + +To acquire initial synchronization ot the GSM network, the LO is tuned to the +desired GSM RF channel (ARFCN) frequency. However, at this point, the LO +frequency is a multiple of the VCTCXO frequency which in turn still has an +undetermined error. This initial frequency error is as large as that of a +regular crystal oscillator, potentially already with temperature compensation. + +The resulting baseband signal thus can be shifted by a fairly large amount in +our baseband spectrum. A specific DSP code is now using correlation and other +techniques to identify the frequency correction burst. The DSP can then +further calculate the actual frequency error of the LO by comparing the +received FCCH burst with the FCCH burst as specified. + +This computed frequency error can be fed into a (software) frequency control +loop filter. The loop filter output is applied to an auxiliary DAC, which +generates the control voltage for the VCTCXO. + +After a number of FCCH bursts and corresponding frequency control loop +iterations, the VCTCXO generated clock has only a residual error. Whenever the +phone is receiving, the frequency control loop is continuously exercised in +order to maintain synchronization. + +\subsection{How to synchronize the frame clock} + +When the DSP performs FCCH burst detection as described above, it identifies +the exact position in the incoming sample stream when the FCCH burst was +happening. By knowing from the specification that the FCCH burst is +part of the BCCH, and that the BCCH is sent on timeslot 0, the Layer1 +software can then synchronize the phone to the TDMA frame start. + +Commonly, a hardware timer unit is clocked by a (divided) VCTCXO clock and thus +counts in multiples of the GSM bit clock, wrapping/resetting at the TDMA duration +of 1250 bits. + +By scheduling events synchronously to this GSM bit-clock timer, the L1 can now +trigger events (such as asking the DSP to demodulate incoming data) or +instructing the LO to retune synchronously to every TDMA frame. +From this timer the DBB typically also generates interrupts to the DSP and MCU. + +\subsection{How to synchronize the GSM TDMA multiplex} + +As part of the BCCH, the BTS not only sends the FCCH but also the +Synchronization CHannel (SCH). The Synchronization channel indicates the +current GSM time / frame number (skipping the 3 least significant bits). +By using this received GSM time and incrementing it every time the GSM bit-clock +timer wraps at the beginning of a new TDMA frame, the GSM time is synchronized. + +Understanding the multiple layers of time multiplex such as the 26/51 +multiframe, superframe and hyperframe, the L1 can multiplex and demultiplex all +the logical channels of GSM. + +\section{Miscellaneous Topics} +\subsection{GPRS} + +GPRS was the first packet switched extension to GSM. In fact, it is much more +its entirely own mobile network, independent of GSM. The only parts shared are +the GSM modulation scheme (GMSK) and time multiplex, in order to ensure peaceful +coexistence between them. + +The L1 and L2 protocols are very different (and much more complex) than GSM. + +So while the phone baseband hardware did not need any modifications for a basic +GPRS enabled phone, the software needed to be extended quite a lot. + +\subsection{EDGE} + +EDGE is a very small incremental step to GPRS. It reuses all of the time +multiplex and protocol stack, but introduces a new modulation: Offset +8-PSK instead of GMSK to increase the bandwidth that can be transmitted. +Offset 8-PSK is used (as opposed to simple 8-PSK) to avoid +zero-crossings in the modulator output. + +So while the software modifications from GPRS to EDGE are minimal, the 8PSK +modulation scheme has a significant impact on the DSP, ABB and even RF +PA design. + +\subsection{UMTS} + +UMTS (sometimes called WCDMA) is an entirely separate cellular network +technology. Its physical layer, modulation schemes, encoding, frequency +bands, channel spacing are entirely different, as is the Layer1. + +UMTS Layer2 has some resemblance to the GPRS Layer2. + +UMTS Layer3 for Mobility Management and Call Control are very similar to GSM. + +Given the vast physical layer and L1 differences, a UMTS phone hardware design +significantly differs from what has been described in this document. + +Notwithstanding, all known commercial UMTS phone chipsets as of today still +include a full GSM modem in hardware and software to remain +backwards-compatible. + +\subsection{Dual-SIM and Triple-SIM phones} + +In recent years, a large number of so-called {\em Dual-SIM} or even {\em +Triple-SIM} phones have entered the market, particularly in China and other +parts of East Asia. + +Those phones come in various flavours. Some of them simply have a multiplexer +that allows electrical switching between multiple SIM card slots. This is +similar to replacing the SIM card in a phone, just without the manual process +of mechanically removing/inserting the card. As a result, you can only use one +of the two SIMs at any time. + +The more sophisticated Dual-SIM phones have two complete phones in one case. Yes, +that's right! They contain two full GSM phone chipsets, i.e. 2 antennas, 2 rf +frontends, 2 analog basebands, 2 digital basebands, ... + +However, they use the same trick as smartphones: One of the two basebands does +not have keypad or display and is simply a GSM modem connected via serial line +to the other baseband processor. + +So if a smartphone (as defined in this document) is a GSM modem connected to a +PDA in one case, a Dual-SIM phone is a GSM modem connected to a feature phone +in one case. + +Triple-SIM phones often combine the two approaches, i.e. they contain two +complete GSM baseband chips, but three SIM slots that can be switched among +the base bands. Only two SIMs can be active at the same time. + +\subsection{Powerful feature phones} + +Feature phones are becoming more and more powerful. However, their +comparatively lower market price cannot afford a full-blown smartphone design +with its two independent processors and the associated design complexity. + +Thus, more and more hardware peripherals are added to the only processor left +in the phone: The baseband processor. Such peripherals include sophisticated +camera interfaces, high-resolution color display controllers, TV output, +touchscreen controllers, audio and video codecs and even interfaces for mobile +TV reception. + +However, all of those features are still implemented on a fairly weak ARM7 or +ARM9 CPU core (compared to ARM11 and Cortex-A8 in the smartphone market). They +also lack a real operating system and still run on top of a real-time +microkernel intended for much less complex systems. They almost always lack +any form of memory protection or multiple address spaces. This makes them +more prone to security issues as there is no privilege separation between +the GSM protocol stack and the applications, or between the applications +themselves. + +\section{Personal rant on the closedness of the GSM industry} + +The GSM industry is one of the most closed areas of computing that I've +encountered so far. It is very hard to get any hard technical +information out of them. All they like to spread is high-level +marketing information, but they're very reluctant when it comes down to +hard technical facts on their products. + +If you want to build a phone, you need to buy a GSM chipset for your +product. There are only very few companies that offer such chipsets. +The classic suppliers are Infineon, Texas Instruments, ST/Ericsson, ADI +(now MediaTek) and Freescale. + +The GSM handset products they sell are not generally available and +distributed like other electronic component they manufacture. If you +need a Microcontroller/SoC, a power management IC, a Wifi or Bluetooth +chip, RFID reader ASIC, you simply approach the respective distributors +and order them. You get your samples directly from Digikey. + +This is impossible for GSM (or other cellphone) chipsets. For some +reason those chips are sold only to hand-picked manufacturers. If you +want to qualify, you have to subscribe to at least six-digit annual +purchasing quantities. And in order for them to believe you, you have +to cough up a significant NRE (non-refundable engineering fee). This +has been reported as high as a seven-digit US\$ amount and is to make +sure that even if you end up buying less chips than you indicate, the +chipset maker will still have your upfront NRE money and keep it. + +And if you buy your way into that select club of cellphone makers, what +you get from the chipset maker is typically not all too impressive +either. The documentation you get is incomplete, i.e. it alone would +not enable you as a cellphone maker to make any use of the hardware, +unless you license the software (drivers, GSM protocol stack, ...) from +the chipset maker, too. + +On the software side, most of the technologically interesting bits (like +the protocol stack) are provided as binary-only libraries, you only get +source code to some parts of the systems, i.e. some hardware drivers +that might need modification for your particular phone electrical +design. + +That GSM protocol stack was not written by the chipset maker either. +They simply license a stack from one of the estimated 4 or 5 +organizations who have ever implemented a commercial GSM protocol stack. + +It is not like the GSM protocols were some kind of military secret. +They are a published international standard, freely accessible for +anyone. So why does everybody in that industry think that there is +a need to be so secretive? + +Having spent a significant part of the last 6 years with reverse +engineering of various aspects of mobile phones in order to understand +them better and do write software tools for security analysis, I still +don't understand this secrecy. + +All the various vendors do more or less the same. The fundamental +architecture of a GSM baseband chip is the same, whether you buy it from +TI, Infineon or from MediaTek. {\em They all cook with water}, like we +Germans tend to say. The details like the particular DSP vendor or +whether you use a traditional IF, zero-IF or low-IF analog baseband +differ. But from whom do they want to hide it? If people like myself +with a personal interest in the technical aspects of mobile phones can +figure it out in a relatively short time, then I'm sure the competiton +of those chipset makers can, too. In much less time, if they actually +care. + +This closedness of the cellular industry is one of the reasons why there +has been very little innovation in the baseband firmware throughout the +last decades. Innovation can only happen by very few players. Source +code bugs can only be found and fixed by very few developers at even +fewer large corporations. No chance for a small start-up to innovate, +like they can in the sphere of the internet. + +It is fundamentally also the reason why the traditional phone makers +have been losing market share to newcomers to the mobile sphere like +Apple with its iPhone or Google with its Android platform. + +Those innovations really only happened on the application processor on +high-end smartphones. The closed GSM baseband processor had to be +accompanied by an independent application processor running a real +operating system, with real processes, memory management, shared +libraries, memory protection, virtual memory spaces, user-installable +applications, etc. + +They still don't happen on the baseband processor, which is as closed as +it was 15 years ago. + +\end{document} diff --git a/2010/gsm_phone-anatomy/gsm_phone-anatomy-v0.3.pdf b/2010/gsm_phone-anatomy/gsm_phone-anatomy-v0.3.pdf Binary files differnew file mode 100644 index 0000000..e666c7a --- /dev/null +++ b/2010/gsm_phone-anatomy/gsm_phone-anatomy-v0.3.pdf diff --git a/2010/gsm_phone-anatomy/gsm_phone-anatomy-v0.3.tex b/2010/gsm_phone-anatomy/gsm_phone-anatomy-v0.3.tex new file mode 100644 index 0000000..fe1e73d --- /dev/null +++ b/2010/gsm_phone-anatomy/gsm_phone-anatomy-v0.3.tex @@ -0,0 +1,770 @@ +\documentclass[a4paper]{article} +\usepackage[english]{babel} +\usepackage{graphicx} +\usepackage{subfigure} +\pagestyle{plain} + +%\usepackage{url} + +\setlength{\oddsidemargin}{0in} +\setlength{\evensidemargin}{0in} +\setlength{\topmargin}{0in} +\setlength{\headheight}{0in} +\setlength{\headsep}{0in} +\setlength{\textwidth}{6.5in} +\setlength{\textheight}{9.5in} +%\setlength{\parindent}{0in} +\setlength{\parskip}{0.05in} + +\begin{document} + +\title{Anatomy of contemporary GSM cellphone hardware} +\author{Harald Welte $<$laforge@gnumonks.org$>$} +\maketitle + +\begin{abstract} +%% add citation for the nubmer of gsm users and phones / carriers. +Billions of cell phones are being used every day by an almost equally large +number of users. The majority of those phones are built according to +the GSM protocol specifications and interoperate with GSM networks of hundreds +of carriers. + +Despite being an openly published international standard, the architecture of +GSM networks and its associated protocols are only known to a relatively +small group of R\&D engineers. + +Even less public information exists about the hardware architecture of the +actual mobile phones themselves, at least as far as it relates to that part +of the phone implementing the GSM protocols and facilitating access to the +public GSM networks. + +This paper is an attempt to serve as an introductory text into the hardware +architecture of contemporary GSM mobile phone hardware anatomy. It is intended +to widen the technical background on mobile phones within the IT community. +\end{abstract} + +%\tableofcontents + +\section{Foreword} + +This document is the result of my personal research on mobile phone +hardware and system-level software throughout the last six years. + +Despite my past work for Openmoko Inc., I have never been professionally +involved in any aspect of the actual GSM related hardware of any phone. +Nevertheless I have the feeling that in the wider information technology +industry, I am part of a very, very small group of people who actually +understand mobile phones down to the lowest layer. + +I hope it is useful for any systems level engineer with an interest in +understanding more about how mobile phone hardware actually works. + +There are no guarantees for accuracy or correctness of any part of the +document. I happily receive your feedback and corrections. + +\section{Is your phone smart or does it have features?} + +Initially, for the first couple of years, GSM cell phones were actual phones +with very little additional functionality. They provided everything that was +required for voice calls, as well as SIM phone book editing features. The only +additional non-features were simple improvements like the ability to use them +as an alarm clock. + +In the mid-1990s, a certain new type of devices became popular: The PDA +(personal digital assistant). They pioneered handheld computing by introducing +touch screen user interfaces and a wide range of application programs, ranging +from calendar/scheduling applications, dictionaries, exchange rate and tip +calculators, scientific calculators, accounting / finance software, etc. + +While in mobile phones the actual cellphone aspect was becoming more and more +commoditized, at some point the PDA features and functionalities were added to +phones, coining the term {\em smartphone}. At that point there was a +need to differentiate from those phones that were not-so-smart. Those +phones were then called {\em feature phones}. + +There has never been an industry-wide accepted definition of those terms, +and especially in the late 2000s, feature phones started to inherit a lot +of the functionality that was formerly only present in smartphones. + +This document will define the terms (only for the purpose of this document) +along a very clear border in hardware architecture, as will be described in the +following sections: + +\subsection{Feature Phone} + +A feature phone is a phone that runs the GSM protocol stack (the software +implementing the GSM protocol) as well as the user interface and all +applications on a single processor. For historic reasons, this +processor is known as the so-called {\em baseband processor} (BP). + +The baseband processor often exposes a serial port (or today USB) over which +the phone can be used as a terminal adapter, similar to old wireline modems. +The industry standard protocol for this interface is an AT command set - +extended and modified from how computers interfaced old wireline modems. +The AT-command interface can be connected to a computer. The computer can then +use the phone to establish data calls, send/receive short messages via SMS, +and generally remote-control the phone. + +\subsection{Smartphone} + +A smartphone is a phone that has a dedicated processor for the GSM protocol +stack, and another (potentially multi-core) general purpose processor for +the user interface and applications. This processor is known as the +{\em application processor} (AP). + +The first hardware generations of smartphones did nothing else but to put the +feature phone and a PDA into one case. The keypad and display of the baseband +processor is removed. What remains of the feature phone is a {\em GSM modem}, +controlled by AT commands sent from the AP. + +Each processor has its own memory (RAM and Flash), peripherals, clocking, etc. +So this setup is not to be confused with the symmetric multi-processor setups +like those seen in the personal computer industry. + +Later generations of smartphones have exchanged the AT command interface by +various proprietary protocols. Also, the serial line was replaced by a +higher-bandwidth hardware connection such as USB, SPI or a shared memory +interface. + +Due to market pressure for ever smaller phones with ever more functions, +the industry has produced highly integrated products, uniting the AP and BP +inside one physical package. Further pressure on reducing cost and PCB +footprint has led to products where there is no need to have independent +RAM and Flash chips for AP and BP. Rather, a single RAM and Flash chip +is divided by assigning portions of the RAM and Flash to each of the two +processors. + +However, the fundamental separation between the AP and BP, each with their own +memory address space and software, remains present in all smartphones until +today. + +\section{GSM modem architecture} + +Every GSM phone, feature phone and smartphone alike, has a GSM modem interfacing +with the GSM network. + +This GSM modem consists of several parts: +\begin{itemize} +\item RF Frontend, responsible for receiving and transmitting on GSM frequencies +\item Analog Baseband, responsible for modulation and demodulation +\item Digital Baseband, responsible for digital signal processing and the GSM protocol stack +\end{itemize} + +\begin{figure}[h] +\centering +\includegraphics[width=160mm]{calypso-block.pdf} +\caption{Block schematics of a TI Calypso/Iota/Rita GSM modem} +\label{reg-form} +\end{figure} + +\subsection{The RF Frontend} + +The RF Frontend is tasked with the physical receive and transmit +interface with the GSM air interface (sometimes called Um interface). + +It minimally consists of an antenna switch, GSM band filters, low-noise +amplifier (LNA) for the receive path, power amplifier for the transmit +path, a local oscillator (LO) and a mixer. + +By mixing the LO frequency with the received RF signal, it generates an +analog baseband signal that is passed to the Analog Baseband (ABB) part +of the modem. By mixing the output of the ABB with the LO frequency, it +generates a RF signal that is to be transmitted in the GSM frequency +band. + +As the receive and transmit framing has an offset of 3 TDMA frames, +there is no need for a frequency duplexer. Instead, an antenna switch +is used. The switch typically is implemented using a MEMS or diode +switch. For a quad-band phone, typically a single-pole 6-throw (SP6T) +switch is used: 4 for the four Rx bands (one for each band), and 2 for +Tx (where 850+900 and 1800+1900 each share one PA output, respectively). + +\subsubsection{RF Frontend receive path} + +The antenna picks up the GSM radio signal as it is sent from a GSM cell tower +(properly called a Base Transceiver Station, or abbreviated as BTS). The +antenna signal first hits the antenna switch, which connects the antenna with +the Rx path for the GSM band of the to-be-received radio frequency. It is then +filtered by a bandpass to block out-of-band signals before entering a low-noise +amplifier for increasing signal amplitude. + +After passing the LNA, the RF signal is mixed with a frequency generated +by the LO. Depending on the LO signal, either an intermediate frequency +(IF) or a direct baseband signal is produced. In modern GSM modems, +zero-IF designs with immediate down-conversion to analog baseband +signals are most common. + +The baseband signal is then filtered to remove unwanted images and sent +as analog I/Q signals (representing amplitude and phase) to the ABB. + +\subsubsection{RF Frontend transmit path} + +The ABB generates analog I/Q signals, which are filtered and passed +into the mixer, where they are mixed with the LO frequency and thus +up-converted to the GSM RF band. From there, they are sent to the +transmit amplifier (RF PA) for amplification. After amplification, they +traverse the antenna switch and are transmitted by the antenna. + +\subsubsection{Local Oscillator} + +The LO of a GSM modem has to be synchronized very closely to that of the +cell (BTS). To achieve the required precision, a Voltage-Controlled, +Temperature-Compensated Crystal Oscillator (VCTCXO) is used. + +Common frequencies for this VCTCXO are 26MHz or 13MHz, as the GSM bit +clock (270,833 Hz) is an integral division (/96 or /48, respectively) of +those frequencies. The tuning range of the VCTCXO is several kHz to +compensate for temperature drift. + +\subsection{The Analog Baseband (ABB)} + +The ABB part of a GSM modem is responsible to interface between the +digital domain and the analog domain of the GSM modem. + +\subsubsection{ABB Receive path} + +The analog baseband I/Q signals are potentially filtered again and +digitized by an Analog-Digital converter (ADC). The sample clocks used +are typically integral multiples of the GSM bit-clock. The sample clock +itself is derived by dividing the VCTCXO of the RF frontend. + +The digital I/Q samples are passed to the Digital Signal Processor +(DSP) in the Digital Baseband (DBB). To reduce the number of traces to +be routed on the PCB, the samples are typically sent over some kind of +synchronous serial link. + +\subsubsection{ABB Transmit path} + +There are multiple architectures found in the ABB transmit path. + +The obvious architecture is to do the inverse of the receive operation: +Transmit digital I/Q samples from the DSP to the ABB and convert +them into an analog signal that is then to be sent to the mixer of the +RF Frontend. + +However, sending a GSM signal with its GMSK modulation is much simpler +than receiving. So in order to reduce computational complexity (and +thus cost as well as power consumption) inside the DSP, the modulation +of the bits is often performed in hardware inside the ABB. + +In this design, the unmodulated GSM burst bits are sent from the DBB to +a burst buffer inside the ABB. From there, based on ROM tables and a +Digital-to-Analog converter (DAC), an analog GMSK modulated signal is +generated. + +\subsection{The Digital Baseband (DBB)} + +The digital baseband implements the actual GSM protocols from Layer1 up +to Layer3 as well as higher layers such as a user interface in the case +of the feature phone. In a smartphone, the DBB only implements a +machine interface to be used by the AP. + +A typical DBB design includes a Digital Signal Processor (DSP) for the +lower half of Layer1, and a general-purpose processor (MCU) for the +upper part of Layer1, as well as anything above. + +\subsubsection{Digital Signal Processor} + +The choice of DSP architecture largely depends on the DBB chipset +vendor. Often they already have a line of DSP cores in-house and will of +course want to reuse that in their DBB chip designs. Every major DSP +architecture can be found (TI, Analog Devices, ...). + +The DSP performs the primary tasks such as Viterbi equalization, +demodulation, decoding, forward error correction, error detection, burst +(de)interleaving. + +Of course, if actual speech data is to be communicated over the GSM +network, the DSP will also have the auxiliary task to perform the +computation of the lossy speech codec used to compress the speech. + +Communication between the DSP and MCU happens most commonly by a shared +memory interface. The shared memory contains both actual data that is +to be processed, as well as control information and parameters +describing what to be done with the respective data. + +For the receive side, the MCU will instruct the DSP to perform decoding +for a particular GSM burst type, after which the DSP will receive I/Q +samples from the ABB, perform detection/demodulation/decoding and +report the result of the operation (including any decoded data) back to +the MCU. + +For the transmit path, the MCU will present the to-be-transmitted data +and auxiliary information to the DSP, which then takes care of encoding +and sends the corresponding burst bits to the ABB (remember, most ABB +devices take care of the modulation to reduce DSP load). + +The detailed programming information (API) of the DSP shared memory +interface is a closely-guarded secret of the baseband chip maker and is +not commonly disclosed even to their customers (the actual phone making +companies). + +In doing so, the baseband chip makers create a close dependency between +the GSM Layer1 software (running on the MCU) driving/implementing this +API and the actual baseband chip. Whoever buys their chip will also +have to license their GSM protocol stack software. + +It is thus almost impossible for an independent software vendor to get +access to the DSP API documentation, which the author of this paper +finds extremely anti-competitive. + +\subsubsection{DSP Peripherals} + +The specifications of the GSM proprietary On-air encryption A5/1 and +A5/2 are only made available to GSM baseband chip makers who declare +their confidentiality. Implementing the algorithm in software is +apparently considered as breach of that confidentiality. Thus, the +encryption algorithms are only implemented in hardware - despite them +being reverse-engineered and publicly disclosed by cryptographers as +early as 1996. %% cite + +Thus, the DSP in a DBB commonly has a integrated peripheral implementing the A5 +encryption. + +Further integrated DSP peripherals may include a viterbi hardware accelerator, +a DMA capable serial interface to the ABB and others. + +\subsection{Baseband Processor (MCU)} + +The MCU of almost all modern GSM DBBs is a System-on-a-Chip (SoC) utilizing a +32bit ARM7TDMI core. The only notable exception are low-cost Infineon chips +like PM7870, who still use a version of their 16bit C166 core. + +Baseband chips that support 3G cellular networks often use a more powerful +ARM926 or ARM975 core as MCU. + +\subsection{MCU peripherals} + +The MCU cores have the typical set of peripherals of any ARM7 based +microcontroller, such as RTC, UARTs for RS232 and IRDA, SPI, I2C, SD/MMC card +controller, keypad scan controller, USB device, ... + +However, there are some additional peripherals that are very GSM specific: +\begin{itemize} +\item A GPRS crypto unit for the proprietary GEA family of ciphers +\item Extended power management facilities, including a timer that can calibrate the RTC clock based on the synchronized VCTCXO in order to wake-up the MCU ahead of pre-programmed events in the GSM time multiplex +\item GSM TDMA timers that can synchronize to the on-air time frames and generate interrupts to MCU and DSP +\item Software-programmable hardware state machines for sequencing GSM burst Rx or Tx in ABB and RF Frontend +\item An ISO7816 compatible smart card reader interface for the SIM card +\item Audio routing, i.e. selecting how audio is routed in the phone, +considering integrated earpiece, ringtone speaker and microphone, as +well as external analog headset, handsfree or even bluetooth-attached +audio devices. +\end{itemize} + +The programming of those peripherals is highly device-specific and there are no +industry standards. Every DBB architecture of every supplier has its own +custom register set and programming interface. + +The register-level documentation for those proprietary peripherals is (like all +documentation on DBB chipsets) closely guarded by NDAs, effectively preventing +the development of Free Software / Open Source drivers for them, unless such +documents are leaked by third parties. + +However, as opposed to the DSP API documentation, the register-level +documentation to the MCU peripherals is normally provided to the cellphone +manufacturers. + +\section{Digital Baseband Software Architecture} + +This section provides an introductory reading in the typical software +architecture as it is found on contemporary GSM digital baseband designs. + +The MCU usually runs a very small realtime operating system (RTOS) such +as Nucleus, VxWorks or the L4 microkernel. In some cases, no operating +system is used at all, in order to save royalties or licensing fees that +would occurr for proprietary RTOS. + +\subsection{GSM Layer 1} + +The Layer1 (L1) software is highly device-specific, as it closely interacts +with the DSP using the shared memory DSP API, as well as the proprietary +integrated peripherals controlling the ABB and RF Frontend. + +However, there are some general observations that can be made about the L1: + +\subsubsection{L1 Synchronous part} + +The synchronous part is executed synchronously to the GSM TDMA frame clock. +Both CPU and DSP are interrupted by some hardware GSM timer every TDMA frame. + +The L1 synchronous part typically runs inside IRQ or FIQ context of the MCU, +taking care of retrieving data from and providing data to the DSP API. + +\subsubsection{L1 Asynchronous part} + +The asynchronous part is scheduled as a normal task, potentially with high +or even real-time priority. It picks up the information provided by the L1 +Sync and schedules its next actions. + +The L1 async typically communicates via a message queue with the Layer2 +above. Common primitives for L1 control are described (as non-normative parts) +of the GSM specifications. + +\subsection{GSM Layer 2} + +As opposed to L1, the GSM Layer 2 (L2) is already fully hardware independent. +It implements the LAPDm protocol as specified in GSM TS 04.06. LAPDm is a +derivative of the ISDN Layer 2 called LAPD, which in turn is a descendent +of the HDLC family of protocols. + +LAPDm takes care of providing communication channels for Layer3. Those +channels are protected from frame loss by the use of sequence numbers and +retransmissions. + +The interface to Layer3 is typically implemented by means of a message queue. + +Primitives (but no detailed protocol) for use of the Layer2 / Layer3 interface +are provided in the GSM specifications. + +\subsection{GSM Layer 3} + +GSM Layer 3 (L3) consist of sublayers for Radio Resource (RR), Mobility +Management (MM) and Call Control (CC). + +There is sufficient treatment of the GSM L3 and its sublayers in +existing texts, so there is no point in making a futile attempt +repeating that here. + +\section{Synchronization and Clocking} + +The author of this paper has been quoted saying {\em GSM is a synchronous +TDMA nightmare}. This is by no means intended as an insult to the +technology itself or to its inventors. It merely serves as evidence how +hard it is to get into the synchronous TDMA mindset, especially for +engineers who have spent most of their career in the world of packet +switched networks. + +GSM is synchronous in multiple ways between cell (BTS) and phone (MS): +\begin{itemize} +\item Synchronization of the carrier clock to tune the receiver and transmitter to the correct frequency +\item Synchronization of the bit clock in order to perform sampling at the most optimal sample intervals +\item Synchronization of the frame clock (and thus timeslots) to know when a TDMA frame and its 8 timeslots start +\item Synchronization of the TDMA multiplex to correctly (de)multiplex the logical channels that are sent over each timeslots +\end{itemize} + +As all those clocks are related to each other, they can (and should) all be +derived from the same master clock: The VCTCXO present in each GSM +phone. + +\subsection{How to synchronize the VCTCXO} + +Every cell sends frequency correction bursts as part of the Frequency +Correction CHannel (FCCH), which is itself part of the BCCH, which in turn is +constantly transmitted by the BTS. + +To acquire initial synchronization to the GSM network, the LO is tuned to the +desired GSM RF channel (ARFCN) frequency. However, at this point, the LO +frequency is a multiple of the VCTCXO frequency which in turn still has an +undetermined error. This initial frequency error is as large as that of a +regular crystal oscillator, potentially already with temperature compensation. + +The resulting baseband signal thus can be shifted by a fairly large amount in +our baseband spectrum. A specific DSP code is now using correlation and other +techniques to identify the frequency correction burst. The DSP can then +further calculate the actual frequency error of the LO by comparing the +received FCCH burst with the FCCH burst as specified. + +This computed frequency error can be fed into a (software) frequency control +loop filter. The loop filter output is applied to an auxiliary DAC, which +generates the control voltage for the VCTCXO. + +After a number of FCCH bursts and corresponding frequency control loop +iterations, the VCTCXO generated clock has only a residual error. Whenever the +phone is receiving, the frequency control loop is continuously exercised in +order to maintain synchronization. + +\subsection{How to synchronize the frame clock} + +When the DSP performs FCCH burst detection as described above, it identifies +the exact position in the incoming sample stream when the FCCH burst was +happening. By knowing from the specification that the FCCH burst is +part of the BCCH, and that the BCCH is sent on timeslot 0, the Layer1 +software can then synchronize the phone to the TDMA frame start. + +Commonly, a hardware timer unit is clocked by a (divided) VCTCXO clock and thus +counts in multiples of the GSM bit clock, wrapping/resetting at the TDMA duration +of 1250 bits. + +By scheduling events synchronously to this GSM bit-clock timer, the L1 can now +trigger events (such as asking the DSP to demodulate incoming data) or +instructing the LO to retune synchronously to every TDMA frame. +From this timer the DBB typically also generates interrupts to the DSP and MCU. + +\subsection{How to synchronize the GSM TDMA multiplex} + +As part of the BCCH, the BTS not only sends the FCCH but also the +Synchronization CHannel (SCH). The Synchronization channel indicates the +current GSM time / frame number (skipping the 3 least significant bits). +By using this received GSM time and incrementing it every time the GSM bit-clock +timer wraps at the beginning of a new TDMA frame, the GSM time is synchronized. + +Understanding the multiple layers of time multiplex such as the 26/51 +multiframe, superframe and hyperframe, the L1 can multiplex and demultiplex all +the logical channels of GSM. +%% this is awkwardly worded + +\section{Miscellaneous Topics} + +\subsection{GPRS} + +GPRS was the first packet switched extension to GSM. In fact, it is much more +its entirely own mobile network, independent of GSM. The only parts shared are +the GSM modulation scheme (GMSK) and time multiplex, in order to ensure peaceful +coexistence between them. + +The L1 and L2 protocols are very different (and much more complex) than GSM. + +So while the phone baseband hardware did not need any modifications for a basic +GPRS enabled phone, the software needed to be extended quite a lot. + +\subsection{EDGE} + +EDGE is a very small incremental set of changes from GPRS. It reuses all of +the time multiplex and protocol stack, but introduces a new modulation: Offset +8-PSK instead of GMSK to increase the bandwidth that can be transmitted. +Offset 8-PSK is used (as opposed to simple 8-PSK) to avoid +zero-crossings in the modulator output. + +So while the software modifications from GPRS to EDGE are minimal, the 8PSK +modulation scheme has a significant impact on the DSP, ABB and even RF +PA design. + +\subsection{UMTS} + +UMTS (sometimes called WCDMA) is an entirely separate cellular network +technology. Its physical layer, modulation schemes, encoding, frequency +bands, channel spacing are entirely different, as is the Layer1. + +UMTS Layer2 has some resemblance to the GPRS Layer2. + +UMTS Layer3 for Mobility Management and Call Control are very similar to GSM. + +Given the vast physical layer and L1 differences, a UMTS phone hardware design +significantly differs from what has been described in this document. + +Notwithstanding, all known commercial UMTS phone chipsets as of today still +include a full GSM modem in hardware and software to remain +backwards-compatible. + +\subsection{Dual-SIM and Triple-SIM phones} + +In recent years, a large number of so-called {\em Dual-SIM} or even {\em +Triple-SIM} phones have entered the market, particularly in China and other +parts of East Asia. + +Those phones come in various flavours. Some of them simply have a multiplexer +that allows electrical switching between multiple SIM card slots. This is +similar to replacing the SIM card in a phone, just without the manual process +of mechanically removing/inserting the card. As a result, you can only use one +of the two SIMs at any time. + +The more sophisticated Dual-SIM phones have two complete phones in one case. Yes, +that's right! They contain two full GSM phone chipsets, i.e. 2 antennas, 2 rf +frontends, 2 analog basebands, 2 digital basebands, ... + +However, they use the same trick as smartphones: One of the two basebands does +not have keypad or display and is simply a GSM modem connected via serial line +to the other baseband processor. + +So if a smartphone (as defined in this document) is a GSM modem connected to a +PDA in one case, a Dual-SIM phone is a GSM modem connected to a feature phone +in one case. + +Triple-SIM phones often combine the two approaches, i.e. they contain two +complete GSM baseband chips, but three SIM slots that can be switched among +the base bands. Only two SIMs can be active at the same time. + +\subsection{Powerful feature phones} + +Feature phones are becoming more and more powerful. However, their +comparatively lower market price cannot afford a full-blown smartphone design +with its two independent processors and the associated design complexity. + +Thus, more and more hardware peripherals are added to the only processor left +in the phone: The baseband processor. Such peripherals include sophisticated +camera interfaces, high-resolution color display controllers, TV output, +touchscreen controllers, audio and video codecs and even interfaces for mobile +TV reception. + +However, all of those features are still implemented on a fairly weak ARM7 or +ARM9 CPU core (compared to ARM11 and Cortex-A8 in the smartphone market). They +also lack a real operating system and still run on top of a real-time +microkernel intended for much less complex systems. They almost always lack +any form of memory protection or multiple address spaces. This makes them +more prone to security issues as there is no privilege separation between +the GSM protocol stack and the applications, or between the applications +themselves. + +\subsection{GSM baseband security features} + +There are several (sometimes conflicting) security requirements that +apply to mobile phones. Interestingly, the security features are +typically used to protect some industry interest against the interest of +the customer. There are very few security features in a phone that are +meant to protect the users or their interests. + +\subsubsection{IMEI - The hardware serial number} + +The International Mobile Equipment Identifier (IMEI) uniquely identifies +a GSM phone. It is a globally unique serial number which is programmed +into the phone non-volatile memory (Flash or EEPROM) during the +production process. There are no particular security features used to +store the IMEI. Once you are able to write to flash and have found it, +it can be changed. + +\subsubsection{The SIM Card} + +The SIM card is a cryptographic smart card that stores the secret key +used for authenticating the user to the GSM network (Ki). The Ki is +never released by the card, and as such copying (cloning) of the SIM +is prevented. Some early implementations of the SIM card had +cryptographic weaknesses that inadvertently permitted cloning until the +late 1990s. + +Furthermore, the SIM stores the International Mobile Subscriber Identity +(IMSI). The IMSI is not encrypted or protected in any way. + +There is no security channel on the connection between the SIM card and +the baseband MCU. Furthermore, there is no way how the MCU can securely +identify/authenticate the SIM itself. Physical access to the SIM card +slot allows sniffing and/or modification of the communications between +the MCU and the SIM. + +\subsubsection{SIM or Operator Locking} + +GSM is an international standard. This ensures interoperability, i.e. +any phone can be used on any network. + +However, in some cases, the vendors of a GSM phone want to restrict this +interoperability and lock a phone to one specific network, or even lock +it to a particular SIM. + +Those locks are implemented by software only, i.e. the MCU software will +instruct the GSM protocol stack not to register with a network unless +its network operator code is a certain factory-programmed network number. + +As such, techniques for circumventing those locks have become +commonplace. It's somewhat of an ongoing race between the phone makers +and the phone-unlockers. The industry invents ever more complex methods +of obfuscating their locks in the software, while the phone-unlockers +reverse engineer those bits for each and every phone model after some +time. + +\subsubsection{DBB firmware signatures} + +In order to protect the operator and phone manufacturers peculiar +business models based on SIM or operator locking, some vendors +extended their baseband software with cryptographic signatures. Only +if the correct signature is present in a software update, the bootloader +program will accept the new software. + +However, there are more or less invasive hardware-related approaches in +circumventing those signature checks, such as hardware debugging +interfaces like JTAG, or replacing the external flash memory components. + +More recently, GSM chipset vendors introduced features such as +hardware-assisted software signature checks. In this case a master key +hash might be present in DBB-internal fuses, together with a +signature-verifying boot loader in DBB-internal mask ROM. As the root +of the chain of trust is moving deeper into the hardware, it becomes +more difficult for anyone to make software modifications to the DBB. + +Especially with tighter integration, where RAM and FLASH are no longer +present as discrete components but part of a multi-chip-package, the +number of options are becoming more limited. + +On the other hand, an ever more complex baseband software stack is +opening up many more options for exploiting software vulnerabilities. +Given the lack of a proper/modern operating system with privilege +separation and virtual memory, such exploits immediately give away +full access to all aspects of the respective DBB. + +\section{Personal rant on the closedness of the GSM industry} + +The GSM industry is one of the most closed areas of computing that I've +encountered so far. It is very hard to get any hard technical +information out of them. All they like to spread is high-level +marketing information, but they're very reluctant when it comes down to +hard technical facts on their products. + +If you want to build a phone, you need to buy a GSM chipset for your +product. There are only very few companies that offer such chipsets. +The classic suppliers are Infineon, Texas Instruments, ST/Ericsson, ADI +(now MediaTek) and Freescale. + +The GSM handset products they sell are not generally available and +distributed like other electronic components they manufacture. If you +need a Microcontroller/SoC, a power management IC, a Wifi or Bluetooth +chip, RFID reader ASIC, you simply approach the respective distributors +and order them. You get your samples directly from Digikey. + +This is impossible for GSM (or other cellphone) chipsets. For some +reason those chips are sold only to hand-picked manufacturers. If you +want to qualify, you have to subscribe to at least six-digit annual +purchasing quantities. And in order for them to believe you, you have +to cough up a significant NRE (non-refundable engineering fee). This +has been reported as high as a seven-digit US\$ amount and is to make +sure that even if you end up buying less chips than you indicate, the +chipset maker will still have your upfront NRE money and keep it. + +And if you buy your way into that select club of cellphone makers, what +you get from the chipset maker is typically not all too impressive +either. The documentation you get is incomplete, i.e. it alone would +not enable you as a cellphone maker to make any use of the hardware, +unless you license the software (drivers, GSM protocol stack, ...) from +the chipset maker, too. + +On the software side, most of the technologically interesting bits (like +the protocol stack) are provided as binary-only libraries, you only get +source code to some parts of the systems, i.e. some hardware drivers +that might need modification for your particular phone electrical +design. + +That GSM protocol stack was not written by the chipset maker either. +They simply license a stack from one of the estimated 4 or 5 +organizations who have ever implemented a commercial GSM protocol stack. + +It is not like the GSM protocols were some kind of military secret. +They are a published international standard, freely accessible for +anyone. So why does everybody in that industry think that there is +a need to be so secretive? + +Having spent a significant part of the last 6 years with reverse +engineering of various aspects of mobile phones in order to understand +them better and to write software tools for security analysis, I still +don't understand this secrecy. + +All the various vendors do more or less the same. The fundamental +architecture of a GSM baseband chip is the same, whether you buy it from +TI, Infineon or from MediaTek. {\em They all cook with water}, like we +Germans tend to say. The details like the particular DSP vendor or +whether you use a traditional IF, zero-IF or low-IF analog baseband +differ. But from whom do they want to hide it? If people like myself +with a personal interest in the technical aspects of mobile phones can +figure it out in a relatively short time, then I'm sure the competition +of those chipset makers can, too. In much less time, if they actually +care. + +This closedness of the cellular industry is one of the reasons why there +has been very little innovation in the baseband firmware throughout the +last decades. Innovation can only happen by very few players. Source +code bugs can only be found and fixed by very few developers at even +fewer large corporations. There is little to no chance for a small start-up to +innovate, like they can in the sphere of the internet. + +It is fundamentally also the reason why the traditional phone makers +have been losing market share to newcomers to the mobile sphere like +Apple with its iPhone or Google with its Android platform. + +Those innovations really only happened on the application processor on +high-end smartphones. The closed GSM baseband processor had to be +accompanied by an independent application processor running a real +operating system, with real processes, memory management, shared +libraries, memory protection, virtual memory spaces, user-installable +applications, etc. + +They still don't happen on the baseband processor, which is as closed as +it was 15 years ago. + +\end{document} diff --git a/2010/gsm_phone-anatomy/gsm_phone-anatomy-v0.4.pdf b/2010/gsm_phone-anatomy/gsm_phone-anatomy-v0.4.pdf Binary files differnew file mode 100644 index 0000000..fe1adbe --- /dev/null +++ b/2010/gsm_phone-anatomy/gsm_phone-anatomy-v0.4.pdf diff --git a/2010/gsm_phone-anatomy/gsm_phone-anatomy-v0.4.tex b/2010/gsm_phone-anatomy/gsm_phone-anatomy-v0.4.tex new file mode 100644 index 0000000..88927b0 --- /dev/null +++ b/2010/gsm_phone-anatomy/gsm_phone-anatomy-v0.4.tex @@ -0,0 +1,984 @@ +\documentclass[a4paper]{article} +\usepackage[english]{babel} +\usepackage{graphicx} +\usepackage{subfigure} +\pagestyle{plain} + +%\usepackage{url} + +\setlength{\oddsidemargin}{0in} +\setlength{\evensidemargin}{0in} +\setlength{\topmargin}{0in} +\setlength{\headheight}{0in} +\setlength{\headsep}{0in} +\setlength{\textwidth}{6.5in} +\setlength{\textheight}{9.5in} +%\setlength{\parindent}{0in} +\setlength{\parskip}{0.05in} + +\begin{document} + +\title{Anatomy of contemporary GSM cellphone hardware} +\author{Harald Welte $<$laforge@gnumonks.org$>$} +\maketitle + +\begin{abstract} +%% add citation for the nubmer of gsm users and phones / carriers. +Billions of cell phones are being used every day by an almost equally large +number of users. The majority of those phones are built according to +the GSM protocol specifications and interoperate with GSM networks of hundreds +of carriers. + +Despite being an openly published international standard, the architecture of +GSM networks and its associated protocols are only known to a relatively +small group of R\&D engineers. + +Even less public information exists about the hardware architecture of the +actual mobile phones themselves, at least as far as it relates to that part +of the phone implementing the GSM protocols and facilitating access to the +public GSM networks. + +This paper is an attempt to serve as an introductory text into the hardware +architecture of contemporary GSM mobile phone hardware anatomy. It is intended +to widen the technical background on mobile phones within the IT community. +\end{abstract} + +\tableofcontents + +\section{Foreword} + +This document is the result of my personal research on mobile phone +hardware and system-level software throughout the last six years. + +Despite my past work for Openmoko Inc., I have never been professionally +involved in any aspect of the actual GSM related hardware of any phone. +Nevertheless I have the feeling that in the wider information technology +industry, I am part of a very, very small group of people who actually +understand mobile phones down to the lowest layer. + +I hope it is useful for any systems level engineer with an interest in +understanding more about how mobile phone hardware actually works. + +There are no guarantees for accuracy or correctness of any part of the +document. I happily receive your feedback and corrections. + +\section{Is your phone smart or does it have features?} + +Initially, for the first couple of years, GSM cell phones were actual phones +with very little additional functionality. They provided everything that was +required for voice calls, as well as SIM phone book editing features. The only +additional non-features were simple improvements like the ability to use them +as an alarm clock. + +In the mid-1990s, a certain new type of devices became popular: The PDA +(personal digital assistant). They pioneered handheld computing by introducing +touch screen user interfaces and a wide range of application programs, ranging +from calendar/scheduling applications, dictionaries, exchange rate and tip +calculators, scientific calculators, accounting / finance software, etc. + +While in mobile phones the actual cellphone aspect was becoming more and more +commoditized, at some point the PDA features and functionalities were added to +phones, coining the term {\em smartphone}. At that point there was a +need to differentiate from those phones that were not-so-smart. Those +phones were then called {\em feature phones}. + +There has never been an industry-wide accepted definition of those terms, +and especially in the late 2000s, feature phones started to inherit a lot +of the functionality that was formerly only present in smartphones. + +This document will define the terms (only for the purpose of this document) +along a very clear border in hardware architecture, as will be described in the +following sections: + +\subsection{Feature Phone} + +A feature phone is a phone that runs the GSM protocol stack (the software +implementing the GSM protocol) as well as the user interface and all +applications on a single processor. For historic reasons, this +processor is known as the so-called {\em baseband processor} (BP). +Some manufacturers also call it Cellular Processor (CP) or CMT. + +The baseband processor often exposes a serial port (or today USB) over which +the phone can be used as a terminal adapter, similar to old wireline modems. +The industry standard protocol for this interface is an AT command set - +extended and modified from how computers interfaced old wireline modems. +The AT-command interface can be connected to a computer. The computer can then +use the phone to establish data calls, send/receive short messages via SMS, +and generally remote-control the phone. + +\subsection{Smartphone} + +There is no clear, industry-wide definition on the term "smartphone". + +Originally, and for the scope of this paper, a smartphone is a phone that has +one dedicated processor for the GSM protocol stack, and another (potentially +multi-core) general purpose processor for the user interface and applications. +This processor is known as the {\em application processor} (AP). + +The baseband processor (BP) part in a smartphone is typically the same as +in a feature phone. But instead of connecting it to a personal computer, +a small PDA (personal digital assistant) is built into the same case. + +We will later discuss smartphone hardware architecture in more detail, but +let's first look at the GSM modem side of things. + +\section{GSM modem architecture} + +Every GSM phone, feature phone and smartphone alike, has a GSM modem interfacing +with the GSM network. + +This GSM modem consists of several parts: +\begin{itemize} +\item RF Frontend, responsible for receiving and transmitting on GSM frequencies +\item Analog Baseband, responsible for modulation and demodulation +\item Digital Baseband, responsible for digital signal processing and the GSM protocol stack +\end{itemize} + +\begin{figure}[h] +\centering +\includegraphics[width=160mm]{calypso-block.pdf} +\caption{Block schematics of a TI Calypso/Iota/Rita GSM modem} +\label{reg-form} +\end{figure} + +\subsection{The RF Frontend} + +The RF Frontend is tasked with the physical receive and transmit +interface with the GSM air interface (sometimes called Um interface). + +It minimally consists of an antenna switch, GSM band filters, low-noise +amplifier (LNA) for the receive path, power amplifier for the transmit +path, a local oscillator (LO) and a mixer. + +By mixing the LO frequency with the received RF signal, it generates an +analog baseband signal that is passed to the Analog Baseband (ABB) part +of the modem. By mixing the output of the ABB with the LO frequency, it +generates a RF signal that is to be transmitted in the GSM frequency +band. + +As the receive and transmit framing has an offset of 3 TDMA frames, +there is no need for a frequency duplexer. Instead, an antenna switch +is used. The switch typically is implemented using a MEMS or diode +switch. For a quad-band phone, typically a single-pole 6-throw (SP6T) +switch is used: 4 for the four Rx bands (one for each band), and 2 for +Tx (where 850+900 and 1800+1900 each share one PA output, respectively). + +\subsubsection{RF Frontend receive path} + +The antenna picks up the GSM radio signal as it is sent from a GSM cell tower +(properly called a Base Transceiver Station, or abbreviated as BTS). The +antenna signal first hits the antenna switch, which connects the antenna with +the Rx path for the GSM band of the to-be-received radio frequency. It is then +filtered by a bandpass to block out-of-band signals before entering a low-noise +amplifier for increasing signal amplitude. + +After passing the LNA, the RF signal is mixed with a frequency generated +by the LO. Depending on the LO signal, either an intermediate frequency +(IF) or a direct baseband signal is produced. In modern GSM modems, +zero-IF designs with immediate down-conversion to analog baseband +signals are most common. + +The baseband signal is then filtered to remove unwanted images and sent +as analog I/Q signals (representing amplitude and phase) to the ABB. + +\subsubsection{RF Frontend transmit path} + +The ABB generates analog I/Q signals, which are filtered and passed +into the mixer, where they are mixed with the LO frequency and thus +up-converted to the GSM RF band. From there, they are sent to the +transmit amplifier (RF PA) for amplification. After amplification, they +traverse the antenna switch and are transmitted by the antenna. + +\subsubsection{Local Oscillator} + +The LO of a GSM modem has to be synchronized very closely to that of the +cell (BTS). To achieve the required precision, a Voltage-Controlled, +Temperature-Compensated Crystal Oscillator (VCTCXO) is used. + +Common frequencies for this VCTCXO are 26MHz or 13MHz, as the GSM bit +clock (270,833 Hz) is an integral division (/96 or /48, respectively) of +those frequencies. The tuning range of the VCTCXO is several kHz to +compensate for temperature drift. + +\subsection{The Analog Baseband (ABB)} + +The ABB part of a GSM modem is responsible to interface between the +digital domain and the analog domain of the GSM modem. + +\subsubsection{ABB Receive path} + +The analog baseband I/Q signals are potentially filtered again and +digitized by an Analog-Digital converter (ADC). The sample clocks used +are typically integral multiples of the GSM bit-clock. The sample clock +itself is derived by dividing the VCTCXO of the RF frontend. + +The digital I/Q samples are passed to the Digital Signal Processor +(DSP) in the Digital Baseband (DBB). To reduce the number of traces to +be routed on the PCB, the samples are typically sent over some kind of +synchronous serial link. + +\subsubsection{ABB Transmit path} + +There are multiple architectures found in the ABB transmit path. + +The obvious architecture is to do the inverse of the receive operation: +Transmit digital I/Q samples from the DSP to the ABB and convert +them into an analog signal that is then to be sent to the mixer of the +RF Frontend. + +However, sending a GSM signal with its GMSK modulation is much simpler +than receiving. So in order to reduce computational complexity (and +thus cost as well as power consumption) inside the DSP, the modulation +of the bits is often performed in hardware inside the ABB. + +In this design, the unmodulated GSM burst bits are sent from the DBB to +a burst buffer inside the ABB. From there, based on ROM tables and a +Digital-to-Analog converter (DAC), an analog GMSK modulated signal is +generated. + +\subsection{The Digital Baseband (DBB)} + +The digital baseband implements the actual GSM protocols from Layer1 up +to Layer3 as well as higher layers such as a user interface in the case +of the feature phone. In a smartphone, the DBB only implements a +machine interface to be used by the AP. + +A typical DBB design includes a Digital Signal Processor (DSP) for the +lower half of Layer1, and a general-purpose processor (MCU) for the +upper part of Layer1, as well as anything above. + +\subsubsection{Digital Signal Processor} + +The choice of DSP architecture largely depends on the DBB chipset +vendor. Often they already have a line of DSP cores in-house and will of +course want to reuse that in their DBB chip designs. Every major DSP +architecture can be found (TI, Analog Devices, ...). + +The DSP performs the primary tasks such as Viterbi equalization, +demodulation, decoding, forward error correction, error detection, burst +(de)interleaving. + +Of course, if actual speech data is to be communicated over the GSM +network, the DSP will also have the auxiliary task to perform the +computation of the lossy speech codec used to compress the speech. + +Communication between the DSP and MCU happens most commonly by a shared +memory interface. The shared memory contains both actual data that is +to be processed, as well as control information and parameters +describing what to be done with the respective data. + +For the receive side, the MCU will instruct the DSP to perform decoding +for a particular GSM burst type, after which the DSP will receive I/Q +samples from the ABB, perform detection/demodulation/decoding and +report the result of the operation (including any decoded data) back to +the MCU. + +For the transmit path, the MCU will present the to-be-transmitted data +and auxiliary information to the DSP, which then takes care of encoding +and sends the corresponding burst bits to the ABB (remember, most ABB +devices take care of the modulation to reduce DSP load). + +The detailed programming information (API) of the DSP shared memory +interface is a closely-guarded secret of the baseband chip maker and is +not commonly disclosed even to their customers (the actual phone making +companies). + +In doing so, the baseband chip makers create a close dependency between +the GSM Layer1 software (running on the MCU) driving/implementing this +API and the actual baseband chip. Whoever buys their chip will also +have to license their GSM protocol stack software. + +It is thus almost impossible for an independent software vendor to get +access to the DSP API documentation, which the author of this paper +finds extremely anti-competitive. + +\subsubsection{DSP Peripherals} + +The specifications of the GSM proprietary On-air encryption A5/1 and +A5/2 are only made available to GSM baseband chip makers who declare +their confidentiality. Implementing the algorithm in software is +apparently considered as breach of that confidentiality. Thus, the +encryption algorithms are only implemented in hardware - despite them +being reverse-engineered and publicly disclosed by cryptographers as +early as 1996. %% cite + +Thus, the DSP in a DBB commonly has a integrated peripheral implementing the A5 +encryption. + +Further integrated DSP peripherals may include a viterbi hardware accelerator, +a DMA capable serial interface to the ABB and others. + +\subsection{Baseband Processor (MCU)} + +The MCU of almost all modern GSM DBBs is a System-on-a-Chip (SoC) utilizing a +32bit ARM7TDMI core. The only notable exception are low-cost Infineon chips +like PM7870, who still use a version of their 16bit C166 core. + +Baseband chips that support 3G cellular networks often use a more powerful +ARM926 or ARM975 core as MCU. + +\subsection{MCU peripherals} + +The MCU cores have the typical set of peripherals of any ARM7 based +microcontroller, such as RTC, UARTs for RS232 and IRDA, SPI, I2C, SD/MMC card +controller, keypad scan controller, USB device, ... + +However, there are some additional peripherals that are very GSM specific: +\begin{itemize} +\item A GPRS crypto unit for the proprietary GEA family of ciphers +\item Extended power management facilities, including a timer that can calibrate the RTC clock based on the synchronized VCTCXO in order to wake-up the MCU ahead of pre-programmed events in the GSM time multiplex +\item GSM TDMA timers that can synchronize to the on-air time frames and generate interrupts to MCU and DSP +\item Software-programmable hardware state machines for sequencing GSM burst Rx or Tx in ABB and RF Frontend +\item An ISO7816 compatible smart card reader interface for the SIM card +\item Audio routing, i.e. selecting how audio is routed in the phone, +considering integrated earpiece, ringtone speaker and microphone, as +well as external analog headset, handsfree or even bluetooth-attached +audio devices. +\end{itemize} + +The programming of those peripherals is highly device-specific and there are no +industry standards. Every DBB architecture of every supplier has its own +custom register set and programming interface. + +The register-level documentation for those proprietary peripherals is (like all +documentation on DBB chipsets) closely guarded by NDAs, effectively preventing +the development of Free Software / Open Source drivers for them, unless such +documents are leaked by third parties. + +However, as opposed to the DSP API documentation, the register-level +documentation to the MCU peripherals is normally provided to the cellphone +manufacturers. + +\section{Digital Baseband Software Architecture} + +This section provides an introductory reading in the typical software +architecture as it is found on contemporary GSM digital baseband designs. + +The MCU usually runs a very small realtime operating system (RTOS) such +as Nucleus, VxWorks or the L4 microkernel. In some cases, no operating +system is used at all, in order to save royalties or licensing fees that +would occurr for proprietary RTOS. + +\subsection{GSM Layer 1} + +The Layer1 (L1) software is highly device-specific, as it closely interacts +with the DSP using the shared memory DSP API, as well as the proprietary +integrated peripherals controlling the ABB and RF Frontend. + +However, there are some general observations that can be made about the L1: + +\subsubsection{L1 Synchronous part} + +The synchronous part is executed synchronously to the GSM TDMA frame clock. +Both CPU and DSP are interrupted by some hardware GSM timer every TDMA frame. + +The L1 synchronous part typically runs inside IRQ or FIQ context of the MCU, +taking care of retrieving data from and providing data to the DSP API. + +\subsubsection{L1 Asynchronous part} + +The asynchronous part is scheduled as a normal task, potentially with high +or even real-time priority. It picks up the information provided by the L1 +Sync and schedules its next actions. + +The L1 async typically communicates via a message queue with the Layer2 +above. Common primitives for L1 control are described (as non-normative parts) +of the GSM specifications. + +\subsection{GSM Layer 2} + +As opposed to L1, the GSM Layer 2 (L2) is already fully hardware independent. +It implements the LAPDm protocol as specified in GSM TS 04.06. LAPDm is a +derivative of the ISDN Layer 2 called LAPD, which in turn is a descendent +of the HDLC family of protocols. + +LAPDm takes care of providing communication channels for Layer3. Those +channels are protected from frame loss by the use of sequence numbers and +retransmissions. + +The interface to Layer3 is typically implemented by means of a message queue. + +Primitives (but no detailed protocol) for use of the Layer2 / Layer3 interface +are provided in the GSM specifications. + +\subsection{GSM Layer 3} + +GSM Layer 3 (L3) consist of sublayers for Radio Resource (RR), Mobility +Management (MM) and Call Control (CC). + +There is sufficient treatment of the GSM L3 and its sublayers in +existing texts, so there is no point in making a futile attempt +repeating that here. + +\section{Synchronization and Clocking} + +The author of this paper has been quoted saying {\em GSM is a synchronous +TDMA nightmare}. This is by no means intended as an insult to the +technology itself or to its inventors. It merely serves as evidence how +hard it is to get into the synchronous TDMA mindset, especially for +engineers who have spent most of their career in the world of packet +switched networks. + +GSM is synchronous in multiple ways between cell (BTS) and phone (MS): +\begin{itemize} +\item Synchronization of the carrier clock to tune the receiver and transmitter to the correct frequency +\item Synchronization of the bit clock in order to perform sampling at the most optimal sample intervals +\item Synchronization of the frame clock (and thus timeslots) to know when a TDMA frame and its 8 timeslots start +\item Synchronization of the TDMA multiplex to correctly (de)multiplex the logical channels that are sent over each timeslots +\end{itemize} + +As all those clocks are related to each other, they can (and should) all be +derived from the same master clock: The VCTCXO present in each GSM +phone. + +\subsection{How to synchronize the VCTCXO} + +Every cell sends frequency correction bursts as part of the Frequency +Correction CHannel (FCCH), which is itself part of the BCCH, which in turn is +constantly transmitted by the BTS. + +To acquire initial synchronization to the GSM network, the LO is tuned to the +desired GSM RF channel (ARFCN) frequency. However, at this point, the LO +frequency is a multiple of the VCTCXO frequency which in turn still has an +undetermined error. This initial frequency error is as large as that of a +regular crystal oscillator, potentially already with temperature compensation. + +The resulting baseband signal thus can be shifted by a fairly large amount in +our baseband spectrum. A specific DSP code is now using correlation and other +techniques to identify the frequency correction burst. The DSP can then +further calculate the actual frequency error of the LO by comparing the +received FCCH burst with the FCCH burst as specified. + +This computed frequency error can be fed into a (software) frequency control +loop filter. The loop filter output is applied to an auxiliary DAC, which +generates the control voltage for the VCTCXO. + +After a number of FCCH bursts and corresponding frequency control loop +iterations, the VCTCXO generated clock has only a residual error. Whenever the +phone is receiving, the frequency control loop is continuously exercised in +order to maintain synchronization. + +\subsection{How to synchronize the frame clock} + +When the DSP performs FCCH burst detection as described above, it identifies +the exact position in the incoming sample stream when the FCCH burst was +happening. By knowing from the specification that the FCCH burst is +part of the BCCH, and that the BCCH is sent on timeslot 0, the Layer1 +software can then synchronize the phone to the TDMA frame start. + +Commonly, a hardware timer unit is clocked by a (divided) VCTCXO clock and thus +counts in multiples of the GSM bit clock, wrapping/resetting at the TDMA duration +of 1250 bits. + +By scheduling events synchronously to this GSM bit-clock timer, the L1 can now +trigger events (such as asking the DSP to demodulate incoming data) or +instructing the LO to retune synchronously to every TDMA frame. +From this timer the DBB typically also generates interrupts to the DSP and MCU. + +\subsection{How to synchronize the GSM TDMA multiplex} + +As part of the BCCH, the BTS not only sends the FCCH but also the +Synchronization CHannel (SCH). The Synchronization channel indicates the +current GSM time / frame number (skipping the 3 least significant bits). +By using this received GSM time and incrementing it every time the GSM bit-clock +timer wraps at the beginning of a new TDMA frame, the GSM time is synchronized. + +Understanding the multiple layers of time multiplex such as the 26/51 +multiframe, superframe and hyperframe, the L1 can multiplex and demultiplex all +the logical channels of GSM. +%% this is awkwardly worded + +\section{Miscellaneous Topics} + +\subsection{GPRS} + +GPRS was the first packet switched extension to GSM. In fact, it is much more +its entirely own mobile network, independent of GSM. The only parts shared are +the GSM modulation scheme (GMSK) and time multiplex, in order to ensure peaceful +coexistence between them. + +The L1 and L2 protocols are very different (and much more complex) than GSM. + +So while the phone baseband hardware did not need any modifications for a basic +GPRS enabled phone, the software needed to be extended quite a lot. + +\subsection{EDGE} + +EDGE is a very small incremental set of changes from GPRS. It reuses all of +the time multiplex and protocol stack, but introduces a new modulation: Offset +8-PSK instead of GMSK to increase the bandwidth that can be transmitted. +Offset 8-PSK is used (as opposed to simple 8-PSK) to avoid +zero-crossings in the modulator output. + +So while the software modifications from GPRS to EDGE are minimal, the 8PSK +modulation scheme has a significant impact on the DSP, ABB and even RF +PA design. + +\subsection{UMTS} + +UMTS (sometimes called WCDMA) is an entirely separate cellular network +technology. Its physical layer, modulation schemes, encoding, frequency +bands, channel spacing are entirely different, as is the Layer1. + +UMTS Layer2 has some resemblance to the GPRS Layer2. + +UMTS Layer3 for Mobility Management and Call Control are very similar to GSM. + +Given the vast physical layer and L1 differences, a UMTS phone hardware design +significantly differs from what has been described in this document. + +Notwithstanding, all known commercial UMTS phone chipsets as of today still +include a full GSM modem in hardware and software to remain +backwards-compatible. + +\subsection{Dual-SIM and Triple-SIM phones} + +In recent years, a large number of so-called {\em Dual-SIM} or even {\em +Triple-SIM} phones have entered the market, particularly in China and other +parts of East Asia. + +Those phones come in various flavours. Some of them simply have a multiplexer +that allows electrical switching between multiple SIM card slots. This is +similar to replacing the SIM card in a phone, just without the manual process +of mechanically removing/inserting the card. As a result, you can only use one +of the two SIMs at any time. + +The more sophisticated Dual-SIM phones have two complete phones in one case. Yes, +that's right! They contain two full GSM phone chipsets, i.e. 2 antennas, 2 rf +frontends, 2 analog basebands, 2 digital basebands, ... + +However, they use the same trick as smartphones: One of the two basebands does +not have keypad or display and is simply a GSM modem connected via serial line +to the other baseband processor. + +So if a smartphone (as defined in this document) is a GSM modem connected to a +PDA in one case, a Dual-SIM phone is a GSM modem connected to a feature phone +in one case. + +Triple-SIM phones often combine the two approaches, i.e. they contain two +complete GSM baseband chips, but three SIM slots that can be switched among +the base bands. Only two SIMs can be active at the same time. + +\subsection{GSM baseband security features} + +There are several (sometimes conflicting) security requirements that +apply to mobile phones. Interestingly, the security features are +typically used to protect some industry interest against the interest of +the customer. There are very few security features in a phone that are +meant to protect the users or their interests. + +\subsubsection{IMEI - The hardware serial number} + +The International Mobile Equipment Identifier (IMEI) uniquely identifies +a GSM phone. It is a globally unique serial number which is programmed +into the phone non-volatile memory (Flash or EEPROM) during the +production process. There are no particular security features used to +store the IMEI. Once you are able to write to flash and have found it, +it can be changed. + +\subsubsection{The SIM Card} + +The SIM card is a cryptographic smart card that stores the secret key +used for authenticating the user to the GSM network (Ki). The Ki is +never released by the card, and as such copying (cloning) of the SIM +is prevented. Some early implementations of the SIM card had +cryptographic weaknesses that inadvertently permitted cloning until the +late 1990s. + +Furthermore, the SIM stores the International Mobile Subscriber Identity +(IMSI). The IMSI is not encrypted or protected in any way. + +There is no security channel on the connection between the SIM card and +the baseband MCU. Furthermore, there is no way how the MCU can securely +identify/authenticate the SIM itself. Physical access to the SIM card +slot allows sniffing and/or modification of the communications between +the MCU and the SIM. + +\subsubsection{SIM or Operator Locking} + +GSM is an international standard. This ensures interoperability, i.e. +any phone can be used on any network. + +However, in some cases, the vendors of a GSM phone want to restrict this +interoperability and lock a phone to one specific network, or even lock +it to a particular SIM. + +Those locks are implemented by software only, i.e. the MCU software will +instruct the GSM protocol stack not to register with a network unless +its network operator code is a certain factory-programmed network number. + +As such, techniques for circumventing those locks have become +commonplace. It's somewhat of an ongoing race between the phone makers +and the phone-unlockers. The industry invents ever more complex methods +of obfuscating their locks in the software, while the phone-unlockers +reverse engineer those bits for each and every phone model after some +time. + +\subsubsection{DBB firmware signatures} + +In order to protect the operator and phone manufacturers peculiar +business models based on SIM or operator locking, some vendors +extended their baseband software with cryptographic signatures. Only +if the correct signature is present in a software update, the bootloader +program will accept the new software. + +However, there are more or less invasive hardware-related approaches in +circumventing those signature checks, such as hardware debugging +interfaces like JTAG, or replacing the external flash memory components. + +More recently, GSM chipset vendors introduced features such as +hardware-assisted software signature checks. In this case a master key +hash might be present in DBB-internal fuses, together with a +signature-verifying boot loader in DBB-internal mask ROM. As the root +of the chain of trust is moving deeper into the hardware, it becomes +more difficult for anyone to make software modifications to the DBB. + +Especially with tighter integration, where RAM and FLASH are no longer +present as discrete components but part of a multi-chip-package, the +number of options are becoming more limited. + +On the other hand, an ever more complex baseband software stack is +opening up many more options for exploiting software vulnerabilities. +Given the lack of a proper/modern operating system with privilege +separation and virtual memory, such exploits immediately give away +full access to all aspects of the respective DBB. + + +\section{Smartphone hardware archtiecture} + +A smartphone is a phone that has a dedicated processor for the GSM protocol +stack, and another (potentially multi-core) general purpose processor for +the user interface and applications. This processor is known as the +{\em application processor} (AP). + +The purpose of the application processor is to run a general-purpose +operating system (OS) driving a rich user interface (UI) software stack, which +provides a platform for running application programs. Such applications +migh be developed by the original phone vendor or by third parties. + +There is no specific technical reason for splitting the functionality among +two independent processors. It is more likely that business and political +issues played a role in this. The baseband processor vendors are typically +very reluctant to give up any amount of control over "their" processor. They +also don't usually provide sufficient informtaion or a general-purpose enough +operating system on it. + +So the logical choice is to keep the "phone part" (aka GSM modem) just like +it was (and is) in feature phones, but add an entirely separate PDA-like +embedded system with an application processor into the same device. + +It is common to use existing feature phone GSM modem designs in smartphones. +The same BP chipset and peripherals are used. + +\subsection{Fully separate AP and BP} + +The first hardware generations of smartphones did nothing else but to put the +feature phone and a PDA into one case. The keypad and display connection to the +BP is removed. What remains of the feature phone is a {\em GSM modem}, +controlled by AT commands sent from the AP. + +Each processor has its own memory (RAM and Flash), peripherals, clocking, etc. +So this setup is not to be confused with the symmetric multi-processor setups +like those seen in the personal computer industry. + +The interface between AP and BP originally was a simple serial (UART) line, +but ever since there has been a growing variety of electrical-level interfaces. +For more information, see the section below on the Interface between AP and BP + +\subsection{Integrated Smartphone-on-a-chip Solutions} + +Due to market pressure for ever smaller phones with ever more functions, the +industry has produced highly integrated products, uniting the AP and BP inside +one physical package. The first popular example was the Qualcomm MSM7200 +as used in the first generation of Android and many Windows Mobile phones. + +More recently, other manufacturers such as ST-Ericsson (a merger of the +cellular chipset business of NXP, ST Micro and Ericsson Mobile Platforms) +have been shipping similar products. + +Such integrated chips typically combine the +\begin{itemize} +\item Application processor (typically ARM11, Cortex-A8 or A9) +\item AP peripherals such as RAM-controller, display controller, I2C, SPI, SDIO, etc. +\item Digital Baseband (DBB), typically including an ARM9 core and a DSP +\item Integrated peripherals of a the BP, including ADC and DAC +\item A GPU (Graphics Processing Unit) for 3D and/or video codec acceleration +\end{itemize} + +Sometimes, even a second DSP is added for signal processing tasks of the AP side. + +Further pressure on reducing cost and PCB footprint has led to products where +there is no need to have independent RAM and Flash chips for AP and BP. +Rather, a single RAM and Flash chip is divided by assigning portions of the RAM +and Flash to each of the two processors. + +In such systems, some integrated peripheral logic is separating the physical +RAM and flash into portions that are accessible from the AP and portions +accesible from the BP. The division ratio as well as the access levels +might be configurable by software, eFuses or bootstrap pins of the package. + +However, the fundamental separation between the AP and BP, each with their own +memory address space and software, remains present in all smartphones until +today. + +\subsection{Control + Data Interface between AP and BP} + +\subsubsection{Serial Line} + +The interface between AP and BP originally was a simple serial line (UART), +over which AT commands compliant with GSM TS 07.05 / 07.07 are spoken. A +serial line with a standard speed of 115200bps is sufficient for the control of +GSM voice calls, SMS, circuit switched data (CSD), as well as most GPRS data +speeds. However, for concurrent data and voice services, a serial multiplexor +protocol according to GSM TS 07.10 was used. It provides multiple virtual +channels with each their own instance of an AT command parser on the BP. + +As the data speeds of the cellular networks were increased with EDGE (both ECSD +and EGPRS), an asynchronouse serial connection at standard speeds became +to narrow as a communications channel. + +\subsubsection{Universal Serial Bus (USB)} + +The EDGE capable GSM modems that were once again coming from the feature phone +designs typically included a USB device mode controller for attaching those +feature phones to personal computers. + +While many of the USB-device-capable BPs use the standardized CDC-ACM protocol +to emulate one or multiple serial ports over USB, there never was any standard +or even any recommendation in the GSM/3GPP specifications. + +So a number of smartphone designs such as the Motorola EZX platform (A780, +A1200, ROKR E6, etc.) simply used that existing USB device-mode controller and +connected it to a USB host controller inside the AP. However, USB is far from +being a good protocol for this application, mostly due to power management +issues. If the phone is idle, the AP switches in some kind of deep-sleep +state. To do this, it has to disable the USB host controller, whcih in turn +means that the BP has no way how to actually issue a wake-up to the AP in case +of an incoming call. The solution to the problem was connecting some general +purpose output signal of the BP to a wakeup-capable general-purpose input +of the AP. However, this means that the system is no longer fully USB +compatible, and that the BP software has to be specifically modified. + +\subsubsection{Serial Peripheral Interface} + +Some smartphone designs, most notably those of E-TEN corporation (now Acer) +have started to use SPI-class electrical interfaces between the AP and BP. + +However, as SPI normally is a master/slave type of protocol, additional +handshaking was needed to allow the slave to request an outgoing data transfer +from the master. + +Modern application processors support SPI with speeds of up to 25 or sometimes +50 MHz, providing more than sufficient bandwidth for even the fastest available +cellular transfer speeds over the air interface. + +The second-layer protocol on top of this SPI link is vendor-specific and +proprietaty. One of them is known as CAIF by Ericsson Mobile Products (EMP). + +\subsubsection{Shared Memory / Dual Ported RAM} + +Another method for interfacing wth AP with the BP is by using some form +of shared memory. The clear advantage is speed, as access to parallel RAM +is typically several orders of magnitude faster than any serial link. +Furthermore, there is no need for serializer/deserializer, the use of DMA +controllers and the like. The data is available without any copying +(zero-copy). + +Management of shared memory is a complex problem though, and there has +to be some kind of mutual exclusion mechanism to prevent coherency/concurrency +problems like race conditions. + +Depending on the chipset architecture, this is either an actual external +dual-ported RAM (DPRAM) that provides separate address and data busses for AP +and BP. Sometimes that DPRAM is built into the BP - or simulated by the BP +using some internal arbitration logic. + +In the latest Smarphone-on-a-Chip systems, the shared memory is simply one +portion of the phyiscal RAM which is mapped into the address space of both AP +and BP parts - while the remaining RAM is mapped exclusively to either the +AP or the BP. + +\subsection{Audio Interface between AP and BP} + +In feature phones, the audio architecture is quite simple: Microphone and +earpiece speaker are all connected to an audio codec which is co-located with +the analog baseband (ABB) chip. A digital serial audio interface connects this +codec with the DSP inside the BP. As the DSP does both the +demodulation/decoding of the baseband signal as well as the actual voice codec +processing, speech data never needs to leave the DSP. The MCU is purely +handling control, but no voice data. + +With a bluetooth headset things get slightly more complex, but not much. +Bluetooth chipsets for mobile phones have a control interface (typically UART), +as well as a synchronous serial PCM interface. That PCM interface then needs +to be hooked up either to the ABB or the DSP. + +In a smartphone however, things are getting more complicated. The Application +Processor wants to play-back music, both via the ringtone speaker as well as +the headset. Ringtones are no longer played back by the BP, but are typically +mp3 files on the AP. Voice recording / memo features require the microphone +to be routed to the AP. Some advanced phones allow you to record an actual +voice call. While that call is handled by the BP, recording is done by the AP, +which is storing it to mass storage memory such as a (micro)SD card. + +There are different audio architectures on smartphones, all of them are complex. + +\subsubsection{Analog audio interface} + +This is the most "logical" interface, looking at the idea of a smartphone being +a feature phone and a PDA in one box: The AP gets an audio codec chip not +different to what a "sound card" used to be for the PC. + +Using proper analog impedance matching networks, you connect the analogue +output of the ABB to a line input of the codec chip. One of the codec +outputs is connected to the microphone input of the codec chip. + +The actual micrphone is connected to the microphone input of the codec chip, +while the headphone jack and ringtone speakers are connected to corresponding +outputs of the codec. + +The digital (PCM/IIS) interface of the codce is driven by the AP. + +So all connections between ABB and codec are analog, while the AP-codec +connection is digital. + +If you add a bluetooth interface for wireless headsets, the codec chip will +need a second IIS/PCM interface which is then connected to that bluetooth chip. + +Analog audio signals on an otherwise completely digital device can be +cumbersome. They will likely catch noise from power supply or digital signals. + +\subsubsection{Digital audio interface} + +The solution to this problem is to use digital audio interfaces. This will +require some cooperation/integration with either the ABB or the DBB of the +baseband processor and was not possible with re-purposed BP chipsets that +were not built with smartphones in mind. + +One possible architecture is to have an ABB that offers a secondary PCM/IIS +interface for the AP. Another solution is to use the PM/IIS as a multi-master +bus, which is either driven by the AP or the BP, depending on the current +use case. + +The third option is to no longer use any voice band DAC/ADC that might be +present in the ABB and use a codec chip that has at least two (three with +bluetooth) PCM/IIS interfaces, and a DBB that has a compatible digital +PCM interface. + +\section{Powerful feature phones} + +Feature phones are becoming more and more powerful. However, their +comparatively lower market price cannot afford a full-blown smartphone design +with its two independent processors and the associated design complexity. + +Thus, more and more hardware peripherals are added to the only processor left +in the phone: The baseband processor. Such peripherals include sophisticated +camera interfaces, high-resolution color display controllers, TV output, +touchscreen controllers, audio and video codecs and even interfaces for mobile +TV reception. + +However, all of those features are still implemented on a fairly weak ARM7 or +ARM9 CPU core (compared to ARM11 and Cortex-A8 in the smartphone market). They +also lack a real operating system and still run on top of a real-time +microkernel intended for much less complex systems. They almost always lack +any form of memory protection or multiple address spaces. This makes them +more prone to security issues as there is no privilege separation between +the GSM protocol stack and the applications, or between the applications +themselves. + +The chipset vendor most associated with this strategy is Mediatek (MTK) in +Taiwan, who bough the cellular chipset business from Analog Devices (ADI). + +In MTK chipsets , you can find unusual combinations of an ARM7 core with +Jazelle (ARM7EJS), which has H.264 hardware codecs attached to it. Most +of the competition doesn't have Jazelle or advanced video codecs in anything +smaller than an ARM9. + +\section{Personal rant on the closedness of the GSM industry} + +The GSM industry is one of the most closed areas of computing that I've +encountered so far. It is very hard to get any hard technical +information out of them. All they like to spread is high-level +marketing information, but they're very reluctant when it comes down to +hard technical facts on their products. + +If you want to build a phone, you need to buy a GSM chipset for your +product. There are only very few companies that offer such chipsets. +The classic suppliers are Infineon, Texas Instruments, ST/Ericsson, ADI +(now MediaTek) and Freescale. + +The GSM handset products they sell are not generally available and +distributed like other electronic components they manufacture. If you +need a Microcontroller/SoC, a power management IC, a Wifi or Bluetooth +chip, RFID reader ASIC, you simply approach the respective distributors +and order them. You get your samples directly from Digikey. + +This is impossible for GSM (or other cellphone) chipsets. For some +reason those chips are sold only to hand-picked manufacturers. If you +want to qualify, you have to subscribe to at least six-digit annual +purchasing quantities. And in order for them to believe you, you have +to cough up a significant NRE (non-refundable engineering fee). This +has been reported as high as a seven-digit US\$ amount and is to make +sure that even if you end up buying less chips than you indicate, the +chipset maker will still have your upfront NRE money and keep it. + +And if you buy your way into that select club of cellphone makers, what +you get from the chipset maker is typically not all too impressive +either. The documentation you get is incomplete, i.e. it alone would +not enable you as a cellphone maker to make any use of the hardware, +unless you license the software (drivers, GSM protocol stack, ...) from +the chipset maker, too. + +On the software side, most of the technologically interesting bits (like +the protocol stack) are provided as binary-only libraries, you only get +source code to some parts of the systems, i.e. some hardware drivers +that might need modification for your particular phone electrical +design. + +That GSM protocol stack was not written by the chipset maker either. +They simply license a stack from one of the estimated 4 or 5 +organizations who have ever implemented a commercial GSM protocol stack. + +It is not like the GSM protocols were some kind of military secret. +They are a published international standard, freely accessible for +anyone. So why does everybody in that industry think that there is +a need to be so secretive? + +Having spent a significant part of the last 6 years with reverse +engineering of various aspects of mobile phones in order to understand +them better and to write software tools for security analysis, I still +don't understand this secrecy. + +All the various vendors do more or less the same. The fundamental +architecture of a GSM baseband chip is the same, whether you buy it from +TI, Infineon or from MediaTek. {\em They all cook with water}, like we +Germans tend to say. The details like the particular DSP vendor or +whether you use a traditional IF, zero-IF or low-IF analog baseband +differ. But from whom do they want to hide it? If people like myself +with a personal interest in the technical aspects of mobile phones can +figure it out in a relatively short time, then I'm sure the competition +of those chipset makers can, too. In much less time, if they actually +care. + +This closedness of the cellular industry is one of the reasons why there +has been very little innovation in the baseband firmware throughout the +last decades. Innovation can only happen by very few players. Source +code bugs can only be found and fixed by very few developers at even +fewer large corporations. There is little to no chance for a small start-up to +innovate, like they can in the sphere of the internet. + +It is fundamentally also the reason why the traditional phone makers +have been losing market share to newcomers to the mobile sphere like +Apple with its iPhone or Google with its Android platform. + +Those innovations really only happened on the application processor on +high-end smartphones. The closed GSM baseband processor had to be +accompanied by an independent application processor running a real +operating system, with real processes, memory management, shared +libraries, memory protection, virtual memory spaces, user-installable +applications, etc. + +They still don't happen on the baseband processor, which is as closed as +it was 15 years ago. + +\end{document} diff --git a/2010/gsm_phone-anatomy/html/gsm_phone-anatomy-v0.2.css b/2010/gsm_phone-anatomy/html/gsm_phone-anatomy-v0.2.css new file mode 100644 index 0000000..ee2c1e3 --- /dev/null +++ b/2010/gsm_phone-anatomy/html/gsm_phone-anatomy-v0.2.css @@ -0,0 +1,120 @@ + +/* start css.sty */ +.cmr-17{font-size:170%;} +.cmr-12{font-size:120%;} +.cmmi-12{font-size:120%;font-style: italic;} +.cmr-9{font-size:90%;} +.cmbx-9{font-size:90%; font-weight: bold;} +.cmti-10{ font-style: italic;} +p.noindent { text-indent: 0em } +td p.noindent { text-indent: 0em; margin-top:0em; } +p.nopar { text-indent: 0em; } +p.indent{ text-indent: 1.5em } +@media print {div.crosslinks {visibility:hidden;}} +a img { border-top: 0; border-left: 0; border-right: 0; } +center { margin-top:1em; margin-bottom:1em; } +td center { margin-top:0em; margin-bottom:0em; } +.Canvas { position:relative; } +img.math{vertical-align:middle;} +li p.indent { text-indent: 0em } +li p:first-child{ margin-top:0em; } +li p:last-child, li div:last-child { margin-bottom:0.5em; } +li p~ul:last-child, li p~ol:last-child{ margin-bottom:0.5em; } +.enumerate1 {list-style-type:decimal;} +.enumerate2 {list-style-type:lower-alpha;} +.enumerate3 {list-style-type:lower-roman;} +.enumerate4 {list-style-type:upper-alpha;} +div.newtheorem { margin-bottom: 2em; margin-top: 2em;} +.obeylines-h,.obeylines-v {white-space: nowrap; } +div.obeylines-v p { margin-top:0; margin-bottom:0; } +.overline{ text-decoration:overline; } +.overline img{ border-top: 1px solid black; } +td.displaylines {text-align:center; white-space:nowrap;} +.centerline {text-align:center;} +.rightline {text-align:right;} +div.verbatim {font-family: monospace; white-space: nowrap; text-align:left; clear:both; } +.fbox {padding-left:3.0pt; padding-right:3.0pt; text-indent:0pt; border:solid black 0.4pt; } +div.fbox {display:table} +div.center div.fbox {text-align:center; clear:both; padding-left:3.0pt; padding-right:3.0pt; text-indent:0pt; border:solid black 0.4pt; } +div.minipage{width:100%;} +div.center, div.center div.center {text-align: center; margin-left:1em; margin-right:1em;} +div.center div {text-align: left;} +div.flushright, div.flushright div.flushright {text-align: right;} +div.flushright div {text-align: left;} +div.flushleft {text-align: left;} +.underline{ text-decoration:underline; } +.underline img{ border-bottom: 1px solid black; margin-bottom:1pt; } +.framebox-c, .framebox-l, .framebox-r { padding-left:3.0pt; padding-right:3.0pt; text-indent:0pt; border:solid black 0.4pt; } +.framebox-c {text-align:center;} +.framebox-l {text-align:left;} +.framebox-r {text-align:right;} +span.thank-mark{ vertical-align: super } +span.footnote-mark sup.textsuperscript, span.footnote-mark a sup.textsuperscript{ font-size:80%; } +div.tabular, div.center div.tabular {text-align: center; margin-top:0.5em; margin-bottom:0.5em; } +table.tabular td p{margin-top:0em;} +table.tabular {margin-left: auto; margin-right: auto;} +td p:first-child{ margin-top:0em; } +td p:last-child{ margin-bottom:0em; } +div.td00{ margin-left:0pt; margin-right:0pt; } +div.td01{ margin-left:0pt; margin-right:5pt; } +div.td10{ margin-left:5pt; margin-right:0pt; } +div.td11{ margin-left:5pt; margin-right:5pt; } +table[rules] {border-left:solid black 0.4pt; border-right:solid black 0.4pt; } +td.td00{ padding-left:0pt; padding-right:0pt; } +td.td01{ padding-left:0pt; padding-right:5pt; } +td.td10{ padding-left:5pt; padding-right:0pt; } +td.td11{ padding-left:5pt; padding-right:5pt; } +table[rules] {border-left:solid black 0.4pt; border-right:solid black 0.4pt; } +.hline hr, .cline hr{ height : 1px; margin:0px; } +.tabbing-right {text-align:right;} +span.TEX {letter-spacing: -0.125em; } +span.TEX span.E{ position:relative;top:0.5ex;left:-0.0417em;} +a span.TEX span.E {text-decoration: none; } +span.LATEX span.A{ position:relative; top:-0.5ex; left:-0.4em; font-size:85%;} +span.LATEX span.TEX{ position:relative; left: -0.4em; } +div.float, div.figure {margin-left: auto; margin-right: auto;} +div.float img {text-align:center;} +div.figure img {text-align:center;} +.marginpar {width:20%; float:right; text-align:left; margin-left:auto; margin-top:0.5em; font-size:85%; text-decoration:underline;} +.marginpar p{margin-top:0.4em; margin-bottom:0.4em;} +table.equation {width:100%;} +.equation td{text-align:center; } +td.equation { margin-top:1em; margin-bottom:1em; } +td.equation-label { width:5%; text-align:center; } +td.eqnarray4 { width:5%; white-space: normal; } +td.eqnarray2 { width:5%; } +table.eqnarray-star, table.eqnarray {width:100%;} +div.eqnarray{text-align:center;} +div.array {text-align:center;} +div.pmatrix {text-align:center;} +table.pmatrix {width:100%;} +span.pmatrix img{vertical-align:middle;} +div.pmatrix {text-align:center;} +table.pmatrix {width:100%;} +span.bar-css {text-decoration:overline;} +img.cdots{vertical-align:middle;} +.partToc a, .partToc, .likepartToc a, .likepartToc {line-height: 200%; font-weight:bold; font-size:110%;} +.index-item, .index-subitem, .index-subsubitem {display:block} +div.caption {text-indent:-2em; margin-left:3em; margin-right:1em; text-align:left;} +div.caption span.id{font-weight: bold; white-space: nowrap; } +h1.partHead{text-align: center} +p.bibitem { text-indent: -2em; margin-left: 2em; margin-top:0.6em; margin-bottom:0.6em; } +p.bibitem-p { text-indent: 0em; margin-left: 2em; margin-top:0.6em; margin-bottom:0.6em; } +.paragraphHead, .likeparagraphHead { margin-top:2em; font-weight: bold;} +.subparagraphHead, .likesubparagraphHead { font-weight: bold;} +.quote {margin-bottom:0.25em; margin-top:0.25em; margin-left:1em; margin-right:1em; text-align:justify;} +.verse{white-space:nowrap; margin-left:2em} +div.maketitle {text-align:center;} +h2.titleHead{text-align:center;} +div.maketitle{ margin-bottom: 2em; } +div.author, div.date {text-align:center;} +div.thanks{text-align:left; margin-left:10%; font-size:85%; font-style:italic; } +div.author{white-space: nowrap;} +.quotation {margin-bottom:0.25em; margin-top:0.25em; margin-left:1em; } +.abstract p {margin-left:5%; margin-right:5%;} +div.abstract {width:100%;} +.figure img.graphics {margin-left:10%;} +.subfigcaption {margin-top:1em; margin-left:1em; text-align:center;} +div.subfigure {text-align:center;} +/* end css.sty */ + diff --git a/2010/gsm_phone-anatomy/html/gsm_phone-anatomy-v0.2.html b/2010/gsm_phone-anatomy/html/gsm_phone-anatomy-v0.2.html new file mode 100644 index 0000000..d688f57 --- /dev/null +++ b/2010/gsm_phone-anatomy/html/gsm_phone-anatomy-v0.2.html @@ -0,0 +1,552 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" + "http://www.w3.org/TR/html4/loose.dtd"> +<html > +<head><title>Anatomy of contemporary GSM cellphone hardware</title> +<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> +<meta name="generator" content="TeX4ht (http://www.cse.ohio-state.edu/~gurari/TeX4ht/)"> +<meta name="originator" content="TeX4ht (http://www.cse.ohio-state.edu/~gurari/TeX4ht/)"> +<!-- html --> +<meta name="src" content="gsm_phone-anatomy-v0.2.tex"> +<meta name="date" content="2010-04-14 12:26:00"> +<link rel="stylesheet" type="text/css" href="gsm_phone-anatomy-v0.2.css"> +</head><body +> + <div class="maketitle"> + + + +<h2 class="titleHead">Anatomy of contemporary GSM cellphone hardware</h2> +<div class="author" ><span +class="cmr-12">Harald Welte </span><span +class="cmmi-12"><</span><span +class="cmr-12">laforge@gnumonks.org</span><span +class="cmmi-12">></span></div> +<br /> +<div class="date" ><span +class="cmr-12">April 14, 2010</span></div> + </div> + <div +class="abstract" +> +<div class="center" +> +<!--l. 25--><p class="noindent" > +<!--l. 25--><p class="noindent" ><span +class="cmbx-9">Abstract</span></div> + <!--l. 27--><p class="indent" > <span +class="cmr-9">Billions of cell phones are being used every day by an almost equally large number of users. The</span> + <span +class="cmr-9">majority of those phones are built according to the GSM protocol and interoperate with GSM networks</span> + <span +class="cmr-9">of hundreds of carriers.</span> + <!--l. 32--><p class="indent" > <span +class="cmr-9">Despite being an openly published international standard, the architecture of the GSM network and</span> + <span +class="cmr-9">its associated protocols are only known to a relatively small group of R&D engineers.</span> + <!--l. 36--><p class="indent" > <span +class="cmr-9">Even less public information exists about the hardware architecture of the actual mobile phones</span> + <span +class="cmr-9">themselves, at least as far as it relates to that part of the phone implementing the GSM protocols and</span> + <span +class="cmr-9">facilitating access to the public GSM networks.</span> + <!--l. 41--><p class="indent" > <span +class="cmr-9">This paper is an attempt to serve as an introductory text into the hardware architecture of</span> + <span +class="cmr-9">contemporary GSM mobile phone hardware anatomy. It is intended to widen the technical background</span> + <span +class="cmr-9">on mobile phones within the IT community.</span> +</div> + <h3 class="sectionHead"><span class="titlemark">1 </span> <a + id="x1-10001"></a>Foreword</h3> +<!--l. 50--><p class="noindent" >This document is the result of my personal research on mobile phone hardware and system-level software +throughout the last 6+ years. +<!--l. 53--><p class="indent" > Despite my past work for Openmoko Inc., I have never been professionally involved in any aspect of the actual +GSM related hardware of any phone. Nevertheless I have the feeling that in the wider information technology +industry, I am part of a very, very small group of people who actually understand mobile phones down to the lowest +layer. +<!--l. 59--><p class="indent" > I hope it is useful for any systems level engineer with an interest in understanding more about how mobile phone +hardware actually works. +<!--l. 62--><p class="indent" > There are no guarantees for accuracy or correctness of any part of the document. I happily receive your feedback +and corrections. + +<!--l. 65--><p class="noindent" > + <h3 class="sectionHead"><span class="titlemark">2 </span> <a + id="x1-20002"></a>Is your phone smart or does it have features?</h3> +<!--l. 67--><p class="noindent" >Initially, for the first couple of years, GSM cell phones were actual phones with very little additional functionality. +They provided everything that was required for voice calls, as well as SIM phone book editing features. +The only additional non-features were simple improvements like the ability to use them as an alarm +clock. +<!--l. 73--><p class="indent" > In the mid-1990s, a certain new type of devices became popular: The PDA (personal digital assistant). They +pioneered handheld computing by introducing touch screen user interfaces and a wide range of application +programs, ranging from calendar/scheduling applications, dictionaries, exchange rate and tip calculators, scientific +calculators, accounting / finance software, etc. +<!--l. 79--><p class="indent" > While in mobile phones the actual cellphone aspect was becoming more and more commoditized, at some point +the PDA features and functionalities were added to phones, coining the term <span +class="cmti-10">smartphone</span>. At that point there was a +need to differentiate from those phones that were not-so-smart. Those phones were then called <span +class="cmti-10">feature</span> +<span +class="cmti-10">phones</span>. +<!--l. 85--><p class="indent" > There has never been an industry-wide accepted definition of those terms, and especially in the late +2000s, feature phones started to inherit a lot of the functionality that was formerly only present in +smartphones. +<!--l. 89--><p class="indent" > This document will define the terms (only for the purpose of this document) along a very clear border in +hardware architecture, as will be described in the following sections: +<!--l. 93--><p class="noindent" > + <h4 class="subsectionHead"><span class="titlemark">2.1 </span> <a + id="x1-30002.1"></a>Feature Phone</h4> +<!--l. 95--><p class="noindent" >A feature phone is a phone that runs the GSM protocol stack (the software implementing the GSM protocol) as well +as the user interface and all applications on a single processor. For historic reasons, this processor is known as the +so-called <span +class="cmti-10">baseband processor </span>(BP). +<!--l. 100--><p class="indent" > The baseband processor often exposes a serial port (or today USB) over which the phone can be +used as a terminal adapter, similar to old wireline modems. The industry standard protocol for this +interface is an AT command set - extended and modified from how computers interfaced old wireline +modems. The AT-command interface can be connected to a computer. The computer can then use the +phone to establish data calls, send/receive short messages via SMS, and generally remote-control the +phone. +<!--l. 108--><p class="noindent" > + <h4 class="subsectionHead"><span class="titlemark">2.2 </span> <a + id="x1-40002.2"></a>Smartphone</h4> +<!--l. 110--><p class="noindent" >A smartphone is a phone that has a dedicated processor for the GSM protocol stack, and another (potentially +multi-core) general purpose processor for the user interface and applications. This processor is known as the +<span +class="cmti-10">application processor </span>(AP). +<!--l. 115--><p class="indent" > The first hardware generations of smartphones did nothing else but to put the feature phone and a PDA into one +case. The keypad and display of the baseband processor is removed. What remains of the feature phone is a <span +class="cmti-10">GSM</span> +<span +class="cmti-10">modem</span>, controlled by AT commands sent from the AP. +<!--l. 120--><p class="indent" > Each processor has its own memory (RAM and Flash), peripherals, clocking, etc. So this setup +is not to be confused with the symmetric multi-processor setups like seen in the personal computer +industry. +<!--l. 124--><p class="indent" > Later generations of smartphones have exchanged the AT command interface by various proprietary protocols. +Also, the serial line was replaced by a higher-bandwidth hardware connection such as USB, SPI or a shared memory +interface. +<!--l. 129--><p class="indent" > Due to market pressure for ever smaller phones with ever more functions, the industry has produced highly +integrated products, uniting the AP and BP inside one physical package. Further pressure on reducing cost and +PCB footprint has led to products where there is no need to have independent RAM and Flash chips for AP and + +BP. Rather, a single RAM and Flash chip is divided by assigning portions of the RAM and Flash to each of the two +processors. +<!--l. 137--><p class="indent" > However, the fundamental separation between the AP and BP, each with their own memory address space and +software, remains present in all smartphones until today. +<!--l. 141--><p class="noindent" > + <h3 class="sectionHead"><span class="titlemark">3 </span> <a + id="x1-50003"></a>GSM modem architecture</h3> +<!--l. 143--><p class="noindent" >Every GSM phone, feature phone and smartphone alike, has a GSM modem interfacing with the GSM +network. +<!--l. 146--><p class="indent" > This GSM modem consists of several parts: + <ul class="itemize1"> + <li class="itemize">RF Frontend, responsible for receiving and transmitting at GSM frequency + </li> + <li class="itemize">Analog Baseband, responsible for modulation and demodulation + </li> + <li class="itemize">Digital Baseband, responsible for digital signal processing and the GSM protocol stack</li></ul> +<!--l. 153--><p class="indent" > <hr class="figure"><div class="figure" +> + +<a + id="x1-50011"></a> + +<!--l. 155--><p class="noindent" ><img +src="gsm_phone-anatomy-v0.20x.png" alt="PIC" class="graphics"><!--tex4ht:graphics +name="gsm_phone-anatomy-v0.20x.png" src="calypso-block.pdf" +--> +<br /> <div class="caption" +><span class="id">Figure 1: </span><span +class="content">Block schematics of a TI Calypso/Iota/Rita GSM modem</span></div><!--tex4ht:label?: x1-50011 --> + +<!--l. 158--><p class="indent" > </div><hr class="endfigure"> + <h4 class="subsectionHead"><span class="titlemark">3.1 </span> <a + id="x1-60003.1"></a>The RF Frontend</h4> +<!--l. 162--><p class="noindent" >The RF Frontend is tasked with the physical receive and transmit interface with the GSM air interface (sometimes +called Um interface). +<!--l. 165--><p class="indent" > It minimally consists of an antenna switch, GSM band filters, low-noise amplifier (LNA) for the receive path, +power amplifier for the transmit path, a local oscillator (LO) and a mixer. +<!--l. 169--><p class="indent" > By mixing the LO frequency with the received RF signal, it generates an analog baseband signal that is passed +to the Analog Baseband (ABB) part of the modem. By mixing the output of the ABB with the LO frequency, it +generates a RF signal that is to be transmitted in the GSM frequency band. +<!--l. 175--><p class="indent" > As the receive and transmit framing has an offset of 3 TDMA frames, there is no need for a frequency duplexer. +Instead, an antenna switch is used. The switch typically is implemented using a MEMS or diode switch. For a +quad-band phone, typically a SP +<!--l. 180--><p class="noindent" > + <h5 class="subsubsectionHead"><span class="titlemark">3.1.1 </span> <a + id="x1-70003.1.1"></a>RF Frontend receive path</h5> +<!--l. 182--><p class="noindent" >The antenna picks up the GSM radio signal as it is sent from a GSM cell (called Base Transceiver Station, BTS). +The antenna signal first hits the antenna switch, which connects the antenna with the Rx path for the GSM band of +the to-be-received radio frequency. It is then filtered by a bandpass to block out-of-band signals before entering a +low-noise amplifier for increasing signal amplitude. +<!--l. 189--><p class="indent" > After passing the LNA, the RF signal is mixed with a frequency generated by the LO. Depending on the +LO signal, either an intermediate frequency (IF) or a direct baseband signal is produced. In modern +GSM modems, zero-IF designs with immediate down-conversion to analog baseband signals are most +common. +<!--l. 195--><p class="indent" > The baseband signal is then filtered to remove unwanted images and sent as analog I/Q signals (representing +amplitude and phase) to the ABB. +<!--l. 198--><p class="noindent" > + <h5 class="subsubsectionHead"><span class="titlemark">3.1.2 </span> <a + id="x1-80003.1.2"></a>RF Frontend transmit path</h5> +<!--l. 200--><p class="noindent" >The ABB generates analog I/Q signals, which are filtered and passed into the mixer, where they are mixed with the +LO frequency and thus up-converted to the GSM RF band. From there, they are sent to the transmit amplifier (RF +PA) for amplification. After amplification, they traverse the antenna switch and are transmitted by the +antenna. +<!--l. 206--><p class="noindent" > + <h5 class="subsubsectionHead"><span class="titlemark">3.1.3 </span> <a + id="x1-90003.1.3"></a>Local Oscillator</h5> +<!--l. 208--><p class="noindent" >The LO of a GSM modem has to be synchronized very closely to that of the cell (BTS). To achieve the +required precision, a Voltage-Controlled, Temperature-Compensated Crystal Oscillator (VCTCXO) is +used. +<!--l. 212--><p class="indent" > Common frequencies for this VCTCXO are 26MHz or 13MHz, as the GSM bit clock (270,833 Hz) is an integral +division (/96 or /48, respectively) of those frequencies. The tuning range of the VCTCXO is several kHz to +compensate for temperature drift. +<!--l. 217--><p class="noindent" > + + <h4 class="subsectionHead"><span class="titlemark">3.2 </span> <a + id="x1-100003.2"></a>The Analog Baseband (ABB)</h4> +<!--l. 219--><p class="noindent" >The ABB part of a GSM modem is responsible to interface between the digital domain and the analog domain of +the GSM modem. +<!--l. 222--><p class="noindent" > + <h5 class="subsubsectionHead"><span class="titlemark">3.2.1 </span> <a + id="x1-110003.2.1"></a>ABB Receive path</h5> +<!--l. 224--><p class="noindent" >The analog baseband I/Q signals are potentially filtered again and digitized by and Analog-Digital converter +(ADC). The sample clocks used are typically integral multiples of the GSM bit-clock. The sample clock itself is +derived by dividing the VCTCXO of the RF frontend. +<!--l. 229--><p class="indent" > The digital I/Q samples are passed to the Digital Signal Processor (DSP) in the Digital Baseband (DBB). To +reduce the number of traces to be routed on the PCB, the samples are typically sent over some kind of synchronous +serial link. +<!--l. 234--><p class="noindent" > + <h5 class="subsubsectionHead"><span class="titlemark">3.2.2 </span> <a + id="x1-120003.2.2"></a>ABB Transmit path</h5> +<!--l. 236--><p class="noindent" >There are multiple architectures found in the ABB transmit path. +<!--l. 238--><p class="indent" > The obvious architecture is to do the inverse of the receive operation: Transmit digital I/Q samples from the +DSP to the ABB and convert them into an analog signal that is then to be sent to the mixer of the RF +Frontend. +<!--l. 243--><p class="indent" > However, sending a GSM signal with its GMSK modulation is much simpler than receiving. So in order to reduce +computational complexity (and thus cost as well as power consumption) inside the DSP, the modulation of the bits +is often performed in hardware inside the ABB. +<!--l. 248--><p class="indent" > In this design, the unmodulated GSM burst bits are sent from the DBB to a burst buffer inside the ABB. From +there, based on ROM tables and a Digital-to-Analog converter (DAC), an analog GMSK modulated signal is +generated. +<!--l. 253--><p class="noindent" > + <h4 class="subsectionHead"><span class="titlemark">3.3 </span> <a + id="x1-130003.3"></a>The Digital Baseband (DBB)</h4> +<!--l. 255--><p class="noindent" >The digital baseband implements the actual GSM protocols from Layer1 up to Layer3 as well as higher layers such +as a user interface in the case of the feature phone. In a smartphone, the DBB only implements a machine interface +to be used by the AP. +<!--l. 260--><p class="indent" > A typical DBB design includes a Digital Signal Processor (DSP) for the lower half of Layer1, and a +general-purpose processor (MCU) for the upper part of Layer1, as well as anything above. +<!--l. 264--><p class="noindent" > + <h5 class="subsubsectionHead"><span class="titlemark">3.3.1 </span> <a + id="x1-140003.3.1"></a>Digital Signal Processor</h5> +<!--l. 266--><p class="noindent" >The choice of DSP architecture largely depends on the DBB chipset vendor. Often they already have a line of DSP +cores in-house and will of course want to reuse that in their DBB chip designs. Every major DSP architecture can be +found (TI, Analog Devices, ...). +<!--l. 271--><p class="indent" > The DSP performs the primary tasks such as Viterbi equalization, demodulation, decoding, forward error +correction, error detection, burst (de)interleaving. +<!--l. 275--><p class="indent" > Of course, if actual speech data is to be communicated over the GSM network, the DSP will also +have the auxiliary task to perform the computation of the lossy speech codec used to compress the +speech. +<!--l. 279--><p class="indent" > Communication between the DSP and MCU happens most commonly by a shared memory interface. The shared + +memory contains both actual data that is to be processed, as well as control information and parameters describing +what to be done with the respective data. +<!--l. 284--><p class="indent" > For the receive side, the MCU will instruct the DSP to perform decoding for a particular GSM burst type, after +which the DSP will receive I/Q samples from the ABB, perform detection/demodulation/decoding and report the +result of the operation (including any decoded data) back to the MCU. +<!--l. 290--><p class="indent" > For the transmit path, the MCU will present the to-be-transmitted data and auxiliary information to the DSP, +which then takes care of encoding and sends the corresponding burst bits to the ABB (remember, most ABB take +care of the modulation to reduce DSP load). +<!--l. 295--><p class="indent" > The detailed programming information (API) of the DSP shared memory interface is a closely-guarded secret of +the baseband chip maker and is not commonly disclosed even to their customers (the actual phone making +companies). +<!--l. 300--><p class="indent" > In doing so, the baseband chip makers create a close dependency between the GSM Layer1 software (running on +the MCU) driving/implementing this API and the actual baseband chip. Whoever buys their chip will also have to +license their GSM protocol stack software. +<!--l. 305--><p class="indent" > It is thus almost impossible for an independent software vendor to get access to the DSP API documentation, +which the author of this paper finds extremely anti-competitive. +<!--l. 309--><p class="noindent" > + <h5 class="subsubsectionHead"><span class="titlemark">3.3.2 </span> <a + id="x1-150003.3.2"></a>DSP Peripherals</h5> +<!--l. 311--><p class="noindent" >The specifications of the GSM proprietary On-air encryption A5/1 and A5/2 are only made available to GSM +baseband chip makers who declare their confidentiality. Implementing the algorithm in software is apparently +considered as breach of that confidentiality. Thus, the encryption algorithms are only implemented in +hardware - despite them being reverse-engineered and publicly disclosed by cryptographers as early as +1996. +<!--l. 319--><p class="indent" > Thus, the DSP in a DBB commonly has a integrated peripheral implementing the A5 encryption. +<!--l. 322--><p class="indent" > Further integrated DSP peripherals may include a viterbi hardware accelerator, a DMA capable serial interface +to the ABB and others. +<!--l. 325--><p class="noindent" > + <h4 class="subsectionHead"><span class="titlemark">3.4 </span> <a + id="x1-160003.4"></a>Baseband Processor (MCU)</h4> +<!--l. 327--><p class="noindent" >The MCU of almost all modern GSM DBBs is a System-on-a-Chip (SoC) utilizing a 32bit ARM7TDMI core. The +only notable exception are low-cost Infineon chips like PM7870, who still use a version of their 16bit C166 +core. +<!--l. 331--><p class="indent" > Baseband chips that support 3G cellular networks often use a more powerful ARM926 or ARM975 core as +MCU. +<!--l. 334--><p class="noindent" > + <h4 class="subsectionHead"><span class="titlemark">3.5 </span> <a + id="x1-170003.5"></a>MCU peripherals</h4> +<!--l. 336--><p class="noindent" >The MCU cores have the typical set of peripherals of any ARM7 based microcontroller, such as RTC, +UARTs for RS232 and IRDA, SPI, I2C, SD/MMC card controller, keypad scan controller, USB device, +... +<!--l. 340--><p class="indent" > However, there are some additional peripherals that are very GSM specific: + <ul class="itemize1"> + <li class="itemize">A GPRS crypto unit for the proprietary GEA family of ciphers + </li> + + <li class="itemize">Extended power management facilities, including a timer that can calibrate the RTC clock based on + the synchronized VCTCXO in order to wake-up the MCU ahead of pre-programmed events in the GSM + time multiplex + </li> + <li class="itemize">GSM TDMA timers that can synchronize to the on-air time frames and generate interrupts to MCU + and DSP + </li> + <li class="itemize">Software-programmable hardware state machines for sequencing GSM burst Rx or Tx in ABB and RF + Frontend + </li> + <li class="itemize">An ISO7816 compatible smart card reader interface for the SIM card</li></ul> +<!--l. 349--><p class="indent" > The programming of those peripherals is highly device-specific and there are no industry standards. Every DBB +architecture of every supplier has its own custom register set and programming interface. +<!--l. 353--><p class="indent" > The register-level documentation for those proprietary peripherals is (like all documentation on DBB chipsets) +closely guarded by NDAs, effectively preventing the development of Free Software / Open Source drivers for them, +unless such documents are leaked by third parties. +<!--l. 358--><p class="indent" > However, as opposed to the DSP API documentation, the register-level documentation to the MCU peripherals +is normally provided to the cellphone manufacturers. +<!--l. 362--><p class="noindent" > + <h3 class="sectionHead"><span class="titlemark">4 </span> <a + id="x1-180004"></a>Digital Baseband Software Architecture</h3> +<!--l. 364--><p class="noindent" >This section provides an introductory reading in the typical software architecture as it is found on contemporary +GSM digital baseband designs. +<!--l. 367--><p class="noindent" > + <h4 class="subsectionHead"><span class="titlemark">4.1 </span> <a + id="x1-190004.1"></a>GSM Layer 1</h4> +<!--l. 369--><p class="noindent" >The Layer1 (L1) software is highly device-specific, as it closely interacts with the DSP using the shared memory +DSP API, as well as the proprietary integrated peripherals controlling the ABB and RF Frontend. +<!--l. 373--><p class="indent" > However, there are some general observations that can be made about the L1: +<!--l. 375--><p class="noindent" > + <h5 class="subsubsectionHead"><span class="titlemark">4.1.1 </span> <a + id="x1-200004.1.1"></a>L1 Synchronous part</h5> +<!--l. 377--><p class="noindent" >The synchronous part is executed synchronously to the GSM TDMA frame clock. Both CPU and DSP are +interrupted by some hardware GSM timer every TDMA frame. +<!--l. 380--><p class="indent" > The L1 synchronous part typically runs inside IRQ or FIQ context of the MCU, taking care of retrieving data +from and providing data to the DSP API. +<!--l. 383--><p class="noindent" > + <h5 class="subsubsectionHead"><span class="titlemark">4.1.2 </span> <a + id="x1-210004.1.2"></a>L1 Asynchronous part</h5> +<!--l. 385--><p class="noindent" >The asynchronous part is scheduled as a normal task, potentially with high or even real-time priority. It picks up the +information provided by the L1 Sync and schedules its next actions. +<!--l. 389--><p class="indent" > The L1 async typically communicates via a message queue with the Layer2 above. Common primitives for L1 +control are described (as non-normative parts) of the GSM specifications. + +<!--l. 393--><p class="noindent" > + <h4 class="subsectionHead"><span class="titlemark">4.2 </span> <a + id="x1-220004.2"></a>GSM Layer 2</h4> +<!--l. 395--><p class="noindent" >As opposed to L1, the GSM Layer 2 (L2) is already fully hardware independent. It implements the LAPDm protocol +as specified in GSM TS 04.06. LAPDm is a derivative of the ISDN Layer 2 called LAPD, which in turn is a +descendent of the HDLC family of protocols. +<!--l. 400--><p class="indent" > LAPDm takes care of providing communication channels for Layer3. Those channels are protected from frame +loss by the use of sequence numbers and retransmissions. +<!--l. 404--><p class="indent" > The interface to Layer3 is typically implemented by means of a message queue. +<!--l. 406--><p class="indent" > Primitives (but no detailed protocol) for use of the Layer2 / Layer3 interface are provided in the GSM +specifications. +<!--l. 409--><p class="noindent" > + <h4 class="subsectionHead"><span class="titlemark">4.3 </span> <a + id="x1-230004.3"></a>GSM Layer 3</h4> +<!--l. 411--><p class="noindent" >GSM Layer 3 (L3) consist of sublayers for Radio Resource (RR), Mobility Management (MM) and Call Control +(CC). +<!--l. 414--><p class="indent" > There is sufficient treatment of the GSM L3 and its sublayers in existing texts, so there is no point in making a +futile attempt repeating that here. +<!--l. 418--><p class="noindent" > + <h3 class="sectionHead"><span class="titlemark">5 </span> <a + id="x1-240005"></a>Synchronization and Clocking</h3> +<!--l. 420--><p class="noindent" >The author of this paper has been quoted saying <span +class="cmti-10">GSM is a synchronous TDMA nightmare</span>. This is by no means +intended as an insult to the technology itself or to its inventors. It merely serves as evidence how hard it is to get +into the synchronous TDMA mindset, especially for engineers who have spent most of their career in the world of +packet switched networks. +<!--l. 427--><p class="indent" > GSM is synchronous in multiple ways between cell (BTS) and phone (MS): + <ul class="itemize1"> + <li class="itemize">Synchronization of the carrier clock to tune the receiver and transmitter to the correct frequency + </li> + <li class="itemize">Synchronization of the bit clock in order to perform sampling at the most optimal sample intervals + </li> + <li class="itemize">Synchronization of the frame clock (and thus timeslots) to know when a TDMA frame and its 8 + timeslots start + </li> + <li class="itemize">Synchronization of the TDMA multiplex to correctly (de)multiplex the logical channels that are sent + over each timeslots</li></ul> +<!--l. 435--><p class="indent" > As all those clocks are related to each other, they can (and should) all be derived from the same master clock: +The VCTCXO in our phone. +<!--l. 438--><p class="noindent" > + <h4 class="subsectionHead"><span class="titlemark">5.1 </span> <a + id="x1-250005.1"></a>How to synchronize the VCTCXO</h4> + +<!--l. 440--><p class="noindent" >Every cell sends frequency correction bursts as part of the Frequency Correction CHannel (FCCH), which is itself +part of the BCCH, which in turn is constantly transmitted by the BTS. +<!--l. 444--><p class="indent" > To acquire initial synchronization ot the GSM network, the LO is tuned to the desired GSM RF channel +(ARFCN) frequency. However, at this point, the LO frequency is a multiple of the VCTCXO frequency which in +turn still has an undetermined error. This initial frequency error is as large as that of a regular crystal oscillator, +potentially already with temperature compensation. +<!--l. 450--><p class="indent" > The resulting baseband signal thus can be shifted by a fairly large amount in our baseband spectrum. A specific +DSP code is now using correlation and other techniques to identify the frequency correction burst. The DSP can +then further calculate the actual frequency error of the LO by comparing the received FCCH burst with the FCCH +burst as specified. +<!--l. 456--><p class="indent" > This computed frequency error can be fed into a (software) frequency control loop filter. The loop filter output is +applied to an auxiliary DAC, which generates the control voltage for the VCTCXO. +<!--l. 460--><p class="indent" > After a number of FCCH bursts and corresponding frequency control loop iterations, the VCTCXO generated +clock has only a residual error. Whenever the phone is receiving, the frequency control loop is continuously exercised +in order to maintain synchronization. +<!--l. 465--><p class="noindent" > + <h4 class="subsectionHead"><span class="titlemark">5.2 </span> <a + id="x1-260005.2"></a>How to synchronize the frame clock</h4> +<!--l. 467--><p class="noindent" >When the DSP performs FCCH burst detection as described above, it identifies the exact position in the incoming +sample stream when the FCCH burst was happening. By knowing from the specification that the FCCH burst is +part of the BCCH, and that the BCCH is sent on timeslot 0, the Layer1 software can then synchronize the phone to +the TDMA frame start. +<!--l. 473--><p class="indent" > Commonly, a hardware timer unit is clocked by a (divided) VCTCXO clock and thus counts in multiples of the +GSM bit clock, wrapping/resetting at the TDMA duration of 1250 bits. +<!--l. 477--><p class="indent" > By scheduling events synchronously to this GSM bit-clock timer, the L1 can now trigger events (such +as asking the DSP to demodulate incoming data) or instructing the LO to retune synchronously to +every TDMA frame. From this timer the DBB typically also generates interrupts to the DSP and +MCU. +<!--l. 482--><p class="noindent" > + <h4 class="subsectionHead"><span class="titlemark">5.3 </span> <a + id="x1-270005.3"></a>How to synchronize the GSM TDMA multiplex</h4> +<!--l. 484--><p class="noindent" >As part of the BCCH, the BTS not only sends the FCCH but also the Synchronization CHannel (SCH). The +Synchronization channel indicates the current GSM time / frame number (skipping the 3 least significant bits). By +using this received GSM time and incrementing it every time the GSM bit-clock timer wraps at the beginning of a +new TDMA frame, the GSM time is synchronized. +<!--l. 490--><p class="indent" > Understanding the multiple layers of time multiplex such as the 26/51 multiframe, superframe and hyperframe, +the L1 can multiplex and demultiplex all the logical channels of GSM. +<!--l. 494--><p class="noindent" > + <h3 class="sectionHead"><span class="titlemark">6 </span> <a + id="x1-280006"></a>Miscellaneous Topics</h3> +<!--l. 495--><p class="noindent" > + <h4 class="subsectionHead"><span class="titlemark">6.1 </span> <a + id="x1-290006.1"></a>GPRS</h4> +<!--l. 497--><p class="noindent" >GPRS was the first packet switched extension to GSM. In fact, it is much more its entirely own mobile network, +independent of GSM. The only parts shared are the GSM modulation scheme (GMSK) and time multiplex, in order + +to ensure peaceful coexistence between them. +<!--l. 502--><p class="indent" > The L1 and L2 protocols are very different (and much more complex) than GSM. +<!--l. 504--><p class="indent" > So while the phone baseband hardware did not need any modifications for a basic GPRS enabled phone, the +software needed to be extended quite a lot. +<!--l. 507--><p class="noindent" > + <h4 class="subsectionHead"><span class="titlemark">6.2 </span> <a + id="x1-300006.2"></a>EDGE</h4> +<!--l. 509--><p class="noindent" >EDGE is a very small incremental step to GPRS. It reuses all of the time multiplex and protocol stack, but +introduces a new modulation: Offset 8-PSK instead of GMSK to increase the bandwidth that can be +transmitted. Offset 8-PSK is used (as opposed to simple 8-PSK) to avoid zero-crossings in the modulator +output. +<!--l. 515--><p class="indent" > So while the software modifications from GPRS to EDGE are minimal, the 8PSK modulation scheme has a +significant impact on the DSP, ABB and even RF PA design. +<!--l. 519--><p class="noindent" > + <h4 class="subsectionHead"><span class="titlemark">6.3 </span> <a + id="x1-310006.3"></a>UMTS</h4> +<!--l. 521--><p class="noindent" >UMTS (sometimes called WCDMA) is an entirely separate cellular network technology. Its physical +layer, modulation schemes, encoding, frequency bands, channel spacing are entirely different, as is the +Layer1. +<!--l. 525--><p class="indent" > UMTS Layer2 has some resemblance to the GPRS Layer2. +<!--l. 527--><p class="indent" > UMTS Layer3 for Mobility Management and Call Control are very similar to GSM. +<!--l. 529--><p class="indent" > Given the vast physical layer and L1 differences, a UMTS phone hardware design significantly differs from what +has been described in this document. +<!--l. 532--><p class="indent" > Notwithstanding, all known commercial UMTS phone chipsets as of today still include a full GSM modem in +hardware and software to remain backwards-compatible. +<!--l. 536--><p class="noindent" > + <h4 class="subsectionHead"><span class="titlemark">6.4 </span> <a + id="x1-320006.4"></a>Dual-SIM and Triple-SIM phones</h4> +<!--l. 538--><p class="noindent" >In recent years, a large number of so-called <span +class="cmti-10">Dual-SIM </span>or even <span +class="cmti-10">Triple-SIM </span>phones have entered the market, +particularly in China and other parts of East Asia. +<!--l. 542--><p class="indent" > Those phones come in various flavours. Some of them simply have a multiplexer that allows electrical switching +between multiple SIM card slots. This is similar to replacing the SIM card in a phone, just without the manual +process of mechanically removing/inserting the card. As a result, you can only use one of the two SIMs at any +time. +<!--l. 548--><p class="indent" > The more sophisticated Dual-SIM phones have two complete phones in one case. Yes, that’s right! They contain +two full GSM phone chipsets, i.e. 2 antennas, 2 rf frontends, 2 analog basebands, 2 digital basebands, +... +<!--l. 552--><p class="indent" > However, they use the same trick as smartphones: One of the two basebands does not have keypad or display and +is simply a GSM modem connected via serial line to the other baseband processor. +<!--l. 556--><p class="indent" > So if a smartphone (as defined in this document) is a GSM modem connected to a PDA in one case, a Dual-SIM +phone is a GSM modem connected to a feature phone in one case. +<!--l. 560--><p class="indent" > Triple-SIM phones often combine the two approaches, i.e. they contain two complete GSM baseband chips, but +three SIM slots that can be switched among the base bands. Only two SIMs can be active at the same +time. + +<!--l. 564--><p class="noindent" > + <h4 class="subsectionHead"><span class="titlemark">6.5 </span> <a + id="x1-330006.5"></a>Powerful feature phones</h4> +<!--l. 566--><p class="noindent" >Feature phones are becoming more and more powerful. However, their comparatively lower market price cannot +afford a full-blown smartphone design with its two independent processors and the associated design +complexity. +<!--l. 570--><p class="indent" > Thus, more and more hardware peripherals are added to the only processor left in the phone: The +baseband processor. Such peripherals include sophisticated camera interfaces, high-resolution color display +controllers, TV output, touchscreen controllers, audio and video codecs and even interfaces for mobile TV +reception. +<!--l. 576--><p class="indent" > However, all of those features are still implemented on a fairly weak ARM7 or ARM9 CPU core (compared to +ARM11 and Cortex-A8 in the smartphone market). They also lack a real operating system and still run on top of a +real-time microkernel intended for much less complex systems. They almost always lack any form of memory +protection or multiple address spaces. This makes them more prone to security issues as there is no +privilege separation between the GSM protocol stack and the applications, or between the applications +themselves. +<!--l. 585--><p class="noindent" > + <h3 class="sectionHead"><span class="titlemark">7 </span> <a + id="x1-340007"></a>Personal rant on the closedness of the GSM industry</h3> +<!--l. 587--><p class="noindent" >The GSM industry is one of the most closed areas of computing that I’ve encountered so far. It is very hard to get +any hard technical information out of them. All they like to spread is high-level marketing information, but they’re +very reluctant when it comes down to hard technical facts on their products. +<!--l. 593--><p class="indent" > If you want to build a phone, you need to buy a GSM chipset for your product. There are only very few +companies that offer such chipsets. The classic suppliers are Infineon, Texas Instruments, ST/Ericsson, ADI (now +MediaTek) and Freescale. +<!--l. 598--><p class="indent" > The GSM handset products they sell are not generally available and distributed like other electronic component +they manufacture. If you need a Microcontroller/SoC, a power management IC, a Wifi or Bluetooth chip, RFID +reader ASIC, you simply approach the respective distributors and order them. You get your samples directly from +Digikey. +<!--l. 604--><p class="indent" > This is impossible for GSM (or other cellphone) chipsets. For some reason those chips are sold only to +hand-picked manufacturers. If you want to qualify, you have to subscribe to at least six-digit annual purchasing +quantities. And in order for them to believe you, you have to cough up a significant NRE (non-refundable +engineering fee). This has been reported as high as a seven-digit US$ amount and is to make sure that even if you +end up buying less chips than you indicate, the chipset maker will still have your upfront NRE money and keep +it. +<!--l. 613--><p class="indent" > And if you buy your way into that select club of cellphone makers, what you get from the chipset maker is +typically not all too impressive either. The documentation you get is incomplete, i.e. it alone would not enable you +as a cellphone maker to make any use of the hardware, unless you license the software (drivers, GSM protocol stack, +...) from the chipset maker, too. +<!--l. 620--><p class="indent" > On the software side, most of the technologically interesting bits (like the protocol stack) are provided as +binary-only libraries, you only get source code to some parts of the systems, i.e. some hardware drivers that might +need modification for your particular phone electrical design. +<!--l. 626--><p class="indent" > That GSM protocol stack was not written by the chipset maker either. They simply license a stack from +one of the estimated 4 or 5 organizations who have ever implemented a commercial GSM protocol +stack. +<!--l. 630--><p class="indent" > It is not like the GSM protocols were some kind of military secret. They are a published international standard, +freely accessible for anyone. So why does everybody in that industry think that there is a need to be so +secretive? +<!--l. 635--><p class="indent" > Having spent a significant part of the last 6 years with reverse engineering of various aspects of mobile phones in +order to understand them better and do write software tools for security analysis, I still don’t understand this +secrecy. + +<!--l. 640--><p class="indent" > All the various vendors do more or less the same. The fundamental architecture of a GSM baseband chip is the +same, whether you buy it from TI, Infineon or from MediaTek. <span +class="cmti-10">They all cook with water</span>, like we Germans tend +to say. The details like the particular DSP vendor or whether you use a traditional IF, zero-IF or +low-IF analog baseband differ. But from whom do they want to hide it? If people like myself with a +personal interest in the technical aspects of mobile phones can figure it out in a relatively short time, +then I’m sure the competiton of those chipset makers can, too. In much less time, if they actually +care. +<!--l. 651--><p class="indent" > This closedness of the cellular industry is one of the reasons why there has been very little innovation in the +baseband firmware throughout the last decades. Innovation can only happen by very few players. Source code bugs +can only be found and fixed by very few developers at even fewer large corporations. No chance for a small start-up +to innovate, like they can in the sphere of the internet. +<!--l. 658--><p class="indent" > It is fundamentally also the reason why the traditional phone makers have been losing market share to +newcomers to the mobile sphere like Apple with its iPhone or Google with its Android platform. +<!--l. 662--><p class="indent" > Those innovations really only happened on the application processor on high-end smartphones. The closed GSM +baseband processor had to be accompanied by an independent application processor running a real operating +system, with real processes, memory management, shared libraries, memory protection, virtual memory spaces, +user-installable applications, etc. +<!--l. 669--><p class="indent" > They still don’t happen on the baseband processor, which is as closed as it was 15 years ago. + +</body></html> + + + diff --git a/2010/gsm_phone-anatomy/html/gsm_phone-anatomy-v0.20x.png b/2010/gsm_phone-anatomy/html/gsm_phone-anatomy-v0.20x.png Binary files differnew file mode 100644 index 0000000..489c5b4 --- /dev/null +++ b/2010/gsm_phone-anatomy/html/gsm_phone-anatomy-v0.20x.png diff --git a/2010/gsm_phone-anatomy/phones.txt b/2010/gsm_phone-anatomy/phones.txt new file mode 100644 index 0000000..16b8879 --- /dev/null +++ b/2010/gsm_phone-anatomy/phones.txt @@ -0,0 +1,14 @@ + +Phone AP BP Intf Audio + +EZX Marvell PXA270 Freescale Neptune LTE USB+ SSI +MAGX Freescale Freescale Neptune LTE USB+ +iPhone Samsung Infineon ? +Palm Pre TI OMAP3 Qualcomm MSM62xx ? +Galaxy S S5PC1100 Qualcomm +Google G1 Qualcoom Integrated MSM7200 +Nexus One +Freerunner S3C2442 TI Calypso UART analog +glofiish M900 S3C2442 Ericsson EMP SPI +glofiish M900 S3C6410 Ericsson EMP SPI +Nokia N900 OMAP3430 Rapu Yama ? SSI diff --git a/2010/gsm_phone-anatomy/topics b/2010/gsm_phone-anatomy/topics new file mode 100644 index 0000000..9786151 --- /dev/null +++ b/2010/gsm_phone-anatomy/topics @@ -0,0 +1,48 @@ +* gsm protocol intro as far as needed +* distinction smartphone / featurephone + * feature phones + * single processor (BP) for gsm stack + UI + * smartphones + * dual processor (AP / BP) + * baseband processor like in feature phone + * additional application processor for OS/UI + * PDA + phone in a box + * different interconnects + +* closer look at baseband chipset architecture + * DBB (MCU+DSP) + * integrated peripherals + * GSM TDMA timer / interrupt + * A5 ciphering unit + * GEA ciphering unit + * low power timers / RTC crystal calibration for power saving + * synchronous clock architecture + * AFC / VCTCXO + * ABB + * RF Frontend + * VCO + PLL + mixer + * RF PA + * Antenna switch (MEMS or diode) + * integrated frontend modules + +* introduction to GSM software architecture + * layer 1 + * synchronous part + * asynchronous part + * layer 2 + * layer 3 + * telephony API + * actual UI + * AT command parser or related + +* misc + * gprs + * edge + * 3g + * multi-sim + * more powerful feature phones + + +* glossary +* references + diff --git a/2010/gsm_security-dc2010/abstract.txt b/2010/gsm_security-dc2010/abstract.txt new file mode 100644 index 0000000..3d730dd --- /dev/null +++ b/2010/gsm_security-dc2010/abstract.txt @@ -0,0 +1 @@ +GSM security nightmares : experiences from running own GSM network diff --git a/2010/gsm_security-dc2010/gsm_network.png b/2010/gsm_security-dc2010/gsm_network.png Binary files differnew file mode 100644 index 0000000..c5f6399 --- /dev/null +++ b/2010/gsm_security-dc2010/gsm_network.png diff --git a/2010/gsm_security-dc2010/gsm_security-openbsc.pdf b/2010/gsm_security-dc2010/gsm_security-openbsc.pdf Binary files differnew file mode 100644 index 0000000..fe0ca94 --- /dev/null +++ b/2010/gsm_security-dc2010/gsm_security-openbsc.pdf diff --git a/2010/gsm_security-dc2010/gsm_security-openbsc.snm b/2010/gsm_security-dc2010/gsm_security-openbsc.snm new file mode 100644 index 0000000..e69de29 --- /dev/null +++ b/2010/gsm_security-dc2010/gsm_security-openbsc.snm diff --git a/2010/gsm_security-dc2010/gsm_security-openbsc.tex b/2010/gsm_security-dc2010/gsm_security-openbsc.tex new file mode 100644 index 0000000..47d77e8 --- /dev/null +++ b/2010/gsm_security-dc2010/gsm_security-openbsc.tex @@ -0,0 +1,586 @@ +% $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} + +% 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{GSM security nightmares} + +\subtitle +{Running your own GSM network with OpenBSC} + +\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[DORS/CLUC 2010] % (optional, should be abbreviation of conference name) +{DORS/CLUC 2010, May 2010, Zagreb/Croatia} +% - 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 + % 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 specialist, focus on network protocol security + \item Board-level Electrical Engineering + \item Always looking for interesting protocols (RFID, DECT, GSM) +\end{itemize} +\end{frame} + +\section{GSM/3G security} + +\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 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}{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 + \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) + \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} + +\begin{frame}{GSM network protocols}{On the A-bis interface} + \begin{itemize} + \item Layer 1: Typically E1 line, TS 08.54 + \item Layer 2: A variant of ISDN LAPD with fixed TEI's, TS 08.56 + \item Layer 3: OML (Organization and Maintenance Layer, TS 12.21) + \item Layer 3: RSL (Radio Signalling Link, TS 08.58) + \item Layer 4+: transparent messages that are sent to the MS via Um + \end{itemize} +\end{frame} + + +\section{Implementing GSM protocols} + +\subsection{Getting started} + +\begin{frame}{Implementing GSM protocols}{How I got started!} +\begin{itemize} + \item In September 2008, we were first able to make the BTS active and see it on a phone + \begin{itemize} + \item This is GSM900 BTS with 2 TRX at 2W output power (each) + \item A 48kg monster with attached antenna + \item 200W power consumption, passive cooling + \item E1 physical interface + \end{itemize} + \item I didn't have much time at the time (day job at Openmoko) + \item Started to read up on GSM specs whenever I could + \item Bought a HFC-E1 based PCI E1 controller, has mISDN kernel support + \item Found somebody in the GSM industry who provided protocol traces +\end{itemize} +\end{frame} + +\subsection{Timeline} + +\begin{frame}{Implementing GSM protocols}{Timeline} +\begin{itemize} + \item In November 2008, I started the development of OpenBSC + \item In December 2008, we did a first demo at 25C3 + \item In January 2009, we had full voice call support + \item In June 2009, I started with actual security related stuff + \item In August 2009, we had the first field test with 2BTS and > 860 phones +\end{itemize} +\end{frame} + +\subsection{OpenBSC} + +\begin{frame}{Security analysis of GSM}{OpenBSC} +What is OpenBSC +\begin{itemize} + \item A {\em GSM network in a box} software + \item Implements minimal subset of BSC, MSC, HLR, SMSC + \item Is Free and Open Source Software licensed under GNU GPL + \item Supports Siemens BS-11 BTS (E1) and ip.access nanoBTS (IP based) + \item Has classic 2G signalling, voice and SMS support + \item Implements various GSM protocols like + \begin{itemize} + \item A-bis RSL (TS 08.58) and OML (TS 12.21) + \item TS 04.08 Radio Resource, Mobility Management, Call Control + \item TS 04.11 Short Message Service + \end{itemize} +\end{itemize} +\end{frame} + +\section{Security analysis} + +\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} + +\subsection{Observations} + +\begin{frame}{Interesting observations}{Learned from implementing the stack} +While developing OpenBSC, we observed a number of interesting +\begin{itemize} + \item Many phones use their TMSI from the old network when they roam to a new network + \item Various phones crash when confronted with incorrect messages. We didn't even start to intentionally send incorrect messages (!) + \item There are tons of obscure options on the GSM spec which no real network uses. Potential attack vector by using rarely tested code paths. +\end{itemize} +\end{frame} + +\subsection{GSM Protocol Fuzzing} + +\begin{frame}{GSM Protocol Fuzzing}{Theoretical basis} +How to do GSM protocol fuzzing +\begin{itemize} + \item From the handset to the network + \begin{itemize} + \item Basically impossible due to closeness of baseband + \item However, some incomplete projects working on it + \end{itemize} + \item From the network side + \begin{itemize} + \item Easy in case of {\em rogue network} attacks + \item Fuzzing target is the GSM stack in the baseband processor + \end{itemize} + \item As an A-bis man in the middle + \begin{itemize} + \item Needs access to an A-bis interface of an actual network + \item Very attractive, since no encryption and ability to fuzz both network and handset + \end{itemize} +\end{itemize} +\end{frame} + +\begin{frame}{A-bis injection}{for A-bis over IP} +How to do inject messages into A-bis over IP? +\begin{itemize} + \item Problem + \begin{itemize} + \item A-bis/IP uses one TCP connection for OML and RSL messages + \item OML initialization is essential for BTS to become operational + \item TCP makes insertion of additional messages relatively hard + \end{itemize} + \item Solution: Build an {\em A-bis injection proxy} + \begin{itemize} + \item Transparently pass OML and RSL packets between BTS and BSC + \item Add additional stateless UDP sockets for injecting messages, one socket each for + \end{itemize} + \begin{itemize} + \item injecting OML/RSL to the network + \item injecting OML/RSL to the BTS + \end{itemize} +\end{itemize} +\end{frame} + +\begin{frame}{A-bis Injection Proxy}{Principle of operation} +\begin{itemize} + \item Proxy needs to be brought between BTS and BSC + \item Luckily, A-bis/IP SSL support not always used + \item Thus, physical access to the Ethernet link sufficient + \item Configure system with two interfaces + \begin{itemize} + \item BSC-facing interface has IP of BTS + \item BTS-facing interface has IP of BSC / default gw + \end{itemize} + \item BTS will make TCP connection to proxy + \item proxy will make independent TCP connection to BSC +\end{itemize} +\end{frame} + +\begin{frame}{scapy GSM support}{The actual fuzzing} +How to actually craft the packets for the fuzzing +\begin{itemize} + \item GSM has many, many protocols + \item Writing custom code will be a hard-coded special case for each of them + \item Solution: Use scapy and implement the GSM protocols as scapy "layers" + \begin{itemize} + \item IPA protocol header + \item RSL protocol layer + \item RLL data indication / data request + \item GSM 04.08 RR / MM / CC messages + \end{itemize} +\end{itemize} +\end{frame} + +\begin{frame}{OpenBSC silent calls}{A more elegant fuzzing interface} +\begin{itemize} + \item Injection at the A-bis level has many problems + \begin{itemize} + \item you can only do it while a call is active + \item you simply piggy-back on existing RR connections + \end{itemize} + \item The OpenBSC {\em silent call} feature can help + \begin{itemize} + \item we use OpenBSC to establish a RR connection + \item in the GSM master/slave model, the phone will not close a connection unless told to do so + \item we then send arbitrary data to the phone and receive its responses + \item this currently only works from within OpenBSC, but we'll provide UDP injection sockets soon + \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 + \end{itemize} + \item There is ongoing work for a phone-based tool to fuzz the network +\end{itemize} +\end{frame} + +\subsection{Where we go from here} + +\begin{frame}{TODO}{Where we go from here} +\begin{itemize} + \item The tools for fuzzing mobile phone protocol stacks are available + \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{Where we go from here} + +\begin{frame}{Current Areas of Work / Future plans} +\begin{itemize} + \item Packet data (GPRS/EDGE) support in OpenBSC + \begin{itemize} + \item GPRS/EDGE is used extensively on modern smartphones + \item Enables us to play on IP level with those phones without a heavily filtered operator network + \end{itemize} + \item UMTS(3G) support in OpenBSC + \item Access to MS side layer 1 + \item Playing with SIM Toolkit from the operator side + \item Playing with MMS + \item More exploration of RRLP +\end{itemize} +\end{frame} + +\subsection{Further Reading} + +\begin{frame}{Further Reading} +\begin{itemize} + \item http://openbsc.gnumonks.org/ + \item http://airprobe.org/ + \item http://openbts.sourceforge.net/ + \item http://bb.osmocom.org/ +\end{itemize} +\end{frame} + +\end{document} diff --git a/2010/gsm_security-dc2010/gsm_security-openbsc.tex.bak b/2010/gsm_security-dc2010/gsm_security-openbsc.tex.bak new file mode 100644 index 0000000..f536c55 --- /dev/null +++ b/2010/gsm_security-dc2010/gsm_security-openbsc.tex.bak @@ -0,0 +1,586 @@ +% $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} + +% 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{GSM security nightmares} + +\subtitle +{Running your own GSM network with OpenBSC} + +\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[DORS/CLUC 2010] % (optional, should be abbreviation of conference name) +{DORS/CLUC 2010, May 2010, Zagreb/Croatia} +% - 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 + % 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 specialist, focus on network protocol security + \item Board-level Electrical Engineering + \item Always looking for interesting protocols (RFID, DECT, GSM) +\end{itemize} +\end{frame} + +\section{GSM/3G security} + +\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 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}{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 + \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) + \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} + +\begin{frame}{GSM network protocols}{On the A-bis interface} + \begin{itemize} + \item Layer 1: Typically E1 line, TS 08.54 + \item Layer 2: A variant of ISDN LAPD with fixed TEI's, TS 08.56 + \item Layer 3: OML (Organization and Maintenance Layer, TS 12.21) + \item Layer 3: RSL (Radio Signalling Link, TS 08.58) + \item Layer 4+: transparent messages that are sent to the MS via Um + \end{itemize} +\end{frame} + + +\section{Implementing GSM protocols} + +\subsection{Getting started} + +\begin{frame}{Implementing GSM protocols}{How I got started!} +\begin{itemize} + \item In September 2008, we were first able to make the BTS active and see it on a phone + \begin{itemize} + \item This is GSM900 BTS with 2 TRX at 2W output power (each) + \item A 48kg monster with attached antenna + \item 200W power consumption, passive cooling + \item E1 physical interface + \end{itemize} + \item I didn't have much time at the time (day job at Openmoko) + \item Started to read up on GSM specs whenever I could + \item Bought a HFC-E1 based PCI E1 controller, has mISDN kernel support + \item Found somebody in the GSM industry who provided protocol traces +\end{itemize} +\end{frame} + +\subsection{Timeline} + +\begin{frame}{Implementing GSM protocols}{Timeline} +\begin{itemize} + \item In November 2008, I started the development of OpenBSC + \item In December 2008, we did a first demo at 25C3 + \item In January 2009, we had full voice call support + \item In June 2009, I started with actual security related stuff + \item In August 2009, we had the first field test with 2BTS and > 860 phones +\end{itemize} +\end{frame} + +\subsection{OpenBSC} + +\begin{frame}{Security analysis of GSM}{OpenBSC} +What is OpenBSC +\begin{itemize} + \item A {\em GSM network in a box} software + \item Implements minimal subset of BSC, MSC, HLR, SMSC + \item Is Free and Open Source Software licensed under GNU GPL + \item Supports Siemens BS-11 BTS (E1) and ip.access nanoBTS (IP based) + \item Has classic 2G signalling, voice and SMS support + \item Implements various GSM protocols like + \begin{itemize} + \item A-bis RSL (TS 08.58) and OML (TS 12.21) + \item TS 04.08 Radio Resource, Mobility Management, Call Control + \item TS 04.11 Short Message Service + \end{itemize} +\end{itemize} +\end{frame} + +\section{Security analysis} + +\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} + +\subsection{Observations} + +\begin{frame}{Interesting observations}{Learned from implementing the stack} +While developing OpenBSC, we observed a number of interesting +\begin{itemize} + \item Many phones use their TMSI from the old network when they roam to a new network + \item Various phones crash when confronted with incorrect messages. We didn't even start to intentionally send incorrect messages (!) + \item There are tons of obscure options on the GSM spec which no real network uses. Potential attack vector by using rarely tested code paths. +\end{itemize} +\end{frame} + +\subsection{GSM Protocol Fuzzing} + +\begin{frame}{GSM Protocol Fuzzing}{Theoretical basis} +How to do GSM protocol fuzzing +\begin{itemize} + \item From the handset to the network + \begin{itemize} + \item Basically impossible due to closeness of baseband + \item However, some incomplete projects working on it + \end{itemize} + \item From the network side + \begin{itemize} + \item Easy in case of {\em rogue network} attacks + \item Fuzzing target is the GSM stack in the baseband processor + \end{itemize} + \item As an A-bis man in the middle + \begin{itemize} + \item Needs access to an A-bis interface of an actual network + \item Very attractive, since no encryption and ability to fuzz both network and handset + \end{itemize} +\end{itemize} +\end{frame} + +\begin{frame}{A-bis injection}{for A-bis over IP} +How to do inject messages into A-bis over IP? +\begin{itemize} + \item Problem + \begin{itemize} + \item A-bis/IP uses one TCP connection for OML and RSL messages + \item OML initialization is essential for BTS to become operational + \item TCP makes insertion of additional messages relatively hard + \end{itemize} + \item Solution: Build an {\em A-bis injection proxy} + \begin{itemize} + \item Transparently pass OML and RSL packets between BTS and BSC + \item Add additional stateless UDP sockets for injecting messages, one socket each for + \end{itemize} + \begin{itemize} + \item injecting OML/RSL to the network + \item injecting OML/RSL to the BTS + \end{itemize} +\end{itemize} +\end{frame} + +\begin{frame}{A-bis Injection Proxy}{Principle of operation} +\begin{itemize} + \item Proxy needs to be brought between BTS and BSC + \item Luckily, A-bis/IP SSL support not always used + \item Thus, physical access to the Ethernet link sufficient + \item Configure system with two interfaces + \begin{itemize} + \item BSC-facing interface has IP of BTS + \item BTS-facing interface has IP of BSC / default gw + \end{itemize} + \item BTS will make TCP connection to proxy + \item proxy will make independent TCP connection to BSC +\end{itemize} +\end{frame} + +\begin{frame}{scapy GSM support}{The actual fuzzing} +How to actually craft the packets for the fuzzing +\begin{itemize} + \item GSM has many, many protocols + \item Writing custom code will be a hardcoded special case for each of them + \item Solution: Use scapy and implement the GSM protocols as scapy "layers" + \begin{itemize} + \item IPA protocol header + \item RSL protocol layer + \item RLL data indication / data request + \item GSM 04.08 RR / MM / CC messages + \end{itemize} +\end{itemize} +\end{frame} + +\begin{frame}{OpenBSC silent calls}{A more elegant fuzzing interface} +\begin{itemize} + \item Injection at the A-bis level has many problems + \begin{itemize} + \item you can only do it while a call is active + \item you simply piggy-back on existing RR connections + \end{itemize} + \item The OpenBSC {\em silent call} feature can help + \begin{itemize} + \item we use OpenBSC to establish a RR connection + \item in the GSM master/slave model, the phone will not close a connection unless told to do so + \item we then send arbitrary data to the phone and receive its responses + \item this currently only works from within OpenBSC, but we'll provide UDP injection sockets soon + \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 + \end{itemize} + \item There is ongoing work for a phone-based tool to fuzz the network +\end{itemize} +\end{frame} + +\subsection{Where we go from here} + +\begin{frame}{TODO}{Where we go from here} +\begin{itemize} + \item The tools for fuzzing mobile phone protocol stacks are available + \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{Where we go from here} + +\begin{frame}{Current Areas of Work / Future plans} +\begin{itemize} + \item Packet data (GPRS/EDGE) support in OpenBSC + \begin{itemize} + \item GPRS/EDGE is used extensively on modern smartphones + \item Enables us to play on IP level with those phones without a heavily filtered operator network + \end{itemize} + \item UMTS(3G) support in OpenBSC + \item Access to MS side layer 1 + \item Playing with SIM Toolkit from the operator side + \item Playing with MMS + \item More exploration of RRLP +\end{itemize} +\end{frame} + +\subsection{Further Reading} + +\begin{frame}{Further Reading} +\begin{itemize} + \item http://openbsc.gnumonks.org/ + \item http://airprobe.org/ + \item http://openbts.sourceforge.net/ + \item http://bb.osmocom.org/ +\end{itemize} +\end{frame} + +\end{document} diff --git a/2010/gsm_security-vf2010/agenda.txt b/2010/gsm_security-vf2010/agenda.txt new file mode 100644 index 0000000..1482115 --- /dev/null +++ b/2010/gsm_security-vf2010/agenda.txt @@ -0,0 +1,31 @@ +== Day 1: GSM protocol review == + +(part 1 from openbsc workshop / deepsec 2009, pp 27-90) + +* gsm network overview +* gsm um interface +* layers of um interface +* um testing tools + +TODO: +* more transaction types (ladder diagrams) + * specifically security related ones (authentication, ciphering setup) + * +* add section on TEMS +* add section on OsmocomBB +* expand airprobe section + +== Day 2: GSM Security problems == + +(deepsec 2009, 'gsm security' pp 18-25) +(deepsec 2009, 'gsm security' pp 92-115) +(deepsec 2009, 'best practises'pp 116-123) +(deepsec 2009, 'passive interception and geolocation' pp 124-149) + +== Day 3: GSM Security problems == + +(deepsec 2009, 'imsi catchers' pp 115-183) +(deepsec 2009, 'jammers' pp 183-188) +(deepsec 2009, 'countermeasures' pp 189-203) + + diff --git a/2010/gsm_security/gsm_security.tex b/2010/gsm_security/gsm_security.tex new file mode 100644 index 0000000..18db4d5 --- /dev/null +++ b/2010/gsm_security/gsm_security.tex @@ -0,0 +1,767 @@ +\documentclass[a4paper]{article} +\usepackage[english]{babel} +\usepackage{graphicx} +\usepackage{subfigure} +\pagestyle{plain} + +%\usepackage{url} + +\setlength{\oddsidemargin}{0in} +\setlength{\evensidemargin}{0in} +\setlength{\topmargin}{0in} +\setlength{\headheight}{0in} +\setlength{\headsep}{0in} +\setlength{\textwidth}{6.5in} +\setlength{\textheight}{9.5in} +%\setlength{\parindent}{0in} +\setlength{\parskip}{0.05in} + +\begin{document} + +\title{GSM Air interface DoS Attack on the RACHe} +\author{Harald Welte $<$laforge@gnumonks.org$>$} +\maketitle + +\begin{abstract} +%% add citation for the nubmer of gsm users and phones / carriers. +Billions of cell phones are being used every day by an almost equally large +number of users. The majority of those phones are built according to +the GSM protocol specifications and interoperate with GSM networks of hundreds +of carriers. + +Despite being an openly published international standard, the architecture of +GSM networks and its associated protocols are only known to a relatively +small group of R\&D engineers. + +Even less public information exists about the security weaknesses of that +architecture and inherent limitations + +This paper is an attempt to serve as an introductory text into the commonly-known +security issues of the GSM mobile telephony system. +\end{abstract} + +%\tableofcontents + +\section{Foreword} + +This document is the result of my personal research on mobile phone +hardware and system-level software throughout the last six years. + +Despite my past work for Openmoko Inc., I have never been professionally +involved in any aspect of the actual GSM related hardware of any phone. +Nevertheless I have the feeling that in the wider information technology +industry, I am part of a very, very small group of people who actually +understand mobile phones down to the lowest layer. + +I hope it is useful for any systems level engineer with an interest in +understanding more about how mobile phone hardware actually works. + +There are no guarantees for accuracy or correctness of any part of the +document. I happily receive your feedback and corrections. + +\section{Is your phone smart or does it have features?} + +Initially, for the first couple of years, GSM cell phones were actual phones +with very little additional functionality. They provided everything that was +required for voice calls, as well as SIM phone book editing features. The only +additional non-features were simple improvements like the ability to use them +as an alarm clock. + +In the mid-1990s, a certain new type of devices became popular: The PDA +(personal digital assistant). They pioneered handheld computing by introducing +touch screen user interfaces and a wide range of application programs, ranging +from calendar/scheduling applications, dictionaries, exchange rate and tip +calculators, scientific calculators, accounting / finance software, etc. + +While in mobile phones the actual cellphone aspect was becoming more and more +commoditized, at some point the PDA features and functionalities were added to +phones, coining the term {\em smartphone}. At that point there was a +need to differentiate from those phones that were not-so-smart. Those +phones were then called {\em feature phones}. + +There has never been an industry-wide accepted definition of those terms, +and especially in the late 2000s, feature phones started to inherit a lot +of the functionality that was formerly only present in smartphones. + +This document will define the terms (only for the purpose of this document) +along a very clear border in hardware architecture, as will be described in the +following sections: + +\subsection{Feature Phone} + +A feature phone is a phone that runs the GSM protocol stack (the software +implementing the GSM protocol) as well as the user interface and all +applications on a single processor. For historic reasons, this +processor is known as the so-called {\em baseband processor} (BP). + +The baseband processor often exposes a serial port (or today USB) over which +the phone can be used as a terminal adapter, similar to old wireline modems. +The industry standard protocol for this interface is an AT command set - +extended and modified from how computers interfaced old wireline modems. +The AT-command interface can be connected to a computer. The computer can then +use the phone to establish data calls, send/receive short messages via SMS, +and generally remote-control the phone. + +\subsection{Smartphone} + +A smartphone is a phone that has a dedicated processor for the GSM protocol +stack, and another (potentially multi-core) general purpose processor for +the user interface and applications. This processor is known as the +{\em application processor} (AP). + +The first hardware generations of smartphones did nothing else but to put the +feature phone and a PDA into one case. The keypad and display of the baseband +processor is removed. What remains of the feature phone is a {\em GSM modem}, +controlled by AT commands sent from the AP. + +Each processor has its own memory (RAM and Flash), peripherals, clocking, etc. +So this setup is not to be confused with the symmetric multi-processor setups +like those seen in the personal computer industry. + +Later generations of smartphones have exchanged the AT command interface by +various proprietary protocols. Also, the serial line was replaced by a +higher-bandwidth hardware connection such as USB, SPI or a shared memory +interface. + +Due to market pressure for ever smaller phones with ever more functions, +the industry has produced highly integrated products, uniting the AP and BP +inside one physical package. Further pressure on reducing cost and PCB +footprint has led to products where there is no need to have independent +RAM and Flash chips for AP and BP. Rather, a single RAM and Flash chip +is divided by assigning portions of the RAM and Flash to each of the two +processors. + +However, the fundamental separation between the AP and BP, each with their own +memory address space and software, remains present in all smartphones until +today. + +\section{GSM modem architecture} + +Every GSM phone, feature phone and smartphone alike, has a GSM modem interfacing +with the GSM network. + +This GSM modem consists of several parts: +\begin{itemize} +\item RF Frontend, responsible for receiving and transmitting on GSM frequencies +\item Analog Baseband, responsible for modulation and demodulation +\item Digital Baseband, responsible for digital signal processing and the GSM protocol stack +\end{itemize} + +\begin{figure}[h] +\centering +\includegraphics[width=160mm]{calypso-block.pdf} +\caption{Block schematics of a TI Calypso/Iota/Rita GSM modem} +\label{reg-form} +\end{figure} + +\subsection{The RF Frontend} + +The RF Frontend is tasked with the physical receive and transmit +interface with the GSM air interface (sometimes called Um interface). + +It minimally consists of an antenna switch, GSM band filters, low-noise +amplifier (LNA) for the receive path, power amplifier for the transmit +path, a local oscillator (LO) and a mixer. + +By mixing the LO frequency with the received RF signal, it generates an +analog baseband signal that is passed to the Analog Baseband (ABB) part +of the modem. By mixing the output of the ABB with the LO frequency, it +generates a RF signal that is to be transmitted in the GSM frequency +band. + +As the receive and transmit framing has an offset of 3 TDMA frames, +there is no need for a frequency duplexer. Instead, an antenna switch +is used. The switch typically is implemented using a MEMS or diode +switch. For a quad-band phone, typically a single-pole 6-throw (SP6T) +switch is used: 4 for the four Rx bands (one for each band), and 2 for +Tx (where 850+900 and 1800+1900 each share one PA output, respectively). + +\subsubsection{RF Frontend receive path} + +The antenna picks up the GSM radio signal as it is sent from a GSM cell tower +(properly called a Base Transceiver Station, or abbreviated as BTS). The +antenna signal first hits the antenna switch, which connects the antenna with +the Rx path for the GSM band of the to-be-received radio frequency. It is then +filtered by a bandpass to block out-of-band signals before entering a low-noise +amplifier for increasing signal amplitude. + +After passing the LNA, the RF signal is mixed with a frequency generated +by the LO. Depending on the LO signal, either an intermediate frequency +(IF) or a direct baseband signal is produced. In modern GSM modems, +zero-IF designs with immediate down-conversion to analog baseband +signals are most common. + +The baseband signal is then filtered to remove unwanted images and sent +as analog I/Q signals (representing amplitude and phase) to the ABB. + +\subsubsection{RF Frontend transmit path} + +The ABB generates analog I/Q signals, which are filtered and passed +into the mixer, where they are mixed with the LO frequency and thus +up-converted to the GSM RF band. From there, they are sent to the +transmit amplifier (RF PA) for amplification. After amplification, they +traverse the antenna switch and are transmitted by the antenna. + +\subsubsection{Local Oscillator} + +The LO of a GSM modem has to be synchronized very closely to that of the +cell (BTS). To achieve the required precision, a Voltage-Controlled, +Temperature-Compensated Crystal Oscillator (VCTCXO) is used. + +Common frequencies for this VCTCXO are 26MHz or 13MHz, as the GSM bit +clock (270,833 Hz) is an integral division (/96 or /48, respectively) of +those frequencies. The tuning range of the VCTCXO is several kHz to +compensate for temperature drift. + +\subsection{The Analog Baseband (ABB)} + +The ABB part of a GSM modem is responsible to interface between the +digital domain and the analog domain of the GSM modem. + +\subsubsection{ABB Receive path} + +The analog baseband I/Q signals are potentially filtered again and +digitized by an Analog-Digital converter (ADC). The sample clocks used +are typically integral multiples of the GSM bit-clock. The sample clock +itself is derived by dividing the VCTCXO of the RF frontend. + +The digital I/Q samples are passed to the Digital Signal Processor +(DSP) in the Digital Baseband (DBB). To reduce the number of traces to +be routed on the PCB, the samples are typically sent over some kind of +synchronous serial link. + +\subsubsection{ABB Transmit path} + +There are multiple architectures found in the ABB transmit path. + +The obvious architecture is to do the inverse of the receive operation: +Transmit digital I/Q samples from the DSP to the ABB and convert +them into an analog signal that is then to be sent to the mixer of the +RF Frontend. + +However, sending a GSM signal with its GMSK modulation is much simpler +than receiving. So in order to reduce computational complexity (and +thus cost as well as power consumption) inside the DSP, the modulation +of the bits is often performed in hardware inside the ABB. + +In this design, the unmodulated GSM burst bits are sent from the DBB to +a burst buffer inside the ABB. From there, based on ROM tables and a +Digital-to-Analog converter (DAC), an analog GMSK modulated signal is +generated. + +\subsection{The Digital Baseband (DBB)} + +The digital baseband implements the actual GSM protocols from Layer1 up +to Layer3 as well as higher layers such as a user interface in the case +of the feature phone. In a smartphone, the DBB only implements a +machine interface to be used by the AP. + +A typical DBB design includes a Digital Signal Processor (DSP) for the +lower half of Layer1, and a general-purpose processor (MCU) for the +upper part of Layer1, as well as anything above. + +\subsubsection{Digital Signal Processor} + +The choice of DSP architecture largely depends on the DBB chipset +vendor. Often they already have a line of DSP cores in-house and will of +course want to reuse that in their DBB chip designs. Every major DSP +architecture can be found (TI, Analog Devices, ...). + +The DSP performs the primary tasks such as Viterbi equalization, +demodulation, decoding, forward error correction, error detection, burst +(de)interleaving. + +Of course, if actual speech data is to be communicated over the GSM +network, the DSP will also have the auxiliary task to perform the +computation of the lossy speech codec used to compress the speech. + +Communication between the DSP and MCU happens most commonly by a shared +memory interface. The shared memory contains both actual data that is +to be processed, as well as control information and parameters +describing what to be done with the respective data. + +For the receive side, the MCU will instruct the DSP to perform decoding +for a particular GSM burst type, after which the DSP will receive I/Q +samples from the ABB, perform detection/demodulation/decoding and +report the result of the operation (including any decoded data) back to +the MCU. + +For the transmit path, the MCU will present the to-be-transmitted data +and auxiliary information to the DSP, which then takes care of encoding +and sends the corresponding burst bits to the ABB (remember, most ABB +devices take care of the modulation to reduce DSP load). + +The detailed programming information (API) of the DSP shared memory +interface is a closely-guarded secret of the baseband chip maker and is +not commonly disclosed even to their customers (the actual phone making +companies). + +In doing so, the baseband chip makers create a close dependency between +the GSM Layer1 software (running on the MCU) driving/implementing this +API and the actual baseband chip. Whoever buys their chip will also +have to license their GSM protocol stack software. + +It is thus almost impossible for an independent software vendor to get +access to the DSP API documentation, which the author of this paper +finds extremely anti-competitive. + +\subsubsection{DSP Peripherals} + +The specifications of the GSM proprietary On-air encryption A5/1 and +A5/2 are only made available to GSM baseband chip makers who declare +their confidentiality. Implementing the algorithm in software is +apparently considered as breach of that confidentiality. Thus, the +encryption algorithms are only implemented in hardware - despite them +being reverse-engineered and publicly disclosed by cryptographers as +early as 1996. %% cite + +Thus, the DSP in a DBB commonly has a integrated peripheral implementing the A5 +encryption. + +Further integrated DSP peripherals may include a viterbi hardware accelerator, +a DMA capable serial interface to the ABB and others. + +\subsection{Baseband Processor (MCU)} + +The MCU of almost all modern GSM DBBs is a System-on-a-Chip (SoC) utilizing a +32bit ARM7TDMI core. The only notable exception are low-cost Infineon chips +like PM7870, who still use a version of their 16bit C166 core. + +Baseband chips that support 3G cellular networks often use a more powerful +ARM926 or ARM975 core as MCU. + +\subsection{MCU peripherals} + +The MCU cores have the typical set of peripherals of any ARM7 based +microcontroller, such as RTC, UARTs for RS232 and IRDA, SPI, I2C, SD/MMC card +controller, keypad scan controller, USB device, ... + +However, there are some additional peripherals that are very GSM specific: +\begin{itemize} +\item A GPRS crypto unit for the proprietary GEA family of ciphers +\item Extended power management facilities, including a timer that can calibrate the RTC clock based on the synchronized VCTCXO in order to wake-up the MCU ahead of pre-programmed events in the GSM time multiplex +\item GSM TDMA timers that can synchronize to the on-air time frames and generate interrupts to MCU and DSP +\item Software-programmable hardware state machines for sequencing GSM burst Rx or Tx in ABB and RF Frontend +\item An ISO7816 compatible smart card reader interface for the SIM card +\item Audio routing, i.e. selecting how audio is routed in the phone, +considering integrated earpiece, ringtone speaker and microphone, as +well as external analog headset, handsfree or even bluetooth-attached +audio devices. +\end{itemize} + +The programming of those peripherals is highly device-specific and there are no +industry standards. Every DBB architecture of every supplier has its own +custom register set and programming interface. + +The register-level documentation for those proprietary peripherals is (like all +documentation on DBB chipsets) closely guarded by NDAs, effectively preventing +the development of Free Software / Open Source drivers for them, unless such +documents are leaked by third parties. + +However, as opposed to the DSP API documentation, the register-level +documentation to the MCU peripherals is normally provided to the cellphone +manufacturers. + +\section{Digital Baseband Software Architecture} + +This section provides an introductory reading in the typical software +architecture as it is found on contemporary GSM digital baseband designs. + +The MCU usually runs a very small realtime operating system (RTOS) such +as Nucleus, VxWorks or the L4 microkernel. In some cases, no operating +system is used at all, in order to save royalties or licensing fees that +would occurr for proprietary RTOS. + +\subsection{GSM Layer 1} + +The Layer1 (L1) software is highly device-specific, as it closely interacts +with the DSP using the shared memory DSP API, as well as the proprietary +integrated peripherals controlling the ABB and RF Frontend. + +However, there are some general observations that can be made about the L1: + +\subsubsection{L1 Synchronous part} + +The synchronous part is executed synchronously to the GSM TDMA frame clock. +Both CPU and DSP are interrupted by some hardware GSM timer every TDMA frame. + +The L1 synchronous part typically runs inside IRQ or FIQ context of the MCU, +taking care of retrieving data from and providing data to the DSP API. + +\subsubsection{L1 Asynchronous part} + +The asynchronous part is scheduled as a normal task, potentially with high +or even real-time priority. It picks up the information provided by the L1 +Sync and schedules its next actions. + +The L1 async typically communicates via a message queue with the Layer2 +above. Common primitives for L1 control are described (as non-normative parts) +of the GSM specifications. + +\subsection{GSM Layer 2} + +As opposed to L1, the GSM Layer 2 (L2) is already fully hardware independent. +It implements the LAPDm protocol as specified in GSM TS 04.06. LAPDm is a +derivative of the ISDN Layer 2 called LAPD, which in turn is a descendent +of the HDLC family of protocols. + +LAPDm takes care of providing communication channels for Layer3. Those +channels are protected from frame loss by the use of sequence numbers and +retransmissions. + +The interface to Layer3 is typically implemented by means of a message queue. + +Primitives (but no detailed protocol) for use of the Layer2 / Layer3 interface +are provided in the GSM specifications. + +\subsection{GSM Layer 3} + +GSM Layer 3 (L3) consist of sublayers for Radio Resource (RR), Mobility +Management (MM) and Call Control (CC). + +There is sufficient treatment of the GSM L3 and its sublayers in +existing texts, so there is no point in making a futile attempt +repeating that here. + +\section{Synchronization and Clocking} + +The author of this paper has been quoted saying {\em GSM is a synchronous +TDMA nightmare}. This is by no means intended as an insult to the +technology itself or to its inventors. It merely serves as evidence how +hard it is to get into the synchronous TDMA mindset, especially for +engineers who have spent most of their career in the world of packet +switched networks. + +GSM is synchronous in multiple ways between cell (BTS) and phone (MS): +\begin{itemize} +\item Synchronization of the carrier clock to tune the receiver and transmitter to the correct frequency +\item Synchronization of the bit clock in order to perform sampling at the most optimal sample intervals +\item Synchronization of the frame clock (and thus timeslots) to know when a TDMA frame and its 8 timeslots start +\item Synchronization of the TDMA multiplex to correctly (de)multiplex the logical channels that are sent over each timeslots +\end{itemize} + +As all those clocks are related to each other, they can (and should) all be +derived from the same master clock: The VCTCXO present in each GSM +phone. + +\subsection{How to synchronize the VCTCXO} + +Every cell sends frequency correction bursts as part of the Frequency +Correction CHannel (FCCH), which is itself part of the BCCH, which in turn is +constantly transmitted by the BTS. + +To acquire initial synchronization to the GSM network, the LO is tuned to the +desired GSM RF channel (ARFCN) frequency. However, at this point, the LO +frequency is a multiple of the VCTCXO frequency which in turn still has an +undetermined error. This initial frequency error is as large as that of a +regular crystal oscillator, potentially already with temperature compensation. + +The resulting baseband signal thus can be shifted by a fairly large amount in +our baseband spectrum. A specific DSP code is now using correlation and other +techniques to identify the frequency correction burst. The DSP can then +further calculate the actual frequency error of the LO by comparing the +received FCCH burst with the FCCH burst as specified. + +This computed frequency error can be fed into a (software) frequency control +loop filter. The loop filter output is applied to an auxiliary DAC, which +generates the control voltage for the VCTCXO. + +After a number of FCCH bursts and corresponding frequency control loop +iterations, the VCTCXO generated clock has only a residual error. Whenever the +phone is receiving, the frequency control loop is continuously exercised in +order to maintain synchronization. + +\subsection{How to synchronize the frame clock} + +When the DSP performs FCCH burst detection as described above, it identifies +the exact position in the incoming sample stream when the FCCH burst was +happening. By knowing from the specification that the FCCH burst is +part of the BCCH, and that the BCCH is sent on timeslot 0, the Layer1 +software can then synchronize the phone to the TDMA frame start. + +Commonly, a hardware timer unit is clocked by a (divided) VCTCXO clock and thus +counts in multiples of the GSM bit clock, wrapping/resetting at the TDMA duration +of 1250 bits. + +By scheduling events synchronously to this GSM bit-clock timer, the L1 can now +trigger events (such as asking the DSP to demodulate incoming data) or +instructing the LO to retune synchronously to every TDMA frame. +From this timer the DBB typically also generates interrupts to the DSP and MCU. + +\subsection{How to synchronize the GSM TDMA multiplex} + +As part of the BCCH, the BTS not only sends the FCCH but also the +Synchronization CHannel (SCH). The Synchronization channel indicates the +current GSM time / frame number (skipping the 3 least significant bits). +By using this received GSM time and incrementing it every time the GSM bit-clock +timer wraps at the beginning of a new TDMA frame, the GSM time is synchronized. + +Understanding the multiple layers of time multiplex such as the 26/51 +multiframe, superframe and hyperframe, the L1 can multiplex and demultiplex all +the logical channels of GSM. +%% this is awkwardly worded + +\section{Miscellaneous Topics} + +\subsection{GPRS} + +GPRS was the first packet switched extension to GSM. In fact, it is much more +its entirely own mobile network, independent of GSM. The only parts shared are +the GSM modulation scheme (GMSK) and time multiplex, in order to ensure peaceful +coexistence between them. + +The L1 and L2 protocols are very different (and much more complex) than GSM. + +So while the phone baseband hardware did not need any modifications for a basic +GPRS enabled phone, the software needed to be extended quite a lot. + +\subsection{EDGE} + +EDGE is a very small incremental set of changes from GPRS. It reuses all of +the time multiplex and protocol stack, but introduces a new modulation: Offset +8-PSK instead of GMSK to increase the bandwidth that can be transmitted. +Offset 8-PSK is used (as opposed to simple 8-PSK) to avoid +zero-crossings in the modulator output. + +So while the software modifications from GPRS to EDGE are minimal, the 8PSK +modulation scheme has a significant impact on the DSP, ABB and even RF +PA design. + +\subsection{UMTS} + +UMTS (sometimes called WCDMA) is an entirely separate cellular network +technology. Its physical layer, modulation schemes, encoding, frequency +bands, channel spacing are entirely different, as is the Layer1. + +UMTS Layer2 has some resemblance to the GPRS Layer2. + +UMTS Layer3 for Mobility Management and Call Control are very similar to GSM. + +Given the vast physical layer and L1 differences, a UMTS phone hardware design +significantly differs from what has been described in this document. + +Notwithstanding, all known commercial UMTS phone chipsets as of today still +include a full GSM modem in hardware and software to remain +backwards-compatible. + +\subsection{Dual-SIM and Triple-SIM phones} + +In recent years, a large number of so-called {\em Dual-SIM} or even {\em +Triple-SIM} phones have entered the market, particularly in China and other +parts of East Asia. + +Those phones come in various flavours. Some of them simply have a multiplexer +that allows electrical switching between multiple SIM card slots. This is +similar to replacing the SIM card in a phone, just without the manual process +of mechanically removing/inserting the card. As a result, you can only use one +of the two SIMs at any time. + +The more sophisticated Dual-SIM phones have two complete phones in one case. Yes, +that's right! They contain two full GSM phone chipsets, i.e. 2 antennas, 2 rf +frontends, 2 analog basebands, 2 digital basebands, ... + +However, they use the same trick as smartphones: One of the two basebands does +not have keypad or display and is simply a GSM modem connected via serial line +to the other baseband processor. + +So if a smartphone (as defined in this document) is a GSM modem connected to a +PDA in one case, a Dual-SIM phone is a GSM modem connected to a feature phone +in one case. + +Triple-SIM phones often combine the two approaches, i.e. they contain two +complete GSM baseband chips, but three SIM slots that can be switched among +the base bands. Only two SIMs can be active at the same time. + +\subsection{Powerful feature phones} + +Feature phones are becoming more and more powerful. However, their +comparatively lower market price cannot afford a full-blown smartphone design +with its two independent processors and the associated design complexity. + +Thus, more and more hardware peripherals are added to the only processor left +in the phone: The baseband processor. Such peripherals include sophisticated +camera interfaces, high-resolution color display controllers, TV output, +touchscreen controllers, audio and video codecs and even interfaces for mobile +TV reception. + +However, all of those features are still implemented on a fairly weak ARM7 or +ARM9 CPU core (compared to ARM11 and Cortex-A8 in the smartphone market). They +also lack a real operating system and still run on top of a real-time +microkernel intended for much less complex systems. They almost always lack +any form of memory protection or multiple address spaces. This makes them +more prone to security issues as there is no privilege separation between +the GSM protocol stack and the applications, or between the applications +themselves. + +\subsection{GSM baseband security features} + +There are several (sometimes conflicting) security requirements that +apply to mobile phones. Interestingly, the security features are +typically used to protect some industry interest against the interest of +the customer. There are very few security features in a phone that are +meant to protect the users or their interests. + +\subsubsection{IMEI - The hardware serial number} + +The International Mobile Equipment Identifier (IMEI) uniquely identifies +a GSM phone. It is a globally unique serial number which is programmed +into the phone non-volatile memory (Flash or EEPROM) during the +production process. There are no particular security features used to +store the IMEI. Once you are able to write to flash and have found it, +it can be changed. + +\subsubsection{The SIM Card} + +The SIM card is a cryptographic smart card that stores the secret key +used for authenticating the user to the GSM network (Ki). The Ki is +never released by the card, and as such copying (cloning) of the SIM +is prevented. Some early implementations of the SIM card had +cryptographic weaknesses that inadvertently permitted cloning until the +late 1990s. + +Furthermore, the SIM stores the International Mobile Subscriber Identity +(IMSI). The IMSI is not encrypted or protected in any way. + +There is no security channel on the connection between the SIM card and +the baseband MCU. Furthermore, there is no way how the MCU can securely +identify/authenticate the SIM itself. Physical access to the SIM card +slot allows sniffing and/or modification of the communications between +the MCU and the SIM. + +\subsubsection{SIM or Operator Locking} + +GSM is an international standard. This ensures interoperability, i.e. +any phone can be used on any network. + +However, in some cases, the vendors of a GSM phone want to restrict this +interoperability and lock a phone to one specific network, or even lock +it to a particular SIM. + +Those locks are implemented by software only, i.e. the MCU software will +instruct the GSM protocol stack not to register with a network unless +its network operator code is a certain factory-programmed network number. + +As such, techniques for circumventing those locks have become +commonplace. It's somewhat of an ongoing race between the phone makers +and the phone-unlockers. The industry invents ever more complex methods +of obfuscating their locks in the software, while the phone-unlockers +reverse engineer those bits for each and every phone model after some +time. + +\subsubsection{DBB firmware signatures} + +In order to protect the operator and phone manufacturers peculiar +business models based on SIM or operator locking, some vendors +extended their baseband software with cryptographic signatures. Only +if the correct signature is present in a software update, the bootloader +program will accept the new software. + +However, there are more or less invasive hardware-related approaches in +circumventing those signature checks, such as hardware debugging +interfaces like JTAG, or replacing the external flash memory components. + +More recently, GSM chipset vendors introduced features such as +hardware-assisted software signature checks. In this case a master key +hash might be present in DBB-internal fuses, together with a +signature-verifying boot loader in DBB-internal mask ROM. As the root +of the chain of trust is moving deeper into the hardware, it becomes +more difficult for anyone to make software modifications to the DBB. + +Especially with tighter integration, where RAM and FLASH are no longer +present as discrete components but part of a multi-chip-package, the +number of options are becoming more limited. + +On the other hand, an ever more complex baseband software stack is +opening up many more options for exploiting software vulnerabilities. +Given the lack of a proper/modern operating system with privilege +separation and virtual memory, such exploits immediately give away +full access to all aspects of the respective DBB. + +\section{Personal rant on the closedness of the GSM industry} + +The GSM industry is one of the most closed areas of computing that I've +encountered so far. It is very hard to get any hard technical +information out of them. All they like to spread is high-level +marketing information, but they're very reluctant when it comes down to +hard technical facts on their products. + +If you want to build a phone, you need to buy a GSM chipset for your +product. There are only very few companies that offer such chipsets. +The classic suppliers are Infineon, Texas Instruments, ST/Ericsson, ADI +(now MediaTek) and Freescale. + +The GSM handset products they sell are not generally available and +distributed like other electronic components they manufacture. If you +need a Microcontroller/SoC, a power management IC, a Wifi or Bluetooth +chip, RFID reader ASIC, you simply approach the respective distributors +and order them. You get your samples directly from Digikey. + +This is impossible for GSM (or other cellphone) chipsets. For some +reason those chips are sold only to hand-picked manufacturers. If you +want to qualify, you have to subscribe to at least six-digit annual +purchasing quantities. And in order for them to believe you, you have +to cough up a significant NRE (non-refundable engineering fee). This +has been reported as high as a seven-digit US\$ amount and is to make +sure that even if you end up buying less chips than you indicate, the +chipset maker will still have your upfront NRE money and keep it. + +And if you buy your way into that select club of cellphone makers, what +you get from the chipset maker is typically not all too impressive +either. The documentation you get is incomplete, i.e. it alone would +not enable you as a cellphone maker to make any use of the hardware, +unless you license the software (drivers, GSM protocol stack, ...) from +the chipset maker, too. + +On the software side, most of the technologically interesting bits (like +the protocol stack) are provided as binary-only libraries, you only get +source code to some parts of the systems, i.e. some hardware drivers +that might need modification for your particular phone electrical +design. + +That GSM protocol stack was not written by the chipset maker either. +They simply license a stack from one of the estimated 4 or 5 +organizations who have ever implemented a commercial GSM protocol stack. + +It is not like the GSM protocols were some kind of military secret. +They are a published international standard, freely accessible for +anyone. So why does everybody in that industry think that there is +a need to be so secretive? + +Having spent a significant part of the last 6 years with reverse +engineering of various aspects of mobile phones in order to understand +them better and to write software tools for security analysis, I still +don't understand this secrecy. + +All the various vendors do more or less the same. The fundamental +architecture of a GSM baseband chip is the same, whether you buy it from +TI, Infineon or from MediaTek. {\em They all cook with water}, like we +Germans tend to say. The details like the particular DSP vendor or +whether you use a traditional IF, zero-IF or low-IF analog baseband +differ. But from whom do they want to hide it? If people like myself +with a personal interest in the technical aspects of mobile phones can +figure it out in a relatively short time, then I'm sure the competition +of those chipset makers can, too. In much less time, if they actually +care. + +This closedness of the cellular industry is one of the reasons why there +has been very little innovation in the baseband firmware throughout the +last decades. Innovation can only happen by very few players. Source +code bugs can only be found and fixed by very few developers at even +fewer large corporations. There is little to no chance for a small start-up to +innovate, like they can in the sphere of the internet. + +It is fundamentally also the reason why the traditional phone makers +have been losing market share to newcomers to the mobile sphere like +Apple with its iPhone or Google with its Android platform. + +Those innovations really only happened on the application processor on +high-end smartphones. The closed GSM baseband processor had to be +accompanied by an independent application processor running a real +operating system, with real processes, memory management, shared +libraries, memory protection, virtual memory spaces, user-installable +applications, etc. + +They still don't happen on the baseband processor, which is as closed as +it was 15 years ago. + +\end{document} diff --git a/2010/openbsc-elce2010/bts_tree_full.jpg b/2010/openbsc-elce2010/bts_tree_full.jpg Binary files differnew file mode 100644 index 0000000..6b5c5e8 --- /dev/null +++ b/2010/openbsc-elce2010/bts_tree_full.jpg diff --git a/2010/openbsc-elce2010/c123_pcb.jpg b/2010/openbsc-elce2010/c123_pcb.jpg Binary files differnew file mode 100644 index 0000000..a9f24fc --- /dev/null +++ b/2010/openbsc-elce2010/c123_pcb.jpg diff --git a/2010/openbsc-elce2010/calypso-block.pdf b/2010/openbsc-elce2010/calypso-block.pdf Binary files differnew file mode 100644 index 0000000..27f8be8 --- /dev/null +++ b/2010/openbsc-elce2010/calypso-block.pdf diff --git a/2010/openbsc-elce2010/gsm_network.png b/2010/openbsc-elce2010/gsm_network.png Binary files differnew file mode 100644 index 0000000..c5f6399 --- /dev/null +++ b/2010/openbsc-elce2010/gsm_network.png diff --git a/2010/openbsc-elce2010/openbsc.pdf b/2010/openbsc-elce2010/openbsc.pdf Binary files differnew file mode 100644 index 0000000..6e824cb --- /dev/null +++ b/2010/openbsc-elce2010/openbsc.pdf diff --git a/2010/openbsc-elce2010/openbsc.snm b/2010/openbsc-elce2010/openbsc.snm new file mode 100644 index 0000000..e69de29 --- /dev/null +++ b/2010/openbsc-elce2010/openbsc.snm diff --git a/2010/openbsc-elce2010/openbsc.tex b/2010/openbsc-elce2010/openbsc.tex new file mode 100644 index 0000000..b387895 --- /dev/null +++ b/2010/openbsc-elce2010/openbsc.tex @@ -0,0 +1,451 @@ +% $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} +\usepackage{subfigure} +\usepackage{hyperref} +% 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{Free Software GSM protocol stacks} + +\subtitle +{OpenBSC, OsmoSGSN, OpenGGSN, OsmocomBB} + +\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[ELCE 2010] % (optional, should be abbreviation of conference name) +{ELCE 2010, October 2010, Cambridge/UK} +% - 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 + % 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 security} + +\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 Network planning / deployment / servicing + \item Even Billing! + \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} + +\begin{frame}{GSM is more than phone calls} +Listening to phone calls is boring... +\begin{itemize} + \item Machine-to-Machine (M2M) communication + \begin{itemize} + \item BMW can unlock/open your car via GSM + \item Alarm systems often report via GSM + \item Smart Metering (Utility companies) + \item GSM-R / European Train Control System + \item Vending machines report that their cash box is full + \item Control if wind-mills supply power into the grid + \item Transaction numbers for electronic banking + \end{itemize} +\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}{The closed GSM industry}{My self-proclaimed mission} +Mission: Bring TCP/IP/Internet security knowledge to GSM +\begin{itemize} + \item Create tools to enable independent/public IT Security community to examine GSM + \item Try to close the estimated 10 year gap between the state of security technology on the Internet vs. GSM networks + \begin{itemize} + \item Industry thinks in terms of {\em walled garden} and {\em phones behaving like specified} + \item No proper incident response strategies! + \item No packet filters, firewalls, intrusion detection on GSM protocol level + \item General public assumes GSM networks are safer than Internet + \end{itemize} +\end{itemize} +\end{frame} + +\begin{frame}{The closed GSM industry}{Areas of interest for Security research} +\begin{itemize} + \item Specification problems + \begin{itemize} + \item Encryption optional, weak and only on the Um interface + \item Lack of mutual authentication + \item Silent calls for pin-pointing a phone + \item RRLP and SUPL to obtain GPS coordinates of phone + \end{itemize} + \item Implementation problems + \begin{itemize} + \item TMSI information leak on network change + \item TLV parsers that have never seen invalid packets + \item Obscure options in spec lead to rarely-tested/used code paths + \end{itemize} + \item Operation problems + \begin{itemize} + \item VLR overflow leading to paging-by-IMSI + \item TMSI re-allocation too infrequent + \item Networks/Cells without frequency hopping + \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 BTS equipment is available, much easier/faster progress + \end{itemize} + \item Result: Started project OpenBSC in 10/2008 +\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 Publicly known attempts (12/2009) + \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 have been successful + \item Result: Started project OsmocomBB in 01/2010 + \end{itemize} +\end{itemize} +\end{frame} + + +\begin{frame}{Security analysis of GSM}{The bootstrapping process} +\begin{itemize} + \item Start to read GSM specs (> 1000 PDF documents) + \item Gradually grow knowledge about the protocols + \item Obtain actual GSM network equipment (BTS) + \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} + +\begin{frame}{GSM network protocols}{On the A-bis interface} + \begin{itemize} + \item Layer 1: Typically E1 line, TS 08.54 + \item Layer 2: A variant of ISDN LAPD with fixed TEI's, TS 08.56 + \item Layer 3: OML (Organization and Maintenance Layer, TS 12.21) + \item Layer 3: RSL (Radio Signalling Link, TS 08.58) + \item Layer 4+: transparent messages that are sent to the MS via Um + \end{itemize} +\end{frame} + +\include{section-openbsc} + +\include{section-osmocombb} + +\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 Frem a FOSS controlled phone to the network (OsmocomBB) + \item From an A-bis proxy to the network or the phones + \end{itemize} +\end{itemize} +\end{frame} + +\subsection{Where we go from here} + +\begin{frame}{TODO}{Where we go from here} +\begin{itemize} + \item The tools for fuzzing mobile phone protocol stacks are available + \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{Where we go from here} + +\begin{frame}{Current Areas of Work / Future plans} +\begin{itemize} + \item UMTS(3G) support for NodeB and femtocells + \item SS7 / MAP integration + \item Playing with SIM Toolkit from the operator side + \item Playing with MMS + \item More exploration of RRLP + SUPL +\end{itemize} +\end{frame} + +\subsection{Further Reading} + +\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} diff --git a/2010/openbsc-elce2010/openbsc_host.jpg b/2010/openbsc-elce2010/openbsc_host.jpg Binary files differnew file mode 100644 index 0000000..10c575d --- /dev/null +++ b/2010/openbsc-elce2010/openbsc_host.jpg diff --git a/2010/openbsc-elce2010/proposal.txt b/2010/openbsc-elce2010/proposal.txt new file mode 100644 index 0000000..c8ebd75 --- /dev/null +++ b/2010/openbsc-elce2010/proposal.txt @@ -0,0 +1,31 @@ +Presentation Proposal for ELCE 2010 + +Name of Presenter: Harald Welte <laforge@gnumonks.org> + +Title: Running your own GSM+GPRS network using OpenBSC, OsmoSGSN and OpenGGSN + +Presentation may be published: Yes +Presentation may be video-recorded + published: Yes + +Brief Abstract: + +Considering how ubiquitous Free Software is in the area of Internet networking +is, there has been surprisingly little Free Software in the area of GSM standards +based cellular networking. In the last two years, project OpenBSC was developed +to change this. It implements the neccessarry signalling protocol stack and +provide a miniature "GSM network in a box" application for small networks, +replacing traditional BSC, MSC, HLR, EIR and SMSC. + +Using the recently-developed OsmoSGSN and the existing OpenGGSN software, this +GSM network can be extended by the neccessarry components to also provide +packet-switched data services like GPRS and EDGE(EGPRS). + +The presentation will introduce the software architecture and give a +practical demonstration. + + +Misc Notes: + +The demonstration requires an experimental/test license from the UK regulatory +body OFCOM. I will provide all neccessary technical data to acquire this +license. diff --git a/2010/openbsc-elce2010/section-openbsc.tex b/2010/openbsc-elce2010/section-openbsc.tex new file mode 100644 index 0000000..17e3065 --- /dev/null +++ b/2010/openbsc-elce2010/section-openbsc.tex @@ -0,0 +1,202 @@ +\section{OpenBSC} + +\subsection{OpenBSC Introduction} + +\begin{frame}{OpenBSC software} +OpenBSC is a Open Source implementation of (not only) the BSC features +of a GSM network. +\begin{itemize} + \item Support A-bis interface over E1 and IP + \item Support for BTS vendor/model is modular, currently Siemens BS-11 and ip.access nanoBTS + \item Multiple BTS models/vendorrs can be mixed! + \item Can work as a {\em pure BSC} or as a full {\em network in a box} + \item Supports mobility management, authentication, intra-BSC hand-over, SMS, voice calls (FR/EFR/AMR) + \item GPRS + EDGE support if combined with OsmoSGSN and OpenGGSN +\end{itemize} +\end{frame} + +\begin{frame}{OpenBSC} +\begin{itemize} + \item Supports Siemens BS-11 BTS (E1) and ip.access nanoBTS (IP based) + \item Has classic 2G signalling, voice and SMS support + \item Implements various GSM protocols like + \begin{itemize} + \item A-bis RSL (TS 08.58) and OML (TS 12.21) + \item TS 04.08 Radio Resource, Mobility Management, Call Control + \item TS 04.11 Short Message Service + \end{itemize} + \item Telnet console with Cisco-style interface +\end{itemize} +\end{frame} + +\begin{frame}{OpenBSC software architecture} +\begin{itemize} + \item Implemented in pure C, similarities to Linux kernel + \begin{itemize} + \item Linked List handling, Timer API, coding style + \end{itemize} + \item Single-threaded event-loop / state machine design + \item Telnet based command line interface {\em Cisco-style} + \item Input driver abstraction (mISDN, Abis-over-IP) +\end{itemize} +\end{frame} + +\begin{frame}{OpenBSC: GSM network protocols}{The A-bis interface} + \begin{description}[Layer 4+] + \item[Layer 1] Typically E1 line, TS 08.54 + \item[Layer 2] A variant of ISDN LAPD with fixed TEI's, TS 08.56 + \item[Layer 3] OML (Organization and Maintenance Layer, TS 12.21) + \item[Layer 3] RSL (Radio Signalling Link, TS 08.58) + \item[Layer 4+] transparent messages that are sent to the MS via Um + \end{description} +\end{frame} + +\begin{frame}{OpenBSC: How it all started} +\begin{itemize} + \item In 2006, I bought a Siemens BS-11 microBTS on eBay + \begin{itemize} + \item This is GSM900 BTS with 2 TRX at 2W output power (each) + \item A 48kg monster with attached antenna + \item 200W power consumption, passive cooling + \item E1 physical interface + \end{itemize} + \item I didn't have much time at the time (day job at Openmoko) + \item Started to read up on GSM specs whenever I could + \item Bought a HFC-E1 based PCI E1 controller, has mISDN kernel support + \item Found somebody in the GSM industry who provided protocol traces +\end{itemize} +\end{frame} + +\begin{frame}{OpenBSC: Timeline} +\begin{itemize} + \item November 2008: I started the development of OpenBSC + \item December 2008: we did a first demo at 25C3 + \item January 2009: we had full voice call support + \item Q1/2009: Add support for ip.access nanoBTS + \item June 2009: I started with actual security related stuff + \item August 2009: We had the first field test with 2BTS and > 860 phones + \item Q1/2010: The first 25 OpenBSC instances running in a commercial network +\end{itemize} +\end{frame} + +\begin{frame}{OpenBSC: Field Test at HAR2009} +\begin{figure}[h] +\subfigure{\includegraphics[width=5cm]{bts_tree_full.jpg}} +\subfigure{\includegraphics[width=5cm]{openbsc_host.jpg}} +\end{figure} +\end{frame} + + +\subsection{OpenBSC Network In The Box} + +\begin{frame}{OpenBSC in NITB mode}{Network In a Box Mode} +The {\tt bsc\_hack} program +\begin{itemize} + \item implements the A-bis interface towards any number of BTS + \item provides most typical features of a GSM network in one software + \item no need for MSC, AuC, HLR, VLR, EIR, ... + \begin{itemize} + \item HLR/VLR as SQLite3 table + \item Authentication + Ciphering support + \item GSM voice calls, MO/MT SMS + \item Hand-over between all BTS + \item Multiple Location Areas within one BSC + \end{itemize} +\end{itemize} +\end{frame} + +\begin{frame}{OpenBSC NITB features} +OpenBSC NITB features +\begin{itemize} + \item Run a small GSM network with 1-n BTS and OpenBSC + \item No need for MSC/HLR/AUC/... + \item No need for your own SIM cards (unless crypto/auth rqd) + \item Establish signalling and voice channels + \item Make incoming and outgoing voice calls between phones + \item Send/receive SMS between phones + \item Connect to ISDN PBX or public ISDN via Linux Call Router +\end{itemize} +\end{frame} + +\begin{frame}{OpenBSC in NITB mode}{Network In a Box Mode} +The {\tt bsc\_hack} program +\begin{itemize} + \item does not implement any other GSM interfaces apart from A-bis + \item no SS7 / TCAP / MAP based protocols + \item no integration (roaming) with existing traditional GSM networks + \item wired telephony interfacing with ISDN PBX {\tt lcr} (Linux Call Router) + \item Has been tested with up to 800 subscribers on 5 BTS + \item Intended for R\&D use or private PBX systems +\end{itemize} +\end{frame} + +\begin{frame}{OpenBSC LCR integration}{Interfacing with wired telephony} +OpenBSC (NITB mode) can be linked into Linux Call Router ({\tt lcr}) +\begin{itemize} + \item OpenBSC is compiled as libbsc.a + \item libbsc.a includes full OpenBSC NITB mod code + \item linking the library into {\tt lcr} results in GSM {\em line interfaces} to become available inside {\tt lcr} + \item OpenBSC no longer takes care of call control, but simply hands everything off to {\tt lcr} + \item Dialling plan, etc. is now configure in {\tt lcr} like for any other wired phones +\end{itemize} +\end{frame} + +\subsection{OpenBSC BSC-only mode} + +\begin{frame}{OpenBSC in BSC-only mode} +The {\tt osmo-bsc} program +\begin{itemize} + \item behaves like a classic GSM BSC + \item uses SCCP-Lite (ip.access multipex) to any SoftMSC like ADC + \item used in production/commercial deployments (~ 75 BSCs) + \item mainly intended to replace proprietary BSC in traditional GSM networks +\end{itemize} +\end{frame} + +%\begin{frame}<handout:0>{OpenBSC} +% Demonstration +%\end{frame} + +\subsection{OpenBSC GPRS support} + +\begin{frame}{GPRS and OpenBSC} +\begin{itemize} + \item The BSC doesn't really do anything related to GPRS + \item GPRS implemented in separate SGSN and GGSN nodes + \item GPRS uses its own Gb interface to RAN, independent of A-bis + \item OpenBSC can configure the nanoBTS for GPRS+EDGE support via OML + \item Actual SGSN and GGSN implemented as OsmoSGSN and OpenGGSN programs +\end{itemize} +\end{frame} + +\begin{frame}{OsmoSGSN} +The Osmocom SGSN program implements +\begin{itemize} + \item basic/minimal SGSN functionality + \item the Gb interface (NS/BSSGP/LLC/SNDCP) + \item mobility management, session management +\end{itemize} +It's a work in progress, many missing features +\begin{itemize} + \item no HLR integration yet + \item no paging coordination with MSC/BSC + \item no encryption support yet +\end{itemize} +\end{frame} + +\begin{frame}{OpenGGSN} +\begin{itemize} + \item GPL licensed Linux program implementing GGSN node + \item Implements GTP-U protocol between SGSN and GGSN + \item User-configurable range/pool of IPv4 addresses for MS + \item Uses {\tt tun} device for terminating IP tunnel from MS + \item provides GTP implementation as libgtp + \item Experimental patches for IPv6 support +\end{itemize} +\end{frame} + +%\begin{frame}<handout:0>{OpenBSC + OpenGGSN + OsmoSGSN} +% Demonstration +%\end{frame} + +% FIXME: include slide showing full OpenBSC+OsmoSGSN+OpenGGSN network diff --git a/2010/openbsc-elce2010/section-osmocombb.tex b/2010/openbsc-elce2010/section-osmocombb.tex new file mode 100644 index 0000000..97b1939 --- /dev/null +++ b/2010/openbsc-elce2010/section-osmocombb.tex @@ -0,0 +1,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} diff --git a/2010/openbsc-sstic2010/gsm_network.png b/2010/openbsc-sstic2010/gsm_network.png Binary files differnew file mode 100644 index 0000000..c5f6399 --- /dev/null +++ b/2010/openbsc-sstic2010/gsm_network.png diff --git a/2010/openbsc-sstic2010/openbsc-abstract.txt b/2010/openbsc-sstic2010/openbsc-abstract.txt new file mode 100644 index 0000000..7ff5a28 --- /dev/null +++ b/2010/openbsc-sstic2010/openbsc-abstract.txt @@ -0,0 +1,23 @@ +OpenBSC: A tool for GSM protocol level security analysis of mobile phones + +By: Harald Welte[1] + +The OpenBSC project[2] is a Free Software implementation of the minimal +neccessarry elements to operate a GSM network. It includes the functionality +typically performed by the Base Station Controller (BSC), Mobile Switching +Center (MSC), Home Location Register (HLR), SMS Switching Center (SMSC) and +others. Using OpenBSC and a commercially available BTS (Base Transceiver +Station), it is possible to operate a completely indpendent GSM network. + +Running your own GSM network will enable you to take full control over +every protocol message that is exchanged with the mobile phone. Suddenly, +it is possible to send arbitrarily crafted and corrupted messages to the +various layers of the GSM protocol stack inside the phone. Attacks can +be performed that so far only cellphone manufacturers or network operators +could implement. + +In 2010, it is finally time for GSM mobile phones to see the kind of +protocol-level attacks that TCP/IP has seen at least a decade ago. + +[1] http://laforge.gnumonks.org/ +[2] http://openbsc.gnumonks.org/ diff --git a/2010/openbsc-sstic2010/openbsc.pdf b/2010/openbsc-sstic2010/openbsc.pdf Binary files differnew file mode 100644 index 0000000..d959319 --- /dev/null +++ b/2010/openbsc-sstic2010/openbsc.pdf diff --git a/2010/openbsc-sstic2010/openbsc.snm b/2010/openbsc-sstic2010/openbsc.snm new file mode 100644 index 0000000..e69de29 --- /dev/null +++ b/2010/openbsc-sstic2010/openbsc.snm diff --git a/2010/openbsc-sstic2010/openbsc.tex b/2010/openbsc-sstic2010/openbsc.tex new file mode 100644 index 0000000..fe41e1c --- /dev/null +++ b/2010/openbsc-sstic2010/openbsc.tex @@ -0,0 +1,638 @@ +% $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{OpenBSC network-side GSM stack} + +\subtitle +{A tool for GSM protocol level 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[SSTIC 2010] % (optional, should be abbreviation of conference name) +{SSTIC 2010, June 2010, Rennes/France} +% - 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 + % 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 security} + +\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 Network planning / deployment / servicing + \item Even Billing! + \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} + +\begin{frame}{GSM is more than phone calls} +Listening to phone calls is boring... +\begin{itemize} + \item Machine-to-Machine (M2M) communication + \begin{itemize} + \item BMW can unlock/open your car via GSM + \item Alarm systems often report via GSM + \item Smart Metering (Utility companies) + \item GSM-R / European Train Control System + \item Vending machines report that their cash box is full + \item Control if wind-mills supply power into the grid + \item Transaction numbers for electronic banking + \end{itemize} +\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}{The closed GSM industry}{My self-proclaimed mission} +Mission: Bring TCP/IP/Internet security knowledge to GSM +\begin{itemize} + \item Create tools to enable independent/public IT Security community to examine GSM + \item Try to close the estimated 10 year gap between the state of security technology on the Internet vs. GSM networks + \begin{itemize} + \item Industry thinks in terms of {\em walled garden} and {\em phones behaving like specified} + \item No proper incident response strategies! + \item No packet filters, firewalls, intrusion detection on GSM protocol level + \item General public assumes GSM networks are safer than Internet + \end{itemize} +\end{itemize} +\end{frame} + +\begin{frame}{The closed GSM industry}{Areas of interest for Security research} +\begin{itemize} + \item Specification problems + \begin{itemize} + \item Encryption optional, weak and only on the Um interface + \item Lack of mutual authentication + \item Silent calls for pin-pointing a phone + \item RRLP and SUPL to obtain GPS coordinates of phone + \end{itemize} + \item Implementation problems + \begin{itemize} + \item TMSI information leak on network change + \item TLV parsers that have never seen invalid packets + \item Obscure options in spec lead to rarely-tested/used code paths + \end{itemize} + \item Operation problems + \begin{itemize} + \item VLR overflow leading to paging-by-IMSI + \item TMSI re-allocation too infrequent + \item Networks/Cells without frequency hopping + \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 Publicly 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}{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 BTS equipment is available, much easier/faster progress + \end{itemize} +\end{itemize} +\end{frame} + +\begin{frame}{Security analysis of GSM}{The bootstrapping process} +\begin{itemize} + \item Read GSM specs (> 1000 PDF documents) ;) + \item Gradually grow knowledge about the protocols + \item Obtain actual GSM network equipment (BTS) + \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} + +\begin{frame}{GSM network protocols}{On the A-bis interface} + \begin{itemize} + \item Layer 1: Typically E1 line, TS 08.54 + \item Layer 2: A variant of ISDN LAPD with fixed TEI's, TS 08.56 + \item Layer 3: OML (Organization and Maintenance Layer, TS 12.21) + \item Layer 3: RSL (Radio Signalling Link, TS 08.58) + \item Layer 4+: transparent messages that are sent to the MS via Um + \end{itemize} +\end{frame} + + +\section{Implementing GSM protocols} + +\subsection{Getting started} + +\begin{frame}{Implementing GSM protocols}{How I got started!} +\begin{itemize} + \item In 2006 I bought an old BTS (Siemens BS-11) on eBay + \begin{itemize} + \item This is 48kg GSM900 BTS with 2 TRX at 2W output power (each) + \item I didn't have much time at the time (day job at Openmoko) + \item Started to read up on GSM specs whenever I could + \item Bought a HFC-E1 based PCI E1 controller, has mISDN kernel support + \item Found somebody in the GSM industry who provided protocol traces + \end{itemize} + \item In September 2008, we were first able to make the BTS active and see it on a phone +\end{itemize} +\end{frame} + +\subsection{Timeline} + +\begin{frame}{Implementing GSM protocols}{Timeline} +\begin{itemize} + \item November 2008: I started the development of OpenBSC + \item December 2008: we did a first demo at 25C3 + \item January 2009: we had full voice call support + \item Q1/2009: Add support for ip.access nanoBTS + \item June 2009: I started with actual security related stuff + \item August 2009: We had the first field test with 2BTS and > 860 phones + \item Q1/2010: The first 25 OpenBSC instances running in a commercial network +\end{itemize} +\end{frame} + +\subsection{OpenBSC} + +\begin{frame}{Security analysis of GSM}{OpenBSC} +What is OpenBSC +\begin{itemize} + \item A {\em GSM network in a box} software + \item Implements minimal subset of BSC, MSC, HLR, SMSC + \item Is Free and Open Source Software licensed under GNU GPL + \item Supports Siemens BS-11 BTS (E1) and ip.access nanoBTS (IP based) + \item Has classic 2G signalling, voice and SMS support + \item Implements various GSM protocols like + \begin{itemize} + \item A-bis RSL (TS 08.58) and OML (TS 12.21) + \item TS 04.08 Radio Resource, Mobility Management, Call Control + \item TS 04.11 Short Message Service + \end{itemize} +\end{itemize} +\end{frame} + +\begin{frame}{Security analysis of GSM}{OpenBSC} +OpenBSC features +\begin{itemize} + \item Run a small GSM network with 1-n BTS and OpenBSC + \item No need for MSC/HLR/AUC/... + \item No need for your own SIM cards + \item Establish signalling channels + \item Make incoming and outgoing voice calls between phones + \item Send/receive SMS between phones + \item Connect to ISDN PBX or public ISDN via Linux Call Router + \item Telnet console with Cisco-style interface +\end{itemize} +\end{frame} + +\section{Security analysis} + +\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{Observations} + +\begin{frame}{Interesting observations}{Learned from implementing the stack} +While developing OpenBSC, we observed a number of interesting +\begin{itemize} + \item Many phones use their TMSI from the old network when they roam to a new network + \item Various phones crash when confronted with incorrect messages. We didn't even start to intentionally send incorrect messages (!) + \item There are tons of obscure options on the GSM spec which no real network uses. Potential attack vector by using rarely tested code paths. +\end{itemize} +\end{frame} + +\subsection{GSM Protocol Fuzzing} + +\begin{frame}{GSM Protocol Fuzzing}{Theoretical basis} +How to do GSM protocol fuzzing +\begin{itemize} + \item From the handset to the network + \begin{itemize} + \item Basically impossible due to closeness of baseband + \item However, some incomplete projects working on it + \end{itemize} + \item From the network side + \begin{itemize} + \item Easy in case of {\em rogue network} attacks + \item Fuzzing target is the GSM stack in the baseband processor + \end{itemize} + \item As an A-bis man in the middle + \begin{itemize} + \item Needs access to an A-bis interface of an actual network + \item Very attractive, since no encryption and ability to fuzz both network and handset + \end{itemize} +\end{itemize} +\end{frame} + +\begin{frame}{A-bis injection}{for A-bis over IP} +How to do inject messages into A-bis over IP? +\begin{itemize} + \item Problem + \begin{itemize} + \item A-bis/IP uses one TCP connection for OML and RSL messages + \item OML initialization is essential for BTS to become operational + \item TCP makes insertion of additional messages relatively hard + \end{itemize} + \item Solution: Build an {\em A-bis injection proxy} + \begin{itemize} + \item Transparently pass OML and RSL packets between BTS and BSC + \item Add additional stateless UDP sockets for injecting messages, one socket each for + \end{itemize} + \begin{itemize} + \item injecting OML/RSL to the network + \item injecting OML/RSL to the BTS + \end{itemize} +\end{itemize} +\end{frame} + +\begin{frame}{A-bis Injection Proxy}{Principle of operation} +\begin{itemize} + \item Proxy needs to be brought between BTS and BSC + \item Luckily, A-bis/IP SSL support not always used + \item Thus, physical access to the Ethernet link sufficient + \item Configure system with two interfaces + \begin{itemize} + \item BSC-facing interface has IP of BTS + \item BTS-facing interface has IP of BSC / default gw + \end{itemize} + \item BTS will make TCP connection to proxy + \item proxy will make independent TCP connection to BSC +\end{itemize} +\end{frame} + +\begin{frame}{scapy GSM support}{The actual fuzzing} +How to actually craft the packets for the fuzzing +\begin{itemize} + \item GSM has many, many protocols + \item Writing custom code will be a hard-coded special case for each of them + \item Solution: Use scapy and implement the GSM protocols as scapy {\em Layers} + \begin{itemize} + \item IPA protocol header + \item RSL protocol layer + \item RLL data indication / data request + \item GSM 04.08 RR / MM / CC messages + \end{itemize} +\end{itemize} +\end{frame} + +\begin{frame}{OpenBSC silent calls}{A more elegant fuzzing interface} +\begin{itemize} + \item Injection at the A-bis level has many problems + \begin{itemize} + \item you can only do it while a call is active + \item you simply piggy-back on existing RR connections + \end{itemize} + \item The OpenBSC {\em silent call} feature can help + \begin{itemize} + \item we use OpenBSC to establish a RR connection + \item in the GSM master/slave model, the phone will not close a connection unless told to do so + \item we then send arbitrary data to the phone and receive its responses + \item this currently only works from within OpenBSC, but we'll provide UDP injection sockets soon + \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 + \end{itemize} +\end{itemize} +\end{frame} + +\subsection{Where we go from here} + +\begin{frame}{TODO}{Where we go from here} +\begin{itemize} + \item The tools for fuzzing mobile phone protocol stacks are available + \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{Where we go from here} + +\begin{frame}{Current Areas of Work / Future plans} +\begin{itemize} + \item OsmoSGSN/OpenGGSN: Packet data (GPRS/EDGE) support + \begin{itemize} + \item GPRS/EDGE is used extensively on modern smartphones + \item Enables us to play on IP level with those phones without a heavily filtered operator network + \item Status: Already functional, but very fragile/incomplete. 1-2 more months + \end{itemize} + \item UMTS(3G) support in OpenBSC + \item Playing with SIM Toolkit from the operator side + \item Playing with MMS + \item More exploration of RRLP + SUPL +\end{itemize} +\end{frame} + +\subsection{Further Reading} + +\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} diff --git a/2010/opening_closed_domains-foi2010/opening_closed_domains.pdf b/2010/opening_closed_domains-foi2010/opening_closed_domains.pdf Binary files differnew file mode 100644 index 0000000..a8bd9f2 --- /dev/null +++ b/2010/opening_closed_domains-foi2010/opening_closed_domains.pdf diff --git a/2010/opening_closed_domains-foi2010/opening_closed_domains.snm b/2010/opening_closed_domains-foi2010/opening_closed_domains.snm new file mode 100644 index 0000000..e69de29 --- /dev/null +++ b/2010/opening_closed_domains-foi2010/opening_closed_domains.snm diff --git a/2010/opening_closed_domains-foi2010/opening_closed_domains.tex b/2010/opening_closed_domains-foi2010/opening_closed_domains.tex new file mode 100644 index 0000000..11182de --- /dev/null +++ b/2010/opening_closed_domains-foi2010/opening_closed_domains.tex @@ -0,0 +1,613 @@ +% $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} + +% 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{Opening Closed Domains} + +\subtitle +{To boldly go where no Free Software has gone before} + +\author{Harald Welte} + +\institute +{gnumonks.org\\gpl-violations.org\\hmw-consulting.de\\OpenPCD, OpenMoko, OpenBSC, airprobe, OsmocomBB} +% - Use the \inst command only if there are several affiliations. +% - Keep it simple, no one is interested in your street address. + +\date[FOI/2010] % (optional, should be abbreviation of conference name) +{FOI, May 2010, Varazdin/Croatia} +% - 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{Free Software} +% 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 + % 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 specialist, focus on network protocol security + \item Some board-level Electrical Engineering + \item Expert on Free Software licensing (gpl-violations.org) +\end{itemize} +\end{frame} + +\section{The FOSS success story} + +\subsection{FOSS is successful} + +\begin{frame}{FOSS is successful} +Free and Open Source Software is successful +\begin{itemize} + \item As a general purpose Operating System + \item In the Internet and Intranet server market, data centers + \item Networking infrastructure (routers, switches, WiFi AP) + \item Workstation / Desktop Market + \item Now Netbooks and MID's +\end{itemize} +Common denominator: (Inter)networked device +\end{frame} + +\begin{frame}{Linux/FOSS and the Internet} +\begin{itemize} + \item Imagine the state of the Linux kernel or other FOSS community without the Internet + \item Imagine working on a FOSS project without Internet access + \item Imagine even using a typical Linux system without Internet access (apt-get / yum / ...) +\end{itemize} +Thus, the current state of FOSS cannot be explained without the success of the Internet as communication and distribution medium. +\end{frame} + + +\begin{frame}{Why FOSS?} + +\begin{itemize} + \item Education + \begin{itemize} + \item Learning by reading the source code + \end{itemize} + \pause + \item Security + \begin{itemize} + \item Review the source for back-doors, exploitable bugs, ... + \end{itemize} + \pause + \item Modification + \begin{itemize} + \item Experiments, Rapid prototyping, test of new ideas + \end{itemize} + \pause + \item Research possible for anyone + \pause + \item No vendor lock-in +\end{itemize} +\end{frame} + +\begin{frame}{So everything is great?} +\begin{itemize} + \item We have multiple FOSS OS kernels + \item We have thousands of FOSS application programs + \item But: Many areas of computing typically have no FOSS at all, e.g. + \begin{itemize} + \item RFID protocols + \item DECT protocols + \item GSM/UMTS/CDMA protocols + \end{itemize} + \item Why those three examples? + \begin{itemize} + \item communications infrastructure is vital for everyone + \item big interest in verifiable/auditable privacy and security + \end{itemize} +\end{itemize} +\end{frame} + +\subsection{Why no FOSS in RFID, DECT and GSM} + +\begin{frame}{Why do you think there no FOSS?}{In RFID DECT and GSM} +\begin{itemize} + \item No Open specifications for the protocols? + \pause + \begin{itemize} + \item WRONG: They're all publicly available to anyone + \end{itemize} + \pause + \item Too close to the hardware for FOSS developers + \pause + \begin{itemize} + \item WRONG: Look at FOSS softmac WiFi drivers + \end{itemize} + \pause + \item Hardware comes without specs + \pause + \begin{itemize} + \item TRUE, but look at reverse engineered 3D drivers + \end{itemize} + \pause + \item Too complex for FOSS developers + \pause + \begin{itemize} + \item WRONG, look at image processing or a TCP/IP protocol stack + \end{itemize} +\end{itemize} +\end{frame} + +\begin{frame}{Why there really is no FOSS?}{In RFID DECT and GSM} +\begin{itemize} + \item RFID, DECT and GSM are hardware industry dominated areas + \begin{itemize} + \item If you think the software industry took 10-15 years to realize the benefits of FOSS, try to imagine how long it will take the hardware and semiconductor industry + \end{itemize} + \item Semiconductor industry actively keeping customers out and ensure their own turf is as big as possible + \item Chicken-and-egg Problem + \begin{itemize} + \item Too little people know about the protocol + \item Too little people are able to work on FOSS for it + \item Too little FOSS in that area + \item Nobody can experiment with / learn from FOSS -> Too little people know about the protocol + \end{itemize} +\end{itemize} +\end{frame} + +\begin{frame}{Why did I care?} +\begin{itemize} + \item because I use cordless phones, cell-phones and RFID + \item because I know and am used to the benefits of FOSS for 15 years + \item because I don't see why I should give up that freedom when leaving the PC world +\end{itemize} +\end{frame} + +\begin{frame}{What could be done about that?} +\begin{itemize} + \item Tackle those cases, one by one + \item Even a single person or a small group of people can make a huge difference + \item None of the projects that were started to change this involved more than a handful of people + \item There are no limits other than those of your mind! +\end{itemize} +\end{frame} + + +\section{Case studies} + +\subsection{RFID} + +\begin{frame}{Why my interest in RFID?} +\begin{itemize} + \item In November 2005, the German federal government has started to issue electronic passports with RFID interface. + \item All other EU member states were mandated to start issuing such passports no later than January 2007 + \item Passports with RF interface raise lots of security questions + \begin{itemize} + \item Can you track/identify a person? + \item Can you determine his nationality? + \item Is the crypto used sufficient to prevent forgeries? + \end{itemize} + \item Thus, in 2005 I realized: FOSS for RFID protocol + ePassport application is needed +\end{itemize} +\end{frame} + +\begin{frame}{RFID products}{commercially available readers} +\begin{itemize} + \item There are many RFID readers, some even with Linux drivers + \item All the protocol logic typically happens inside reader firmware + \item Application programmer presented with high-level API (PC/SC) + \item No way of doing actual practical protocol-level security research +\end{itemize} +\end{frame} + +\begin{frame}{RFID products}{Semiconductors} +\begin{itemize} + \item Inside a reader, you need to somehow implement the radio layer + \item Typically, for mass-produced products, you use integrated circuits + \item The early RFID ASICs were dumb transceivers with no protocol logic + \item ASIC Documentation for NXP RC5xx {\em almost} openly available as 40-bit {\em encrypted} PDF + \item Some readers export those ASIC registers to PC software and run protocol stack in proprietary software +\end{itemize} +\end{frame} + +\begin{frame}{Project librfid} +\begin{itemize} + \item Project librfid was born + \item The first FOSS protocol stack for RFID protocols + \begin{itemize} + \item ISO 14443-1,2,3,4 (specification public) + \item ISO 15693 (specification public) + \item Mifare Classic (vendor-specific proprietary system) + \end{itemize} + \item Mainly written by one person! +\end{itemize} +\end{frame} + +\begin{frame}{More FOSS for RFID}{OpenPCD} +OpenPCD +\begin{itemize} + \item Project OpenPCD developed an open hardware RFID reader + \item FOSS firmware, cross-compiled with avr-gcc, installed with FOSS flashing tools + \item librfid used as protocol stack either inside reader firmware or on host PC + \item R\&D done by three people! +\end{itemize} +OpenPICC +\begin{itemize} + \item Project OpenPICC developed an open hardware RFID simulator + \item R\&D by three people in their spare time! +\end{itemize} +\end{frame} + +\begin{frame}{More FOSS for RFID}{OpenPCD} +\begin{itemize} + \item Various groups started RFID security research on proprietary RFID standards + \begin{itemize} + \item Wrong security claims by RFID industry could be revealed as part of the Mifare Classic CRYPTO-1 reverse engineering in 2006 + \item Industry was forced to introduce and use components with higher security + \item Still, e-payment and access control systems all over the world rely on broken-by-design, proprietary and small-keysize Mifare Classic CRYPTO1. They deserve to be hacked, and the responsible IT managers deserve to be fired. + \item Watch 26C3 in four weeks: Yet another proprietary insecure system will die. + \end{itemize} +\end{itemize} +\end{frame} + +\subsection{DECT} + +\begin{frame}{DECT systems}{What they are} +\begin{itemize} + \item DECT means Digital European Cordless Telephony + \item Is a standard used in large parts of the world for cordless telephony + \item Standardized at the ETSI, documents available to everyone + \item Authentication and Encryption algorithms kept secret + \item Typically, all you can buy is a black-box appliance consisting of phone + base station +\end{itemize} +\end{frame} + +\begin{frame}{DECT beyond just simple cordless phones} +\begin{itemize} + \item DECT always supported the transmission of data, e.g. ISDN payloads + \item At some point, people wanted to use their DECT handset with VoIP + \item Companies started to sell PCMCIA, USB and PCI DECT adapters + \item DECT protocol stack is running inside proprietary windows software + \item DECT encryption implemented inside the DECT chipset silicon +\end{itemize} +\end{frame} + +\begin{frame}{First FOSS for DECT} +\begin{itemize} + \item In order to do research on DECT, Open Source is needed + \item Group (later called deDECTed.org) formed doing reverse engineering of windows drivers + \item Started to implement FOSS driver for the hardware and Receive-only processing of DECT protocol stack + \item Was used by cryptographers as a toolbox to demonstrate that the DECT Security is not worth the paper it is printed on + \begin{itemize} + \item Problems in the protocol specification + \item Problems in the implementations (16bit random numbers?!?) + \end{itemize} +\end{itemize} +\end{frame} + +\begin{frame}{More FOSS for DECT} +\begin{itemize} + \item Patrick McHardy (netfilter/iptables maintainer) starts a Linux kernel DECT stack + \item His experience in Linux kernel networking enables him to write a true Linux network stack for the DECT protocol + \item git://git.kernel.org/pub/scm/linux/kernel/git/kaber/dect-2.6.git + \item Written by one person! +\end{itemize} +\end{frame} + +\subsection{GSM} + +\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} + +\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 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}{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 + \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) + \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} + +\begin{frame}{OpenBSC}{A FOSS GSM protocol stack implementation} +\begin{itemize} + \item OpenBSC implements {\em GSM network in a box} + \begin{itemize} + \item BSC, MSC, HLR, AuC, ... + \item You can use a BTS + OpenBSC and run your own network + \end{itemize} + \item Commercial systems with same functionality sell for >~50,000 USD + \begin{itemize} + \item Did you also hear the rumors about 100-man-years intellectual property in a GSM stack? + \end{itemize} + \item Developed by three people in their spare time! +\end{itemize} +\end{frame} + +\begin{frame}{OpenBTS}{A different GSM protocol stack implementation} +\begin{itemize} + \item Open implementation of Um L1 \& L2, an all-software BTS. + \item L1/L2 design based on an object-oriented dataflow approach. + \item Includes L3 RR functions normally found in BSC. + \item Uses SIP PBX for MM and CC functions, eliminating the conventional GSM network. L3 is like an ISDN/SIP gateway. + \item Intended for use in low-cost and rapidly-deployed communications networks, but can be used for experiments. + \item Written by two people! +\end{itemize} +\end{frame} + +\begin{frame}{airprobe}{A GSM receiver / protocol analyzer} +\begin{itemize} + \item {\em airprobe} is a collection of Um protocol analyzer tools using the USRP software defined radio + \item A number of different Um receiver implementations + \begin{description}[gsm-receiver] + \item[gssm] One of the two early Um receiver implementations (M\&M clock recovery) + \item[gsmsp] The other early Um receiver implementation + \item[gsm-tvoid] For a long time the Um receiver with best performance + \item[gsm-receiver] The latest generation of Um receiver + \end{description} + \item Today, gsm-receiver seems to be the most popular choice +\end{itemize} +\end{frame} + +\begin{frame}{OsmocomBB}{A telephone-side GSM baseband firmware} +\begin{itemize} + \item {\em OsmocomBB} is a FOSS implementation of GSM protocols for the mobile phone + \item Implemented in portable C with drivers for one TI baseband chipset + \item Current features include + \begin{itemize} + \item Passive protocol-analysis and protocol sniffing + \item Determine operating parameters of any GSM network, including its cell configuration, use of encryption, use of TMSI, etc. + \item Transmit arbitrary data to any GMS cell/network + \end{itemize} + \item Will serve as foundation for security analysis tools for the GSM air interface +\end{itemize} +\end{frame} + + +\begin{frame}{What has GSM FOSS shown?} +\begin{itemize} + \item We can now do real-world demonstration of GSM weaknesses + \begin{itemize} + \item Lack of mutual authentication + \item Silent calls to turn phones into permanently transmitting beacons + \item RRLP to inquire the GPS fix of any phone + \end{itemize} + \item We can make people aware of the dangers those features have + \item Hopefully, public pressure will force the industry to change +\end{itemize} +\end{frame} + +\section{Summary} + +\subsection{What we've learned} + +\begin{frame}{Summary}{What we've learned} +\begin{itemize} + \item There are many areas which the benefits of FOSS have not yet reached + \item Nonetheless, those systems are used by billions of people every day + \item Without independent research, security flaws will never be removed + \item Small projects with few dedicated developers can make a huge impact +\end{itemize} +\end{frame} + +\subsection{Get involved!} + +\begin{frame}{Get involved!} +\begin{itemize} + \item Boldly go where no (FOSS) man has gone before + \item Don't be deterred by people who say it's impossible + \item What are you waiting for? + \item Would you rather become the worlds 10,000th application security expert or the worlds 100th GSM protocol security expert? + \item Help us to get some sense into the semiconductor industry. +\end{itemize} +\end{frame} + +\subsection{Knowledge is power} + +\begin{frame}{Knowledge is power} +\begin{itemize} + \item Educate yourself + \item Never underestimate {\em learning by doing} + \item Educate others about + \begin{itemize} + \item How every-day technology like cellphones really work + \item What is the true security and privacy level of those systems + \end{itemize} +\end{itemize} +\end{frame} + +\begin{frame}{Where to go?}{Areas that need openness} +\begin{itemize} + \item 3G (UMTS) protocol stack + \item GSM telephone side GSM stack + \item What about DAB, DMB-T + \item DVB-S encapsulated Internet downlink + \item TETRA being deployed in multiple European countries + \item CDMA / CDMA2000 + \pause + \item ... and this is just in the communications protocol sector! +\end{itemize} +\end{frame} + +\end{document} diff --git a/2010/osmocombb-ccc2010/c123_pcb.jpg b/2010/osmocombb-ccc2010/c123_pcb.jpg Binary files differnew file mode 100644 index 0000000..a9f24fc --- /dev/null +++ b/2010/osmocombb-ccc2010/c123_pcb.jpg diff --git a/2010/osmocombb-ccc2010/calypso-block.pdf b/2010/osmocombb-ccc2010/calypso-block.pdf Binary files differnew file mode 100644 index 0000000..27f8be8 --- /dev/null +++ b/2010/osmocombb-ccc2010/calypso-block.pdf diff --git a/2010/osmocombb-ccc2010/gsm_network2.png b/2010/osmocombb-ccc2010/gsm_network2.png Binary files differnew file mode 100644 index 0000000..c4456b0 --- /dev/null +++ b/2010/osmocombb-ccc2010/gsm_network2.png diff --git a/2010/osmocombb-ccc2010/osmocombb-security.pdf b/2010/osmocombb-ccc2010/osmocombb-security.pdf Binary files differnew file mode 100644 index 0000000..334af31 --- /dev/null +++ b/2010/osmocombb-ccc2010/osmocombb-security.pdf diff --git a/2010/osmocombb-ccc2010/osmocombb-security.snm b/2010/osmocombb-ccc2010/osmocombb-security.snm new file mode 100644 index 0000000..e69de29 --- /dev/null +++ b/2010/osmocombb-ccc2010/osmocombb-security.snm diff --git a/2010/osmocombb-ccc2010/osmocombb-security.tex b/2010/osmocombb-ccc2010/osmocombb-security.tex new file mode 100644 index 0000000..47926dd --- /dev/null +++ b/2010/osmocombb-ccc2010/osmocombb-security.tex @@ -0,0 +1,736 @@ +% $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 +{Running your own GSM stack on a phone} + +\author{Harald Welte and Steve Markgraf} + +\institute +{http://bb.osmocom.org/} +% - Use the \inst command only if there are several affiliations. +% - Keep it simple, no one is interested in your street address. + +\date[27c3] % (optional, should be abbreviation of conference name) +{27th CCC Congress, December 2010, Berlin/Germany} +% - 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. + +\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}{Source: Wikipedia, User Tsaitgaist, Licensed under GPLv3} + \begin{figure}[h] + \centering + \includegraphics[width=100mm]{gsm_network2.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} + +\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/Firmware} + +\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} + +\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 Layer1 + \begin{itemize} + \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} + +\subsection{OsmocomBB Apps} + +\begin{frame}{The {\tt mobile} app} +\begin{itemize} + \item implementation of a mobile phone + \begin{itemize} + \item cell (re)selection, mobility management + \item voice calls (only full rate) + \item SMS + \end{itemize} + \item both mobile originated and mobile terminated calls work + \item VTY (telnet) interface to configure and call control + \item optional interface to linux call router PBX +\end{itemize} +\end{frame} + +\begin{frame}{cell\_log} +The {\tt cell\_log} app +\begin{itemize} + \item scanning and logging application for cell beacon information + \item send RACH to all cells to get the timing advance (distance) + \item logs the GPS position of where the cell was found +\end{itemize} +\end{frame} + +\begin{frame}{gsmmap} +The {\tt gsmmap} app +\begin{itemize} + \item parses the logs generated by cell\_log + \item uses triangulation to calculate estimated cell position + \item exports a .kml file for Google Earth +\end{itemize} +\end{frame} + +\begin{frame}{bcch\_scan} +The {\tt bcch\_scan} app +\begin{itemize} + \item iterates over full spectrum and does power scan + \item tunes to ARFCN in order of received signal strength + \item acquires BCCHs and dumps all SYSTEM INFO to wireshark +\end{itemize} +\end{frame} + +\begin{frame}{cbch\_sniff} +The {\tt cbch\_sniff} app +\begin{itemize} + \item dumps cell broadcast messages to wireshark + \item some operators include GPS location of cell inside CB +\end{itemize} + +There are some more apps, mostly R\&D related. + +We are looking forward to {\bf your contribution}, e.g. the {\it scapy fuzzing +gateway app}. +\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 Freyther (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} diff --git a/2010/osmocombb-coscup2010/c123_pcb.jpg b/2010/osmocombb-coscup2010/c123_pcb.jpg Binary files differnew file mode 100644 index 0000000..a9f24fc --- /dev/null +++ b/2010/osmocombb-coscup2010/c123_pcb.jpg diff --git a/2010/osmocombb-coscup2010/calypso-block.pdf b/2010/osmocombb-coscup2010/calypso-block.pdf Binary files differnew file mode 100644 index 0000000..27f8be8 --- /dev/null +++ b/2010/osmocombb-coscup2010/calypso-block.pdf diff --git a/2010/osmocombb-coscup2010/gsm_network.png b/2010/osmocombb-coscup2010/gsm_network.png Binary files differnew file mode 100644 index 0000000..c5f6399 --- /dev/null +++ b/2010/osmocombb-coscup2010/gsm_network.png diff --git a/2010/osmocombb-coscup2010/osmocombb-security.pdf b/2010/osmocombb-coscup2010/osmocombb-security.pdf Binary files differnew file mode 100644 index 0000000..2433a3c --- /dev/null +++ b/2010/osmocombb-coscup2010/osmocombb-security.pdf diff --git a/2010/osmocombb-coscup2010/osmocombb-security.snm b/2010/osmocombb-coscup2010/osmocombb-security.snm new file mode 100644 index 0000000..e69de29 --- /dev/null +++ b/2010/osmocombb-coscup2010/osmocombb-security.snm diff --git a/2010/osmocombb-coscup2010/osmocombb-security.tex b/2010/osmocombb-coscup2010/osmocombb-security.tex new file mode 100644 index 0000000..568373b --- /dev/null +++ b/2010/osmocombb-coscup2010/osmocombb-security.tex @@ -0,0 +1,667 @@ +% $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 +{A Free Software GSM baseband firmware} + +\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[COSCUP 2010] % (optional, should be abbreviation of conference name) +{COSCUP 2010, August 2010, Taipei/Taiwan} +% - 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 in January 2010 + \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: Not working} +\begin{itemize} + \item Actual SIM card reader inside phone (WIP) + \item Layer1 + \begin{itemize} + \item Automatic Tx power control (APC) + \item Neighbor Cell Measurements + \item Traffic Channels (WIP) + \end{itemize} + \item Actual UI on the phone +\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 is currently being integrated + \begin{itemize} + \item Dieter Spaar and Andreas Eversberg have made a 20 minute call with current alpha code + \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}{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} diff --git a/2010/osmocombb-deepsec2010/abstract.txt b/2010/osmocombb-deepsec2010/abstract.txt new file mode 100644 index 0000000..84b900a --- /dev/null +++ b/2010/osmocombb-deepsec2010/abstract.txt @@ -0,0 +1,25 @@ +OsmocomBB: Protocol stack and baesband firmware for GSM mobile phones + +By: Harald Welte[1] + +The OsmocomBB project[2] is a Free Software implementation of the GSM +protocol stack running on a mobile phone. + +For decades, the cellular industry comprised by cellphone chipset makers and +network operators keep their hardware and system-level software as well as GSM +protocol stack implementations closed. As a result, it was never possible +to send arbitrary data at the lower levels of the GSM protocol stack. +Existing phones only allow application-level data to be user-supplied, such as +SMS messages, IP over GPRS or circuit-switched data (CSD). + +Using OsmocomBB, the Free Software enethusiast as well as the security +researcher finally has a tool equivalent to an Ethernet card in the TCP/IP +protocol world: A simple transceiver that will send arbitrary protocol +messages to a GSM network. + +By the time Linux Kongress 2010 is held, it is expected that OsmocomBB +has proceeded to a level where it can make actual phone calls on any +GSM network. + +[1] http://laforge.gnumonks.org/ +[2] http://bb.osmocom.org/ diff --git a/2010/osmocombb-deepsec2010/bio.txt b/2010/osmocombb-deepsec2010/bio.txt new file mode 100644 index 0000000..4168a1b --- /dev/null +++ b/2010/osmocombb-deepsec2010/bio.txt @@ -0,0 +1,25 @@ +Harald Welte is a freelancer, consultant, enthusiast, freedom fighter and +hacker who is working with Free Software (and particularly the Linux kernel) +since 1995. His first major code contribution to the kernel was within the +netfilter/iptables packet filter. + +He has started a number of other Free Software and Free Hardware projects, +mainly related to RFID such as librfid, OpenMRTD, OpenBeacon, OpenPCD, +OpenPICC. During 2006 and 2007 Harald became the co-founder of OpenMoko, where +he served as Lead System Architect for the worlds first 100% Open Free Software +based mobile phone. + +Aside from his technical contributions, Harald has been pioneering the legal +enforcement of the GNU GPL license as part of his gpl-violations.org project. +More than 150 inappropriate use of GPL licensed code by commercial companies +have been resolved as part of this effort, both in court and out of court. He +has received the 2007 "FSF Award for the Advancement of Free Software" and the +"2008 Google/O'Reilly Open Source award: Defender of Rights". + +In 2008, Harald started to work on Free Software on the GSM protocol side, both +for passive sniffing and protocol analysis, as well as an actual network-side +GSM stack implementation called OpenBSC. He is currently in the early design +phase for the hardware and software design of a Free Software based GSM +baseband side. + +He continues to operate his consulting business hmw-consulting. diff --git a/2010/osmocombb-deepsec2010/c123_pcb.jpg b/2010/osmocombb-deepsec2010/c123_pcb.jpg Binary files differnew file mode 100644 index 0000000..a9f24fc --- /dev/null +++ b/2010/osmocombb-deepsec2010/c123_pcb.jpg diff --git a/2010/osmocombb-deepsec2010/calypso-block.pdf b/2010/osmocombb-deepsec2010/calypso-block.pdf Binary files differnew file mode 100644 index 0000000..27f8be8 --- /dev/null +++ b/2010/osmocombb-deepsec2010/calypso-block.pdf diff --git a/2010/osmocombb-deepsec2010/gsm_network.png b/2010/osmocombb-deepsec2010/gsm_network.png Binary files differnew file mode 100644 index 0000000..c5f6399 --- /dev/null +++ b/2010/osmocombb-deepsec2010/gsm_network.png diff --git a/2010/osmocombb-deepsec2010/osmocombb-security.pdf b/2010/osmocombb-deepsec2010/osmocombb-security.pdf Binary files differnew file mode 100644 index 0000000..9dcfb42 --- /dev/null +++ b/2010/osmocombb-deepsec2010/osmocombb-security.pdf diff --git a/2010/osmocombb-deepsec2010/osmocombb-security.tex b/2010/osmocombb-deepsec2010/osmocombb-security.tex new file mode 100644 index 0000000..f83533f --- /dev/null +++ b/2010/osmocombb-deepsec2010/osmocombb-security.tex @@ -0,0 +1,697 @@ +% $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[DeepSec 2010] % (optional, should be abbreviation of conference name) +{DeepSec 2010, November 2010, Vienna/Austria} +% - 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 Layer1 + \begin{itemize} + \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} diff --git a/2010/osmocombb-elce2010/proposal.txt b/2010/osmocombb-elce2010/proposal.txt new file mode 100644 index 0000000..9fb9039 --- /dev/null +++ b/2010/osmocombb-elce2010/proposal.txt @@ -0,0 +1,25 @@ +Presentation Proposal for ELCE 2010 + +Name of Presenter: Harald Welte <laforge@gnumonks.org> + +Title: Implmementing a Free Software telephone-side GSM protocol stack + +Presentation may be published: Yes +Presentation may be video-recorded + published: Yes + +Brief Abstract: + +Recent years have seen a remarkable increase in Free Software running on +smartphones. However, all such software is designed to run on the Application +Processor (AP) only. The actual GSM protocol stack and RF Modem drivers are +running as firmware on a completely different processor: The Baseband Processor +(BP). + +OsmocomBB is a project developing the worlds first Free Software GSM protocol +stack for the mobile phone side. It includes the hardare drivers for one +particular GSM baseband processor chipset and replaces the vendor-provided +firmware on compatible chipsets/phones. + +The presentation will introduce the challenges of doing this development in +the environment of the arguably most closed part of the semiconductor industry, +describe the software architecture and give a practical demonstration. diff --git a/2010/osmocombb-hashdays2010/abstract.txt b/2010/osmocombb-hashdays2010/abstract.txt new file mode 100644 index 0000000..84b900a --- /dev/null +++ b/2010/osmocombb-hashdays2010/abstract.txt @@ -0,0 +1,25 @@ +OsmocomBB: Protocol stack and baesband firmware for GSM mobile phones + +By: Harald Welte[1] + +The OsmocomBB project[2] is a Free Software implementation of the GSM +protocol stack running on a mobile phone. + +For decades, the cellular industry comprised by cellphone chipset makers and +network operators keep their hardware and system-level software as well as GSM +protocol stack implementations closed. As a result, it was never possible +to send arbitrary data at the lower levels of the GSM protocol stack. +Existing phones only allow application-level data to be user-supplied, such as +SMS messages, IP over GPRS or circuit-switched data (CSD). + +Using OsmocomBB, the Free Software enethusiast as well as the security +researcher finally has a tool equivalent to an Ethernet card in the TCP/IP +protocol world: A simple transceiver that will send arbitrary protocol +messages to a GSM network. + +By the time Linux Kongress 2010 is held, it is expected that OsmocomBB +has proceeded to a level where it can make actual phone calls on any +GSM network. + +[1] http://laforge.gnumonks.org/ +[2] http://bb.osmocom.org/ diff --git a/2010/osmocombb-hashdays2010/bio.txt b/2010/osmocombb-hashdays2010/bio.txt new file mode 100644 index 0000000..4168a1b --- /dev/null +++ b/2010/osmocombb-hashdays2010/bio.txt @@ -0,0 +1,25 @@ +Harald Welte is a freelancer, consultant, enthusiast, freedom fighter and +hacker who is working with Free Software (and particularly the Linux kernel) +since 1995. His first major code contribution to the kernel was within the +netfilter/iptables packet filter. + +He has started a number of other Free Software and Free Hardware projects, +mainly related to RFID such as librfid, OpenMRTD, OpenBeacon, OpenPCD, +OpenPICC. During 2006 and 2007 Harald became the co-founder of OpenMoko, where +he served as Lead System Architect for the worlds first 100% Open Free Software +based mobile phone. + +Aside from his technical contributions, Harald has been pioneering the legal +enforcement of the GNU GPL license as part of his gpl-violations.org project. +More than 150 inappropriate use of GPL licensed code by commercial companies +have been resolved as part of this effort, both in court and out of court. He +has received the 2007 "FSF Award for the Advancement of Free Software" and the +"2008 Google/O'Reilly Open Source award: Defender of Rights". + +In 2008, Harald started to work on Free Software on the GSM protocol side, both +for passive sniffing and protocol analysis, as well as an actual network-side +GSM stack implementation called OpenBSC. He is currently in the early design +phase for the hardware and software design of a Free Software based GSM +baseband side. + +He continues to operate his consulting business hmw-consulting. diff --git a/2010/osmocombb-hashdays2010/c123_pcb.jpg b/2010/osmocombb-hashdays2010/c123_pcb.jpg Binary files differnew file mode 100644 index 0000000..a9f24fc --- /dev/null +++ b/2010/osmocombb-hashdays2010/c123_pcb.jpg diff --git a/2010/osmocombb-hashdays2010/calypso-block.pdf b/2010/osmocombb-hashdays2010/calypso-block.pdf Binary files differnew file mode 100644 index 0000000..27f8be8 --- /dev/null +++ b/2010/osmocombb-hashdays2010/calypso-block.pdf diff --git a/2010/osmocombb-hashdays2010/gsm_network.png b/2010/osmocombb-hashdays2010/gsm_network.png Binary files differnew file mode 100644 index 0000000..c5f6399 --- /dev/null +++ b/2010/osmocombb-hashdays2010/gsm_network.png diff --git a/2010/osmocombb-hashdays2010/osmocombb-security.pdf b/2010/osmocombb-hashdays2010/osmocombb-security.pdf Binary files differnew file mode 100644 index 0000000..29bd4b7 --- /dev/null +++ b/2010/osmocombb-hashdays2010/osmocombb-security.pdf diff --git a/2010/osmocombb-hashdays2010/osmocombb-security.snm b/2010/osmocombb-hashdays2010/osmocombb-security.snm new file mode 100644 index 0000000..e69de29 --- /dev/null +++ b/2010/osmocombb-hashdays2010/osmocombb-security.snm diff --git a/2010/osmocombb-hashdays2010/osmocombb-security.tex b/2010/osmocombb-hashdays2010/osmocombb-security.tex new file mode 100644 index 0000000..76c53cd --- /dev/null +++ b/2010/osmocombb-hashdays2010/osmocombb-security.tex @@ -0,0 +1,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} diff --git a/2010/osmocombb-linuxkongress2010/abstract.txt b/2010/osmocombb-linuxkongress2010/abstract.txt new file mode 100644 index 0000000..84b900a --- /dev/null +++ b/2010/osmocombb-linuxkongress2010/abstract.txt @@ -0,0 +1,25 @@ +OsmocomBB: Protocol stack and baesband firmware for GSM mobile phones + +By: Harald Welte[1] + +The OsmocomBB project[2] is a Free Software implementation of the GSM +protocol stack running on a mobile phone. + +For decades, the cellular industry comprised by cellphone chipset makers and +network operators keep their hardware and system-level software as well as GSM +protocol stack implementations closed. As a result, it was never possible +to send arbitrary data at the lower levels of the GSM protocol stack. +Existing phones only allow application-level data to be user-supplied, such as +SMS messages, IP over GPRS or circuit-switched data (CSD). + +Using OsmocomBB, the Free Software enethusiast as well as the security +researcher finally has a tool equivalent to an Ethernet card in the TCP/IP +protocol world: A simple transceiver that will send arbitrary protocol +messages to a GSM network. + +By the time Linux Kongress 2010 is held, it is expected that OsmocomBB +has proceeded to a level where it can make actual phone calls on any +GSM network. + +[1] http://laforge.gnumonks.org/ +[2] http://bb.osmocom.org/ diff --git a/2010/osmocombb-linuxkongress2010/bio.txt b/2010/osmocombb-linuxkongress2010/bio.txt new file mode 100644 index 0000000..4168a1b --- /dev/null +++ b/2010/osmocombb-linuxkongress2010/bio.txt @@ -0,0 +1,25 @@ +Harald Welte is a freelancer, consultant, enthusiast, freedom fighter and +hacker who is working with Free Software (and particularly the Linux kernel) +since 1995. His first major code contribution to the kernel was within the +netfilter/iptables packet filter. + +He has started a number of other Free Software and Free Hardware projects, +mainly related to RFID such as librfid, OpenMRTD, OpenBeacon, OpenPCD, +OpenPICC. During 2006 and 2007 Harald became the co-founder of OpenMoko, where +he served as Lead System Architect for the worlds first 100% Open Free Software +based mobile phone. + +Aside from his technical contributions, Harald has been pioneering the legal +enforcement of the GNU GPL license as part of his gpl-violations.org project. +More than 150 inappropriate use of GPL licensed code by commercial companies +have been resolved as part of this effort, both in court and out of court. He +has received the 2007 "FSF Award for the Advancement of Free Software" and the +"2008 Google/O'Reilly Open Source award: Defender of Rights". + +In 2008, Harald started to work on Free Software on the GSM protocol side, both +for passive sniffing and protocol analysis, as well as an actual network-side +GSM stack implementation called OpenBSC. He is currently in the early design +phase for the hardware and software design of a Free Software based GSM +baseband side. + +He continues to operate his consulting business hmw-consulting. diff --git a/2010/osmocombb-linuxkongress2010/c123_pcb.jpg b/2010/osmocombb-linuxkongress2010/c123_pcb.jpg Binary files differnew file mode 100644 index 0000000..a9f24fc --- /dev/null +++ b/2010/osmocombb-linuxkongress2010/c123_pcb.jpg diff --git a/2010/osmocombb-linuxkongress2010/calypso-block.pdf b/2010/osmocombb-linuxkongress2010/calypso-block.pdf Binary files differnew file mode 100644 index 0000000..27f8be8 --- /dev/null +++ b/2010/osmocombb-linuxkongress2010/calypso-block.pdf diff --git a/2010/osmocombb-linuxkongress2010/gsm_network.png b/2010/osmocombb-linuxkongress2010/gsm_network.png Binary files differnew file mode 100644 index 0000000..c5f6399 --- /dev/null +++ b/2010/osmocombb-linuxkongress2010/gsm_network.png diff --git a/2010/osmocombb-linuxkongress2010/osmocombb-security.pdf b/2010/osmocombb-linuxkongress2010/osmocombb-security.pdf Binary files differnew file mode 100644 index 0000000..5b4100a --- /dev/null +++ b/2010/osmocombb-linuxkongress2010/osmocombb-security.pdf diff --git a/2010/osmocombb-linuxkongress2010/osmocombb-security.snm b/2010/osmocombb-linuxkongress2010/osmocombb-security.snm new file mode 100644 index 0000000..e69de29 --- /dev/null +++ b/2010/osmocombb-linuxkongress2010/osmocombb-security.snm diff --git a/2010/osmocombb-linuxkongress2010/osmocombb-security.tex b/2010/osmocombb-linuxkongress2010/osmocombb-security.tex new file mode 100644 index 0000000..774d8ab --- /dev/null +++ b/2010/osmocombb-linuxkongress2010/osmocombb-security.tex @@ -0,0 +1,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 +{A Free Software GSM baseband firmware} + +\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[LK 2010] % (optional, should be abbreviation of conference name) +{Linux Kongress 2010, September 2010, Nuremberg/Germany} +% - 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 mastar 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} diff --git a/2010/osmocombb-ols2010/abstract.txt b/2010/osmocombb-ols2010/abstract.txt new file mode 100644 index 0000000..b84c3b1 --- /dev/null +++ b/2010/osmocombb-ols2010/abstract.txt @@ -0,0 +1,18 @@ +For more than 19 years, every GSM mobile phone is running a proprietary +protocol stack on a proprietary operating system on top of equally +proprietary hardware. Billions of phones have been shipped worldwide, +running as a black box controlled by the phone maker and/or operator - +outside the control of the user + +Most of those devices have no user-upgradable firmware for the baseband +processor, and yet those billions of GSM phones are all connected to a public +network. Their software is complex compiled C code on a CPU without any +form of memory protection. + +Mobile phones have all sort of features that the user would never want. Why +would he want his phone to reveal its GPS position to the operator? Why +would he allow the operator to hide from him, if calls are not encrypted? + +The only solution is a Free Software / Open Source GSM baseband stack. + +OsmocomBB has set out to create this protocol stack. diff --git a/2010/osmocombb-phneutral2010/c123_pcb.jpg b/2010/osmocombb-phneutral2010/c123_pcb.jpg Binary files differnew file mode 100644 index 0000000..a9f24fc --- /dev/null +++ b/2010/osmocombb-phneutral2010/c123_pcb.jpg diff --git a/2010/osmocombb-phneutral2010/calypso-block.pdf b/2010/osmocombb-phneutral2010/calypso-block.pdf Binary files differnew file mode 100644 index 0000000..27f8be8 --- /dev/null +++ b/2010/osmocombb-phneutral2010/calypso-block.pdf diff --git a/2010/osmocombb-phneutral2010/gsm_network.png b/2010/osmocombb-phneutral2010/gsm_network.png Binary files differnew file mode 100644 index 0000000..c5f6399 --- /dev/null +++ b/2010/osmocombb-phneutral2010/gsm_network.png diff --git a/2010/osmocombb-phneutral2010/osmocombb-abstract.txt b/2010/osmocombb-phneutral2010/osmocombb-abstract.txt new file mode 100644 index 0000000..497e495 --- /dev/null +++ b/2010/osmocombb-phneutral2010/osmocombb-abstract.txt @@ -0,0 +1,24 @@ +OsmocomBB: A tool for GSM protocol level security analysis of GSM networks + +By: Harald Welte[1] + +The OsmocomBB project[2] is a Free Software implementation of the GSM +protocol stack running on a mobile phone. + +For decades, the cellular industry comprised by cellphone chipset makers and +network operators keep their hardware and system-level software as well as GSM +protocol stack implementations closed. As a result, it was never possible +to send arbitrary data at the lower levels of the GSM protocol stack. +Existing phones only allow application-level data to be specified, such as +SMS messages, IP over GPRS or circuit-switched data (CSD). + +Using OsmocomBB, the security researcher finally has a tool equivalent +to an Ethernet card in the TCP/IP protocol world: A simple transceiver +that will send arbitrary protocol messages to a GSM network. + +Well-known and established techniques like protocol fuzzing can finally +be used in GSM networks and reveal how reliable and fault tolerant the +equipment used in the GSM networks really is. + +[1] http://laforge.gnumonks.org/ +[2] http://bb.osmocom.org/ diff --git a/2010/osmocombb-phneutral2010/osmocombb-security.pdf b/2010/osmocombb-phneutral2010/osmocombb-security.pdf Binary files differnew file mode 100644 index 0000000..892cd76 --- /dev/null +++ b/2010/osmocombb-phneutral2010/osmocombb-security.pdf diff --git a/2010/osmocombb-phneutral2010/osmocombb-security.snm b/2010/osmocombb-phneutral2010/osmocombb-security.snm new file mode 100644 index 0000000..e69de29 --- /dev/null +++ b/2010/osmocombb-phneutral2010/osmocombb-security.snm diff --git a/2010/osmocombb-phneutral2010/osmocombb-security.tex b/2010/osmocombb-phneutral2010/osmocombb-security.tex new file mode 100644 index 0000000..848b889 --- /dev/null +++ b/2010/osmocombb-phneutral2010/osmocombb-security.tex @@ -0,0 +1,645 @@ +% $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 +{Sending arbitrary protocol data to GSM networks} + +\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[ph-neutral 2010] % (optional, should be abbreviation of conference name) +{ph-neutral 2010, May 2010, Berlin/Germany} +% - 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 specialist, focus on network protocol security + \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} + + +\subsection{Observations} + +\begin{frame}{Interesting observations}{Learned from implementing the stack} +While developing OpenBSC, we observed a number of interesting +\begin{itemize} + \item Many phones use their TMSI from the old network when they roam to a new network + \item Various phones crash when confronted with incorrect messages. We didn't even start to intentionally send incorrect messages (!) + \item There are tons of obscure options on the GSM spec which no real network uses. Potential attack vector by using rarely tested code paths. +\end{itemize} +\end{frame} + +\subsection{GSM Protocol Fuzzing} + +\begin{frame}{GSM Protocol Fuzzing}{Theoretical basis} +How to do GSM protocol fuzzing +\begin{itemize} + \item From the handset to the network + \begin{itemize} + \item Basically impossible due to closeness of baseband + \item However, some incomplete projects working on it + \end{itemize} + \item From the network side + \begin{itemize} + \item Easy in case of {\em rogue network} attacks + \item Fuzzing target is the GSM stack in the baseband processor + \end{itemize} + \item As an A-bis man in the middle + \begin{itemize} + \item Needs access to an A-bis interface of an actual network + \item Very attractive, since no encryption and ability to fuzz both network and handset + \end{itemize} +\end{itemize} +\end{frame} + +\begin{frame}{scapy GSM support}{The actual fuzzing} +How to actually craft the packets for the fuzzing +\begin{itemize} + \item GSM has many, many protocols + \item Writing custom code will be a hard-coded special case for each of them + \item Solution: Use scapy and implement the GSM protocols as scapy "layers" + \begin{itemize} + \item IPA protocol header + \item RSL protocol layer + \item RLL data indication / data request + \item GSM 04.08 RR / MM / CC messages + \end{itemize} +\end{itemize} +\end{frame} + +\section{OsmocomBB Project} + +\subsection{OsmocomBB Introduction} + +\begin{frame}{OsmoocmBB Introduction} +\begin{itemize} + \item Project was started in January 2010 + \item Implementing a GSM baseband software from scratch + \item This includes + \begin{itemize} + \item GSM MS-side protocl 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}{OsmoocmBB 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}{OsmoocmBB 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}{OsmoocmBB 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}{OsmoocmBB 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}{OsmoocmBB Supported Hardware} +\begin{itemize} + \item Baseband Chipsets + \begin{itemize} + \item TI Calypso/Iota/Rita + \item Some early research being doen 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}{OsmoocmBB Project Status: Working} +\begin{itemize} + \item Hardware Drivers for Calypso/Iota/Rita very complete + \item Layer1 + \begin{itemize} + \item Power measurements + \item Carrier/bit/TDMA synchronization + \item Receive and trnasmit of normal bursts on SDCCH + \item Transmit of RACH bursts + \end{itemize} + \item Layer2 UI/SABM/UA frames + \item Layer3 Messages for RR / MM / CC + \item Cell (re)selection according GSM 03.22 +\end{itemize} +\end{frame} + +\begin{frame}{OsmoocmBB Project Status: Not working} +\begin{itemize} + \item Actual SIM card reader inside phone (WIP) + \item Layer1 + \begin{itemize} + \item Automatic Tx power control (APC) + \item Automatic Rx gain control (AGC) + \item Frequency Hopping + \item Neighbor Cell Measurements + \item Traffic Channels (TCH) + \end{itemize} + \item Layer2 Asynchronous Balanced Mode (ACK/retransmissions) + \item Actual UI on the phone + \item Drivers for Audio/Voice signal path +\end{itemize} +\end{frame} + +\begin{frame}{OsmoocmBB Project Status: Executive Summary} +\begin{itemize} + \item We can esetablish control/signalling channels with non-hopping cells + \begin{itemize} + \item Used in small single-TRX cells in rural areas + \item Used in GSM-R networks + \item As provided by OpenBSC + OpenBTS + \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 Adding frequency hopping support not very hard +\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}{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} diff --git a/2010/osmocombb-phneutral2010/outline.txt b/2010/osmocombb-phneutral2010/outline.txt new file mode 100644 index 0000000..d7799fa --- /dev/null +++ b/2010/osmocombb-phneutral2010/outline.txt @@ -0,0 +1,41 @@ + +what is osmocombb + name + goals + +supported hardware + baseband chipset + actual phone + +gsm phone anatomy + +OsmocomBB software architecture + libosmocore + firmware + l1ctl interface + layer23 on the host + + firmware + calypso hardware drivers + clock, dma, dsp-api, i2c, irq, keypad, rtc, spi, timer, tpu, tsp, uart, uwire, backlight + LCM driver + CFI flash driver + ABB driver (TWL3025) + RF driver (TRF6151) + GSM layer1 sync/async + sercomm (HDLC variant) + + + host software ('layer23') + l1ctl protocol wrapper + layer2 (LAPDm) implementaiton + layer3 (RR/MM/CC) imcplementation + GSM 03.22 cell (re)selection + + +project status + +help needed + actual UI on the phone + port layer1 to Mediatek/MTK chipsets (lots of reversing) + diff --git a/2010/osmocombb-sstic2010/c123_pcb.jpg b/2010/osmocombb-sstic2010/c123_pcb.jpg Binary files differnew file mode 100644 index 0000000..a9f24fc --- /dev/null +++ b/2010/osmocombb-sstic2010/c123_pcb.jpg diff --git a/2010/osmocombb-sstic2010/calypso-block.pdf b/2010/osmocombb-sstic2010/calypso-block.pdf Binary files differnew file mode 100644 index 0000000..27f8be8 --- /dev/null +++ b/2010/osmocombb-sstic2010/calypso-block.pdf diff --git a/2010/osmocombb-sstic2010/gsm_network.png b/2010/osmocombb-sstic2010/gsm_network.png Binary files differnew file mode 100644 index 0000000..c5f6399 --- /dev/null +++ b/2010/osmocombb-sstic2010/gsm_network.png diff --git a/2010/osmocombb-sstic2010/osmocombb-abstract.txt b/2010/osmocombb-sstic2010/osmocombb-abstract.txt new file mode 100644 index 0000000..497e495 --- /dev/null +++ b/2010/osmocombb-sstic2010/osmocombb-abstract.txt @@ -0,0 +1,24 @@ +OsmocomBB: A tool for GSM protocol level security analysis of GSM networks + +By: Harald Welte[1] + +The OsmocomBB project[2] is a Free Software implementation of the GSM +protocol stack running on a mobile phone. + +For decades, the cellular industry comprised by cellphone chipset makers and +network operators keep their hardware and system-level software as well as GSM +protocol stack implementations closed. As a result, it was never possible +to send arbitrary data at the lower levels of the GSM protocol stack. +Existing phones only allow application-level data to be specified, such as +SMS messages, IP over GPRS or circuit-switched data (CSD). + +Using OsmocomBB, the security researcher finally has a tool equivalent +to an Ethernet card in the TCP/IP protocol world: A simple transceiver +that will send arbitrary protocol messages to a GSM network. + +Well-known and established techniques like protocol fuzzing can finally +be used in GSM networks and reveal how reliable and fault tolerant the +equipment used in the GSM networks really is. + +[1] http://laforge.gnumonks.org/ +[2] http://bb.osmocom.org/ diff --git a/2010/osmocombb-sstic2010/osmocombb-security.pdf b/2010/osmocombb-sstic2010/osmocombb-security.pdf Binary files differnew file mode 100644 index 0000000..d5f76c4 --- /dev/null +++ b/2010/osmocombb-sstic2010/osmocombb-security.pdf diff --git a/2010/osmocombb-sstic2010/osmocombb-security.snm b/2010/osmocombb-sstic2010/osmocombb-security.snm new file mode 100644 index 0000000..e69de29 --- /dev/null +++ b/2010/osmocombb-sstic2010/osmocombb-security.snm diff --git a/2010/osmocombb-sstic2010/osmocombb-security.tex b/2010/osmocombb-sstic2010/osmocombb-security.tex new file mode 100644 index 0000000..55e66bc --- /dev/null +++ b/2010/osmocombb-sstic2010/osmocombb-security.tex @@ -0,0 +1,666 @@ +% $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 +{A tool for GSM protocol level security} + +\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[SSTIC 2010] % (optional, should be abbreviation of conference name) +{SSTIC 2010, June 2010, Rennes/France} +% - 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 in January 2010 + \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 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 + \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: Not working} +\begin{itemize} + \item Actual SIM card reader inside phone (WIP) + \item Layer1 + \begin{itemize} + \item Automatic Tx power control (APC) + \item Automatic Rx gain control (AGC) + \item Frequency Hopping + \item Neighbor Cell Measurements + \item Traffic Channels (TCH) + \end{itemize} + \item Actual UI on the phone + \item Drivers for Audio/Voice signal path +\end{itemize} +\end{frame} + +\begin{frame}{OsmocomBB Project Status: Executive Summary} +\begin{itemize} + \item We can establish control/signalling channels with non-hopping cells + \begin{itemize} + \item Used in small single-TRX cells in rural areas + \item Used in GSM-R networks + \item As provided by OpenBSC + OpenBTS + \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 Adding frequency hopping support not very hard +\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}{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} diff --git a/2010/osmocombb-sstic2010/osmocombb-security.tex.bak b/2010/osmocombb-sstic2010/osmocombb-security.tex.bak new file mode 100644 index 0000000..7a82bb0 --- /dev/null +++ b/2010/osmocombb-sstic2010/osmocombb-security.tex.bak @@ -0,0 +1,666 @@ +% $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 +{A tool for GSM protocol level security} + +\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[SSTIC 2010] % (optional, should be abbreviation of conference name) +{SSTIC 2010, June 2010, Rennes/France} +% - 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 genric 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 possilble + \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 laeked 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}{OsmoocmBB Introduction} +\begin{itemize} + \item Project was started in January 2010 + \item Implementing a GSM baseband software from scratch + \item This includes + \begin{itemize} + \item GSM MS-side protocl 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}{OsmoocmBB 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}{OsmoocmBB 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}{OsmoocmBB 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}{OsmoocmBB 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}{OsmoocmBB Supported Hardware} +\begin{itemize} + \item Baseband Chipsets + \begin{itemize} + \item TI Calypso/Iota/Rita + \item Some early research being doen 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}{OsmoocmBB Project Status: Working} +\begin{itemize} + \item Hardware Drivers for Calypso/Iota/Rita very complete + \item Layer1 + \begin{itemize} + \item Power measurements + \item Carrier/bit/TDMA synchronization + \item Receive and trnasmit of normal bursts on SDCCH + \item Transmit of RACH bursts + \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}{OsmoocmBB Project Status: Not working} +\begin{itemize} + \item Actual SIM card reader inside phone (WIP) + \item Layer1 + \begin{itemize} + \item Automatic Tx power control (APC) + \item Automatic Rx gain control (AGC) + \item Frequency Hopping + \item Neighbor Cell Measurements + \item Traffic Channels (TCH) + \end{itemize} + \item Actual UI on the phone + \item Drivers for Audio/Voice signal path +\end{itemize} +\end{frame} + +\begin{frame}{OsmoocmBB Project Status: Executive Summary} +\begin{itemize} + \item We can esetablish control/signalling channels with non-hopping cells + \begin{itemize} + \item Used in small single-TRX cells in rural areas + \item Used in GSM-R networks + \item As provided by OpenBSC + OpenBTS + \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 Adding frequency hopping support not very hard +\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}{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} |
