1
00:00:00,000 --> 00:00:12,443
applause
2
00:00:12,443 --> 00:00:15,936
Karsten: Thank you very much
and a very good evening.
3
00:00:15,936 --> 00:00:21,264
We're here yet again to talk about mobile
network attacks, and we're going to give this talk
4
00:00:21,264 --> 00:00:23,674
a somewhat different spin.
5
00:00:23,674 --> 00:00:31,834
Instead of focusing on giving out new vulnerabilities,
and then hinting at how a fix could be,
6
00:00:31,834 --> 00:00:36,601
and suggesting that somebody else would be
responsible for implementing these fixes.
7
00:00:36,601 --> 00:00:42,530
We wanna look at those later stages of the
attack evolution today.
8
00:00:42,530 --> 00:00:50,130
And make sure we don't keep re-creating new
results while old ones are not being resolved yet.
9
00:00:50,130 --> 00:00:53,150
Rest assured there will also be new attacks.
10
00:00:53,150 --> 00:00:56,391
We need to deliver on that every year.
11
00:00:56,391 --> 00:01:05,437
But we want to make sure specifically, to introduce
some dynamics that help everybody,
12
00:01:05,437 --> 00:01:09,422
for networks to become more secure.
13
00:01:09,422 --> 00:01:18,509
My primary goal today is to enable all of you to help
with that evolution, and to do some of the research
14
00:01:18,509 --> 00:01:22,550
that we've been doing in Berlin so far, all over the world.
15
00:01:22,550 --> 00:01:30,996
There will be a couple of tool releases, and a
couple of, hopefully, evolution drivers
16
00:01:30,996 --> 00:01:38,175
In the end, for us security researchers to be successful in
making the world better, we need industry.
17
00:01:38,175 --> 00:01:45,141
As painful as that sounds, we need somebody to put
in a fix, and we haven't been very good
18
00:01:45,141 --> 00:01:50,906
about keeping check on those people that need to put
in fixes for the research that we've been doing
19
00:01:50,906 --> 00:01:55,683
over the last couple of years, and we're going
to complete the picture today.
20
00:01:55,683 --> 00:02:05,201
by talking a little bit about what networks have
been doing around research in two areas.
21
00:02:05,201 --> 00:02:12,189
SIM card attacks, a topic of this year where networks
found themselves in a critical situation
22
00:02:12,189 --> 00:02:19,696
at risk of large parts of the subscriber base being
remotely infected, not in the phone, but in the SIM card.
23
00:02:19,696 --> 00:02:27,489
So there has been fruitful discussion with industry,
and lots of responses, but not enough.
24
00:02:27,489 --> 00:02:32,951
Much more so around GSM intercept, a topic that
probably the NSA discussions have moved
25
00:02:32,951 --> 00:02:38,938
into everbodys mind again, but one that was really
luring for a decade now, that anybody can
26
00:02:38,938 --> 00:02:41,935
intercept your phonecalls at any time.
27
00:02:41,935 --> 00:02:46,354
and again, here we want to check on the network
operators, and make sure that they are
28
00:02:46,354 --> 00:02:53,380
forced into putting in the protection that we deserve.
29
00:02:53,380 --> 00:03:00,408
We first discussed SIM card attacks publicly in August
of this year, after a few months of
30
00:03:00,408 --> 00:03:08,967
responsible disclosure, and we found
a combination of three vulnerabilities,
31
00:03:08,967 --> 00:03:15,800
that led to a potentially terrible situation for networks.
32
00:03:15,800 --> 00:03:23,639
The first fragment that we found was the ability
to send binary text messages from one subscriber
33
00:03:23,639 --> 00:03:30,434
to really any other subscriber, so networks
allowed traffic that has no place to be routed
34
00:03:30,434 --> 00:03:36,474
through networks, there's no such thing as network
neutrality in mobile networks of course,
35
00:03:36,474 --> 00:03:42,566
they shouldn't be routing internal management applications through what basically is
36
00:03:42,566 --> 00:03:46,783
the IP space, or the phone number space of subscribers.
37
00:03:46,783 --> 00:03:52,691
The second thing we found is that the services that
these messages reach on the SIM cards are
38
00:03:52,691 --> 00:04:01,828
often badly protected cryptographically. In particular
we were finding lots of cards that used DES keys
39
00:04:01,828 --> 00:04:08,557
56-bit from the seventies, that has long been
phased out in pretty much any other application.
40
00:04:08,557 --> 00:04:10,888
SIM cards still use old keys like that.
41
00:04:10,888 --> 00:04:17,940
And thirdly we found that applications you
could install through those DES keys
42
00:04:17,940 --> 00:04:24,300
can break out of the sandbox of the Java protection
parameter, and then access all kinds of data
43
00:04:24,300 --> 00:04:28,643
on the SIM card that no Java was supposed to access.
44
00:04:28,643 --> 00:04:36,203
And combining those three made for a remote
SIM cloning vector at massive scale.
45
00:04:36,203 --> 00:04:40,889
And networks raced to fix those on at least
two of the three layers.
46
00:04:40,889 --> 00:04:48,222
They put in filtering so the network, the SMS
messages would not reach the phone any more.
47
00:04:48,222 --> 00:04:52,123
And they upgraded DES keys to triple DES keys.
48
00:04:52,123 --> 00:04:56,700
But most networks left it at that without really
thinking through the problem and without really
49
00:04:56,700 --> 00:05:02,195
understanding the root causes of what
made the SIM card so vulnerable.
50
00:05:02,195 --> 00:05:07,454
So I want to go into the first two categories, since
the third one wasn't adressed even until today, and
51
00:05:07,454 --> 00:05:12,291
show how the industry response
was in large part insufficient.
52
00:05:12,291 --> 00:05:17,519
And I shouldn't generalise as I do now, because
some network operators have responded very
53
00:05:17,519 --> 00:05:23,783
responsibly, but by and large networks shrugged
us off or put in quick fixes and then moved on to
54
00:05:23,783 --> 00:05:30,531
their daily business of making networks faster
and faster and faster, but rarely more secure.
55
00:05:30,531 --> 00:05:36,583
So let's look at filtering first, and what
goes wrong with filtering.
56
00:05:36,583 --> 00:05:43,808
Networks, many networks started filtering at
around the time when we presented this publicly,
57
00:05:43,808 --> 00:05:51,795
around Black Hat and OHM camp, and they put in
one specific filtering rule that was not surprisingly
58
00:05:51,795 --> 00:05:56,744
the exact message that we used in demonstrations
at Black Hat and at OHM to demonstrate this
59
00:05:56,744 --> 00:06:04,185
class of vulnerabilities, but did not understand
how much broader the vulnerabilty class is.
60
00:06:04,185 --> 00:06:13,957
So to put this in a comparison to computer security,
if you tell somebody that they have a problem in a
61
00:06:13,957 --> 00:06:21,605
TCP stack, let's say in the linux implementation,
and you demo it by sending packets to the ssh daemon,
62
00:06:21,605 --> 00:06:27,944
the fix that they implemented is to block port 22, not
understanding that of course this exact same
63
00:06:27,944 --> 00:06:32,245
vulnerability is also present on any
other exposed TCP service,
64
00:06:32,245 --> 00:06:37,805
And there's bunches of ways to format
an SMS to reach the SIM card.
65
00:06:37,805 --> 00:06:44,513
Some have come out of the standard, others are
just fragments of wrong implementations on phones.
66
00:06:44,513 --> 00:06:50,031
In particular some recent android phones will
route pretty much anything to the SIM card.
67
00:06:50,031 --> 00:06:56,358
and that's pretty convenient, because the SIM card
will look at the message and then discard it, if it's not
68
00:06:56,358 --> 00:06:59,520
properly formatted for a SIM card.
69
00:06:59,520 --> 00:07:02,866
So the implementor of the android
phone took the easy way.
70
00:07:02,866 --> 00:07:07,503
Just put everything to the SIM card, it will
decide what it wants and what it doesn't want.
71
00:07:07,503 --> 00:07:14,900
Of course with a phone like that no level of network
filtering, no filtering whatever TCP port will protect it,
72
00:07:14,900 --> 00:07:19,485
Since normal user messages sometimes
get forwarded to the phone.
73
00:07:19,485 --> 00:07:26,639
So the industry response was a bit insufficient here
and we'd like to see more testing of networks
74
00:07:26,639 --> 00:07:34,265
and when we talk about tools we will perhaps
enable you to do exactly that type of testing,
75
00:07:34,265 --> 00:07:39,600
The second area where the industry response falls
way short of understanding the problem,
76
00:07:39,600 --> 00:07:45,193
again I'm generalising here, is that the
configuration of the SIM cards.
77
00:07:45,193 --> 00:07:53,355
We did discuss the problem with DES keys, that you
can break a 56-bit DES key in a minute or so using
78
00:07:53,355 --> 00:08:00,163
a rainbow table, and that of course, this is terrible
if those services are reachable remotely.
79
00:08:00,163 --> 00:08:06,880
And networks then went in to look at
configurations, and lot of them came out
80
00:08:06,880 --> 00:08:11,200
saying "We made sure everything is
triple-DES on our SIM cards"
81
00:08:11,200 --> 00:08:19,334
or at least a few places there was still DES in older
profiles, we patched them to now be triple-DES.
82
00:08:19,334 --> 00:08:24,698
Again that falls way short of
understanding the core issue.
83
00:08:24,698 --> 00:08:29,200
Here's a bit of technical background so you can
appreciate what's going on in the SIM card.
84
00:08:29,200 --> 00:08:34,778
There's a collection of keys, up to sixteen keysets,
and each keyset can have keys for signing and
85
00:08:34,778 --> 00:08:40,239
encryption and so forth, and those keys have
a specific type, DES or triple-DES for instance,
86
00:08:40,239 --> 00:08:43,751
sometimes even AES on very new cards.
87
00:08:43,751 --> 00:08:49,520
And then there's applications on the SIM card
and these applications, there's up to sixteen million
88
00:08:49,520 --> 00:08:51,451
application identifiers.
89
00:08:51,451 --> 00:08:56,034
Of course no sixteen million applications fit on a card,
so some of these are present on
90
00:08:56,034 --> 00:09:03,503
every SIM card, and the application gets to
choose which keys get what level of access.
91
00:09:03,503 --> 00:09:08,291
And what seems to have happened in August is that
the networks go through this first application,
92
00:09:08,291 --> 00:09:14,011
the standard application and make sure that triple-DES
keys are required for signature or encryption or
93
00:09:14,011 --> 00:09:20,100
better, even both. And then the DES keys they
had there, they upgraded to triple-DES.
94
00:09:20,100 --> 00:09:26,449
However we find in a surprisingly large number
of SIM cards the following situation:
95
00:09:26,449 --> 00:09:35,201
One of the other sixteen million applications says
we use this keyset, but we require none of it.
96
00:09:35,201 --> 00:09:41,982
So you send a command to that SIM TAR specifying
this keyset, and you're not required to do
97
00:09:41,982 --> 00:09:44,783
signatures or encryption.
98
00:09:44,783 --> 00:09:50,690
And at that point it doesn't matter if you use triple-DES
or AES or whatever algorithm, this SIM card
99
00:09:50,690 --> 00:09:54,633
will accept any command sent to it.
100
00:09:54,633 --> 00:09:59,646
And again that kind of being obvious to check for
when you're going through your inventory of
101
00:09:59,646 --> 00:10:08,290
SIM cards, but that requires a deeper level
of understanding of these attacks than most
102
00:10:08,290 --> 00:10:12,617
operators seem to have developed for this issue.
103
00:10:12,617 --> 00:10:19,619
So I hope this again helps to carry the point that to
drive the co-evolution of attacks and defenses,
104
00:10:19,619 --> 00:10:26,878
industry is required to think through the attacks and
understand what exactly the attack parameter is.
105
00:10:26,878 --> 00:10:40,766
To make sure it gets across very visually now, I'd like
to get Luca to demo the attack as we think
106
00:10:40,766 --> 00:10:43,873
it would play out in the real world.
107
00:10:43,873 --> 00:10:50,925
and just as one sentence of introduction perhaps,
this is coming from a very recent SIM card
108
00:10:50,925 --> 00:10:56,724
one that we picked up when we started playing
with the iPhone 5 as fingerprint reader.
109
00:10:56,724 --> 00:11:05,887
It's just an US SIM card, and Luca,
what are you going to do now?
110
00:11:08,507 --> 00:11:10,611
Can you switch on his microphone please?
111
00:11:10,611 --> 00:11:20,240
Luca: Ok, so as Karsten said we found this
particularily interesting SIM card and
112
00:11:20,240 --> 00:11:28,257
the last one we found was very recent, it's a
nano SIM and it goes into an iPhone 5.
113
00:11:28,257 --> 00:11:37,222
I'm going to show you what can we do to
bypass the filterset operators have now.
114
00:11:37,222 --> 00:11:56,107
So we put it into the phone. I have here a BTS,
that emulates the real operator network.
115
00:11:56,107 --> 00:12:01,193
Karsten: Of course that's a default way to bypass
any type of filtering that the real network may be
116
00:12:01,193 --> 00:12:09,976
Luka: So now the mobile is connecting, and I'm trying
to show you better, my BTS is sending some SMS's,
117
00:12:09,976 --> 00:12:18,341
as soon as the mobile is close to the BTS, and
it tries to register, because it thinks it is
118
00:12:18,341 --> 00:12:27,983
the home network, I send my application, that
is completly installed without any warning,
119
00:12:27,983 --> 00:12:31,209
or anything on the iPhone.
120
00:12:31,209 --> 00:12:34,358
umm
121
00:12:34,358 --> 00:12:42,825
I want to show you something here, so this is the
first command and it's a delete, since I've already
122
00:12:42,825 --> 00:12:45,147
installed the application many times, I first delete it.
123
00:12:45,147 --> 00:12:46,931
and then I install it again.
124
00:12:46,931 --> 00:12:50,228
Karsten: So this is remote application management.
125
00:12:50,228 --> 00:12:54,430
On a recent SIM card, that requires
no security whatsoever, you can put in
126
00:12:54,430 --> 00:13:00,863
whatever Java software you'd
like to run on this SIM card.
127
00:13:00,863 --> 00:13:05,594
Luka: Ok, so it's finished, took a couple
of seconds, ten seconds, I dunno.
128
00:13:05,594 --> 00:13:12,843
and now the SIM card is infected with a malware,
that every five minutes sends the current location of
129
00:13:12,843 --> 00:13:18,370
the user to the attackers number.
130
00:13:18,370 --> 00:13:26,054
Since the iPhone doesn't show anything, I'm
going to put this SIM card into another phone,
131
00:13:26,054 --> 00:13:32,171
so you can see it better, and you can also
have a proof that it's on the SIM card.
132
00:13:38,244 --> 00:13:43,499
It's not very easy with the nano SIM
into a normal phone.
133
00:13:43,499 --> 00:13:49,800
so this is the other phone, I have a ok..
134
00:13:52,949 --> 00:13:57,640
Karsten: So the virus stays with the SIM
card (when moved to) another phone
135
00:13:57,346 --> 00:14:02,158
Luka:I'm going to turn it on now.
136
00:14:05,450 --> 00:14:07,523
Yeah.
137
00:14:14,768 --> 00:14:20,530
Hopefully it will register to the home network.
138
00:14:26,293 --> 00:14:28,210
Yeah.
139
00:14:32,279 --> 00:14:34,768
Karsten: Is it still set to manual?
140
00:14:34,768 --> 00:14:37,623
Luka: Yeah, it did register.
141
00:14:43,109 --> 00:14:45,306
Yeah,
142
00:14:45,306 --> 00:14:50,674
So we are actually replaying the
attack again, just for fun.
143
00:14:50,674 --> 00:14:53,461
Karsten: Oops.
144
00:14:56,631 --> 00:14:59,946
Luka: [sigh]
Karsten: Bear with us, this is a complex demo
145
00:14:59,946 --> 00:15:05,107
lots of moving parts.
Luka: What I can do is delete the SMS
146
00:15:08,563 --> 00:15:13,333
Luka: So is it showing someting now?
147
00:15:19,809 --> 00:15:23,372
Ok, I'll just try again.
148
00:15:25,987 --> 00:15:33,532
Oh, actually I have a better idea,
so now I stop my fake BTS
149
00:15:33,532 --> 00:15:36,048
Karsten: yeah, better connect to the real network.
150
00:15:36,048 --> 00:15:40,093
Luka: and I let it connect to the real network.
151
00:15:50,844 --> 00:15:55,220
Okay. Let's see.
152
00:16:02,936 --> 00:16:07,168
Karsten: You're confident the virus
got deployed the second time?
153
00:16:07,168 --> 00:16:12,691
Luka: Umm, that's actually a nice...
154
00:16:12,691 --> 00:16:16,933
Okay, yeah that was a.
155
00:16:16,933 --> 00:16:19,788
Karsten: Ok, lets come back to you
in a couple of minutes then.
156
00:16:19,788 --> 00:16:23,365
When you've prepared this, but everybody
got the idea roughly right,
157
00:16:23,365 --> 00:16:29,205
what should have happend; He's catching
the phone or any of your phones really,
158
00:16:29,205 --> 00:16:35,140
he can test for vulnerabilities by sending
SMS, hundreds of them, not sixteen million,
159
00:16:35,140 --> 00:16:40,230
he has to prepare a little bit, know where
a vulnerability could be, and then once
160
00:16:40,230 --> 00:16:47,263
he finds an unprotected application, he just sends
a bunch of binary SMSs and combine that Java file.
161
00:16:47,263 --> 00:16:52,717
and that java file installs on the SIM card and
it stays installed on the SIM card,
162
00:16:52,717 --> 00:16:58,581
and it will every five minutes send the
current location via SMS to his number,
163
00:16:58,581 --> 00:17:04,454
or do any other thing that the Java on
the SIM card is allowed to do.
164
00:17:04,454 --> 00:17:11,719
It could even try to exploit the other parts of the SIM
card through that unpatched Java vulnerability that
165
00:17:11,719 --> 00:17:17,799
a lot of these SIM cards still have.
166
00:17:17,799 --> 00:17:19,535
Installing the virus again?
167
00:17:19,535 --> 00:17:24,814
Luka: It's installing again.
168
00:17:27,646 --> 00:17:34,170
Luka: This was just the best case we found so
you can actually install an application inside the SIM,
169
00:17:34,170 --> 00:17:41,843
in case this is not available, another choice is just
reading the current ciphering key from the SIM.
170
00:17:43,329 --> 00:17:46,440
Karsten: Yeah, so there's a lot of these..
171
00:17:46,440 --> 00:17:50,443
Luka: So this is the message I was waiting for.
172
00:17:50,443 --> 00:17:55,978
Karsten: So this older Nokia phone is the only phone
we ever found that asked whether you allow your
173
00:17:55,978 --> 00:18:02,203
SIM card to send anything back to the attacker.
The iPhone just does it by default without asking you.
174
00:18:02,203 --> 00:18:05,280
Luka: Press yes.
175
00:18:05,280 --> 00:18:10,806
applause
176
00:18:10,806 --> 00:18:13,940
Luka: Oh it's a bit small there. I try to copy
177
00:18:13,940 --> 00:18:16,446
Karsten: Did you want to show more Luka?
178
00:18:16,446 --> 00:18:26,224
Luka: Yeah the phone now sent the SMS to me,
and I want to show how it looks like, so
179
00:18:26,224 --> 00:18:28,800
hmm no.
180
00:18:34,421 --> 00:18:39,429
Something like this? Nope
181
00:18:40,627 --> 00:18:41,299
sighs
182
00:18:41,299 --> 00:18:49,258
I want to enlarge this, so in this little field, there is
the current network, the location area and cell-ID.
183
00:18:49,258 --> 00:18:55,509
So basically it's a very precise location
information about the user.
184
00:18:55,509 --> 00:18:58,538
applause
185
00:18:58,538 --> 00:19:01,005
Karsten: thank you.
186
00:19:01,005 --> 00:19:04,145
applause
187
00:19:04,145 --> 00:19:10,049
Luka: And the best is that this message is not filtered by the operator since it's a normal text SMS.
188
00:19:10,049 --> 00:19:12,190
So it goes through.
189
00:19:12,190 --> 00:19:18,055
Karsten: So a persistant virus on a modern SIM
card, I think that's what was needed to
190
00:19:18,055 --> 00:19:22,725
give the industry another nudge to
deeply understand this.
191
00:19:22,725 --> 00:19:29,951
Now to create some further nudges from you all,
and to fulfill that goal that I stated going in,
192
00:19:29,951 --> 00:19:38,240
to enable everybody to do these tests yourself,
we wanna release a tool today that condenses all
193
00:19:38,240 --> 00:19:43,334
the SIM card knowledge that we collected
over the last couple of years.
194
00:19:43,334 --> 00:19:51,183
It's an open source tool, written in Java, that was
the easiest to speak to SIM cards with, and it tests
195
00:19:51,183 --> 00:19:58,536
for all the vulnerabilites we discussed in August,
including things like triple-DES downgrade which
196
00:19:58,536 --> 00:20:02,509
a lot of operators seem to not
have understood quite yet.
197
00:20:02,509 --> 00:20:07,535
But it also detects these more recent vulnerabilities.
198
00:20:07,535 --> 00:20:13,549
Now scanning these sixteen million possibilites on
a SIM card, and each sixteen keys for them,
199
00:20:13,549 --> 00:20:17,372
that takes a long time, and some older
slower SIM cards up to two weeks.
200
00:20:17,372 --> 00:20:25,515
So one thing the tool does is pre-select these
TAR's smartly, so it only takes a couple of minutes.
201
00:20:25,515 --> 00:20:31,561
It does run on a normal smart card reader,
PC/SC interface, as well as the Osmocom phone
202
00:20:31,561 --> 00:20:33,981
awesome opensource project also.
203
00:20:33,981 --> 00:20:39,125
We patched it a little bit to now act as a smartcard
reader. So of course it can communicate
204
00:20:39,125 --> 00:20:40,502
with a SIM card.
205
00:20:40,502 --> 00:20:46,784
So if you have any of those; PC/SC reader or an
Osmocom phone and a couple of minutes of time,
206
00:20:46,784 --> 00:20:51,271
download the software and please run the tests,
make sure you're not affected, and if you are
207
00:20:51,271 --> 00:20:56,015
be very vocal to your network operator and
demand that these things get removed.
208
00:20:56,015 --> 00:21:03,724
applause
209
00:21:03,724 --> 00:21:06,669
Thank you.
210
00:21:06,669 --> 00:21:13,760
Looking at similar technology or similar weaknesses,
let's revisit the topic of GSM intercept,
211
00:21:13,760 --> 00:21:23,197
and I'll again try to make the point that networks may
be casually interested in fixing some bugs that
212
00:21:23,197 --> 00:21:31,012
they may not have fully understood, so they only did
half the fixes or not at all and again I think this is
213
00:21:31,012 --> 00:21:36,436
of high urgency, understanding now how many
people are intercepting our phone calls.
214
00:21:36,436 --> 00:21:44,235
Network operators are supposed to protect us on
all the frequencies we use and while 3G and 4G
215
00:21:44,235 --> 00:21:53,125
bring pretty ok cryptography with longer key
lengths, most of our calls still go over 2G,
216
00:21:53,125 --> 00:21:54,873
this standard from the eighties.
217
00:21:54,873 --> 00:22:01,816
It's the only technology that can cover large areas,
and even in cities where the cell sizes don't
218
00:22:01,816 --> 00:22:07,160
have to be so large, these frequencies have to
get used because all frequencies are full.
219
00:22:07,160 --> 00:22:14,618
We have a frequency scarcity, so 2G frequencies are
certainly still used by everybody, almost every day.
220
00:22:14,618 --> 00:22:20,230
and on 2G there are two different encryption
standards that are found in the wild.
221
00:22:20,230 --> 00:22:27,280
There's A5/1, the first encryption cipher, the one
that was originally invented along with GSM, back in
222
00:22:27,280 --> 00:22:34,635
the eighties, and then there's A5/3, a ten year
old encryption standard, that's supported by
223
00:22:34,635 --> 00:22:40,541
newer phones, I would say about half the phones
in current use support this A5/3 cipher.
224
00:22:40,541 --> 00:22:44,371
where the other ones will always default to A5/1.
225
00:22:44,371 --> 00:22:50,712
And the network would have to support both of them
in a secure way or as secure as possible way
226
00:22:50,712 --> 00:22:54,277
to sufficiently protect their customers.
227
00:22:54,277 --> 00:22:58,563
Let's visit each of them in turn.
228
00:22:58,563 --> 00:23:08,142
To break A5/1 with tools like the ones we released
some five years ago now, you have to have
229
00:23:08,142 --> 00:23:16,954
some attack surface. It's not enough to have
a tool that can break an A5/1 packet, you also
230
00:23:16,954 --> 00:23:20,577
need to know what's inside the A5/1 packet.
231
00:23:20,577 --> 00:23:26,420
So for one of all these packets you have to predict
the content, you break the key from it, and
232
00:23:26,420 --> 00:23:29,979
then you can decrypt the rest of them as well.
233
00:23:29,979 --> 00:23:33,916
So you've got to start somewhere
to then break the rest of it.
234
00:23:33,916 --> 00:23:39,615
And I believe no spy agency would have a
better way of breaking A5/1 over the air.
235
00:23:39,615 --> 00:23:42,946
They also have to rely on some attack surface.
236
00:23:42,946 --> 00:23:50,187
So if everything is unpredicable, it basically
becomes XOR'ing random numbers.
237
00:23:50,187 --> 00:23:58,614
The GSMA and later the 3GPP, the standardisation
bodies, that tried to make the mobile world
238
00:23:58,614 --> 00:24:05,635
a little bit more secure, they worked hard
some five years ago to amend standards for
239
00:24:05,635 --> 00:24:08,045
this attack surface to go away.
240
00:24:08,045 --> 00:24:14,808
So in a standard trace as we see it in too many
networks pretty much everything that is
241
00:24:14,808 --> 00:24:19,287
encrypted is predictable, at least in the call setup.
242
00:24:19,287 --> 00:24:28,238
So the phone starts unencrypted, it receives
a ciphering mode command and it will then
243
00:24:28,238 --> 00:24:35,570
encrypt every single packet it sends, and also
expect packets it receives to be encrypted,
244
00:24:35,570 --> 00:24:38,266
including some that actually make sense, where it
245
00:24:38,266 --> 00:24:42,732
says, "Here, you phone with that TMSI, have
another TMSI", but also things are
246
00:24:42,732 --> 00:24:49,193
encrypted that carry not content whatsoever, like
a null frame, that says the network is supposed to
247
00:24:49,193 --> 00:24:54,986
speak now, but it has nothing to say, but also things
with static content, like these system information
248
00:24:54,986 --> 00:25:02,157
messages. This exact same message was sent
maybe a second earlier unencrypted.
249
00:25:02,157 --> 00:25:08,829
And once it switches on encryption the phone
expects this also to be encrypted.
250
00:25:08,829 --> 00:25:14,394
Then there's messages with very little content
and again null frames. Things that bascially have
251
00:25:14,394 --> 00:25:19,299
no meaning whatsoever. Assignment to certain
frequencies, there are not many frequencies
252
00:25:19,299 --> 00:25:25,546
to choose from so this is mostly predictable,
and all of this is to be considered attack surface.
253
00:25:25,546 --> 00:25:30,453
And there are two standards, padding randomisation,
which takes shorter messages and
254
00:25:30,453 --> 00:25:38,281
appends random bytes, and SI5 randomisation which
takes longer messages but scrambles that content,
255
00:25:38,281 --> 00:25:41,533
that removes this attack surface almost entirely.
256
00:25:41,533 --> 00:25:48,643
The little bit of attack surface that's left is due
to vendor specific communications, and
257
00:25:48,643 --> 00:25:51,783
this needs to be fixed vendor by vendor.
258
00:25:51,783 --> 00:25:58,794
But by just putting in those two standards,
A5/1 calls should be protected from at least
259
00:25:58,794 --> 00:26:02,120
the tools that we can think of.
260
00:26:02,120 --> 00:26:07,118
Now given that this is five years ago that these
were standardised and that there is a lot of
261
00:26:07,118 --> 00:26:14,872
pressure on security these days. You'd imagine
that these fixes, just tiny software fixes,
262
00:26:14,872 --> 00:26:20,968
would be deployed thoroughly, however we
rarely see networks that do either of them,
263
00:26:20,968 --> 00:26:24,266
and we've never seen a network
that does both these fixes.
264
00:26:24,266 --> 00:26:29,730
So somewhere along the way, between the
GSMA and 3GPP who write the standards
265
00:26:29,730 --> 00:26:33,242
and you as a customer, that idea got lost.
266
00:26:33,242 --> 00:26:38,893
And it's not a difficult idea, to throw in some
random numbers, instead of static values,
267
00:26:38,893 --> 00:26:45,198
or to take a message and scramble its contents.
These things should be pretty straight forward to
268
00:26:45,198 --> 00:26:50,613
implement, and we've seen both ideas in the wild,
so there is proof that at least some vendors
269
00:26:50,613 --> 00:26:52,212
have implemented these features.
270
00:26:52,212 --> 00:26:58,033
However the networks do not
seem to be using them at all.
271
00:26:58,033 --> 00:27:04,210
The same attack surface then would open up for
A5/3 if somebody had a much bigger computer
272
00:27:04,210 --> 00:27:08,516
to decrypt it. And by much bigger
I mean about a million dollars.
273
00:27:08,516 --> 00:27:14,530
So A5/3 is now ten years old and ten years
ago it seemed like a great idea to take
274
00:27:14,530 --> 00:27:22,160
a 64-bit stream cipher and make a 64-bit block
cipher out of it, you don't have to mess
275
00:27:22,160 --> 00:27:27,757
with key generation or anything, it becomes
much more secure, and in fact it did,
276
00:27:27,757 --> 00:27:31,038
two million times more secure.
277
00:27:31,038 --> 00:27:37,537
But guess who's going to spend a million dollars
to break your A5/3 encrypted call, this year right.
278
00:27:37,537 --> 00:27:44,437
and not just that one agency, every agency has a
spare one million dollar to build an A5/3 cracker.
279
00:27:44,437 --> 00:27:49,496
So industry took ten years to implement
this standard, and now that they do,
280
00:27:49,496 --> 00:27:54,990
in Germany for instance two networks just
started this past month to roll out A5/3,
281
00:27:54,990 --> 00:27:57,819
now it's already outdated.
282
00:27:57,819 --> 00:28:03,124
Guess what, the next standard was developed
five years ago again. A5/4 it's called,
283
00:28:03,124 --> 00:28:07,206
it blows up the key size to a good 128-bit,
284
00:28:07,206 --> 00:28:13,483
it steals that from the 3G part of the SIM card,
but every SIM card these days is a 3G sim card.
285
00:28:13,483 --> 00:28:20,704
So somehow we are always ten years behind
the state of the art in cryptography, and
286
00:28:20,704 --> 00:28:28,557
ten years behind what even industry describes,
prescribes themselves to implement.
287
00:28:28,557 --> 00:28:35,111
We want that to change, and again we want you
to help us change that by creating awareness
288
00:28:35,111 --> 00:28:39,040
around where networks put in
what type of countermeasures.
289
00:28:39,040 --> 00:28:43,516
It's not enough for them to standardise
padding randomisation and SI5 randomisation,
290
00:28:43,516 --> 00:28:49,286
It's not enough for them to specify A5/3 and
A5/4, they actually need to deploy it.
291
00:28:49,286 --> 00:28:55,723
And here's three tools you can
use to create some visibility.
292
00:28:55,723 --> 00:29:00,425
The first two we're releasing today, and the
third one has always been available, there's just
293
00:29:00,425 --> 00:29:04,006
an incremental patch from us today.
294
00:29:04,006 --> 00:29:09,915
First one runs on an android phone and
it allows you to record network traces.
295
00:29:09,915 --> 00:29:15,575
Those network traces of course tell you what type
of encryption is used, whether keys get rolled over,
296
00:29:15,575 --> 00:29:22,070
whether your temporary identity gets
changed regularly, and so forth.
297
00:29:22,070 --> 00:29:28,298
The second tool is basically the same running on a
linux computer, if you want to have the data for
298
00:29:28,298 --> 00:29:37,110
further analysis, with the xgoldmontool,
Tobias Engel's tool.
299
00:29:37,110 --> 00:29:41,420
And then the third possibility for aquiring
the same data, not just for your own phone, but
300
00:29:41,420 --> 00:29:48,034
basically everybody in the cell you're connected to,
is the OsmocomBB open source project.
301
00:29:48,034 --> 00:29:53,268
Sylvain put in a lot of work a few years ago
and created this burst_ind branch,
302
00:29:53,268 --> 00:29:59,520
we extended it just a little bit to run much more
stable and to really help as a capturing tool.
303
00:29:59,520 --> 00:30:06,438
So any of these tools now helps you to look at
what configurations your network is using,
304
00:30:06,438 --> 00:30:11,631
and perhaps interpret this yourself, and to
check whether they are using the latest
305
00:30:11,631 --> 00:30:13,655
encryption and what not.
306
00:30:13,655 --> 00:30:20,874
We'd much appreciate if you shared some of
that information with us, and we could then again
307
00:30:20,874 --> 00:30:26,994
help other by sharing this further and
interpreting the information, and to make that
308
00:30:26,994 --> 00:30:34,309
even easier, we put all these tool in a Live-ISO
that you can put on a USB stick and boot
309
00:30:34,309 --> 00:30:40,010
with it. That has all the tools on it, the network
measurement tools, it has the SIM tester on it,
310
00:30:40,010 --> 00:30:47,156
it has all the stuff on it, catch-a-catcher to
find IMSI catchers in your vincinity.
311
00:30:47,156 --> 00:30:54,516
It has an option to send data to a website called
gsmmap.org and along with all these tools we
312
00:30:54,516 --> 00:31:02,293
are releasing today, a new version of the GSM
map website, much more colourful than before,
313
00:31:02,293 --> 00:31:05,604
but also much more usable we hope.
314
00:31:05,604 --> 00:31:15,868
So here's the new GSM map, and this now
interprets a lot of network traces that many of you
315
00:31:15,868 --> 00:31:24,988
collected over the last couple of years, with Sylvains
burst_ind setup, and for those countries where
316
00:31:24,988 --> 00:31:31,180
we have a little bit of data we do estimates,
these are the striped countries here,
317
00:31:31,180 --> 00:31:40,710
and for those networks where we have a lot of data,
we try to track the network security over time.
318
00:31:40,710 --> 00:31:46,247
So this for instance are the four german networks,
and you see how over time they actually do change
319
00:31:46,247 --> 00:31:54,649
their security settings. T-Mobile for instance,
the high-flyer here, they had a big drop in
320
00:31:54,649 --> 00:32:02,410
network security, intercept this is, by switching off some
of the randomisation, earlier this year, but then
321
00:32:02,410 --> 00:32:08,644
after they did that they started rolling out A5/3,
so somehow they're trading in security features,
322
00:32:08,644 --> 00:32:17,205
one for the other. This now on an aggregate level
tells you how secure your network currently is,
323
00:32:17,205 --> 00:32:24,972
against intercept, basically spy agencies listening
in to your calls, impersonation, that is other
324
00:32:24,972 --> 00:32:30,752
people using your phone identity to conduct
some transaction, and against tracking, that is
325
00:32:30,752 --> 00:32:36,790
somebody following your whereabouts by electronic
means. Basically information exposed through
326
00:32:36,790 --> 00:32:39,172
HLR queries remotely.
327
00:32:39,172 --> 00:32:42,867
And you see how networks
differ in these catgories.
328
00:32:42,867 --> 00:32:48,404
This map by the way is where contributions came
from. So a lot of these of course are collected
329
00:32:48,404 --> 00:32:50,954
by us in Berlin.
330
00:32:50,954 --> 00:32:55,484
But thank you so much to all of you who sent
in all these traces from all these places that
331
00:32:55,484 --> 00:32:58,171
none of us have ever been to.
332
00:32:58,171 --> 00:33:03,059
So it's absolutely fabulous to see what
coverage we've gained here.
333
00:33:03,059 --> 00:33:09,987
Still a lot of striped and white countries,
so we hope to complete the picture, but
334
00:33:09,987 --> 00:33:11,520
we need everybody's help.
335
00:33:11,520 --> 00:33:17,546
And hopefully with the tools we released
today it becomes so much easier to push
336
00:33:17,546 --> 00:33:21,735
data up here, that this will
soon be filled a lot more.
337
00:33:21,735 --> 00:33:27,101
Now for those countries that we have a lot of
data, and that is twenty-seven countries total,
338
00:33:27,101 --> 00:33:36,269
we are releasing detailed reports today
also, that interpret these measurements and
339
00:33:36,269 --> 00:33:42,136
rank the networks, but also explain a little bit
of how we measure these things, but then give you
340
00:33:42,136 --> 00:33:48,430
detailed technical measurements on what encryption
is used, for what types of transactions are
341
00:33:48,430 --> 00:33:51,183
authenticated and so forth.
342
00:33:51,183 --> 00:33:52,771
applause
343
00:33:52,771 --> 00:33:53,524
Thank you.
344
00:33:53,524 --> 00:34:01,010
applause
345
00:34:01,010 --> 00:34:06,680
So if your country is one of the twenty-seven,
we'd love if you read the report.
346
00:34:06,680 --> 00:34:12,324
If it isn't we'd love for you to download the tools
and make sure we can publish a report next month.
347
00:34:12,324 --> 00:34:19,329
So these will be refreshed every month, hopefully
forever, or until every network fulfills every
348
00:34:19,329 --> 00:34:22,967
security goal imaginable and then we
will shut down our website.
349
00:34:22,967 --> 00:34:26,485
laughter
350
00:34:26,485 --> 00:34:35,967
So that's GSM Map, the new website, and
you saw all the tools that are available now.
351
00:34:35,967 --> 00:34:42,290
You may notice that GSM map does not
yet have a security metric on SIM cards.
352
00:34:42,290 --> 00:34:48,018
Just because our measurements are
too sparse to paint a good picture.
353
00:34:48,018 --> 00:34:56,632
We'd like to start calling out the networks that do
bad SIM card security, but again we need your help
354
00:34:56,632 --> 00:35:02,703
to scan your SIM cards, and to make sure we get
some fair comparison among all the networks.
355
00:35:02,703 --> 00:35:09,200
Just as a heads up, we found about in every other
network where we have a lot of SIM cards to test,
356
00:35:09,200 --> 00:35:12,194
vulnerabilites like the ones we discussed today.
357
00:35:12,194 --> 00:35:17,102
So there should be a good chance if you have
couple of SIM cards at home, to find at least a few
358
00:35:17,102 --> 00:35:18,651
that are actually vulnerable.
359
00:35:18,651 --> 00:35:24,285
And if you do you can start installing Java
on them and playing around with them.
360
00:35:24,285 --> 00:35:34,631
Allright, that was everything we wanted to discuss.
A round of thank you, in particular to Lukas and Linus
361
00:35:34,631 --> 00:35:40,506
who have put in many months of really hard work
to get these tools ready for release today,
362
00:35:40,506 --> 00:35:48,103
they were just about ready this morning after many
months of working on them, so thanks to them.
363
00:35:48,103 --> 00:35:51,862
But thanks to everybody else also, who were
involved. There's just a long list of people
364
00:35:51,862 --> 00:35:55,662
who contributed a month or two of work.
365
00:35:55,662 --> 00:36:02,578
Thanks to the open technology fund for sponsoring
this research and for helping us fight
366
00:36:02,578 --> 00:36:10,784
bad security in the world and raising awareness
around where bad security is implemented.
367
00:36:10,784 --> 00:36:18,004
Thank you to all of you for using our tools to take
this research to places that we could not have imagined.
368
00:36:18,004 --> 00:36:19,070
Thanks.
369
00:36:19,070 --> 00:36:25,360
applause
370
00:36:25,360 --> 00:36:30,050
Herald: Thank you very much Karsten and Luca.
So we have quite some time left, so as always if
371
00:36:30,050 --> 00:36:36,221
you have questions, in the room, please line up
behind the four microphones on the ground floor.
372
00:36:36,221 --> 00:36:40,057
If you have questions from the web, or
if you have questions on the streams,
373
00:36:40,057 --> 00:36:44,623
please write them on twitter or on IRC
and we will ask them here live in the room.
374
00:36:44,623 --> 00:36:49,170
And I think we'll start with two
questions from the internet please.
375
00:36:49,170 --> 00:36:51,963
Karsten: One quick...
Signal angel: Okay Herald angel: Wait please.
376
00:36:51,963 --> 00:36:56,806
Karsten: One quick heads-up before the first
people start leaving, if you're interested in playing
377
00:36:56,806 --> 00:37:02,326
with the tools or at least seeing them being
played with there's a workshop that will start
378
00:37:02,326 --> 00:37:09,815
at six in Saal D, so if you want to see the live-ISO
and all its components and perhaps
379
00:37:09,815 --> 00:37:15,333
take a USB stick home, we brought plenty to
play with, saal D is where we'll meet you in a few
380
00:37:15,333 --> 00:37:18,225
minutes. Sorry, go ahead with the questions.
381
00:37:18,225 --> 00:37:20,896
Herald: Okay, two questions
from the internet now.
382
00:37:20,896 --> 00:37:29,427
Signal angel: So first one: there are still many low
hanging fruits, so what about SS7 networks, did you
383
00:37:29,427 --> 00:37:34,999
investigate them and their way of communicating with
each other. Can you tell us anything what happened
384
00:37:34,999 --> 00:37:37,846
with the industry in the last year there?
385
00:37:37,846 --> 00:37:45,344
Karsten: Sure, yeah, SS7 is another decades old
technology that was built with a wrong threat model.
386
00:37:45,344 --> 00:37:49,865
Basically everybody who connects to the network
is trusted, but you have to connect to every
387
00:37:49,865 --> 00:37:56,205
other telco in the world to route calls to them,
so there's some disagreement in the threat model.
388
00:37:56,205 --> 00:38:02,199
And people find SS7 vulnerabilites wherever
they look, both in the configuration, stuff like,
389
00:38:02,199 --> 00:38:08,117
you know, the SIM filtering, the SMS filtering,
the same kinds of topics come up in SS7,
390
00:38:08,117 --> 00:38:15,211
where of course you want to block unneeded traffic,
and networks are really bad at that typically.
391
00:38:15,211 --> 00:38:21,796
But also people find implementation bugs on
boxes that are connected to SS7 and those are
392
00:38:21,796 --> 00:38:23,974
really, really hard to research.
393
00:38:23,974 --> 00:38:29,491
The boxes are very expensive, so you can't just
research it in isolation, and everybody who is
394
00:38:29,491 --> 00:38:36,480
running a box like that, will probably put you
in jail if you ever attempted to break them,
395
00:38:36,480 --> 00:38:39,655
if you started to do some fuzz testing on them.
396
00:38:39,655 --> 00:38:47,182
So SS7 unfortunately isn't really prime for open
research. It actually requires what I showed
397
00:38:47,182 --> 00:38:53,211
on the first slide, kind of a co-evolution where
the networks let the hackers in, so that they
398
00:38:53,211 --> 00:38:57,834
then learn what other hackers could have
done to them, and I don't see many networks
399
00:38:57,834 --> 00:39:00,579
to be ready for that yet.
400
00:39:00,579 --> 00:39:06,920
Definitely a topic with lots of low hanging fruit,
but no easy way to research it.
401
00:39:06,920 --> 00:39:09,468
Signal angel: Okay, thank you.
402
00:39:09,468 --> 00:39:12,461
Signal Angel: Should we go on with the second one?
Karsten: Yes
403
00:39:12,461 --> 00:39:18,051
Signal Angel:Has there been any testing using
parallel application only SIM card overlay
404
00:39:18,051 --> 00:39:23,334
to block apps on the primary SIM card
so that's probably a strange question,
405
00:39:23,334 --> 00:39:28,749
but the MuVuCo? project is mentioned here, or
did you investigate any other simple way to block
406
00:39:28,749 --> 00:39:31,267
the Java card bits?
407
00:39:31,267 --> 00:39:37,281
Karsten: So I think I understood the question as,
is there any easy way of putting in another layer
408
00:39:37,281 --> 00:39:42,798
of protection just in front of your SIM card? I guess
we can't ask the person asking the question right?
409
00:39:42,798 --> 00:39:48,224
But if that were the question then the answer is,
of course you can put all kinds of proxy stuff
410
00:39:48,224 --> 00:39:54,310
in between your phone and your SIM card, there's
a nice open source project called SIMtrace,
411
00:39:54,310 --> 00:39:58,959
That then means you carry a little computer next
to your phone whenever you use it and of course
412
00:39:58,959 --> 00:40:04,877
that's impractical, so that would be a forensic tool
perhaps to investigate what people are currently
413
00:40:04,877 --> 00:40:08,519
doing to your SIM card, when you already have
a suspicion that something is going on, but
414
00:40:08,519 --> 00:40:14,923
there's no practical way to get a phone to give
you that level of access, even on android, the part of
415
00:40:14,923 --> 00:40:24,139
the operating system, the system that speaks with
the SIM card is usually more baseband than android
416
00:40:24,139 --> 00:40:32,872
or at the very least a proprietary device driver type.
So I can't think of any usable phone where
417
00:40:32,872 --> 00:40:38,690
you could easily implement a SIM card firewall
for instance, but I'd love to learn about them
418
00:40:38,690 --> 00:40:41,748
if they do exist.
419
00:40:41,748 --> 00:40:45,331
Herald: Okay we take a question from microphone four.
420
00:40:45,331 --> 00:40:49,731
Question: Did you investigate any upstream
vulnerabilities from or to the baseband
421
00:40:49,731 --> 00:40:56,437
or to the average phone OS, so for instance
if you have infiltrated the SIM card can you do
422
00:40:56,437 --> 00:40:59,642
any stuff to an iPhone or something?
423
00:40:59,642 --> 00:41:05,764
Karsten: Good question, and no we haven't and
I wouldn't think that that would be the most
424
00:41:05,764 --> 00:41:11,180
fruitful vector, because the interface between
a SIM card and a phone is pretty defined,
425
00:41:11,180 --> 00:41:17,803
very narrow channel. So I'd think that a phone
baseband is much easier exploited like Ralph did it
426
00:41:17,803 --> 00:41:23,780
a couple of years ago, emulating a network and
sending commands, that interface is much wider
427
00:41:23,780 --> 00:41:28,773
and has many more protocols running that
could potentially be exploit targets.
428
00:41:28,773 --> 00:41:30,678
Good question though, thank you.
429
00:41:30,678 --> 00:41:33,490
Herald: Okay, number three please.
430
00:41:33,490 --> 00:41:38,684
Question: You showed the map broken down by
country, would it make sense to look at smaller
431
00:41:38,684 --> 00:41:44,377
districts or regions, do we have differences
within one country for example the US.
432
00:41:44,377 --> 00:41:49,661
Karsten: That's a good question, and we have
occasionally come across a country where
433
00:41:49,661 --> 00:41:54,336
there's configuration differences in different
parts of the country, like for instance in Germany
434
00:41:54,336 --> 00:42:00,424
right now, two of the network operators are
rolling out A5/3, but they go location by location.
435
00:42:00,424 --> 00:42:07,543
So there's two zones right now, but those are
going away over time because the goal of course is
436
00:42:07,543 --> 00:42:13,782
to implement the security feature everywhere.
There are networks though where they
437
00:42:13,782 --> 00:42:18,199
purchase one part of the country from one vendor
and another part from another vendor, and
438
00:42:18,199 --> 00:42:23,347
where security patches just don't get deployed
everywhere, and we would like to track that
439
00:42:23,347 --> 00:42:28,884
more accurately. Currently it's just averaged.
What we need to track it more accurately is
440
00:42:28,884 --> 00:42:34,813
constant measurements from more places. So
currently what our metric does is try to fairly
441
00:42:34,813 --> 00:42:40,133
combine information from different location
and then average them even though for instance
442
00:42:40,133 --> 00:42:46,783
in Germany, of course Berlin is dominating in
our measurement set, and some other locations
443
00:42:46,783 --> 00:42:52,780
I think, thank you CCC Munich, are contributing
too, but if there were somewhere in
444
00:42:52,780 --> 00:42:59,170
the middle of Germany, some extra security
feature, we would not learn about it for a long time.
445
00:42:59,170 --> 00:43:08,147
You see this route? This is from last years trip from Hamburg
to Berlin, when everybody came to the CCC. laughter
446
00:43:08,147 --> 00:43:13,846
So we are not distinguishing by country yet,
but if the information is ever there to see
447
00:43:13,846 --> 00:43:17,298
a clear border we'll definitely do that.
448
00:43:17,298 --> 00:43:20,001
Herald: Question from number four please.
449
00:43:20,001 --> 00:43:25,840
Question: Yes, I wanted to ask, you showed that
you were simulating a BTS somewhere around
450
00:43:25,840 --> 00:43:31,968
the middle of the talk, and I was wondering where
you using any of the known OpenBTS or OsmoBTS
451
00:43:31,968 --> 00:43:35,221
solutions or anything else?
452
00:43:35,221 --> 00:43:44,790
Luca: It's a patched version of OpenBSC. It's just
a few lines, there is a nice function that triggers
453
00:43:44,790 --> 00:43:50,540
the software to send the SMS on queue for a
user as soon as the user logs in, and as soon as
454
00:43:50,540 --> 00:43:55,789
the user does this I put a lot of SMS's
in the queue, so I can send it.
455
00:43:55,789 --> 00:44:03,572
Karsten: Yeah there are OpenBSC, OpenBTS,
OsmocomBB project, they are an enormous help in
456
00:44:03,572 --> 00:44:09,336
our research, we could have done none of this,
had we had to implement all of this in open source.
457
00:44:09,336 --> 00:44:14,826
So they're very, very useful, and thank you
to everybody who've contributed to them.
458
00:44:14,826 --> 00:44:17,231
Herald: Another question from number four please.
459
00:44:17,231 --> 00:44:22,730
Question: Banks and other organisations love
to send one-time tokens via SMS, from what I
460
00:44:22,730 --> 00:44:32,658
understand the talk, would it be in the range of the
regular criminal to exploit this and steal those tokens?
461
00:44:32,658 --> 00:44:39,995
Karsten: With GSM intercept yes, you can read
other people's SMS when they're A5/1 encrypted,
462
00:44:39,995 --> 00:44:47,273
however you have to be close to them, in a
proximity of let's say two kilometers, and it's probably
463
00:44:47,273 --> 00:44:52,957
unlikely that the person who infected your online
banking credentials, stole them from your infected
464
00:44:52,957 --> 00:44:59,536
computer, is also your neighbour. Those two
groups seem to overlap in locations.
465
00:44:59,536 --> 00:45:03,970
With the SIM card vulnerabilities though,
you can do lots of stuff, you can send SMS,
466
00:45:03,970 --> 00:45:09,248
you can redirect calls, you can steal decryption
keys, the only thing you can't do is read people's
467
00:45:09,248 --> 00:45:14,507
incoming SMS. So banks got lucky there.
468
00:45:14,507 --> 00:45:19,580
Q: Thanks
Herald: We have another question from the internet.
469
00:45:19,580 --> 00:45:26,524
Q: Wouldn't it be easier to just reinvent maybe a more
nerd driven mobile network from scratch, than
470
00:45:26,524 --> 00:45:32,612
to mess around with all this industry stuff
that has piled up for years now?
471
00:45:32,612 --> 00:45:39,256
Karsten: Well, that's interesting, things do not
really pile up as people imagine them, so the
472
00:45:39,256 --> 00:45:45,147
One of the big drivers of the OpenBSC project
I understand was the availability of really cheap
473
00:45:45,147 --> 00:45:49,453
base stations. Why were they available? Because
people threw them away and replaced
474
00:45:49,453 --> 00:45:53,858
them with newer base stations, and they do
that every time they add a new technology.
475
00:45:53,858 --> 00:45:58,510
So when they added 3G they threw away the 2G
base stations, and replaced them with combined
476
00:45:58,510 --> 00:46:02,210
2G/3G base stations, same with 4G now.
477
00:46:02,210 --> 00:46:07,693
So as 4G is being rolled out all over Germany,
everything gets thrown away and
478
00:46:07,693 --> 00:46:14,046
replaced. There isn't so much legacy in terms of
installed boxes, the legacy is more the protocol,
479
00:46:14,046 --> 00:46:21,523
so if you throw away one end of the connection
and not the other you maintain the old protocol,
480
00:46:21,523 --> 00:46:26,685
but then when you throw away the other side,
you again maintain it because it's kind of the logical
481
00:46:26,685 --> 00:46:36,922
legacy. So I don't think there's an easy fix to that.
This is just very high-scalability engineering where
482
00:46:36,922 --> 00:46:43,963
things have to work in extreme corner cases, and I
think all the tools are there for the existing networks
483
00:46:43,963 --> 00:46:50,521
to get fixed, it's just a question of priority. At the
investment that a 4G network costs, a single one,
484
00:46:50,521 --> 00:46:56,704
you can probably make the entire world use
A5/3 and upgrade to secure SIM cards.
485
00:46:56,704 --> 00:47:01,958
So the money is there, it's just a question of
priority that keeps the networks away from
486
00:47:01,958 --> 00:47:04,223
deploying these software patches.
487
00:47:04,223 --> 00:47:07,718
In the end it's single lines of code.
488
00:47:07,718 --> 00:47:11,488
Herald: Ok, we have another question in
the room from microphone number three.
489
00:47:11,488 --> 00:47:17,543
Q: Quick question, for tools that you are offering
can they work with some kind of passive recording
490
00:47:17,543 --> 00:47:25,459
device, for example can you collect data for gsmmap
using the OsmoSDR tools? The ones that use
491
00:47:25,459 --> 00:47:30,965
the simple DVB-tuners to listen to the spectrum.
492
00:47:30,965 --> 00:47:36,632
Harald: Luca, do you know OsmoSDR?
Luca: Yeah, I think that's more focused on being
493
00:47:36,632 --> 00:47:42,823
a BTS than a sniffer device, but I think you can use
it as a sniffer device, it's just that then you need
494
00:47:42,823 --> 00:47:49,433
to process the data in a different way, really the
easiest is to use the Osmocom mobile phone,
495
00:47:49,433 --> 00:47:55,356
and it does this and it's what we use for the
Live-ISO. There are many models actually, so.
496
00:47:55,356 --> 00:47:59,920
Karsten: What would you consider the
advantage of using an OsmoSDR?
497
00:47:59,920 --> 00:48:04,865
Q:It's mostly because it doesn't require a phone
or a SIM card or anything, The question is can it
498
00:48:04,865 --> 00:48:08,318
work passively without being,
without sending anything?
499
00:48:08,318 --> 00:48:13,126
Karsten: Yeah, the phone he just held up,
that captures traffic with no SIM card and
500
00:48:13,126 --> 00:48:21,204
without connecting to a network, it does so passively
by latching on to a cell, passively, just hearing what
501
00:48:21,204 --> 00:48:27,964
is happening on the broadcast channel, and as soon
as the cell starts communicating with another phone
502
00:48:27,964 --> 00:48:33,909
it jumps to that frequency and also listens to
the traffic. So that's already a passive setup.
503
00:48:33,909 --> 00:48:40,173
And the C139 I think is the most available Osmocom
phone, you can still get that for twelve dollars
504
00:48:40,173 --> 00:48:46,977
in China. So I don't think there's any reason to
reimplement that for any other platform if there's
505
00:48:46,977 --> 00:48:49,181
already a twelve dollar solution.
506
00:48:49,181 --> 00:48:53,606
Q: Thank you.
Herald: And we take another question from the internet
507
00:48:53,606 --> 00:48:57,905
Q: Actually some people are complaining that
they have no signal in this room, could that be
508
00:48:57,905 --> 00:49:02,417
caused by you, or is the range not that large?
509
00:49:02,417 --> 00:49:08,636
Karsten: Well, we add choices for signal, we don't
take them away, so this is just an additional BTS.
510
00:49:08,636 --> 00:49:10,143
laughter
511
00:49:10,143 --> 00:49:12,145
Q: Okay, thank you.
512
00:49:12,145 --> 00:49:18,027
Herald: Ok, are there any other questions,
now is the time to ask. If not I ask you again
513
00:49:18,027 --> 00:49:21,779
for a warm round of applause for Karsten and Luca
514
00:49:21,779 --> 00:49:24,924
applause
515
00:49:24,924 --> 00:49:33,532
subtitles created by c3subtitles.de