From fca59bea770346cf1c1f9b0e00cb48a61b44a8f3 Mon Sep 17 00:00:00 2001 From: Harald Welte Date: Sun, 25 Oct 2015 21:00:20 +0100 Subject: import of old now defunct presentation slides svn repo --- 2015/bio.txt | 36 + 2015/bio.txt.bak | 29 + 2015/hardwear_io/keynote.pdf | Bin 0 -> 96523 bytes 2015/hardwear_io/keynote.snm | 0 2015/hardwear_io/keynote.tex | 543 +++++++ 2015/hardwear_io/keynote.tex.bak | 543 +++++++ 2015/osmo_iuh/640px-UMTS_structures.png | Bin 0 -> 116704 bytes 2015/osmo_iuh/iu_cs_stacking.png | Bin 0 -> 154221 bytes 2015/osmo_iuh/iu_ps_stacking.png | Bin 0 -> 141631 bytes 2015/osmo_iuh/iuh_stacking.png | Bin 0 -> 117133 bytes 2015/osmo_iuh/nodeb_hnb.png | Bin 0 -> 216922 bytes 2015/osmo_iuh/osmo_iuh.pdf | Bin 0 -> 1092939 bytes 2015/osmo_iuh/osmo_iuh.snm | 0 2015/osmo_iuh/osmo_iuh.tex | 540 +++++++ 2015/osmo_iuh/osmo_iuh.tex.bak | 539 +++++++ 2015/osmo_iuh/umts_channel_mapping.png | Bin 0 -> 152875 bytes 2015/osmo_iuh/umts_hnb_control.pdf | Bin 0 -> 61656 bytes 2015/osmo_iuh/umts_hnb_control.svg | 1437 ++++++++++++++++++ 2015/osmo_iuh/umts_ps_control.pdf | Bin 0 -> 70743 bytes 2015/osmo_iuh/umts_ps_control.svg | 1519 +++++++++++++++++++ 2015/osmo_iuh/umts_structure.svg | 2416 +++++++++++++++++++++++++++++++ 21 files changed, 7602 insertions(+) create mode 100644 2015/bio.txt create mode 100644 2015/bio.txt.bak create mode 100644 2015/hardwear_io/keynote.pdf create mode 100644 2015/hardwear_io/keynote.snm create mode 100644 2015/hardwear_io/keynote.tex create mode 100644 2015/hardwear_io/keynote.tex.bak create mode 100644 2015/osmo_iuh/640px-UMTS_structures.png create mode 100644 2015/osmo_iuh/iu_cs_stacking.png create mode 100644 2015/osmo_iuh/iu_ps_stacking.png create mode 100644 2015/osmo_iuh/iuh_stacking.png create mode 100644 2015/osmo_iuh/nodeb_hnb.png create mode 100644 2015/osmo_iuh/osmo_iuh.pdf create mode 100644 2015/osmo_iuh/osmo_iuh.snm create mode 100644 2015/osmo_iuh/osmo_iuh.tex create mode 100644 2015/osmo_iuh/osmo_iuh.tex.bak create mode 100644 2015/osmo_iuh/umts_channel_mapping.png create mode 100644 2015/osmo_iuh/umts_hnb_control.pdf create mode 100644 2015/osmo_iuh/umts_hnb_control.svg create mode 100644 2015/osmo_iuh/umts_ps_control.pdf create mode 100644 2015/osmo_iuh/umts_ps_control.svg create mode 100644 2015/osmo_iuh/umts_structure.svg (limited to '2015') diff --git a/2015/bio.txt b/2015/bio.txt new file mode 100644 index 0000000..e893452 --- /dev/null +++ b/2015/bio.txt @@ -0,0 +1,36 @@ +Harald Welte is a data communications freelancer, enthusiast and hacker +who is working with Free Software (and particularly GNU/Linux) +since 1995 His major code contribution to the Linux kernel was as a +core developer of the netfilter/iptables packet filter. + +He has co-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. In 2010, he expanded those +efforts by creating OsmocomBB, a GSM telephony-side baseband processor +firmware and protocol stack. Other projects include +OsmocomTETRA, a receive-only implementation of the ETSI TETRA radio +interface. + +Together with fellow developer Dieter Spaar, Harald has been giving many +incarnations of deeply technical trainings about mobile communications +protocols from the air inteface to the core network, with a special +emphasis on security. + +Harald is co-founder of sysmocom GmbH, Berlin/Germany based company +working on innovative Free Software based products and solutions for +conventional and unconventional operators of mobile networks. Said +projects are also used by various entities in research of mobile +security. diff --git a/2015/bio.txt.bak b/2015/bio.txt.bak new file mode 100644 index 0000000..087372d --- /dev/null +++ b/2015/bio.txt.bak @@ -0,0 +1,29 @@ +Harald Welte is a data communicatiosn freelancer, enthusiast and hacker +who is working with Free Software (and particularly GNU/Linux) +since 1995 His major code contribution to the Linux kernel was as a +core developer of 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. In 2010, he expanded those +efforts by creating OsmocomBB, a GSM teleophony-side baseband processor +firmware and protocol stack. Other projects include +OsmocomTETRA, a receive-only implementation of the ETSI TETRA radio +interface. + +Harald is co-founder of sysmocom - systems for mobile communications +GmbH, a company working on Free Software based products and solutions +for conventional and unconventional operators of mobile networks. diff --git a/2015/hardwear_io/keynote.pdf b/2015/hardwear_io/keynote.pdf new file mode 100644 index 0000000..12adabc Binary files /dev/null and b/2015/hardwear_io/keynote.pdf differ diff --git a/2015/hardwear_io/keynote.snm b/2015/hardwear_io/keynote.snm new file mode 100644 index 0000000..e69de29 diff --git a/2015/hardwear_io/keynote.tex b/2015/hardwear_io/keynote.tex new file mode 100644 index 0000000..aacbe96 --- /dev/null +++ b/2015/hardwear_io/keynote.tex @@ -0,0 +1,543 @@ + +\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 . +% +% 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 +{ + \usetheme{CambridgeUS} + \usecolortheme{whale} + +%\setbeamercolor{titlelike}{parent=palette primary,fg=black} +\setbeamercolor{frametitle}{use=block title,fg=black,bg=block title.bg!10!bg} +% from beamercolorthemeorchid.sty to make it look more like warsaw +\setbeamercolor{block title}{use=structure,fg=white,bg=structure.fg!75!black} +\setbeamercolor{block title alerted}{use=alerted text,fg=white,bg=alerted text.fg!75!black} +\setbeamercolor{block title example}{use=example text,fg=white,bg=example text.fg!75!black} + +\setbeamercolor{block body}{parent=normal text,use=block title,bg=block title.bg!10!bg} +\setbeamercolor{block body alerted}{parent=normal text,use=block title alerted,bg=block title alerted.bg!10!bg} +\setbeamercolor{block body example}{parent=normal text,use=block title example,bg=block title example.bg!10!bg} + + + + % or ... + + %\setbeamercovered{transparent} + % or whatever (possibly just delete it) +} + +\mode{ + \usepackage{misc/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, tabsize=8} + + +\title{Telecom Security - lessons learned (or not)?} + +\subtitle{Personal review on the last 7 years} + +\author{Harald~Welte} + +\institute{hardwear.io 2015 Keynote} + +% - Use the \inst command only if there are several affiliations. +% - Keep it simple, no one is interested in your street address. + +\date[October 2015] % (optional, should be abbreviation of conference name) +%{DeepSec Conference, November 2011, 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} +% 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}{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. + +\begin{frame}{About} +\begin{itemize} + \item Linux Kernel / bootloader / driver / firmware developer since 1999 + \item Former core developer of Linux packet filter netfilter/iptables + \item Comms / Network Security beyond TCP/IP + \begin{itemize} + \item OpenPCD, librfid, libmtrd, OpenBeacon + \item deDECTed.org project + \item Openmoko - FOSS smartphone with focus on security + owner device control + \item OpenBSC as network-side FOSS GSM Stack + \item OsmocomBB - device-side GSM protocol stack + baseband firmware + \end{itemize} + \item practical security research / testing on baseband side and + telecom infrastructure side + \item running a small team at sysmocom GmbH in Berlin, building + custom tailored mobile communications technology +\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{Hardware Security? Embedded Security?} + +\begin{frame}{Terminology / Perspective} +\begin{itemize} + \item Many people speak about {\em hardware security} but mean {\em embedded systems security} + \item Embedded systems today (Android, etc.) are more complex + than PCs 10 years ago, so that's not primarily hardware security + but classic software security + \item Actual hardware security (tamper protection, avoiding + information leakage via side-channels, preventing + glitching, ...) is a very narrow topic, too + \item There's a lot of deeply-embedded firmware in between, what + I consider the area in biggest need of attention. +\end{itemize} +\end{frame} + +\section{Telecom Security} + +\begin{frame}{Mobile / Telecom Security} +Main areas: +\begin{itemize} + \item Phone-side baseband security + \item Air interface security + \item Radio Access Network Security + \item Back-haul network security + \item Core network security + \item Interconnect security +\end{itemize} +\end{frame} + +\begin{frame}{Phone-side baseband security} +\begin{itemize} + \item Since 2009, there are accessible tools to run your own + GSM/GPRS network to attack phones (OsmoBTS, OpenBSC, + OsmoSGSN, etc.) + \item baseband exploiting via malformed air interface messages + has been shown multiple times during the last 5 years + (Ralf-Philipp Weinmann, others) + \item some stack/chip vendors started large-scale security code + audits, but by far not the entire industry + \item Still 100\% closed/proprietary environment with very + limited amount of research/attacks + \item Summary: Some improvement, but a long way to go +\end{itemize} +\end{frame} + +\begin{frame}{Air interface security} +\begin{itemize} + \item Some operators have rolled out A5/3 encryption + \item Spec is broken and permits semi-active down-grade attacks + \item Industry took 7 years from A5/3 specification to first + interop test -> fail. + \item Summary: Nice try, but way too late and way too little +\end{itemize} +\end{frame} + +\begin{frame}{Radio Access Network Security} +\begin{itemize} + \item Still no standard practise to do penetration testing on +BTS, NodeB, eNodeB + \item Equipment makers putting pressure on operator to cancel + already scheduled penetration tests! + \item Sometimes there are very basic / superficial tests as part + of a tender + \item No single known/documented/public case where an operator + or a equipment maker consistently pen-tested all of + their equipment + \item Summary: No visible change from 7 years ago +\end{itemize} +\end{frame} + +\begin{frame}{Core Network Security} +\begin{itemize} + \item See Radio Access Network Security + \item Occasional pen-testing is performed and reveals horrible + implementation bugs in affected equipment + (MSC/VLR/HLR/SGSN) + \item Summary: No visible change from 7 years ago +\end{itemize} +As all core network elements are software implementatiosn these days, +this is 100\% a software security topic! +\end{frame} + +\begin{frame}{Interconnect Security} +\begin{itemize} + \item Still no standard practise to have packet filter / + firewall / IDS / IPS like functionality for SS7/SIGTRAN + interfaces + \item I don't know of any operator who has any idea about what + actually is happening on their roaming interfaces + \item No matter how many clearly suspicious/malicious messages + you get from a roaming/interconnect partner, it triggers + no alarm + \item Only fraud gets detected from a certain scale onwards and + triggers investigation + \item Summary: No visible change from 7 years ago +\end{itemize} +\end{frame} + +\section{Symptoms} + +\begin{frame}{Telco vs. Internet-driven IT security} +mobile industry today has security practises 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 / firewalls on signalling traffic + \item active hostility towards operators who want to do pen-testing + \item attempts to use legal means to stop researchers from publishing their findings +\end{itemize} +this sounds like medieval times. We are in 2015 ?!? +\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 overall 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} + +\begin{frame}{The A5/3 disaster}{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 disaster} +\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 Infrastructure 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} + +\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{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 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 defenses, 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 mono-culture} +\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-upgradeability of components +\end{itemize} +\end{frame} + +\begin{frame}{Long-term maintenance/upgradeability} +\begin{itemize} + \item Just having the capability for secure upgrades is only the + start + \item manufacturers need to commit to {\em decades} of security + fixes and updates for infrastructure parts that are + often used ten years and more. + \item unless that's required from before the purchase, they won't + do it + \item source code escrow mandatory in case of manufacturers + going out of business + \item Operators need to bring those requirements to their tenders! +\end{itemize} +\end{frame} + + +%\begin{frame}{Engagement with the security community} +%\begin{itemize} + %\item Actively engage academic and individual security researchers + %\item Suing 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}{Summary} +\begin{itemize} + \item A lot of tools are available for 7 years now + \item They have not been used as much as they could + \item Operators and Equipment makers still largely ignorant of + the problems + \item We are still at the tip of the iceberg +\end{itemize} +\end{frame} + +\begin{frame}{Thanks} +Thanks for your attention. I hope we have time for Q\&A. +\end{frame} + + + + +\end{document} diff --git a/2015/hardwear_io/keynote.tex.bak b/2015/hardwear_io/keynote.tex.bak new file mode 100644 index 0000000..f27a4de --- /dev/null +++ b/2015/hardwear_io/keynote.tex.bak @@ -0,0 +1,543 @@ + +\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 . +% +% 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 +{ + \usetheme{CambridgeUS} + \usecolortheme{whale} + +%\setbeamercolor{titlelike}{parent=palette primary,fg=black} +\setbeamercolor{frametitle}{use=block title,fg=black,bg=block title.bg!10!bg} +% from beamercolorthemeorchid.sty to make it look more like warsaw +\setbeamercolor{block title}{use=structure,fg=white,bg=structure.fg!75!black} +\setbeamercolor{block title alerted}{use=alerted text,fg=white,bg=alerted text.fg!75!black} +\setbeamercolor{block title example}{use=example text,fg=white,bg=example text.fg!75!black} + +\setbeamercolor{block body}{parent=normal text,use=block title,bg=block title.bg!10!bg} +\setbeamercolor{block body alerted}{parent=normal text,use=block title alerted,bg=block title alerted.bg!10!bg} +\setbeamercolor{block body example}{parent=normal text,use=block title example,bg=block title example.bg!10!bg} + + + + % or ... + + %\setbeamercovered{transparent} + % or whatever (possibly just delete it) +} + +\mode{ + \usepackage{misc/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, tabsize=8} + + +\title{Telecom Security - lessons learned (or not)?} + +\subtitle{Personal review on the last 7 years} + +\author{Harald~Welte} + +\institute{hardwear.io 2015 Keynote} + +% - Use the \inst command only if there are several affiliations. +% - Keep it simple, no one is interested in your street address. + +\date[October 2015] % (optional, should be abbreviation of conference name) +%{DeepSec Conference, November 2011, 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} +% 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}{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. + +\begin{frame}{About} +\begin{itemize} + \item Linux Kernel / bootloader / driver / firmware developer since 1999 + \item Former core developer of Linux packet filter netfilter/iptables + \item Comms / Network Security beyond TCP/IP + \begin{itemize} + \item OpenPCD, librfid, libmtrd, OpenBeacon + \item deDECTed.org project + \item Openmoko - FOSS smartphone with focus on security + owner device control + \item OpenBSC as network-side FOSS GSM Stack + \item OsmocomBB - device-side GSM protocol stack + baseband firmware + \end{itemize} + \item practical security research / testing on baseband side and + telecom infrastrucuture side + \item running a small team at sysmocom GmbH in Berlin, building + custom tailored mobile communications technology +\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{Hardware Security? Embedded Security?} + +\begin{frame}{Terminology / Perspective} +\begin{itemize} + \item Many people speak about {\em hardware security} but mean {\em embedded systems security} + \item Embedded systems today (Android, etc.) are more complex + than PCs 10 years ago, so that's not primarily hardware security + but classic software security + \item Actual hardware security (tamper protection, avoiding + information leakage via side-channels, preventing + glitching, ...) is a very narrow topic, too + \item There's a lot of deeply-embedded firmware in between, what + I consider the area in biggest need of attention. +\end{itemize} +\end{frame} + +\section{Telecom Security} + +\begin{frame}{Mobile / Telecom Security} +Main areas: +\begin{itemize} + \item Phone-side baseband security + \item Air interface security + \item Radio Access Network Security + \item Back-haul network security + \item Core network security + \item Interconnect security +\end{itemize} +\end{frame} + +\begin{frame}{Phone-side baseband securty} +\begin{itemize} + \item Since 2009, there are accessible tools to run your own + GSM/GPRS network to attack phones (OsmoBTS, OpenBSC, + OsmoSGSN, etc.) + \item baseband exploiting via malformed air interface messages + has been shown multiple times during the lat 5 years + (Ralf-Philipp Weinmann, others) + \item some stack/chip vendors started large-scale security code + audits, but by far not the entire industry + \item Still 100\% closed/proprietary environment with very + limited amount of research/attacks + \item Summary: Some improvement, but a long way to go +\end{itemize} +\end{frame} + +\begin{frame}{Air interface secrity} +\begin{itemize} + \item Some operators have rolled out A5/3 encryption + \item Spec is broken and permits semi-active down-grade attacks + \item Industry took 7 years from A5/3 specification to first + interop test -> fail. + \item Summary: Nice try, but way too late and way too little +\end{itemize} +\end{frame} + +\begin{frame}{Radio Access Network Security} +\begin{itemize} + \item Still no standard practise to do penetration testing ond +BTS, NodeB, eNodeB + \item Equipment makers putting pressure on operator to cancel + already scheduled penetration tests! + \item Sometimes there are very basic / superficial tests as part + of a tender + \item No single known/documented/public case where an operator + or a equipment maker consistently pen-tested all of + their equipment + \item Summary: No visible change from 7 years ago +\end{itemize} +\end{frame} + +\begin{frame}{Core Network Security} +\begin{itemize} + \item See Radio Access Netwok Security + \item Occasional pen-testing is performed and reveals horrible + implementation bugs in affected equipment + (MSC/VLR/HLR/SGSN) + \item Summary: No visible change from 7 years ago +\end{itemize} +As all core network elements are software implementatiosn these days, +this is 100\% a software security topic! +\end{frame} + +\begin{frame}{Interconnect Security} +\begin{itemize} + \item Still no standard practise to have packet filter / + firewall / IDS / IPS like functionality for SS7/SIGTRAN + intefaces + \item I don't know of any operator who has any idea about what + actually is happening on their roaming interfaces + \item No matter how many clearly suspicious/malicous messages + you get from a roaming/interconnect partner, it triggers + no alarm + \item Only fraud gets detected from a certain scale onwards and + triggers investigation + \item Summary: No visible change from 7 years ago +\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 / firewalls 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 2015 ?!? +\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} + +\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} + +\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{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 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}{Long-term maintenance/upgradability} +\begin{itemize} + \item Just having the capability for secure upgrades is only the + start + \item manufacturers need to commit to {\em decades} of security + fixes and updates for infrastructure parts that are + often used ten years and more. + \item unless that's required from befoe the purchase, they won't + do it + \item source code escrow mandatory in case of manufacturers + going out of business + \item Operators need to bring those requirements to their tenders! +\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}{Summary} +\begin{itemize} + \item A lot of tools are available for 7 years now + \item They have not been used as much as they could + \item Operators and Equipment makors still largely ignorant of + the problems + \item We are still at the tip of the iceberg +\end{itemize} +\end{frame} + +\begin{frame}{Thanks} +Thanks for your attention. I hope we have time for Q\&A. +\end{frame} + + + + +\end{document} diff --git a/2015/osmo_iuh/640px-UMTS_structures.png b/2015/osmo_iuh/640px-UMTS_structures.png new file mode 100644 index 0000000..61f8ff2 Binary files /dev/null and b/2015/osmo_iuh/640px-UMTS_structures.png differ diff --git a/2015/osmo_iuh/iu_cs_stacking.png b/2015/osmo_iuh/iu_cs_stacking.png new file mode 100644 index 0000000..ced0dbf Binary files /dev/null and b/2015/osmo_iuh/iu_cs_stacking.png differ diff --git a/2015/osmo_iuh/iu_ps_stacking.png b/2015/osmo_iuh/iu_ps_stacking.png new file mode 100644 index 0000000..b657dfe Binary files /dev/null and b/2015/osmo_iuh/iu_ps_stacking.png differ diff --git a/2015/osmo_iuh/iuh_stacking.png b/2015/osmo_iuh/iuh_stacking.png new file mode 100644 index 0000000..9297962 Binary files /dev/null and b/2015/osmo_iuh/iuh_stacking.png differ diff --git a/2015/osmo_iuh/nodeb_hnb.png b/2015/osmo_iuh/nodeb_hnb.png new file mode 100644 index 0000000..b285b74 Binary files /dev/null and b/2015/osmo_iuh/nodeb_hnb.png differ diff --git a/2015/osmo_iuh/osmo_iuh.pdf b/2015/osmo_iuh/osmo_iuh.pdf new file mode 100644 index 0000000..634076f Binary files /dev/null and b/2015/osmo_iuh/osmo_iuh.pdf differ diff --git a/2015/osmo_iuh/osmo_iuh.snm b/2015/osmo_iuh/osmo_iuh.snm new file mode 100644 index 0000000..e69de29 diff --git a/2015/osmo_iuh/osmo_iuh.tex b/2015/osmo_iuh/osmo_iuh.tex new file mode 100644 index 0000000..0edbda0 --- /dev/null +++ b/2015/osmo_iuh/osmo_iuh.tex @@ -0,0 +1,540 @@ + +\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 . +% +% 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 +{ + \usetheme{CambridgeUS} + \usecolortheme{whale} + +%\setbeamercolor{titlelike}{parent=palette primary,fg=black} +\setbeamercolor{frametitle}{use=block title,fg=black,bg=block title.bg!10!bg} +% from beamercolorthemeorchid.sty to make it look more like warsaw +\setbeamercolor{block title}{use=structure,fg=white,bg=structure.fg!75!black} +\setbeamercolor{block title alerted}{use=alerted text,fg=white,bg=alerted text.fg!75!black} +\setbeamercolor{block title example}{use=example text,fg=white,bg=example text.fg!75!black} + +\setbeamercolor{block body}{parent=normal text,use=block title,bg=block title.bg!10!bg} +\setbeamercolor{block body alerted}{parent=normal text,use=block title alerted,bg=block title alerted.bg!10!bg} +\setbeamercolor{block body example}{parent=normal text,use=block title example,bg=block title example.bg!10!bg} + + + + % or ... + + %\setbeamercovered{transparent} + % or whatever (possibly just delete it) +} + +\mode{ + \usepackage{misc/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, tabsize=8} + + +\title{The Iuh protocol stack and osmo-iuh} + +\subtitle{Implementing HNBAP, RUA and RANAP in Free Software} + +\author{Harald~Welte} + +\institute{Osmocom / sysmocom GmbH} + +% - Use the \inst command only if there are several affiliations. +% - Keep it simple, no one is interested in your street address. + +\date[October 2015] % (optional, should be abbreviation of conference name) +%{DeepSec Conference, November 2011, 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{UMTS} +% 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}{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. + +\begin{frame}{About} +\begin{itemize} + \item Linux Kernel / bootloader / driver / firmware developer since 1999 + \item Former core developer of Linux packet filter netfilter/iptables + \item Comms / Network Security beyond TCP/IP + \begin{itemize} + \item OpenPCD, librfid, libmtrd, OpenBeacon + \item deDECTed.org project + \item Openmoko - FOSS smartphone with focus on security + owner device control + \item OpenBSC as network-side FOSS GSM Stack + \item OsmocomBB - device-side GSM protocol stack + baseband firmware + \end{itemize} + \item practical security research / testing on baseband side and + telecom infrastructure side + \item running a small team at sysmocom GmbH in Berlin, building + custom tailored mobile communications technology +\end{itemize} +\end{frame} + +\section{UMTS Architecture and Iuh} + +\subsection{Classic UMTS} + +\begin{frame}{UMTS Architecture} +\begin{figure}[h] + \centering + \includegraphics[width=105mm]{640px-UMTS_structures.png} +\end{figure} +UMTS Structure by Tsaitgaist - icons from Gnome +\end{frame} + +\begin{frame}{UMTS Protocol stacking} +\begin{itemize} + \item Iu is split in Iu-CS (MSC) and Iu-PS (SGSN) + \item Next slides show protocol stacking of Iu-CS and Iu-PS + \item Notice all the ATM legacy that's way obsolete by now + \item IP based transport does away with a lot of it + \item however, M3UA and SCCP remain even on IP based Iu +\end{itemize} +\end{frame} + +\begin{frame}{UMTS protocol stacking} +\begin{figure}[h] + \centering + \includegraphics[width=115mm]{umts_ps_control.pdf} +\end{figure} +\end{frame} + +\begin{frame}{Iu-CS protocol stacking} +\begin{figure}[h] + \centering + \includegraphics[width=70mm]{iu_cs_stacking.png} +\end{figure} +from 3GPP TS 25.410 +\end{frame} + +\begin{frame}{Iu-PS protocol stacking} +\begin{figure}[h] + \centering + \includegraphics[width=75mm]{iu_ps_stacking.png} +\end{figure} +from 3GPP TS 25.410 +\end{frame} + +\subsection{UMTS for HomeNodeB} + +\begin{frame}{UMTS Architecture for hNodeB} +\begin{figure}[h] + \centering + \includegraphics[width=105mm]{nodeb_hnb.png} +\end{figure} +nodeB and Home nodeB by Tsaitgaist - icons from Gnome +\end{frame} + +\begin{frame}{UMTS protocol stacking with HomeNodeB} +\begin{figure}[h] + \centering + \includegraphics[width=115mm]{umts_hnb_control.pdf} +\end{figure} +\end{frame} + +\begin{frame}{Differences NodeB to hNodeB} +\begin{itemize} + \item hNodeB is basically a NodeB with a RNC built-in + \item all lower-level protocols are implemented in the RNC + \item only RANAP is exposed + \item Iuh interface is similar to Iu-CS/Iu-PS + \item Iu interface is at much lower level. + \item Compared with GSM: Iu = Abis, Iuh = A +\end{itemize} +\end{frame} + +\begin{frame}{Why work with hNodeB instead of NodeB} +\begin{itemize} + \item UMTS is not a single telephony system but a set of + re-configurable building blocks to create any type of + telephony system. + \item complexity at every level, particularly the lower levels + \item using hNodeB interface / stack (Iuh), we can avoid having + to worry about RLC/MAC, RRC, HNBAP, etc. + \item many femtocells implement Iuh + \item quite some small cells also implement Iuh +\end{itemize} +\end{frame} + +\begin{frame}{UMTS channel mapping} +speaking of UMTS access stratum complexity... +\begin{figure}[h] + \centering + \includegraphics[width=105mm]{umts_channel_mapping.png} +\end{figure} +from 3GPP TS 25.301 +\end{frame} + +\section{Iuh interface protocols} + +\begin{frame}{A closer look at Iuh} +\begin{itemize} + \item Iuh is {\em basically} just RANAP encapsulated in + something less complex over SCTP/IP + \item In addition to RANAP, there is + \begin{itemize} + \item RUA (RANAP User Adaption) to replace SCCP + \item HNBAP to register hNodeB and UE + \end{itemize} + \item RANAP for both CS and PS is sent together, but on RUA + level there is a {\em Domain Indicator} that helps + separating both. +\end{itemize} +\end{frame} + +\begin{frame}{UMTS protocol stacking for Iuh} +\begin{figure}[h] + \centering + \includegraphics[width=65mm]{iuh_stacking.png} +\end{figure} +from 3GPP TS 25.467 +\end{frame} + +\subsection{RANAP User Adaption} + +\begin{frame}{RUA Protocol (3GPP TS 25.468)} +\begin{itemize} + \item Very simple connection-oriented layer + \begin{itemize} + \item {\tt CONNECT} + \item {\tt DIRECT TRANSFER} + \item {\tt DISCONNECT} + \item {\tt CONNECTIONLESS TRANSFER} + \item {\tt ERROR INDICATION} + \end{itemize} + \item 24-bit Context ID differentiates multiple parallel RUA + connections +\end{itemize} +\end{frame} + +\subsection{HomeNodeB Application Part} + +\begin{frame}{HNBAP Protocol (3GPP TS 25.469)} +\begin{itemize} + \item HNBAP protocol has only very few messages/transactions + \begin{itemize} + \item {\tt HNB REGISTER (REQUEST, ACCEPT, REJECT)} + \item {\tt HNB DE-REGISTER} + \item {\tt UE REGISTER (REQUEST, ACCEPT, REJECT)} + \item {\tt UE DE-REGISTER} + \item {\tt TNL UPDATE (REQUEST, RESPONSE, FAILURE)} + \item {\tt HNB CONFIG TRANSFER (REQUEST, RESPONSE)} + \item {\tt ERROR INDICATION} + \item {\tt CSG MEMBERSHIP UPDATE} + \item {\tt RELOCATION COMPLETE} + \end{itemize} + \item most important is HNB and UE registration +\end{itemize} +\end{frame} + +\subsection{RANAP} + +\begin{frame}{RANAP Protocol (3GPP TS 25.413)} +\begin{itemize} + \item Lots of transactions, some key transactions here: + \begin{itemize} + \item {\tt RESET / RESET ACKNOWLEDGE} + \item {\tt INITIAL UE MESSAGE} + \item {\tt DIRECT TRANSFER} + \item {\tt IU RELEASE (COMMAND, COMPLETE)} + \item {\tt SECURITY MODE (COMMAND, COMPLETE, REJECT)} + \item {\tt PAGING} + \item {\tt RAB ASSIGNMENT (REQUEST, RESPONSE)} + \end{itemize} +\end{itemize} +\end{frame} + +\section{Osmocom and Iu(h)} + +\begin{frame}{SCCP in Free Software} +\begin{itemize} + \item comes in connection-less and connection-oriented flavor + \item is used a lot in SS7 core network protocols + \item connection-oriented SCCP is only used on classic GSM A + interface (over E1) and in UMTS Iu interface + \item no finished free software implementation of + connection-oriented SCCP exists + \begin{itemize} + \item libosmo-sccp, Yate, Mobicents only implement connection-less + \item osmo\_sccp Erlang code has partial but never + completed/tested code for connection-oriented mode + \end{itemize} +\end{itemize} +\end{frame} + +\begin{frame}{How to support UMTS from OsmoNITB, OsmoSGSN} +\begin{itemize} + \item Separation of MSC-part from NITB, generating Osmo-MSS + \begin{itemize} + \item OsmoBSC already implements BSC-side A interface, + we need to add MSC-side A interface + \end{itemize} + \item UMTS AKA support as library, link into OsmoMSS and OsmoSGSN + \item RANAP protocol support in a library, also linked into OsmoMSS and OsmoSGSN + \item NITB: support {\tt subscriber\_connection} over A (BSSMAP/BSSAP) and over RANAP + \item SGSN: support {\tt mm\_context} over Gb (LLC/BSSGP/NS) or over RANAP +\end{itemize} +\end{frame} + +\begin{frame}{How to encapsulate RANAP towards the RAN} +\begin{itemize} + \item we could either + \begin{itemize} + \item Try to convert from Iuh to A interface, make + (h)NodeB look like GSM BTS+BSC. + \item Implement classic Iu-CS and Iu-PS over SCCP/M3Ua + and have a classic HNB-GW to convert to Iuh + \item Implement Iuh directly, avoiding SCCP and M3UA + \end{itemize} + \item Iu-CS/PS requires connection-oriented SCCP + \item when implementing Iuh directly, we still need to somehow + split CS and PS plane + \item Idea: Simple proxy that speaks Iuh to hNodeB, MSS and SGSN + \item Iu-CS/PS over SCCP/M3UA could be added later, if required +\end{itemize} +\end{frame} + +\subsection{Protocol Encoding} + +\begin{frame}{RANAP, RUA and HNBAP Encoding} +\begin{itemize} + \item Use ASN.1 syntax for defining protocol messages + \item Use APER (Aligned Packed Encoding Rules) + \begin{itemize} + \item unlike BER: No Tag/Length values + \item unlike UPER: all fields start at octet boundary + \end{itemize} + \item ASN.1 syntax uses Information Object Classes heavily + \item ASN.1 is not abstract enough for them, so they use ASN.1 to + define containers, i.e. they build something like a TLV structure inside ASN.1 + \begin{itemize} + \item Every IE is its own ASN.1 SEQUENCE, and it gets wrapped into an IE container indicating an IEI and the encoded sequence + \item The Main message then simply has an array (SEQUENCE OF) of IE containers + \end{itemize} + \item Regular ASN.1 code generator will not generate very useful code + for this, i.e. it will not be able to parse the entire message + in one go, but it requires manual iteration code that calls the + generated decoder separately for every IE Container +\end{itemize} +\end{frame} + +\subsection{RANAP, RUA, HNBAP and asn1c} + +\begin{frame}{RANAP, RUA, HNBAP and asn1c} +\begin{itemize} + \item Lev Walkins asn1c is a Free Software ASN.1 compiler / code generator + \item it is good for basic usage, but lacks many if not most of the features required in telecom + \begin{itemize} + \item No support for information object classes + \item No support for aligned PER support + \item No support for type prefixing, i.e. every type uses the same global C namespace and you have problems if RANAP, RUA and/or HNBAP all have types of the same name + \end{itemize} + \item No other free software alternatives exist + \item Somebody with firm knowledge on compiler theory needs to help out, I'm at a loss here. +\end{itemize} +\end{frame} + +\begin{frame}{Alternatives to asn1c} +\begin{itemize} + \item Write all related code in Erlang + \begin{itemize} + \item I tried that in the past, but nobody ever contributed to any of the Osmocom Erlang projects :( + \item At Osmocom we're mostly low-level C guys with an inherent dislike of abstract/complex languages, VMs and the like + \end{itemize} + \item Use proprietary asn1 compiler + \begin{itemize} + \item In theory not a problem, as the compiler has no copyright on the generated C code, we can use it from FOSS + \item Problem: Mandatory runtime code is proprietary + \item We certainly don't want proprietary blobs in Free Software, ever + \item FOSS code would have to be MIT/BSD/LGPL, incompatible with osmo-* GPL/AGPL. + \end{itemize} + \item So it seems we have to stick with asn1c, after all +\end{itemize} +\end{frame} + +\begin{frame}{How to make asn1c work for Iuh} +\begin{itemize} + \item Eurecom has a patch for adding APER support to asn1c + \begin{itemize} + \item it's against an ages old version of asn1c + \item I forward-ported that to current asn1c master + \item Probably needs some clean-up before it can be merged + \end{itemize} + \item Information Object Classes are hard + \begin{itemize} + \item compile only the IE and PDU definitions of the ASN.1 + \item skip all parts related to Information Object Classes + \end{itemize} + \item Type prefixing + \begin{itemize} + \item Could be done in the ASN.1 source files, but that's ugly + \item I hacked asn1c for a day until I finally had found all the locations where prefixing must be used (or not) + \item Code is at {\tt git://git.osmocom.org/asn1c.git} + \end{itemize} +\end{itemize} +\end{frame} + +\begin{frame}{But what about the IE Containers?} +\begin{itemize} + \item Eurecom has an {\tt asn1tostruct.py} script + \begin{itemize} + \item Another layer on top of asn1c to handle the IE containers and un-do the damage caused by the additional layer of abstraction of RANAP and related protocols + \item Developed to cope with S1-AP (RANAP equivalent for LTE) + \item Can be used for Iuh with some modifications + \item Also had to be taught type prefixing + \end{itemize} +\end{itemize} +\end{frame} + +\subsection{osmo-iuh, after all} + +\begin{frame}{Putting it all together} +Brief history of what I did so far: +\begin{itemize} + \item copy+paste Asn.1 syntax from 3GPP .doc files + \item use hacked asn1c to generate C code + \item don't use copied runtime code but shared osmocom libasn1c + \item use modified asn1tostruct.py for the obfuscation layer + \item write some code to dispatch messages + \item implement minimally required transactions like {\tt HNB REGISTER}, {\tt UE REGISTER} + \item see the {\tt INITIAL UE MESSAGE} with the {\tt LOCATION UPDATE} +\end{itemize} +{\tt git clone git://git.osmocom.org/osmo-iuh.git} +\end{frame} + +\begin{frame}{Where do we go from here?} +\begin{itemize} + \item Implement UMTS AKA in libosmogsm, test over GSM and GPRS + \item Crete small HNB-GW with RANAP-over-RUA on both sides, splitting CS and PS + \item Split OsmoMSS from OsmoNITB, add RANAP interface + \item Add RANAP-over-RUA to OsmoSGSN + \item More Volunteers needed! +\end{itemize} +\end{frame} + +\begin{frame}{What kind of hardware can we use?} +\begin{itemize} + \item The (undisclosed) small cell hardware I currently use is very expensive (several thousand EUR) and thus not suitable to most hackers + \item Many consumer-grade femtocells in the market, most modern ones should use Iuh + \begin{itemize} + \item they are typically quite locked down and provide no local console / JTAG + \item they establish an IPsec tunnel to the SEGW (Security Gateway) and then only talk Iuh inside the tunnel + \item Several groups of people have looked at them in the past (including Kevin, Nico and myself) + \item maybe we can find a model that's easily convinced to talk to a different HNB-GW? + \end{itemize} +\end{itemize} +\end{frame} + + +\begin{frame}{Summary} +\begin{itemize} + \item Iuh is actually not difficult conceptually + \item Lack of good FOSS asn1 tools is biggest factor + \item Obfuscation by IE Containers must be overcome + \item In the end you spend 90\% of the time on tooling, before you can spend the remaining 10\% on actual code + \item Core Iuh protocol code exists now as {\tt osmo-iuh} + \item Work on OsmoMSS and OsmoSGSN has not even started yet + \item Volunteers needed. Now! +\end{itemize} +\end{frame} + +\begin{frame}{Thanks} +Thanks for your attention. I hope we have time for Q\&A. +\end{frame} + + +\end{document} diff --git a/2015/osmo_iuh/osmo_iuh.tex.bak b/2015/osmo_iuh/osmo_iuh.tex.bak new file mode 100644 index 0000000..74c5820 --- /dev/null +++ b/2015/osmo_iuh/osmo_iuh.tex.bak @@ -0,0 +1,539 @@ + +\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 . +% +% 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 +{ + \usetheme{CambridgeUS} + \usecolortheme{whale} + +%\setbeamercolor{titlelike}{parent=palette primary,fg=black} +\setbeamercolor{frametitle}{use=block title,fg=black,bg=block title.bg!10!bg} +% from beamercolorthemeorchid.sty to make it look more like warsaw +\setbeamercolor{block title}{use=structure,fg=white,bg=structure.fg!75!black} +\setbeamercolor{block title alerted}{use=alerted text,fg=white,bg=alerted text.fg!75!black} +\setbeamercolor{block title example}{use=example text,fg=white,bg=example text.fg!75!black} + +\setbeamercolor{block body}{parent=normal text,use=block title,bg=block title.bg!10!bg} +\setbeamercolor{block body alerted}{parent=normal text,use=block title alerted,bg=block title alerted.bg!10!bg} +\setbeamercolor{block body example}{parent=normal text,use=block title example,bg=block title example.bg!10!bg} + + + + % or ... + + %\setbeamercovered{transparent} + % or whatever (possibly just delete it) +} + +\mode{ + \usepackage{misc/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, tabsize=8} + + +\title{The Iuh protocol stack and osmo-iuh} + +\subtitle{Implementing HNBAP, RUA and RANAP in Free Software} + +\author{Harald~Welte} + +\institute{Osmocom Project / sysmocom GmbH} + +% - Use the \inst command only if there are several affiliations. +% - Keep it simple, no one is interested in your street address. + +\date[October 2015] % (optional, should be abbreviation of conference name) +%{DeepSec Conference, November 2011, 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{UMTS} +% 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}{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. + +\begin{frame}{About} +\begin{itemize} + \item Linux Kernel / bootloader / driver / firmware developer since 1999 + \item Former core developer of Linux packet filter netfilter/iptables + \item Comms / Network Security beyond TCP/IP + \begin{itemize} + \item OpenPCD, librfid, libmtrd, OpenBeacon + \item deDECTed.org project + \item Openmoko - FOSS smartphone with focus on security + owner device control + \item OpenBSC as network-side FOSS GSM Stack + \item OsmocomBB - device-side GSM protocol stack + baseband firmware + \end{itemize} + \item practical security research / testing on baseband side and + telecom infrastructure side + \item running a small team at sysmocom GmbH in Berlin, building + custom tailored mobile communications technology +\end{itemize} +\end{frame} + +\section{UMTS Architecture and Iuh} + +\subsection{Classic UMTS} + +\begin{frame}{UMTS Architecture} +\begin{figure}[h] + \centering + \includegraphics[width=105mm]{640px-UMTS_structures.png} +\end{figure} +UMTS Structure by Tsaitgaist - icons from Gnome +\end{frame} + +\begin{frame}{UMTS Protocol stacking} +\begin{itemize} + \item Iu is split in Iu-CS (MSC) and Iu-PS (SGSN) + \item Next slides show protocol stacking of Iu-CS and Iu-PS + \item Notice all the ATM legacy that's way obsolete by now + \item IP based transport does away with a lot of it + \item however, M3UA and SCCP remain even on IP based Iu +\end{itemize} +\end{frame} + +\begin{frame}{UMTS protocol stacking} +\begin{figure}[h] + \centering + \includegraphics[width=115mm]{umts_ps_control.pdf} +\end{figure} +\end{frame} + +\begin{frame}{Iu-CS protocol stacking} +\begin{figure}[h] + \centering + \includegraphics[width=70mm]{iu_cs_stacking.png} +\end{figure} +from 3GPP TS 25.410 +\end{frame} + +\begin{frame}{Iu-PS protocol stacking} +\begin{figure}[h] + \centering + \includegraphics[width=75mm]{iu_ps_stacking.png} +\end{figure} +from 3GPP TS 25.410 +\end{frame} + +\subsection{UMTS for HomeNodeB} + +\begin{frame}{UMTS Architecture for hNodeB} +\begin{figure}[h] + \centering + \includegraphics[width=105mm]{nodeb_hnb.png} +\end{figure} +nodeB and Home nodeB by Tsaitgaist - icons from Gnome +\end{frame} + +\begin{frame}{UMTS protocol stacking with HomeNodeB} +\begin{figure}[h] + \centering + \includegraphics[width=115mm]{umts_hnb_control.pdf} +\end{figure} +\end{frame} + +\begin{frame}{Differences NodeB to hNodeB} +\begin{itemize} + \item hNodeB is basically a NodeB with a RNC built-in + \item all lower-level protocols are implemented in the RNC + \item only RANAP is exposed + \item Iuh interface is similar to Iu-CS/Iu-PS + \item Iu interface is at much lower level. + \item Compared with GSM: Iu = Abis, Iuh = A +\end{itemize} +\end{frame} + +\begin{frame}{Why work with hNodeB instead of NodeB} +\begin{itemize} + \item UMTS is not a single telephony system but a set of + re-configurable building blocks to create any type of + telephony system. + \item complexity at every level, particularly the lower levels + \item using hNodeB interface / stack (Iuh), we can avoid having + to worry about RLC/MAC, RRC, HNBAP, etc. + \item many femtocells implement Iuh + \item quite some small cells also implemet Iuh +\end{itemize} +\end{frame} + +\begin{frame}{UMTS channel mapping} +speaking of UMTS access stratum complexity... +\begin{figure}[h] + \centering + \includegraphics[width=105mm]{umts_channel_mapping.png} +\end{figure} +from 3GPP TS 25.301 +\end{frame} + +\section{Iuh interface protocols} + +\begin{frame}{A closer look at Iuh} +\begin{itemize} + \item Iuh is {\em basically} just RANAP encapsulated in + something les complex over SCTP/IP + \item In addition to RANAP, there is + \begin{itemize} + \item RUA (RANAP User Adaption) to replace SCCP + \item HNBAP to register hNodeB and UE + \end{itemize} + \item RANAP for both CS and PS is sent together, but on RUA + level there is a {\em Domain Indicator} that helps + separating both. +\end{itemize} +\end{frame} + +\begin{frame}{UMTS protocol stacking for Iuh} +\begin{figure}[h] + \centering + \includegraphics[width=65mm]{iuh_stacking.png} +\end{figure} +from 3GPP TS 25.467 +\end{frame} + +\subsection{RANAP User Adaption} + +\begin{frame}{RUA Protocol (3GPP TS 25.468)} +\begin{itemize} + \item Very simple connection-oriented layer + \begin{itemize} + \item {\tt CONNECT} + \item {\tt DIRECT TRANSFER} + \item {\tt DISCONNECT} + \item {\tt CONNECTIONLESS TRANSFER} + \item {\tt ERROR INDICATION} + \end{itemize} + \item 24-bit Context ID differentiates multiple parallel RUA + connections +\end{itemize} +\end{frame} + +\subsection{HomeNodeB Application Part} + +\begin{frame}{HNBAP Protocol (3GPP TS 25.469)} +\begin{itemize} + \item HNBAP protocol has only very few messages/transactions + \begin{itemize} + \item {\tt HNB REGISTER (REQUEST, ACCEPT, REJECT)} + \item {\tt HNB DE-REGISTER} + \item {\tt UE REGISTER (REQUEST, ACCEPT, REJECT)} + \item {\tt UE DE-REGISTER} + \item {\tt TNL UPDATE (REQUEST, RESPONSE, FAILURE)} + \item {\tt HNB CONFIG TRANSFER (REQUEST, RESPONSE)} + \item {\tt ERROR INDICATION} + \item {\tt CSG MEMBERSHIP UPDATE} + \item {\tt RELOCATION COMPLETE} + \end{itemize} + \item most important is HNB and UE registration +\end{itemize} +\end{frame} + +\subsection{RANAP} + +\begin{frame}{RANAP Protocol (3GPP TS 25.413)} +\begin{itemize} + \item Lots of transactions, some key transactions here: + \begin{itemize} + \item {\tt RESET / RESET ACKNOWLEDGE} + \item {\tt INITIAL UE MESSAGE} + \item {\tt DIRECT TRANSFER} + \item {\tt IU RELEASE (COMMAND, COMPLETE)} + \item {\tt SECURITY MODE (COMMAND, COMPLETE, REJECT)} + \item {\tt PAGING} + \item {\tt RAB ASSIGNMENT (REQUEST, RESPONSE)} + \end{itemize} +\end{itemize} +\end{frame} + +\section{Osmocom and Iu(h)} + +\begin{frame}{SCCP in Free Software} +\begin{itemize} + \item comes in connection-less and connection-oriented flavor + \item is used a lot in SS7 core network protocols + \item connection-oriented SCCP is only used on classic GSM A + interface (over E1) and in UMTS Iu interface + \item no finished free software implementation of + connection-oriented SCCP exists + \begin{itemize} + \item libosmo-sccp, Yate, Mobicents only implement conneciton-less + \item osmo\_sccp Erlang code has partial but never + completed/tested code for connection-oriented mode + \end{itemize} +\end{itemize} +\end{frame} + +\begin{frame}{How to support UMTS from OsmoNITB, OsmoSGSN} +\begin{itemize} + \item Separation of MSC-part from NITB, generating Osmo-MSS + \begin{itemize} + \item OsmoBSC already implements BSC-side A interface, + we need to add MSC-side A interface + \end{itemize} + \item UMTS AKA support as library, link into OsmoMSS and OsmoSGSN + \item RANAP protocol support in a library, also linked into OsmoMSS and OsmoSGSN + \item NITB: support {\tt subscriber\_connection} over A (BSSMAP/BSSAP) and over RANAP + \item SGSN: support {\tt mm\_context} over Gb (LLC/BSSGP/NS) or over RANAP +\end{itemize} +\end{frame} + +\begin{frame}{How to encapulate RANAP towards the RAN} +\begin{itemize} + \item we could either + \begin{itemize} + \item Try to convert from Iuh to A interface, make + (h)NodeB look like GSM BTS+BSC. + \item Implement classic Iu-CS and Iu-PS over SCCP/M3Ua + and have a classic HNB-GW to convert to Iuh + \item Implement Iuh directly, avoiding SCCP and M3UA + \end{itemize} + \item Iu-CS/PS requires connection-oriented SCCP + \item when implementing Iuh directly, we still need to somehow + split CS and PS plane + \item Idea: Simple proxy that speaks Iuh to hNodeB, MSS and SGSN + \item Iu-CS/PS over SCCP/M3UA could be added later, if required +\end{itemize} +\end{frame} + +\subsection{Protocol Encoding} + +\begin{frame}{RANAP, RUA and HNBAP Encoding} +\begin{itemize} + \item Use ASN.1 syntax for defining protocol messages + \item Use APER (Aligned Packed Encoding Rules) + \begin{itemize} + \item unlike BER: No Tag/Length values + \item unlike UPER: all fields start at octet boundary + \end{itemize} + \item ASN.1 syntax uses Information Object Classes havily + \item ASN.1 is not abstract enough for them, so they use ASN.1 to + define containers, i.e. they build something like a TLV structure inside ASN.1 + \begin{itemize} + \item Every IE is its own ASN.1 SEQUENCE, and it gets wrapped into an IE container indicating an IEI and the encoded sequence + \item The Main message then simply has an array (SEQUENCE OF) of IE containers + \end{itemize} + \item Regular ASN.1 code generator will not generate very useful code + for this, i.e. it wil not be able to parse the entire message + in one go, but it requires manual iteration code that calls the + generated decoder separetely for every IE Container +\end{itemize} +\end{frame} + +\subsection{RANAP, RUA, HNBAP and asn1c} + +\begin{frame}{RANAP, RUA, HNBAP and asn1c} +\begin{itemize} + \item Lev Walkins asn1c is a Free Software ASN.1 compiler / code generator + \item it is good for basic usage, but lacks many if not most of the features required in telecom + \begin{itemize} + \item No support for information object classes + \item No support for aligned PER support + \item No support for type prefixing, i.e. evey type uses the same global C namespace and you have problems if RANAP, RUA and/or HNBAP all have types of the same name + \end{itemize} + \item No other free software alternatives exist + \item Somebody with firm knowledge on compiler theory needs to help out, I'm at a loss here. +\end{itemize} +\end{frame} + +\begin{frame}{Alternatives to asn1c} +\begin{itemize} + \item Write all related code in Erlang + \begin{itemize} + \item I tried that in the past, but nobody ever contributed to any of the osmcoom Erlang projects :( + \item At Osmocom we're mostly low-level C guys with an inherent dislike of abstract/complex languages, VMs and the like + \end{itemize} + \item Use proprietary asn1 compiler + \begin{itemize} + \item In theory not a problem, as the compiler has no copyright on the generated C code, we can use it from FOSS + \item Problem: Mandatory runtime code is proprietary + \item We certainly don't want proprietary blobs in Free Software, ever + \item FOSS code would have to be MIT/BSD/LGPL, incompatible with osmo-* GPL/AGPL. + \end{itemize} + \item So it seems we have to stick with asn1c, after all +\end{itemize} +\end{frame} + +\begin{frame}{How to make asn1c work for Iuh} +\begin{itemize} + \item Eurecom has a patch for adding APER support to asn1c + \begin{itemize} + \item it's against an agest old version of asn1c + \item I forward-ported that to current asn1c master + \item Probably needs some clean-up before it can be merged + \end{itemize} + \item Information Object Classes are hard + \begin{itemize} + \item compile only the IE and PDU definitions of the ASN.1 + \item skip all parts related to Information Object Classes + \end{itemize} + \item Type prefixing + \begin{itemize} + \item Could be done in the ASN.1 source files, but that's ugly + \item I hacked asn1c for a day until I finally had found all the locations where prefixing must be used (or not) + \item Code is at {\tt git://git.osmocom.org/asn1c.git} + \end{itemize} +\end{itemize} +\end{frame} + +\begin{frame}{But what about the IE Containers?} +\begin{itemize} + \item Eurecom has an {\tt asn1tostruct.py} script + \begin{itemize} + \item Another layer on top of asn1c to handle the IE containers and un-do the damage caused by the additional layer of abstraction of RANAP and related protocols + \item Developed to cope with S1-AP (RANAP equipvalent for LTE) + \item Can be used for Iuh wit some modifications + \item Also had to be taught type prefixing + \end{itemize} +\end{itemize} +\end{frame} + +\subsection{osmo-iuh, after all} + +\begin{frame}{Putting it all together} +Brief history of what I did so far: +\begin{itemize} + \item copy+paste Asn.1 syntax from 3GPP .doc files + \item use hacked asn1c to generate C code + \item don't use copied runtime code but shared osmocom libasn1c + \item use modified asn1tostruct.py for the obfuscation layer + \item write some code to dispatch messages + \item implement minimally required transactions like {\tt HNB REGISTER}, {\tt UE REGISTER} + \item see the {\tt INITIAL UE MESSAGE} with the {\tt LOCATION UPDATE} +\end{itemize} +\end{frame} + +\begin{frame}{Where do we go from here?} +\begin{itemize} + \item Implement UMTS AKA in libosmogsm, test over GSM and GPRS + \item Crete small HNB-GW with RANAP-over-RUA on both sides, splitting CS and PS + \item Split OsmoMSS from OsmoNITB, add RANAP interface + \item Add RANAP-over-RUA to OsmoSGSN + \item More Volunteers needed! +\end{itemize} +\end{frame} + +\begin{frame}{What kind of hardware can we use?} +\begin{itemize} + \item The (undisclosed) small cell hardware I currently use is very expensive (several thousand EUR) and thus not suitable to most hackers + \item Many consumer-grade femtocells in the market, most modern ones should use Iuh + \begin{itemize} + \item they are typically quite locked down and provide no local console / JTAG + \item they establish an IPsec tunnel to the SEGW (Security Gateway) and then only talk Iuh inside the tunnel + \item Several groups of people have looked at them in the past (including Kevin, Nico and myself) + \item maybe we can find a model that's easily convinced to talk to a different HNB-GW? + \end{itemize} +\end{itemize} +\end{frame} + + +\begin{frame}{Summary} +\begin{itemize} + \item Iuh is actually not difficult conceptually + \item Lack of good FOSS asn1 tools is biggest factor + \item Obfuscation by IE Containers must be overcome + \item In the end you spend 90\% of the time on tooling, before you can spend the remaining 10\% on actual code + \item Core Iuh protocol code exists now as {\tt osmo-iuh} + \item Work on OsmoMSS and OsmoSGSN has not even started yet + \item Volunteers needed. Now! +\end{itemize} +\end{frame} + +\begin{frame}{Thanks} +Thanks for your attention. I hope we have time for Q\&A. +\end{frame} + + +\end{document} diff --git a/2015/osmo_iuh/umts_channel_mapping.png b/2015/osmo_iuh/umts_channel_mapping.png new file mode 100644 index 0000000..9fc25fa Binary files /dev/null and b/2015/osmo_iuh/umts_channel_mapping.png differ diff --git a/2015/osmo_iuh/umts_hnb_control.pdf b/2015/osmo_iuh/umts_hnb_control.pdf new file mode 100644 index 0000000..2837008 Binary files /dev/null and b/2015/osmo_iuh/umts_hnb_control.pdf differ diff --git a/2015/osmo_iuh/umts_hnb_control.svg b/2015/osmo_iuh/umts_hnb_control.svg new file mode 100644 index 0000000..1dd5a34 --- /dev/null +++ b/2015/osmo_iuh/umts_hnb_control.svg @@ -0,0 +1,1437 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + + + + + + + + MAC + RLC + RRC + GMM + SM + + + + + MAC + RLC + RRC + + + + GMM + SM + + + + RANAP + + + + RANAP + + + + + + + + + + SCCP + + + + + SCCP + Ethernet + + GTP-C + + GTP-C + + + + + + + PhysicalLayer + + + + + + PhysicalLayer + TransportChannels + + TransportChannels + + + + + + + Uu + Iuh + Iu-ps + Gn + MT + hNodeB + HNB-GW + SGSN + GGSN + UMTS Packet Switched Control Plane using HomeNodeB + RUA + + SCTP + IP + RUA + SCTP + IP + SCTP + IP + + M3UA + + M3UA + SCTP + IP + + + + + + + + Ethernet + Ethernet + Ethernet + + Ethernet + + + UDP + IP + + Ethernet + + + UDP + IP + + + + + diff --git a/2015/osmo_iuh/umts_ps_control.pdf b/2015/osmo_iuh/umts_ps_control.pdf new file mode 100644 index 0000000..ae1ef74 Binary files /dev/null and b/2015/osmo_iuh/umts_ps_control.pdf differ diff --git a/2015/osmo_iuh/umts_ps_control.svg b/2015/osmo_iuh/umts_ps_control.svg new file mode 100644 index 0000000..0e24f88 --- /dev/null +++ b/2015/osmo_iuh/umts_ps_control.svg @@ -0,0 +1,1519 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + + + Iub-FP + + + + + + + MAC + RLC + RRC + GMM + SM + + + + + MAC + RLC + RRC + + + + GMM + SM + + + + RANAP + + + + RANAP + + + + + + + + ATM + SAR + CPCS + SSCOP + SSCF/UNI + + Iub-FP + + + + + + ATM + SAR + CPCS + SSCOP + SSCF NNI + + + + + + SCCP + MTP3b + M3UA + SCTP + IP + + + + + + + + ATM + SAR + CPCS + SSCOP + SSCF NNI + + + + + + SCCP + MTP3b + M3UA + SCTP + IP + + + + UDP + IP + Ethernet + + + GTP-C + + + + UDP + IP + Ethernet + + GTP-C + + + + + + + PhysicalLayer + + + + + + + ATM + SAR + CPCS + SSCOP + SSCF/UNI + + PhysicalLayer + + TransportChannels + + TransportChannels + + + + + + + Uu + Iub + Iu-ps + Gn + MT + NodeB + RNC + SGSN + GGSN + UMTS Packet Switched Control Plane + + diff --git a/2015/osmo_iuh/umts_structure.svg b/2015/osmo_iuh/umts_structure.svg new file mode 100644 index 0000000..35095e5 --- /dev/null +++ b/2015/osmo_iuh/umts_structure.svg @@ -0,0 +1,2416 @@ + + + + UMTS structure + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + image/svg+xml + + UMTS structure + 2010-04-15 + + + Kevin (tsaitgaist) Redon + + + key elements of the structure of a UMTS network + + + + icons from gnome + + + https://secure.wikimedia.org/wikipedia/commons/wiki/File:Gsm_structures.svg + + + + + + + + Structure of an UMTS network + CN : Core Network + + MS : Mobile Station + + UE : UserEquipment + + ME : MobileEquipment + + UICC + + UTRAN : Universal TerrestrialRadio Access Network /RNS : RadioNetwork System + + GPRS PS :Packet Switched + + PS & CS + CS : CircuitSwitched + AN : Access Network + + + MSC + HSS + + + + + + + Uu + + Cu + Iub + Iur + + IuPS + PSTN + IuCS + + + + + + + + Nb + Mc + + Nc + E + + B + C + + H + + D + G + + F + + Gf,Sv + + Gd + + Gn + + + Gc + Gp + Gi + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + PSTN + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Internet + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + # + 0 + * + + + + + + + + + + + + Node B + RNC + CS-MGW + SGSN + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + MT/TE + + + + + + + + + + + + USIM + cell + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + GGSN + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + VLR + EIR + MSC server + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + # + 0 + * + + + + + + + + + + + + + + + + HLR + AuC + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + SMS-GMSC + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + # + 0 + * + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + # + 0 + * + + + + GMSC + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + \ No newline at end of file -- cgit v1.2.3