summaryrefslogtreecommitdiff
path: root/2015/hardwear_io/keynote.tex.bak
blob: f27a4de59202e779095083cd37264b502408c6ab (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
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 <tantau@users.sourceforge.net>.
%
% In principle, this file can be redistributed and/or modified under
% the terms of the GNU Public License, version 2.
%
% However, this file is supposed to be a template to be modified
% for your own needs. For this reason, if you use this file as a
% template and not specifically distribute it as part of a another
% package/program, I grant the extra permission to freely copy and
% modify this file as you see fit and even to delete this copyright
% notice. 


\mode<presentation>
{
  \usetheme{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<handout>{
	\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}<beamer>{Outline}
%    \tableofcontents[currentsection,currentsubsection]
%  \end{frame}
%}


% If you wish to uncover everything in a step-wise fashion, uncomment
% the following command: 

%\beamerdefaultoverlayspecification{<+->}


\begin{document}

\begin{frame}
  \titlepage
\end{frame}


% Structuring a talk is a difficult task and the following structure
% may not be suitable. Here are some rules that apply for this
% solution: 

% - Exactly two or three sections (other than the summary).
% - At *most* three subsections per section.
% - Talk about 30s to 2min per frame. So there should be between about
%   15 and 30 frames, all told.

% - A conference audience is likely to know very little of what you
%   are going to talk about. So *simplify*!
% - In a 20min talk, getting the main ideas across is hard
%   enough. Leave out details, even if it means being less precise than
%   you think necessary.
% - If you omit details that are vital to the proof/implementation,
%   just say so once. Everybody will be happy with that.

\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}
personal git repositories of Harald Welte. Your mileage may vary