diff options
Diffstat (limited to '2013/mobsec-cso2013/mobsec.tex')
| -rw-r--r-- | 2013/mobsec-cso2013/mobsec.tex | 487 |
1 files changed, 487 insertions, 0 deletions
diff --git a/2013/mobsec-cso2013/mobsec.tex b/2013/mobsec-cso2013/mobsec.tex new file mode 100644 index 0000000..9e04f9a --- /dev/null +++ b/2013/mobsec-cso2013/mobsec.tex @@ -0,0 +1,487 @@ +% $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{Structural deficits in Telco security} + +%\subtitle {community based Free / Open Source Software for communications} + +\author{Harald Welte <hwelte@hmw-consulting.de>} + +\institute +{gnumonks.org\\hmw-consulting.de\\sysmocom GmbH} +% - Use the \inst command only if there are several affiliations. +% - Keep it simple, no one is interested in your street address. + +\date[] % (optional, should be abbreviation of conference name) +{March 21, 2013 / CSO} +% - 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{Communications} +% 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 Linux Kernel / bootloader / driver / firmware developer since 1999 + \item IT security expert, focus on network protocol security + \item Former core developer of Linux packet filter netfilter/iptables + \item Board-level Electrical Engineering + \item Always looking for interesting protocols (RFID, DECT, GSM) + \item OpenEXZ, OpenPCD, Openmoko, OpenBSC, OsmocomBB, OsmoSGSN + \item consulting/freelancing + sysmocom GmbH for custom-tailored GSM solutoins +\end{itemize} +\end{frame} + +\begin{frame}{Disclaimer} +\begin{itemize} + \item This presentation is not intended to insult any participant + \item No companies or individuals will be named + \item However, the collective failure of the mobile industry + cannot be ignored, sorry. + \item Many of the issues we have today could have been avoided + extremely easily, there really is no excuse... +\end{itemize} +\end{frame} + +\section{Symptoms} + +\begin{frame}{Telco vs. Internet-driven IT security} +mobile industry today has security practieses and procedures of the 20th century +\begin{itemize} + \item no proper incident response on RAN/CN + \item no procedures for quick roll-out of new sw releases + \item no requirements for software-upgradeability + \item no interaction with hacker community + \item no packet filtering / DPI / IDS on signalling traffic + \item active hostility towards operators who want to do pentesting + \item attempts to use legal means to stop researchers from publishing their findings +\end{itemize} +this sounds like medieval times. We are in 2012 ?!? +\end{frame} + +\subsection{Real-world quotes} + +\begin{frame}{Real-world quotes} +The following slides indicate some quotes that I have heard over the +last couple of years from my contacts inside the mobile industry. They +are not made up! +\end{frame} + + +\begin{frame}{Quote: Disclosure of Ki/K/OPC} +"we are sending our IMSI+Key lists as CSV files to the SIM card supplier in China" +\end{frame} + +\begin{frame}{Quote: RRLP} +"RRLP? What is that? We never heard about it!" +\end{frame} + +\begin{frame}{Quote: SIM OTA keys} +"we have no clue what remote accessible (OTA) features our sim cards have or what kind of keys were used during provisioning" +\end{frame} + +\begin{frame}{Quote: Malformed} +"we have never tried to intentionally send any malformed message to any of our equipment" +\end{frame} + +\begin{frame}{Quote: Roaming} +"We are seeing TCAP/MAP related attacks/fraud from Operator XYZ in Pakistan. However, it is more important that European travellers can roam into their network than it is for Pakistanis to roam into our network. Can you see while the roaming agreement was only suspended for two days?" +\end{frame} + +\begin{frame}{Quote: SIGTRAN IPsec} +"we are unable to mandate from our roaming partners that SIGTRAN links shall always go through IPsec - we don't even know how to facilitate safe distribution of certificates between operators" +\end{frame} + +\begin{frame}{Quote: NodeB / IPsec} +"We mandated IPsec to be used for all of the (e)NodeB back-haul in our tender, the supplier still shipped equipment that didn't comply to it. Do you think the CEO is going to cancel the contract with them for that?" +\end{frame} + +\begin{frame}{Quote: Government / independent study} +"Govt: We put out a tender for a study on overal operator network security in our country. Everyone who put in a bid is economically affiliated or dependent on one of the operators or equipment suppliers, so we knew the results were not worth much." +\end{frame} + +\begin{frame}{Quote: Technical Staff} +"15 years ago we still had staff that understood all those details. But today, you know, those experts are expensive - we laid them off." +\end{frame} + +\begin{frame}{Quote: Baseband chip vendor} +"We have no clue what version of our protocol stack with what modifications are shipped in which particular phones, or if/when the phone makers distribute updates to the actual phone population" +\end{frame} + +%we live in a world where +% operators regularly don't fully understand the equipment they use +% "The frequencies of the mircrowave back-haul links are a trade secret of the operator +% operators are compltely dependent and live at the merit of few equipment suppliers +% suppliers have spent decades of achieving as little mix+match compatibility as possible +% huge conflict of interest between operators and suppliers +% selling new hardware vs. updating software of old units +% extreme disconnect between technical merits of certain changes/features and prices / licensing +% charge a six-digit EUR amount for the A5/3 upgrade for each BSC, despite the fact that it is the BTS that changes, not the BSC! + +\subsection{Algorithm nightmares} + +\begin{frame}{The A5/2 desaster}{Brief history} +\begin{itemize} + \item August 2003: Barkan/Biham/Keller paper on instant ciphertext-only cryptanalysis of A5/2 + \item April 2006: GSMA initiative to withdraw A5/2. Resistance {\em mainly from north america}. + \item October 2006: SA WG3 formally requests removal of A5/2 from spec + \item July 2007: Almost all operators have moved to A5/1 + \item As long as phones support A5/2, semi-active down-grade attacks against A5/1 can be implemented! +\end{itemize} +Three years incident response to update the spec! I'm not even talking +about the time to update all equipment or until old equipment will be +fully phased out. +\end{frame} + +\begin{frame}{The A5/1 desaster}{history repeats itself} +The industry did not learn from the A5/2 incident. History repeated +itself: +\begin{itemize} + \item Kc generation was not changed between A5/1,2,3 + \item as long as phones support A5/1, A5/3 can be broken with + semi-active down-grade attacks just like A5/2 -> A5/1 + before + \item There is still no way to disable algorithms of devices in + the field, not even by flags on the SIM card +\end{itemize} +How can an entire industy be so resilient against learning? +\end{frame} + +\begin{frame}{The A5/3 desaster}{Nobody cares to implement it} +\begin{itemize} + \item May 2002: A5/3 spec first released. Target: supported in handsets and networks in 2004. + \item May 2007: SA WG3: lack of BSS vendors supporting A5/3 (5 years later!!!) + \item January 2009: First discussions with phone makers on A5/3 interop tests + \item November 2009: 10 handsets from 7 manufacturers being tested on a live A5/3 network +\end{itemize} +After the track record of A5/2 and A5/3, they seem to be on a {\em fast track} to improve. +\end{frame} + +\begin{frame}{The overall algorithm desaster} +\begin{itemize} + \item Advances in security require algorithms to be replaced and key lengths to grow + \item Nobody in the GSM world seems to have realized such a basic cryptographic truth + \item Infrastruture vendors reluctant to make algorithms software-upgradeable. They'd rather sell ten-thousands of new BTSs + \item Operators never made it a requirement to do in-field algorithm upgrades. Why would they? + \item Internet analogy: Who would ever want to use more than 40-bit RC4 encryption in his SSL implementation and upgrade that? +\end{itemize} +\end{frame} + +\begin{frame}{2009: GSMA starts to think} +\begin{itemize} + \item November 2009, 3GPP TSG SA3 WG, GSMA Liaison Report: {\em + The meeting considered the need to ensure that + future infrastructure algorithm updates will be + exclusively software based} + \item About one decade too late for anyone with even remote + knowledge of real-world cryptographic deployment + \item Six years after the A5/2 cryptanalysis paper + \item Seven years after A5/3 has been specified +\end{itemize} +\end{frame} + + +\begin{frame}{ETSI/3GPP security working group(s)} +\begin{itemize} + \item seem to have done excellent work + \item nobody seemed to care about what they say + \item A5/4 (128bit) was originally supposed to come together with A5/3 in 2004 + \begin{itemize} + \item has been put back as it would affect handset software (so what? there are only about 6 implementations out there. How hard is it to update all 6?) + is the only solution of fixing semi-active downgrade attacks + \end{itemize} + \item UMTS AKA over GERAN + \begin{itemize} + \item good idea, but where is the SIM card flag that tells the phone about mutual auth being mandatory? + \end{itemize} + \item Great ideas seem to fall short of being thought-through to + the end, and nobody implements them in a timely manner + anyway +\end{itemize} +\end{frame} + +\section{Causes / Reasons} + +\begin{frame}{Telco vs. Internet} +still remember the days of analog modems, UUCP, BBSs, Usenet? +\begin{itemize} + \item the culture gap between Internet vs. Telco has always existed + \item it didn't change much during the last decades + \item analogy: The "IBM priests" mainframes vs. personal computing in 1970ies/1980ies + \item IETF vs. ITU + \item open participation vs. closed club +\end{itemize} +\end{frame} + +\subsection{Change of power divide between Operators and Vendors} + +\begin{frame}{Evolving GSM specification process} +\begin{itemize} + \item At CEPT, it was government officials of postal/comms ministry equipment vendors didn't even have the right to propose something + \item At ETSI, equipment vendors got onto the table Over time, shift of power from operators to equipment manufacturers + \item At 3GPP, today we see way too little operator input in standardization + \item Interest of users seems completely absent + \begin{itemize} + \item neither professional users (companies worried about industrial espionage, government users, ...) + \item nor consumers in form of consumer protection, privacy, data protection or other organizations seems to be missing completely + \end{itemize} + \item standardization process primarily serves the interest of equipment vendors to get their patented technology into widespread adoption to drive IP licensing revenue +\end{itemize} +\end{frame} + +\begin{frame}{Evolution of operators} +\begin{itemize} + \item classic operator: Does everything in-house + \item common today: Outsource everything + \begin{itemize} + \item billing + \item network administration / operation / servicing + \item network planning + \end{itemize} + \item outsourcing to whom? + \begin{itemize} + \item to the equipment suppliers + \item am I the only one seing a conflict of interests here? + \end{itemize} +\end{itemize} +\end{frame} + +\subsection{Lack of Open Source Implementations} + +\begin{frame}{Research in TCP/IP/Ethernet} +Assume you want to do some research in the TCP/IP/Ethernet +communications area, +\begin{itemize} + \item you use off-the-shelf hardware (x86, Ethernet card) + \item you start with the Linux / *BSD stack + \item you add the instrumentation you need + \item you make your proposed modifications + \item you do some testing + \item you write your paper / proof-of-concept and publish the results +\end{itemize} +\end{frame} + +\begin{frame}{Research in (mobile) communications} +Assume it is before 2009 (before OpenBSC/OsmocomBB) and you want to do some research in mobile comms +\begin{itemize} + \item there is no FOSS implementation of any of the protocols or + functional entities + \item almost no university has a test lab with the required + equipment. And if they do, it is black boxes that you + cannot modify according to your research requirements + \item you turn away at that point, or you cannot work on really + exciting stuff + \item only chance is to partner with commercial company, who + puts you under NDAs and who wants to profit from your + research +\end{itemize} +\end{frame} + +\begin{frame}{GSM/3G vs. Internet} +\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 very few closed-source protocol stack implementations + \item GSM chipset makers never release any hardware documentation + \end{itemize} +\end{itemize} +\end{frame} + +\section{Proposed Solution} + +\begin{frame}{Testing/Auditing just like in the IP world} +\begin{itemize} + \item Learn and adapt from the Internet security world + \item Encourage all kinds of testing and audits rather than prevent them + \item Fuzzing+Pentesting all protocols on all levels +\end{itemize} +\begin{itemize} + \item I'm not aware of any of the well-known GSM/GPRS security researchers having been invited to equipment vendors to do sophisticated testing/attacks/audit + \item That's inefficient use of existing skills! +\end{itemize} +\end{frame} + +\begin{frame}{Change the way of thinking} +\begin{itemize} + \item Give up the idea that certain interfaces are not exposed + \item TCAP/MAP/CAP are exposed to anyone with SCCP (SS7) access + \item This includes all government agencies world-wide, as they can easily force domestic operators to give them access! + \item Governments / regulators should put strong security requirements on domestic operators to secure those interfaces against attacks + \item This is critical infrastructure that the general public, industry and even government/administration increasingly relies on + \item Multiple lines of defences, not one or zero +\end{itemize} +\end{frame} + +\begin{frame}{Specifications / Testing} +\begin{itemize} + \item If specs require any tests, they are {\em functional} specs + \item I've never seen requirements to test for invalid / intentionally malformed messages + \item Actively provide equipment (access) to academia and research, invite researchers to test/break things +\end{itemize} +\end{frame} + +\begin{frame}{Skill building} +\begin{itemize} + \item We need more teaching/training in academia to generate independent experts, without vendor affiliation + \item Theoretic lectures are boring. Practical experiments / lab exercises required to get students excited / interested + \item Very few universities have been provided with sufficient equipment to run / experiment / play with their own GSM/3G networks + \item As long as it is much easier to research TCP/IP than mobile protocols, majority of the brain power will focus on TCP/IP + \item Open Source implementations are critical for experiments! +\end{itemize} +\end{frame} + +\begin{frame}{Less monoculture} +\begin{itemize} + \item Very few equipment vendors and protocol stack vendors + \item Even less vendors of ASN.1 / CSN.1 code generators + \item Finding an exploitable bug in one of the 2-3 major ASN.1 + code generators will permit you to exploit pretty much + any equipment independent of the vendor +\end{itemize} +\end{frame} + +\begin{frame}{Procedures / incident response} +\begin{itemize} + \item start to adopt scheme like CVE, vulnerability databases + \item be prepared to rapidly roll out updates to all elements in + the operator infrastructure + \item have specs that require sufficient spare FPGA / DSP / CPU + / RAM resources in hardware to ensure + software-upgradability of components +\end{itemize} +\end{frame} + +\begin{frame}{Engagement with the security community} +\begin{itemize} + \item Actively engage academic and individual security researchers + \item Sueing them is not a solution, this has been tried in the 1990ies in the PC/Software industry + \item If you don't provide researchers inexpensive/available hardware, they have to break femtocells and other devices in order to do their legitimate research + \item Compare with gaming consoles exploits: All of them have been broken by people who wanted to run Linux and custom software on them. Only PS3 survived much longer, as they provided such means to the users from day 1 (and later removed it, requiring to break the PS3, too) +\end{itemize} +\end{frame} + +\begin{frame}{Thanks} +Thanks for your attention. I hope we have time for Q\&A. +\end{frame} + + +\end{document} |