WEBVTT
00:00:00.000 --> 00:00:12.443
applause
00:00:12.443 --> 00:00:15.936
Karsten: Thank you very much
and a very good evening.
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
00:00:21.264 --> 00:00:23.674
a somewhat different spin.
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,
00:00:31.834 --> 00:00:36.601
and suggesting that somebody else would be
responsible for implementing these fixes.
00:00:36.601 --> 00:00:42.530
We wanna look at those later stages of the
attack evolution today.
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.
00:00:50.130 --> 00:00:53.150
Rest assured there will also be new attacks.
00:00:53.150 --> 00:00:56.391
We need to deliver on that every year.
00:00:56.391 --> 00:01:05.437
But we want to make sure specifically, to introduce
some dynamics that help everybody,
00:01:05.437 --> 00:01:09.422
for networks to become more secure.
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
00:01:18.509 --> 00:01:22.550
that we've been doing in Berlin so far, all over the world.
00:01:22.550 --> 00:01:30.996
There will be a couple of tool releases, and a
couple of, hopefully, evolution drivers
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.
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
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
00:01:50.906 --> 00:01:55.683
over the last couple of years, and we're going
to complete the picture today.
00:01:55.683 --> 00:02:05.201
by talking a little bit about what networks have
been doing around research in two areas.
00:02:05.201 --> 00:02:12.189
SIM card attacks, a topic of this year where networks
found themselves in a critical situation
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.
00:02:19.696 --> 00:02:27.489
So there has been fruitful discussion with industry,
and lots of responses, but not enough.
00:02:27.489 --> 00:02:32.951
Much more so around GSM intercept, a topic that
probably the NSA discussions have moved
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
00:02:38.938 --> 00:02:41.935
intercept your phonecalls at any time.
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
00:02:46.354 --> 00:02:53.380
forced into putting in the protection that we deserve.
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
00:03:00.408 --> 00:03:08.967
responsible disclosure, and we found
a combination of three vulnerabilities,
00:03:08.967 --> 00:03:15.800
that led to a potentially terrible situation for networks.
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
00:03:23.639 --> 00:03:30.434
to really any other subscriber, so networks
allowed traffic that has no place to be routed
00:03:30.434 --> 00:03:36.474
through networks, there's no such thing as network
neutrality in mobile networks of course,
00:03:36.474 --> 00:03:42.566
they shouldn't be routing internal management applications through what basically is
00:03:42.566 --> 00:03:46.783
the IP space, or the phone number space of subscribers.
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
00:03:52.691 --> 00:04:01.828
often badly protected cryptographically. In particular
we were finding lots of cards that used DES keys
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.
00:04:08.557 --> 00:04:10.888
SIM cards still use old keys like that.
00:04:10.888 --> 00:04:17.940
And thirdly we found that applications you
could install through those DES keys
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
00:04:24.300 --> 00:04:28.643
on the SIM card that no Java was supposed to access.
00:04:28.643 --> 00:04:36.203
And combining those three made for a remote
SIM cloning vector at massive scale.
00:04:36.203 --> 00:04:40.889
And networks raced to fix those on at least
two of the three layers.
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.
00:04:48.222 --> 00:04:52.123
And they upgraded DES keys to triple DES keys.
00:04:52.123 --> 00:04:56.700
But most networks left it at that without really
thinking through the problem and without really
00:04:56.700 --> 00:05:02.195
understanding the root causes of what
made the SIM card so vulnerable.
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
00:05:07.454 --> 00:05:12.291
show how the industry response
was in large part insufficient.
00:05:12.291 --> 00:05:17.519
And I shouldn't generalise as I do now, because
some network operators have responded very
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
00:05:23.783 --> 00:05:30.531
their daily business of making networks faster
and faster and faster, but rarely more secure.
00:05:30.531 --> 00:05:36.583
So let's look at filtering first, and what
goes wrong with filtering.
00:05:36.583 --> 00:05:43.808
Networks, many networks started filtering at
around the time when we presented this publicly,
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
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
00:05:56.744 --> 00:06:04.185
class of vulnerabilities, but did not understand
how much broader the vulnerabilty class is.
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
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,
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
00:06:27.944 --> 00:06:32.245
vulnerability is also present on any
other exposed TCP service,
00:06:32.245 --> 00:06:37.805
And there's bunches of ways to format
an SMS to reach the SIM card.
00:06:37.805 --> 00:06:44.513
Some have come out of the standard, others are
just fragments of wrong implementations on phones.
00:06:44.513 --> 00:06:50.031
In particular some recent android phones will
route pretty much anything to the SIM card.
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
00:06:56.358 --> 00:06:59.520
properly formatted for a SIM card.
00:06:59.520 --> 00:07:02.866
So the implementor of the android
phone took the easy way.
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.
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,
00:07:14.900 --> 00:07:19.485
Since normal user messages sometimes
get forwarded to the phone.
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
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,
00:07:34.265 --> 00:07:39.600
The second area where the industry response falls
way short of understanding the problem,
00:07:39.600 --> 00:07:45.193
again I'm generalising here, is that the
configuration of the SIM cards.
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
00:07:53.355 --> 00:08:00.163
a rainbow table, and that of course, this is terrible
if those services are reachable remotely.
00:08:00.163 --> 00:08:06.880
And networks then went in to look at
configurations, and lot of them came out
00:08:06.880 --> 00:08:11.200
saying "We made sure everything is
triple-DES on our SIM cards"
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.
00:08:19.334 --> 00:08:24.698
Again that falls way short of
understanding the core issue.
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.
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
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,
00:08:40.239 --> 00:08:43.751
sometimes even AES on very new cards.
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
00:08:49.520 --> 00:08:51.451
application identifiers.
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
00:08:56.034 --> 00:09:03.503
every SIM card, and the application gets to
choose which keys get what level of access.
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,
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
00:09:14.011 --> 00:09:20.100
better, even both. And then the DES keys they
had there, they upgraded to triple-DES.
00:09:20.100 --> 00:09:26.449
However we find in a surprisingly large number
of SIM cards the following situation:
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.
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
00:09:41.982 --> 00:09:44.783
signatures or encryption.
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
00:09:50.690 --> 00:09:54.633
will accept any command sent to it.
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
00:09:59.646 --> 00:10:08.290
SIM cards, but that requires a deeper level
of understanding of these attacks than most
00:10:08.290 --> 00:10:12.617
operators seem to have developed for this issue.
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,
00:10:19.619 --> 00:10:26.878
industry is required to think through the attacks and
understand what exactly the attack parameter is.
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
00:10:40.766 --> 00:10:43.873
it would play out in the real world.
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
00:10:50.925 --> 00:10:56.724
one that we picked up when we started playing
with the iPhone 5 as fingerprint reader.
00:10:56.724 --> 00:11:05.887
It's just an US SIM card, and Luca,
what are you going to do now?
00:11:08.507 --> 00:11:10.611
Can you switch on his microphone please?
00:11:10.611 --> 00:11:20.240
Luca: Ok, so as Karsten said we found this
particularily interesting SIM card and
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.
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.
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.
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
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,
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
00:12:18.341 --> 00:12:27.983
the home network, I send my application, that
is completly installed without any warning,
00:12:27.983 --> 00:12:31.209
or anything on the iPhone.
00:12:31.209 --> 00:12:34.358
umm
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
00:12:42.825 --> 00:12:45.147
installed the application many times, I first delete it.
00:12:45.147 --> 00:12:46.931
and then I install it again.
00:12:46.931 --> 00:12:50.228
Karsten: So this is remote application management.
00:12:50.228 --> 00:12:54.430
On a recent SIM card, that requires
no security whatsoever, you can put in
00:12:54.430 --> 00:13:00.863
whatever Java software you'd
like to run on this SIM card.
00:13:00.863 --> 00:13:05.594
Luka: Ok, so it's finished, took a couple
of seconds, ten seconds, I dunno.
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
00:13:12.843 --> 00:13:18.370
the user to the attackers number.
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,
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.
00:13:38.244 --> 00:13:43.499
It's not very easy with the nano SIM
into a normal phone.
00:13:43.499 --> 00:13:49.800
so this is the other phone, I have a ok..
00:13:52.949 --> 00:13:57.640
Karsten: So the virus stays with the SIM
card (when moved to) another phone
00:13:57.346 --> 00:14:02.158
Luka:I'm going to turn it on now.
00:14:05.450 --> 00:14:07.523
Yeah.
00:14:14.768 --> 00:14:20.530
Hopefully it will register to the home network.
00:14:26.293 --> 00:14:28.210
Yeah.
00:14:32.279 --> 00:14:34.768
Karsten: Is it still set to manual?
00:14:34.768 --> 00:14:37.623
Luka: Yeah, it did register.
00:14:43.109 --> 00:14:45.306
Yeah,
00:14:45.306 --> 00:14:50.674
So we are actually replaying the
attack again, just for fun.
00:14:50.674 --> 00:14:53.461
Karsten: Oops.
00:14:56.631 --> 00:14:59.946
Luka: [sigh]
Karsten: Bear with us, this is a complex demo
00:14:59.946 --> 00:15:05.107
lots of moving parts.
Luka: What I can do is delete the SMS
00:15:08.563 --> 00:15:13.333
Luka: So is it showing someting now?
00:15:19.809 --> 00:15:23.372
Ok, I'll just try again.
00:15:25.987 --> 00:15:33.532
Oh, actually I have a better idea,
so now I stop my fake BTS
00:15:33.532 --> 00:15:36.048
Karsten: yeah, better connect to the real network.
00:15:36.048 --> 00:15:40.093
Luka: and I let it connect to the real network.
00:15:50.844 --> 00:15:55.220
Okay. Let's see.
00:16:02.936 --> 00:16:07.168
Karsten: You're confident the virus
got deployed the second time?
00:16:07.168 --> 00:16:12.691
Luka: Umm, that's actually a nice...
00:16:12.691 --> 00:16:16.933
Okay, yeah that was a.
00:16:16.933 --> 00:16:19.788
Karsten: Ok, lets come back to you
in a couple of minutes then.
00:16:19.788 --> 00:16:23.365
When you've prepared this, but everybody
got the idea roughly right,
00:16:23.365 --> 00:16:29.205
what should have happend; He's catching
the phone or any of your phones really,
00:16:29.205 --> 00:16:35.140
he can test for vulnerabilities by sending
SMS, hundreds of them, not sixteen million,
00:16:35.140 --> 00:16:40.230
he has to prepare a little bit, know where
a vulnerability could be, and then once
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.
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,
00:16:52.717 --> 00:16:58.581
and it will every five minutes send the
current location via SMS to his number,
00:16:58.581 --> 00:17:04.454
or do any other thing that the Java on
the SIM card is allowed to do.
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
00:17:11.719 --> 00:17:17.799
a lot of these SIM cards still have.
00:17:17.799 --> 00:17:19.535
Installing the virus again?
00:17:19.535 --> 00:17:24.814
Luka: It's installing again.
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,
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.
00:17:43.329 --> 00:17:46.440
Karsten: Yeah, so there's a lot of these..
00:17:46.440 --> 00:17:50.443
Luka: So this is the message I was waiting for.
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
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.
00:18:02.203 --> 00:18:05.280
Luka: Press yes.
00:18:05.280 --> 00:18:10.806
applause
00:18:10.806 --> 00:18:13.940
Luka: Oh it's a bit small there. I try to copy
00:18:13.940 --> 00:18:16.446
Karsten: Did you want to show more Luka?
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
00:18:26.224 --> 00:18:28.800
hmm no.
00:18:34.421 --> 00:18:39.429
Something like this? Nope
00:18:40.627 --> 00:18:41.299
sighs
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.
00:18:49.258 --> 00:18:55.509
So basically it's a very precise location
information about the user.
00:18:55.509 --> 00:18:58.538
applause
00:18:58.538 --> 00:19:01.005
Karsten: thank you.
00:19:01.005 --> 00:19:04.145
applause
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.
00:19:10.049 --> 00:19:12.190
So it goes through.
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
00:19:18.055 --> 00:19:22.725
give the industry another nudge to
deeply understand this.
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,
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
00:19:38.240 --> 00:19:43.334
the SIM card knowledge that we collected
over the last couple of years.
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
00:19:51.183 --> 00:19:58.536
for all the vulnerabilites we discussed in August,
including things like triple-DES downgrade which
00:19:58.536 --> 00:20:02.509
a lot of operators seem to not
have understood quite yet.
00:20:02.509 --> 00:20:07.535
But it also detects these more recent vulnerabilities.
00:20:07.535 --> 00:20:13.549
Now scanning these sixteen million possibilites on
a SIM card, and each sixteen keys for them,
00:20:13.549 --> 00:20:17.372
that takes a long time, and some older
slower SIM cards up to two weeks.
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.
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
00:20:31.561 --> 00:20:33.981
awesome opensource project also.
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
00:20:39.125 --> 00:20:40.502
with a SIM card.
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,
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
00:20:51.271 --> 00:20:56.015
be very vocal to your network operator and
demand that these things get removed.
00:20:56.015 --> 00:21:03.724
applause
00:21:03.724 --> 00:21:06.669
Thank you.
00:21:06.669 --> 00:21:13.760
Looking at similar technology or similar weaknesses,
let's revisit the topic of GSM intercept,
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
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
00:21:31.012 --> 00:21:36.436
of high urgency, understanding now how many
people are intercepting our phone calls.
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
00:21:44.235 --> 00:21:53.125
bring pretty ok cryptography with longer key
lengths, most of our calls still go over 2G,
00:21:53.125 --> 00:21:54.873
this standard from the eighties.
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
00:22:01.816 --> 00:22:07.160
have to be so large, these frequencies have to
get used because all frequencies are full.
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.
00:22:14.618 --> 00:22:20.230
and on 2G there are two different encryption
standards that are found in the wild.
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
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
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.
00:22:40.541 --> 00:22:44.371
where the other ones will always default to A5/1.
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
00:22:50.712 --> 00:22:54.277
to sufficiently protect their customers.
00:22:54.277 --> 00:22:58.563
Let's visit each of them in turn.
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
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
00:23:16.954 --> 00:23:20.577
need to know what's inside the A5/1 packet.
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
00:23:26.420 --> 00:23:29.979
then you can decrypt the rest of them as well.
00:23:29.979 --> 00:23:33.916
So you've got to start somewhere
to then break the rest of it.
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.
00:23:39.615 --> 00:23:42.946
They also have to rely on some attack surface.
00:23:42.946 --> 00:23:50.187
So if everything is unpredicable, it basically
becomes XOR'ing random numbers.
00:23:50.187 --> 00:23:58.614
The GSMA and later the 3GPP, the standardisation
bodies, that tried to make the mobile world
00:23:58.614 --> 00:24:05.635
a little bit more secure, they worked hard
some five years ago to amend standards for
00:24:05.635 --> 00:24:08.045
this attack surface to go away.
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
00:24:14.808 --> 00:24:19.287
encrypted is predictable, at least in the call setup.
00:24:19.287 --> 00:24:28.238
So the phone starts unencrypted, it receives
a ciphering mode command and it will then
00:24:28.238 --> 00:24:35.570
encrypt every single packet it sends, and also
expect packets it receives to be encrypted,
00:24:35.570 --> 00:24:38.266
including some that actually make sense, where it
00:24:38.266 --> 00:24:42.732
says, "Here, you phone with that TMSI, have
another TMSI", but also things are
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
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
00:24:54.986 --> 00:25:02.157
messages. This exact same message was sent
maybe a second earlier unencrypted.
00:25:02.157 --> 00:25:08.829
And once it switches on encryption the phone
expects this also to be encrypted.
00:25:08.829 --> 00:25:14.394
Then there's messages with very little content
and again null frames. Things that bascially have
00:25:14.394 --> 00:25:19.299
no meaning whatsoever. Assignment to certain
frequencies, there are not many frequencies
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.
00:25:25.546 --> 00:25:30.453
And there are two standards, padding randomisation,
which takes shorter messages and
00:25:30.453 --> 00:25:38.281
appends random bytes, and SI5 randomisation which
takes longer messages but scrambles that content,
00:25:38.281 --> 00:25:41.533
that removes this attack surface almost entirely.
00:25:41.533 --> 00:25:48.643
The little bit of attack surface that's left is due
to vendor specific communications, and
00:25:48.643 --> 00:25:51.783
this needs to be fixed vendor by vendor.
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
00:25:58.794 --> 00:26:02.120
the tools that we can think of.
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
00:26:07.118 --> 00:26:14.872
pressure on security these days. You'd imagine
that these fixes, just tiny software fixes,
00:26:14.872 --> 00:26:20.968
would be deployed thoroughly, however we
rarely see networks that do either of them,
00:26:20.968 --> 00:26:24.266
and we've never seen a network
that does both these fixes.
00:26:24.266 --> 00:26:29.730
So somewhere along the way, between the
GSMA and 3GPP who write the standards
00:26:29.730 --> 00:26:33.242
and you as a customer, that idea got lost.
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,
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
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
00:26:50.613 --> 00:26:52.212
have implemented these features.
00:26:52.212 --> 00:26:58.033
However the networks do not
seem to be using them at all.
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
00:27:04.210 --> 00:27:08.516
to decrypt it. And by much bigger
I mean about a million dollars.
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
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
00:27:22.160 --> 00:27:27.757
with key generation or anything, it becomes
much more secure, and in fact it did,
00:27:27.757 --> 00:27:31.038
two million times more secure.
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.
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.
00:27:44.437 --> 00:27:49.496
So industry took ten years to implement
this standard, and now that they do,
00:27:49.496 --> 00:27:54.990
in Germany for instance two networks just
started this past month to roll out A5/3,
00:27:54.990 --> 00:27:57.819
now it's already outdated.
00:27:57.819 --> 00:28:03.124
Guess what, the next standard was developed
five years ago again. A5/4 it's called,
00:28:03.124 --> 00:28:07.206
it blows up the key size to a good 128-bit,
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.
00:28:13.483 --> 00:28:20.704
So somehow we are always ten years behind
the state of the art in cryptography, and
00:28:20.704 --> 00:28:28.557
ten years behind what even industry describes,
prescribes themselves to implement.
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
00:28:35.111 --> 00:28:39.040
around where networks put in
what type of countermeasures.
00:28:39.040 --> 00:28:43.516
It's not enough for them to standardise
padding randomisation and SI5 randomisation,
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.
00:28:49.286 --> 00:28:55.723
And here's three tools you can
use to create some visibility.
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
00:29:00.425 --> 00:29:04.006
an incremental patch from us today.
00:29:04.006 --> 00:29:09.915
First one runs on an android phone and
it allows you to record network traces.
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,
00:29:15.575 --> 00:29:22.070
whether your temporary identity gets
changed regularly, and so forth.
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
00:29:28.298 --> 00:29:37.110
further analysis, with the xgoldmontool,
Tobias Engel's tool.
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
00:29:41.420 --> 00:29:48.034
basically everybody in the cell you're connected to,
is the OsmocomBB open source project.
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,
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.
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,
00:30:06.438 --> 00:30:11.631
and perhaps interpret this yourself, and to
check whether they are using the latest
00:30:11.631 --> 00:30:13.655
encryption and what not.
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
00:30:20.874 --> 00:30:26.994
help other by sharing this further and
interpreting the information, and to make that
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
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,
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.
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
00:30:54.516 --> 00:31:02.293
are releasing today, a new version of the GSM
map website, much more colourful than before,
00:31:02.293 --> 00:31:05.604
but also much more usable we hope.
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
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
00:31:24.988 --> 00:31:31.180
we have a little bit of data we do estimates,
these are the striped countries here,
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.
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
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
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
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,
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,
00:32:17.205 --> 00:32:24.972
against intercept, basically spy agencies listening
in to your calls, impersonation, that is other
00:32:24.972 --> 00:32:30.752
people using your phone identity to conduct
some transaction, and against tracking, that is
00:32:30.752 --> 00:32:36.790
somebody following your whereabouts by electronic
means. Basically information exposed through
00:32:36.790 --> 00:32:39.172
HLR queries remotely.
00:32:39.172 --> 00:32:42.867
And you see how networks
differ in these catgories.
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
00:32:48.404 --> 00:32:50.954
by us in Berlin.
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
00:32:55.484 --> 00:32:58.171
none of us have ever been to.
00:32:58.171 --> 00:33:03.059
So it's absolutely fabulous to see what
coverage we've gained here.
00:33:03.059 --> 00:33:09.987
Still a lot of striped and white countries,
so we hope to complete the picture, but
00:33:09.987 --> 00:33:11.520
we need everybody's help.
00:33:11.520 --> 00:33:17.546
And hopefully with the tools we released
today it becomes so much easier to push
00:33:17.546 --> 00:33:21.735
data up here, that this will
soon be filled a lot more.
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,
00:33:27.101 --> 00:33:36.269
we are releasing detailed reports today
also, that interpret these measurements and
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
00:33:42.136 --> 00:33:48.430
detailed technical measurements on what encryption
is used, for what types of transactions are
00:33:48.430 --> 00:33:51.183
authenticated and so forth.
00:33:51.183 --> 00:33:52.771
applause
00:33:52.771 --> 00:33:53.524
Thank you.
00:33:53.524 --> 00:34:01.010
applause
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.
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.
00:34:12.324 --> 00:34:19.329
So these will be refreshed every month, hopefully
forever, or until every network fulfills every
00:34:19.329 --> 00:34:22.967
security goal imaginable and then we
will shut down our website.
00:34:22.967 --> 00:34:26.485
laughter
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.
00:34:35.967 --> 00:34:42.290
You may notice that GSM map does not
yet have a security metric on SIM cards.
00:34:42.290 --> 00:34:48.018
Just because our measurements are
too sparse to paint a good picture.
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
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.
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,
00:35:09.200 --> 00:35:12.194
vulnerabilites like the ones we discussed today.
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
00:35:17.102 --> 00:35:18.651
that are actually vulnerable.
00:35:18.651 --> 00:35:24.285
And if you do you can start installing Java
on them and playing around with them.
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
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,
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.
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
00:35:51.862 --> 00:35:55.662
who contributed a month or two of work.
00:35:55.662 --> 00:36:02.578
Thanks to the open technology fund for sponsoring
this research and for helping us fight
00:36:02.578 --> 00:36:10.784
bad security in the world and raising awareness
around where bad security is implemented.
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.
00:36:18.004 --> 00:36:19.070
Thanks.
00:36:19.070 --> 00:36:25.360
applause
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
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.
00:36:36.221 --> 00:36:40.057
If you have questions from the web, or
if you have questions on the streams,
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.
00:36:44.623 --> 00:36:49.170
And I think we'll start with two
questions from the internet please.
00:36:49.170 --> 00:36:51.963
Karsten: One quick...
Signal angel: Okay Herald angel: Wait please.
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
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
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
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
00:37:15.333 --> 00:37:18.225
minutes. Sorry, go ahead with the questions.
00:37:18.225 --> 00:37:20.896
Herald: Okay, two questions
from the internet now.
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
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
00:37:34.999 --> 00:37:37.846
with the industry in the last year there?
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.
00:37:45.344 --> 00:37:49.865
Basically everybody who connects to the network
is trusted, but you have to connect to every
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.
00:37:56.205 --> 00:38:02.199
And people find SS7 vulnerabilites wherever
they look, both in the configuration, stuff like,
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,
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.
00:38:15.211 --> 00:38:21.796
But also people find implementation bugs on
boxes that are connected to SS7 and those are
00:38:21.796 --> 00:38:23.974
really, really hard to research.
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
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,
00:38:36.480 --> 00:38:39.655
if you started to do some fuzz testing on them.
00:38:39.655 --> 00:38:47.182
So SS7 unfortunately isn't really prime for open
research. It actually requires what I showed
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
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
00:38:57.834 --> 00:39:00.579
to be ready for that yet.
00:39:00.579 --> 00:39:06.920
Definitely a topic with lots of low hanging fruit,
but no easy way to research it.
00:39:06.920 --> 00:39:09.468
Signal angel: Okay, thank you.
00:39:09.468 --> 00:39:12.461
Signal Angel: Should we go on with the second one?
Karsten: Yes
00:39:12.461 --> 00:39:18.051
Signal Angel:Has there been any testing using
parallel application only SIM card overlay
00:39:18.051 --> 00:39:23.334
to block apps on the primary SIM card
so that's probably a strange question,
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
00:39:28.749 --> 00:39:31.267
the Java card bits?
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
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?
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
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,
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
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
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
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
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
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
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
00:40:38.690 --> 00:40:41.748
if they do exist.
00:40:41.748 --> 00:40:45.331
Herald: Okay we take a question from microphone four.
00:40:45.331 --> 00:40:49.731
Question: Did you investigate any upstream
vulnerabilities from or to the baseband
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
00:40:56.437 --> 00:40:59.642
any stuff to an iPhone or something?
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
00:41:05.764 --> 00:41:11.180
fruitful vector, because the interface between
a SIM card and a phone is pretty defined,
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
00:41:17.803 --> 00:41:23.780
a couple of years ago, emulating a network and
sending commands, that interface is much wider
00:41:23.780 --> 00:41:28.773
and has many more protocols running that
could potentially be exploit targets.
00:41:28.773 --> 00:41:30.678
Good question though, thank you.
00:41:30.678 --> 00:41:33.490
Herald: Okay, number three please.
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
00:41:38.684 --> 00:41:44.377
districts or regions, do we have differences
within one country for example the US.
00:41:44.377 --> 00:41:49.661
Karsten: That's a good question, and we have
occasionally come across a country where
00:41:49.661 --> 00:41:54.336
there's configuration differences in different
parts of the country, like for instance in Germany
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.
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
00:42:07.543 --> 00:42:13.782
to implement the security feature everywhere.
There are networks though where they
00:42:13.782 --> 00:42:18.199
purchase one part of the country from one vendor
and another part from another vendor, and
00:42:18.199 --> 00:42:23.347
where security patches just don't get deployed
everywhere, and we would like to track that
00:42:23.347 --> 00:42:28.884
more accurately. Currently it's just averaged.
What we need to track it more accurately is
00:42:28.884 --> 00:42:34.813
constant measurements from more places. So
currently what our metric does is try to fairly
00:42:34.813 --> 00:42:40.133
combine information from different location
and then average them even though for instance
00:42:40.133 --> 00:42:46.783
in Germany, of course Berlin is dominating in
our measurement set, and some other locations
00:42:46.783 --> 00:42:52.780
I think, thank you CCC Munich, are contributing
too, but if there were somewhere in
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.
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
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
00:43:13.846 --> 00:43:17.298
a clear border we'll definitely do that.
00:43:17.298 --> 00:43:20.001
Herald: Question from number four please.
00:43:20.001 --> 00:43:25.840
Question: Yes, I wanted to ask, you showed that
you were simulating a BTS somewhere around
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
00:43:31.968 --> 00:43:35.221
solutions or anything else?
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
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
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.
00:43:55.789 --> 00:44:03.572
Karsten: Yeah there are OpenBSC, OpenBTS,
OsmocomBB project, they are an enormous help in
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.
00:44:09.336 --> 00:44:14.826
So they're very, very useful, and thank you
to everybody who've contributed to them.
00:44:14.826 --> 00:44:17.231
Herald: Another question from number four please.
00:44:17.231 --> 00:44:22.730
Question: Banks and other organisations love
to send one-time tokens via SMS, from what I
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?
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,
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
00:44:47.273 --> 00:44:52.957
unlikely that the person who infected your online
banking credentials, stole them from your infected
00:44:52.957 --> 00:44:59.536
computer, is also your neighbour. Those two
groups seem to overlap in locations.
00:44:59.536 --> 00:45:03.970
With the SIM card vulnerabilities though,
you can do lots of stuff, you can send SMS,
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
00:45:09.248 --> 00:45:14.507
incoming SMS. So banks got lucky there.
00:45:14.507 --> 00:45:19.580
Q: Thanks
Herald: We have another question from the internet.
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
00:45:26.524 --> 00:45:32.612
to mess around with all this industry stuff
that has piled up for years now?
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
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
00:45:45.147 --> 00:45:49.453
base stations. Why were they available? Because
people threw them away and replaced
00:45:49.453 --> 00:45:53.858
them with newer base stations, and they do
that every time they add a new technology.
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
00:45:58.510 --> 00:46:02.210
2G/3G base stations, same with 4G now.
00:46:02.210 --> 00:46:07.693
So as 4G is being rolled out all over Germany,
everything gets thrown away and
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,
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,
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
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
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
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,
00:46:50.521 --> 00:46:56.704
you can probably make the entire world use
A5/3 and upgrade to secure SIM cards.
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
00:47:01.958 --> 00:47:04.223
deploying these software patches.
00:47:04.223 --> 00:47:07.718
In the end it's single lines of code.
00:47:07.718 --> 00:47:11.488
Herald: Ok, we have another question in
the room from microphone number three.
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
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
00:47:25.459 --> 00:47:30.965
the simple DVB-tuners to listen to the spectrum.
00:47:30.965 --> 00:47:36.632
Harald: Luca, do you know OsmoSDR?
Luca: Yeah, I think that's more focused on being
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
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,
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.
00:47:55.356 --> 00:47:59.920
Karsten: What would you consider the
advantage of using an OsmoSDR?
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
00:48:04.865 --> 00:48:08.318
work passively without being,
without sending anything?
00:48:08.318 --> 00:48:13.126
Karsten: Yeah, the phone he just held up,
that captures traffic with no SIM card and
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
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
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.
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
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
00:48:46.977 --> 00:48:49.181
already a twelve dollar solution.
00:48:49.181 --> 00:48:53.606
Q: Thank you.
Herald: And we take another question from the internet
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
00:48:57.905 --> 00:49:02.417
caused by you, or is the range not that large?
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.
00:49:08.636 --> 00:49:10.143
laughter
00:49:10.143 --> 00:49:12.145
Q: Okay, thank you.
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
00:49:18.027 --> 00:49:21.779
for a warm round of applause for Karsten and Luca
00:49:21.779 --> 00:49:24.924
applause
00:49:24.924 --> 00:49:33.532
subtitles created by c3subtitles.de