0:00:00.000,0:00:12.443
<i>applause</i>

0:00:12.443,0:00:15.936
Karsten: Thank you very much[br]and a very good evening.

0:00:15.936,0:00:21.264
We're here yet again to talk about mobile[br]network attacks, and we're going to give this talk

0:00:21.264,0:00:23.674
a somewhat different spin.

0:00:23.674,0:00:31.834
Instead of focusing on giving out new vulnerabilities,[br]and then hinting at how a fix could be,

0:00:31.834,0:00:36.601
and suggesting that somebody else would be[br]responsible for implementing these fixes.

0:00:36.601,0:00:42.530
We wanna look at those later stages of the[br]attack evolution today.

0:00:42.530,0:00:50.130
And make sure we don't keep re-creating new[br]results while old ones are not being resolved yet.

0:00:50.130,0:00:53.150
Rest assured there will also be new attacks.

0:00:53.150,0:00:56.391
We need to deliver on that every year.

0:00:56.391,0:01:05.437
But we want to make sure specifically, to introduce[br]some dynamics that help everybody,

0:01:05.437,0:01:09.422
for networks to become more secure.

0:01:09.422,0:01:18.509
My primary goal today is to enable all of you to help[br]with that evolution, and to do some of the research

0:01:18.509,0:01:22.550
that we've been doing in Berlin so far, all over the world.

0:01:22.550,0:01:30.996
There will be a couple of tool releases, and a[br]couple of, hopefully, evolution drivers

0:01:30.996,0:01:38.175
In the end, for us security researchers to be successful in[br]making the world better, we need industry.

0:01:38.175,0:01:45.141
As painful as that sounds, we need somebody to put[br]in a fix, and we haven't been very good

0:01:45.141,0:01:50.906
about keeping check on those people that need to put[br]in fixes for the research that we've been doing

0:01:50.906,0:01:55.683
over the last couple of years, and we're going[br]to complete the picture today.

0:01:55.683,0:02:05.201
by talking a little bit about what networks have[br]been doing around research in two areas.

0:02:05.201,0:02:12.189
SIM card attacks, a topic of this year where networks[br]found themselves in a critical situation

0:02:12.189,0:02:19.696
at risk of large parts of the subscriber base being[br]remotely infected, not in the phone, but in the SIM card.

0:02:19.696,0:02:27.489
So there has been fruitful discussion with industry,[br]and lots of responses, but not enough.

0:02:27.489,0:02:32.951
Much more so around GSM intercept, a topic that[br]probably the NSA discussions have moved

0:02:32.951,0:02:38.938
into everbodys mind again, but one that was really[br]luring for a decade now, that anybody can

0:02:38.938,0:02:41.935
intercept your phonecalls at any time.

0:02:41.935,0:02:46.354
and again, here we want to check on the network[br]operators, and make sure that they are

0:02:46.354,0:02:53.380
forced into putting in the protection that we deserve.

0:02:53.380,0:03:00.408
We first discussed SIM card attacks publicly in August[br]of this year, after a few months of

0:03:00.408,0:03:08.967
responsible disclosure, and we found[br]a combination of three vulnerabilities,

0:03:08.967,0:03:15.800
that led to a potentially terrible situation for networks.

0:03:15.800,0:03:23.639
The first fragment that we found was the ability[br]to send binary text messages from one subscriber

0:03:23.639,0:03:30.434
to really any other subscriber, so networks[br]allowed traffic that has no place to be routed

0:03:30.434,0:03:36.474
through networks, there's no such thing as network[br]neutrality in mobile networks of course,

0:03:36.474,0:03:42.566
they shouldn't be routing internal management applications through what basically is

0:03:42.566,0:03:46.783
the IP space, or the phone number space of subscribers.

0:03:46.783,0:03:52.691
The second thing we found is that the services that[br]these messages reach on the SIM cards are

0:03:52.691,0:04:01.828
often badly protected cryptographically. In particular[br]we were finding lots of cards that used DES keys

0:04:01.828,0:04:08.557
56-bit from the seventies, that has long been[br]phased out in pretty much any other application.

0:04:08.557,0:04:10.888
SIM cards still use old keys like that.

0:04:10.888,0:04:17.940
And thirdly we found that applications you[br]could install through those DES keys

0:04:17.940,0:04:24.300
can break out of the sandbox of the Java protection[br]parameter, and then access all kinds of data

0:04:24.300,0:04:28.643
on the SIM card that no Java was supposed to access.

0:04:28.643,0:04:36.203
And combining those three made for a remote[br]SIM cloning vector at massive scale.

0:04:36.203,0:04:40.889
And networks raced to fix those on at least[br]two of the three layers.

0:04:40.889,0:04:48.222
They put in filtering so the network, the SMS[br]messages would not reach the phone any more.

0:04:48.222,0:04:52.123
And they upgraded DES keys to triple DES keys.

0:04:52.123,0:04:56.700
But most networks left it at that without really[br]thinking through the problem and without really

0:04:56.700,0:05:02.195
understanding the root causes of what[br]made the SIM card so vulnerable.

0:05:02.195,0:05:07.454
So I want to go into the first two categories, since[br]the third one wasn't adressed even until today, and

0:05:07.454,0:05:12.291
show how the industry response[br]was in large part insufficient.

0:05:12.291,0:05:17.519
And I shouldn't generalise as I do now, because[br]some network operators have responded very

0:05:17.519,0:05:23.783
responsibly, but by and large networks shrugged[br]us off or put in quick fixes and then moved on to

0:05:23.783,0:05:30.531
their daily business of making networks faster[br]and faster and faster, but rarely more secure.

0:05:30.531,0:05:36.583
So let's look at filtering first, and what[br]goes wrong with filtering.

0:05:36.583,0:05:43.808
Networks, many networks started filtering at[br]around the time when we presented this publicly,

0:05:43.808,0:05:51.795
around Black Hat and OHM camp, and they put in[br]one specific filtering rule that was not surprisingly

0:05:51.795,0:05:56.744
the exact message that we used in demonstrations[br]at Black Hat and at OHM to demonstrate this

0:05:56.744,0:06:04.185
class of vulnerabilities, but did not understand[br]how much broader the vulnerabilty class is.

0:06:04.185,0:06:13.957
So to put this in a comparison to computer security,[br]if you tell somebody that they have a problem in a

0:06:13.957,0:06:21.605
TCP stack, let's say in the linux implementation,[br]and you demo it by sending packets to the ssh daemon,

0:06:21.605,0:06:27.944
the fix that they implemented is to block port 22, not[br]understanding that of course this exact same

0:06:27.944,0:06:32.245
vulnerability is also present on any[br]other exposed TCP service,

0:06:32.245,0:06:37.805
And there's bunches of ways to format[br]an SMS to reach the SIM card.

0:06:37.805,0:06:44.513
Some have come out of the standard, others are[br]just fragments of wrong implementations on phones.

0:06:44.513,0:06:50.031
In particular some recent android phones will[br]route pretty much anything to the SIM card.

0:06:50.031,0:06:56.358
and that's pretty convenient, because the SIM card[br]will look at the message and then discard it, if it's not

0:06:56.358,0:06:59.520
properly formatted for a SIM card.

0:06:59.520,0:07:02.866
So the implementor of the android[br]phone took the easy way.

0:07:02.866,0:07:07.503
Just put everything to the SIM card, it will[br]decide what it wants and what it doesn't want.

0:07:07.503,0:07:14.900
Of course with a phone like that no level of network[br]filtering, no filtering whatever TCP port will protect it,

0:07:14.900,0:07:19.485
Since normal user messages sometimes[br]get forwarded to the phone.

0:07:19.485,0:07:26.639
So the industry response was a bit insufficient here[br]and we'd like to see more testing of networks

0:07:26.639,0:07:34.265
and when we talk about tools we will perhaps[br]enable you to do exactly that type of testing,

0:07:34.265,0:07:39.600
The second area where the industry response falls[br]way short of understanding the problem,

0:07:39.600,0:07:45.193
again I'm generalising here, is that the[br]configuration of the SIM cards.

0:07:45.193,0:07:53.355
We did discuss the problem with DES keys, that you[br]can break a 56-bit DES key in a minute or so using

0:07:53.355,0:08:00.163
a rainbow table, and that of course, this is terrible[br]if those services are reachable remotely.

0:08:00.163,0:08:06.880
And networks then went in to look at[br]configurations, and lot of them came out

0:08:06.880,0:08:11.200
saying "We made sure everything is[br]triple-DES on our SIM cards"

0:08:11.200,0:08:19.334
or at least a few places there was still DES in older[br]profiles, we patched them to now be triple-DES.

0:08:19.334,0:08:24.698
Again that falls way short of[br]understanding the core issue.

0:08:24.698,0:08:29.200
Here's a bit of technical background so you can[br]appreciate what's going on in the SIM card.

0:08:29.200,0:08:34.778
There's a collection of keys, up to sixteen keysets,[br]and each keyset can have keys for signing and

0:08:34.778,0:08:40.239
encryption and so forth, and those keys have[br]a specific type, DES or triple-DES for instance,

0:08:40.239,0:08:43.751
sometimes even AES on very new cards.

0:08:43.751,0:08:49.520
And then there's applications on the SIM card[br]and these applications, there's up to sixteen million

0:08:49.520,0:08:51.451
application identifiers.

0:08:51.451,0:08:56.034
Of course no sixteen million applications fit on a card,[br]so some of these are present on

0:08:56.034,0:09:03.503
every SIM card, and the application gets to[br]choose which keys get what level of access.

0:09:03.503,0:09:08.291
And what seems to have happened in August is that[br]the networks go through this first application,

0:09:08.291,0:09:14.011
the standard application and make sure that triple-DES[br]keys are required for signature or encryption or

0:09:14.011,0:09:20.100
better, even both. And then the DES keys they[br]had there, they upgraded to triple-DES.

0:09:20.100,0:09:26.449
However we find in a surprisingly large number[br]of SIM cards the following situation:

0:09:26.449,0:09:35.201
One of the other sixteen million applications says[br]we use this keyset, but we require none of it.

0:09:35.201,0:09:41.982
So you send a command to that SIM TAR specifying[br]this keyset, and you're not required to do

0:09:41.982,0:09:44.783
signatures or encryption.

0:09:44.783,0:09:50.690
And at that point it doesn't matter if you use triple-DES[br]or AES or whatever algorithm, this SIM card

0:09:50.690,0:09:54.633
will accept any command sent to it.

0:09:54.633,0:09:59.646
And again that kind of being obvious to check for[br]when you're going through your inventory of

0:09:59.646,0:10:08.290
SIM cards, but that requires a deeper level[br]of understanding of these attacks than most

0:10:08.290,0:10:12.617
operators seem to have developed for this issue.

0:10:12.617,0:10:19.619
So I hope this again helps to carry the point that to[br]drive the co-evolution of attacks and defenses,

0:10:19.619,0:10:26.878
industry is required to think through the attacks and[br]understand what exactly the attack parameter is.

0:10:26.878,0:10:40.766
To make sure it gets across very visually now, I'd like[br]to get Luca to demo the attack as we think

0:10:40.766,0:10:43.873
it would play out in the real world.

0:10:43.873,0:10:50.925
and just as one sentence of introduction perhaps,[br]this is coming from a very recent SIM card

0:10:50.925,0:10:56.724
one that we picked up when we started playing[br]with the iPhone 5 as fingerprint reader.

0:10:56.724,0:11:05.887
It's just an US SIM card, and Luca,[br]what are you going to do now?

0:11:08.507,0:11:10.611
Can you switch on his microphone please?

0:11:10.611,0:11:20.240
Luca: Ok, so as Karsten said we found this[br]particularily interesting SIM card and

0:11:20.240,0:11:28.257
the last one we found was very recent, it's a[br]nano SIM and it goes into an iPhone 5.

0:11:28.257,0:11:37.222
I'm going to show you what can we do to[br]bypass the filterset operators have now.

0:11:37.222,0:11:56.107
So we put it into the phone. I have here a BTS,[br]that emulates the real operator network.

0:11:56.107,0:12:01.193
Karsten: Of course that's a default way to bypass[br]any type of filtering that the real network may be

0:12:01.193,0:12:09.976
Luka: So now the mobile is connecting, and I'm trying[br]to show you better, my BTS is sending some SMS's,

0:12:09.976,0:12:18.341
as soon as the mobile is close to the BTS, and[br]it tries to register, because it thinks it is

0:12:18.341,0:12:27.983
the home network, I send my application, that[br]is completly installed without any warning,

0:12:27.983,0:12:31.209
or anything on the iPhone.

0:12:31.209,0:12:34.358
<i>umm</i>

0:12:34.358,0:12:42.825
I want to show you something here, so this is the[br]first command and it's a delete, since I've already

0:12:42.825,0:12:45.147
installed the application many times, I first delete it.

0:12:45.147,0:12:46.931
and then I install it again.

0:12:46.931,0:12:50.228
Karsten: So this is remote application management.

0:12:50.228,0:12:54.430
On a recent SIM card, that requires[br]no security whatsoever, you can put in

0:12:54.430,0:13:00.863
whatever Java software you'd[br]like to run on this SIM card.

0:13:00.863,0:13:05.594
Luka: Ok, so it's finished, took a couple[br]of seconds, ten seconds, I dunno.

0:13:05.594,0:13:12.843
and now the SIM card is infected with a malware,[br]that every five minutes sends the current location of

0:13:12.843,0:13:18.370
the user to the attackers number.

0:13:18.370,0:13:26.054
Since the iPhone doesn't show anything, I'm[br]going to put this SIM card into another phone,

0:13:26.054,0:13:32.171
so you can see it better, and you can also[br]have a proof that it's on the SIM card.

0:13:38.244,0:13:43.499
It's not very easy with the nano SIM[br]into a normal phone.

0:13:43.499,0:13:49.800
so this is the other phone, I have a ok..

0:13:52.949,0:13:57.640
Karsten: So the virus stays with the SIM[br]card (when moved to) another phone

0:13:57.346,0:14:02.158
Luka:I'm going to turn it on now.

0:14:05.450,0:14:07.523
Yeah.

0:14:14.768,0:14:20.530
Hopefully it will register to the home network.

0:14:26.293,0:14:28.210
Yeah.

0:14:32.279,0:14:34.768
Karsten: Is it still set to manual?

0:14:34.768,0:14:37.623
Luka: Yeah, it did register.

0:14:43.109,0:14:45.306
Yeah,

0:14:45.306,0:14:50.674
So we are actually replaying the[br]attack again, just for fun.

0:14:50.674,0:14:53.461
Karsten: Oops.

0:14:56.631,0:14:59.946
Luka: [sigh][br]Karsten: Bear with us, this is a complex demo

0:14:59.946,0:15:05.107
lots of moving parts.[br]Luka: What I can do is delete the SMS

0:15:08.563,0:15:13.333
Luka: So is it showing someting now?

0:15:19.809,0:15:23.372
Ok, I'll just try again.

0:15:25.987,0:15:33.532
Oh, actually I have a better idea,[br]so now I stop my fake BTS

0:15:33.532,0:15:36.048
Karsten: yeah, better connect to the real network.

0:15:36.048,0:15:40.093
Luka: and I let it connect to the real network.

0:15:50.844,0:15:55.220
Okay. Let's see.

0:16:02.936,0:16:07.168
Karsten: You're confident the virus[br]got deployed the second time?

0:16:07.168,0:16:12.691
Luka: Umm, that's actually a nice...

0:16:12.691,0:16:16.933
Okay, yeah that was a.

0:16:16.933,0:16:19.788
Karsten: Ok, lets come back to you[br]in a couple of minutes then.

0:16:19.788,0:16:23.365
When you've prepared this, but everybody[br]got the idea roughly right,

0:16:23.365,0:16:29.205
what should have happend; He's catching[br]the phone or any of your phones really,

0:16:29.205,0:16:35.140
he can test for vulnerabilities by sending[br]SMS, hundreds of them, not sixteen million,

0:16:35.140,0:16:40.230
he has to prepare a little bit, know where[br]a vulnerability could be, and then once

0:16:40.230,0:16:47.263
he finds an unprotected application, he just sends[br]a bunch of binary SMSs and combine that Java file.

0:16:47.263,0:16:52.717
and that java file installs on the SIM card and[br]it stays installed on the SIM card,

0:16:52.717,0:16:58.581
and it will every five minutes send the[br]current location via SMS to his number,

0:16:58.581,0:17:04.454
or do any other thing that the Java on[br]the SIM card is allowed to do.

0:17:04.454,0:17:11.719
It could even try to exploit the other parts of the SIM[br]card through that unpatched Java vulnerability that

0:17:11.719,0:17:17.799
a lot of these SIM cards still have.

0:17:17.799,0:17:19.535
Installing the virus again?

0:17:19.535,0:17:24.814
Luka: It's installing again.

0:17:27.646,0:17:34.170
Luka: This was just the best case we found so[br]you can actually install an application inside the SIM,

0:17:34.170,0:17:41.843
in case this is not available, another choice is just[br]reading the current ciphering key from the SIM.

0:17:43.329,0:17:46.440
Karsten: Yeah, so there's a lot of these..

0:17:46.440,0:17:50.443
Luka: So this is the message I was waiting for.

0:17:50.443,0:17:55.978
Karsten: So this older Nokia phone is the only phone[br]we ever found that asked whether you allow your

0:17:55.978,0:18:02.203
SIM card to send anything back to the attacker.[br]The iPhone just does it by default without asking you.

0:18:02.203,0:18:05.280
Luka: Press yes.

0:18:05.280,0:18:10.806
<i>applause</i>

0:18:10.806,0:18:13.940
Luka: Oh it's a bit small there. I try to copy

0:18:13.940,0:18:16.446
Karsten: Did you want to show more Luka?

0:18:16.446,0:18:26.224
Luka: Yeah the phone now sent the SMS to me,[br]and I want to show how it looks like, so

0:18:26.224,0:18:28.800
<i>hmm</i> no.

0:18:34.421,0:18:39.429
Something like this? Nope

0:18:40.627,0:18:41.299
<i>sighs</i>

0:18:41.299,0:18:49.258
I want to enlarge this, so in this little field, there is[br]the current network, the location area and cell-ID.

0:18:49.258,0:18:55.509
So basically it's a very precise location[br]information about the user.

0:18:55.509,0:18:58.538
<i>applause</i>

0:18:58.538,0:19:01.005
Karsten: thank you.

0:19:01.005,0:19:04.145
<i>applause</i>

0:19:04.145,0:19:10.049
Luka: And the best is that this message is not filtered by the operator since it's a normal text SMS.

0:19:10.049,0:19:12.190
So it goes through.

0:19:12.190,0:19:18.055
Karsten: So a persistant virus on a modern SIM[br]card, I think that's what was needed to

0:19:18.055,0:19:22.725
give the industry another nudge to[br]deeply understand this.

0:19:22.725,0:19:29.951
Now to create some further nudges from you all,[br]and to fulfill that goal that I stated going in,

0:19:29.951,0:19:38.240
to enable everybody to do these tests yourself,[br]we wanna release a tool today that condenses all

0:19:38.240,0:19:43.334
the SIM card knowledge that we collected[br]over the last couple of years.

0:19:43.334,0:19:51.183
It's an open source tool, written in Java, that was[br]the easiest to speak to SIM cards with, and it tests

0:19:51.183,0:19:58.536
for all the vulnerabilites we discussed in August,[br]including things like triple-DES downgrade which

0:19:58.536,0:20:02.509
a lot of operators seem to not[br]have understood quite yet.

0:20:02.509,0:20:07.535
But it also detects these more recent vulnerabilities.

0:20:07.535,0:20:13.549
Now scanning these sixteen million possibilites on[br]a SIM card, and each sixteen keys for them,

0:20:13.549,0:20:17.372
that takes a long time, and some older[br]slower SIM cards up to two weeks.

0:20:17.372,0:20:25.515
So one thing the tool does is pre-select these[br]TAR's smartly, so it only takes a couple of minutes.

0:20:25.515,0:20:31.561
It does run on a normal smart card reader,[br]PC/SC interface, as well as the Osmocom phone

0:20:31.561,0:20:33.981
awesome opensource project also.

0:20:33.981,0:20:39.125
We patched it a little bit to now act as a smartcard[br]reader. So of course it can communicate

0:20:39.125,0:20:40.502
with a SIM card.

0:20:40.502,0:20:46.784
So if you have any of those; PC/SC reader or an[br]Osmocom phone and a couple of minutes of time,

0:20:46.784,0:20:51.271
download the software and please run the tests,[br]make sure you're not affected, and if you are

0:20:51.271,0:20:56.015
be very vocal to your network operator and[br]demand that these things get removed.

0:20:56.015,0:21:03.724
<i>applause</i>

0:21:03.724,0:21:06.669
Thank you.

0:21:06.669,0:21:13.760
Looking at similar technology or similar weaknesses,[br]let's revisit the topic of GSM intercept,

0:21:13.760,0:21:23.197
and I'll again try to make the point that networks may[br]be casually interested in fixing some bugs that

0:21:23.197,0:21:31.012
they may not have fully understood, so they only did[br]half the fixes or not at all and again I think this is

0:21:31.012,0:21:36.436
of high urgency, understanding now how many[br]people are intercepting our phone calls.

0:21:36.436,0:21:44.235
Network operators are supposed to protect us on[br]all the frequencies we use and while 3G and 4G

0:21:44.235,0:21:53.125
bring pretty ok cryptography with longer key[br]lengths, most of our calls still go over 2G,

0:21:53.125,0:21:54.873
this standard from the eighties.

0:21:54.873,0:22:01.816
It's the only technology that can cover large areas,[br]and even in cities where the cell sizes don't

0:22:01.816,0:22:07.160
have to be so large, these frequencies have to[br]get used because all frequencies are full.

0:22:07.160,0:22:14.618
We have a frequency scarcity, so 2G frequencies are[br]certainly still used by everybody, almost every day.

0:22:14.618,0:22:20.230
and on 2G there are two different encryption[br]standards that are found in the wild.

0:22:20.230,0:22:27.280
There's A5/1, the first encryption cipher, the one[br]that was originally invented along with GSM, back in

0:22:27.280,0:22:34.635
the eighties, and then there's A5/3, a ten year[br]old encryption standard, that's supported by

0:22:34.635,0:22:40.541
newer phones, I would say about half the phones[br]in current use support this A5/3 cipher.

0:22:40.541,0:22:44.371
where the other ones will always default to A5/1.

0:22:44.371,0:22:50.712
And the network would have to support both of them[br]in a secure way or as secure as possible way

0:22:50.712,0:22:54.277
to sufficiently protect their customers.

0:22:54.277,0:22:58.563
Let's visit each of them in turn.

0:22:58.563,0:23:08.142
To break A5/1 with tools like the ones we released[br]some five years ago now, you have to have

0:23:08.142,0:23:16.954
some attack surface. It's not enough to have[br]a tool that can break an A5/1 packet, you also

0:23:16.954,0:23:20.577
need to know what's inside the A5/1 packet.

0:23:20.577,0:23:26.420
So for one of all these packets you have to predict[br]the content, you break the key from it, and

0:23:26.420,0:23:29.979
then you can decrypt the rest of them as well.

0:23:29.979,0:23:33.916
So you've got to start somewhere[br]to then break the rest of it.

0:23:33.916,0:23:39.615
And I believe no spy agency would have a[br]better way of breaking A5/1 over the air.

0:23:39.615,0:23:42.946
They also have to rely on some attack surface.

0:23:42.946,0:23:50.187
So if everything is unpredicable, it basically[br]becomes XOR'ing random numbers.

0:23:50.187,0:23:58.614
The GSMA and later the 3GPP, the standardisation[br]bodies, that tried to make the mobile world

0:23:58.614,0:24:05.635
a little bit more secure, they worked hard[br]some five years ago to amend standards for

0:24:05.635,0:24:08.045
this attack surface to go away.

0:24:08.045,0:24:14.808
So in a standard trace as we see it in too many[br]networks pretty much everything that is

0:24:14.808,0:24:19.287
encrypted is predictable, at least in the call setup.

0:24:19.287,0:24:28.238
So the phone starts unencrypted, it receives[br]a ciphering mode command and it will then

0:24:28.238,0:24:35.570
encrypt every single packet it sends, and also[br]expect packets it receives to be encrypted,

0:24:35.570,0:24:38.266
including some that actually make sense, where it

0:24:38.266,0:24:42.732
says, "Here, you phone with that TMSI, have[br]another TMSI", but also things are

0:24:42.732,0:24:49.193
encrypted that carry not content whatsoever, like[br]a null frame, that says the network is supposed to

0:24:49.193,0:24:54.986
speak now, but it has nothing to say, but also things[br]with static content, like these system information

0:24:54.986,0:25:02.157
messages. This exact same message was sent[br]maybe a second earlier unencrypted.

0:25:02.157,0:25:08.829
And once it switches on encryption the phone[br]expects this also to be encrypted.

0:25:08.829,0:25:14.394
Then there's messages with very little content[br]and again null frames. Things that bascially have

0:25:14.394,0:25:19.299
no meaning whatsoever. Assignment to certain[br]frequencies, there are not many frequencies

0:25:19.299,0:25:25.546
to choose from so this is mostly predictable,[br]and all of this is to be considered attack surface.

0:25:25.546,0:25:30.453
And there are two standards, padding randomisation,[br]which takes shorter messages and

0:25:30.453,0:25:38.281
appends random bytes, and SI5 randomisation which[br]takes longer messages but scrambles that content,

0:25:38.281,0:25:41.533
that removes this attack surface almost entirely.

0:25:41.533,0:25:48.643
The little bit of attack surface that's left is due[br]to vendor specific communications, and

0:25:48.643,0:25:51.783
this needs to be fixed vendor by vendor.

0:25:51.783,0:25:58.794
But by just putting in those two standards,[br]A5/1 calls should be protected from at least

0:25:58.794,0:26:02.120
the tools that we can think of.

0:26:02.120,0:26:07.118
Now given that this is five years ago that these[br]were standardised and that there is a lot of

0:26:07.118,0:26:14.872
pressure on security these days. You'd imagine[br]that these fixes, just tiny software fixes,

0:26:14.872,0:26:20.968
would be deployed thoroughly, however we[br]rarely see networks that do either of them,

0:26:20.968,0:26:24.266
and we've never seen a network[br]that does both these fixes.

0:26:24.266,0:26:29.730
So somewhere along the way, between the[br]GSMA and 3GPP who write the standards

0:26:29.730,0:26:33.242
and you as a customer, that idea got lost.

0:26:33.242,0:26:38.893
And it's not a difficult idea, to throw in some[br]random numbers, instead of static values,

0:26:38.893,0:26:45.198
or to take a message and scramble its contents.[br]These things should be pretty straight forward to

0:26:45.198,0:26:50.613
implement, and we've seen both ideas in the wild,[br]so there is proof that at least some vendors

0:26:50.613,0:26:52.212
have implemented these features.

0:26:52.212,0:26:58.033
However the networks do not[br]seem to be using them at all.

0:26:58.033,0:27:04.210
The same attack surface then would open up for[br]A5/3 if somebody had a much bigger computer

0:27:04.210,0:27:08.516
to decrypt it. And by much bigger[br]I mean about a million dollars.

0:27:08.516,0:27:14.530
So A5/3 is now ten years old and ten years[br]ago it seemed like a great idea to take

0:27:14.530,0:27:22.160
a 64-bit stream cipher and make a 64-bit block[br]cipher out of it, you don't have to mess

0:27:22.160,0:27:27.757
with key generation or anything, it becomes[br]much more secure, and in fact it did,

0:27:27.757,0:27:31.038
two million times more secure.

0:27:31.038,0:27:37.537
But guess who's going to spend a million dollars[br]to break your A5/3 encrypted call, this year right.

0:27:37.537,0:27:44.437
and not just that one agency, every agency has a[br]spare one million dollar to build an A5/3 cracker.

0:27:44.437,0:27:49.496
So industry took ten years to implement[br]this standard, and now that they do,

0:27:49.496,0:27:54.990
in Germany for instance two networks just[br]started this past month to roll out A5/3,

0:27:54.990,0:27:57.819
now it's already outdated.

0:27:57.819,0:28:03.124
Guess what, the next standard was developed[br]five years ago again. A5/4 it's called,

0:28:03.124,0:28:07.206
it blows up the key size to a good 128-bit,

0:28:07.206,0:28:13.483
it steals that from the 3G part of the SIM card,[br]but every SIM card these days is a 3G sim card.

0:28:13.483,0:28:20.704
So somehow we are always ten years behind[br]the state of the art in cryptography, and

0:28:20.704,0:28:28.557
ten years behind what even industry describes,[br]prescribes themselves to implement.

0:28:28.557,0:28:35.111
We want that to change, and again we want you[br]to help us change that by creating awareness

0:28:35.111,0:28:39.040
around where networks put in[br]what type of countermeasures.

0:28:39.040,0:28:43.516
It's not enough for them to standardise[br]padding randomisation and SI5 randomisation,

0:28:43.516,0:28:49.286
It's not enough for them to specify A5/3 and[br]A5/4, they actually need to deploy it.

0:28:49.286,0:28:55.723
And here's three tools you can[br]use to create some visibility.

0:28:55.723,0:29:00.425
The first two we're releasing today, and the[br]third one has always been available, there's just

0:29:00.425,0:29:04.006
an incremental patch from us today.

0:29:04.006,0:29:09.915
First one runs on an android phone and[br]it allows you to record network traces.

0:29:09.915,0:29:15.575
Those network traces of course tell you what type[br]of encryption is used, whether keys get rolled over,

0:29:15.575,0:29:22.070
whether your temporary identity gets[br]changed regularly, and so forth.

0:29:22.070,0:29:28.298
The second tool is basically the same running on a[br]linux computer, if you want to have the data for

0:29:28.298,0:29:37.110
further analysis, with the xgoldmontool,[br]Tobias Engel's tool.

0:29:37.110,0:29:41.420
And then the third possibility for aquiring[br]the same data, not just for your own phone, but

0:29:41.420,0:29:48.034
basically everybody in the cell you're connected to,[br]is the OsmocomBB open source project.

0:29:48.034,0:29:53.268
Sylvain put in a lot of work a few years ago[br]and created this burst_ind branch,

0:29:53.268,0:29:59.520
we extended it just a little bit to run much more[br]stable and to really help as a capturing tool.

0:29:59.520,0:30:06.438
So any of these tools now helps you to look at[br]what configurations your network is using,

0:30:06.438,0:30:11.631
and perhaps interpret this yourself, and to[br]check whether they are using the latest

0:30:11.631,0:30:13.655
encryption and what not.

0:30:13.655,0:30:20.874
We'd much appreciate if you shared some of[br]that information with us, and we could then again

0:30:20.874,0:30:26.994
help other by sharing this further and[br]interpreting the information, and to make that

0:30:26.994,0:30:34.309
even easier, we put all these tool in a Live-ISO[br]that you can put on a USB stick and boot

0:30:34.309,0:30:40.010
with it. That has all the tools on it, the network[br]measurement tools, it has the SIM tester on it,

0:30:40.010,0:30:47.156
it has all the stuff on it, catch-a-catcher to[br]find IMSI catchers in your vincinity.

0:30:47.156,0:30:54.516
It has an option to send data to a website called[br]gsmmap.org and along with all these tools we

0:30:54.516,0:31:02.293
are releasing today, a new version of the GSM[br]map website, much more colourful than before,

0:31:02.293,0:31:05.604
but also much more usable we hope.

0:31:05.604,0:31:15.868
So here's the new GSM map, and this now[br]interprets a lot of network traces that many of you

0:31:15.868,0:31:24.988
collected over the last couple of years, with Sylvains[br]burst_ind setup, and for those countries where

0:31:24.988,0:31:31.180
we have a little bit of data we do estimates,[br]these are the striped countries here,

0:31:31.180,0:31:40.710
and for those networks where we have a lot of data,[br]we try to track the network security over time.

0:31:40.710,0:31:46.247
So this for instance are the four german networks,[br]and you see how over time they actually do change

0:31:46.247,0:31:54.649
their security settings. T-Mobile for instance,[br]the high-flyer here, they had a big drop in

0:31:54.649,0:32:02.410
network security, intercept this is, by switching off some[br]of the randomisation, earlier this year, but then

0:32:02.410,0:32:08.644
after they did that they started rolling out A5/3,[br]so somehow they're trading in security features,

0:32:08.644,0:32:17.205
one for the other. This now on an aggregate level[br]tells you how secure your network currently is,

0:32:17.205,0:32:24.972
against intercept, basically spy agencies listening[br]in to your calls, impersonation, that is other

0:32:24.972,0:32:30.752
people using your phone identity to conduct[br]some transaction, and against tracking, that is

0:32:30.752,0:32:36.790
somebody following your whereabouts by electronic[br]means. Basically information exposed through

0:32:36.790,0:32:39.172
HLR queries remotely.

0:32:39.172,0:32:42.867
And you see how networks[br]differ in these catgories.

0:32:42.867,0:32:48.404
This map by the way is where contributions came[br]from. So a lot of these of course are collected

0:32:48.404,0:32:50.954
by us in Berlin.

0:32:50.954,0:32:55.484
But thank you so much to all of you who sent[br]in all these traces from all these places that

0:32:55.484,0:32:58.171
none of us have ever been to.

0:32:58.171,0:33:03.059
So it's absolutely fabulous to see what[br]coverage we've gained here.

0:33:03.059,0:33:09.987
Still a lot of striped and white countries,[br]so we hope to complete the picture, but

0:33:09.987,0:33:11.520
we need everybody's help.

0:33:11.520,0:33:17.546
And hopefully with the tools we released[br]today it becomes so much easier to push

0:33:17.546,0:33:21.735
data up here, that this will[br]soon be filled a lot more.

0:33:21.735,0:33:27.101
Now for those countries that we have a lot of[br]data, and that is twenty-seven countries total,

0:33:27.101,0:33:36.269
we are releasing detailed reports today[br]also, that interpret these measurements and

0:33:36.269,0:33:42.136
rank the networks, but also explain a little bit[br]of how we measure these things, but then give you

0:33:42.136,0:33:48.430
detailed technical measurements on what encryption[br]is used, for what types of transactions are

0:33:48.430,0:33:51.183
authenticated and so forth.

0:33:51.183,0:33:52.771
<i>applause</i>

0:33:52.771,0:33:53.524
Thank you.

0:33:53.524,0:34:01.010
<i>applause</i>

0:34:01.010,0:34:06.680
So if your country is one of the twenty-seven,[br]we'd love if you read the report.

0:34:06.680,0:34:12.324
If it isn't we'd love for you to download the tools[br]and make sure we can publish a report next month.

0:34:12.324,0:34:19.329
So these will be refreshed every month, hopefully[br]forever, or until every network fulfills every

0:34:19.329,0:34:22.967
security goal imaginable and then we[br]will shut down our website.

0:34:22.967,0:34:26.485
<i>laughter</i>

0:34:26.485,0:34:35.967
So that's GSM Map, the new website, and[br]you saw all the tools that are available now.

0:34:35.967,0:34:42.290
You may notice that GSM map does not[br]yet have a security metric on SIM cards.

0:34:42.290,0:34:48.018
Just because our measurements are[br]too sparse to paint a good picture.

0:34:48.018,0:34:56.632
We'd like to start calling out the networks that do[br]bad SIM card security, but again we need your help

0:34:56.632,0:35:02.703
to scan your SIM cards, and to make sure we get[br]some fair comparison among all the networks.

0:35:02.703,0:35:09.200
Just as a heads up, we found about in every other[br]network where we have a lot of SIM cards to test,

0:35:09.200,0:35:12.194
vulnerabilites like the ones we discussed today.

0:35:12.194,0:35:17.102
So there should be a good chance if you have[br]couple of SIM cards at home, to find at least a few

0:35:17.102,0:35:18.651
that are actually vulnerable.

0:35:18.651,0:35:24.285
And if you do you can start installing Java[br]on them and playing around with them.

0:35:24.285,0:35:34.631
Allright, that was everything we wanted to discuss.[br]A round of thank you, in particular to Lukas and Linus

0:35:34.631,0:35:40.506
who have put in many months of really hard work[br]to get these tools ready for release today,

0:35:40.506,0:35:48.103
they were just about ready this morning after many[br]months of working on them, so thanks to them.

0:35:48.103,0:35:51.862
But thanks to everybody else also, who were[br]involved. There's just a long list of people

0:35:51.862,0:35:55.662
who contributed a month or two of work.

0:35:55.662,0:36:02.578
Thanks to the open technology fund for sponsoring[br]this research and for helping us fight

0:36:02.578,0:36:10.784
bad security in the world and raising awareness[br]around where bad security is implemented.

0:36:10.784,0:36:18.004
Thank you to all of you for using our tools to take[br]this research to places that we could not have imagined.

0:36:18.004,0:36:19.070
Thanks.

0:36:19.070,0:36:25.360
<i>applause</i>

0:36:25.360,0:36:30.050
Herald: Thank you very much Karsten and Luca.[br]So we have quite some time left, so as always if

0:36:30.050,0:36:36.221
you have questions, in the room, please line up[br]behind the four microphones on the ground floor.

0:36:36.221,0:36:40.057
If you have questions from the web, or[br]if you have questions on the streams,

0:36:40.057,0:36:44.623
please write them on twitter or on IRC[br]and we will ask them here live in the room.

0:36:44.623,0:36:49.170
And I think we'll start with two[br]questions from the internet please.

0:36:49.170,0:36:51.963
Karsten: One quick...[br]Signal angel: Okay Herald angel: Wait please.

0:36:51.963,0:36:56.806
Karsten: One quick heads-up before the first[br]people start leaving, if you're interested in playing

0:36:56.806,0:37:02.326
with the tools or at least seeing them being[br]played with there's a workshop that will start

0:37:02.326,0:37:09.815
at six in Saal D, so if you want to see the live-ISO[br]and all its components and perhaps

0:37:09.815,0:37:15.333
take a USB stick home, we brought plenty to[br]play with, saal D is where we'll meet you in a few

0:37:15.333,0:37:18.225
minutes. Sorry, go ahead with the questions.

0:37:18.225,0:37:20.896
Herald: Okay, two questions[br]from the internet now.

0:37:20.896,0:37:29.427
Signal angel: So first one: there are still many low[br]hanging fruits, so what about SS7 networks, did you

0:37:29.427,0:37:34.999
investigate them and their way of communicating with[br]each other. Can you tell us anything what happened

0:37:34.999,0:37:37.846
with the industry in the last year there?

0:37:37.846,0:37:45.344
Karsten: Sure, yeah, SS7 is another decades old[br]technology that was built with a wrong threat model.

0:37:45.344,0:37:49.865
Basically everybody who connects to the network[br]is trusted, but you have to connect to every

0:37:49.865,0:37:56.205
other telco in the world to route calls to them,[br]so there's some disagreement in the threat model.

0:37:56.205,0:38:02.199
And people find SS7 vulnerabilites wherever[br]they look, both in the configuration, stuff like,

0:38:02.199,0:38:08.117
you know, the SIM filtering, the SMS filtering,[br]the same kinds of topics come up in SS7,

0:38:08.117,0:38:15.211
where of course you want to block unneeded traffic,[br]and networks are really bad at that typically.

0:38:15.211,0:38:21.796
But also people find implementation bugs on[br]boxes that are connected to SS7 and those are

0:38:21.796,0:38:23.974
really, really hard to research.

0:38:23.974,0:38:29.491
The boxes are very expensive, so you can't just[br]research it in isolation, and everybody who is

0:38:29.491,0:38:36.480
running a box like that, will probably put you[br]in jail if you ever attempted to break them,

0:38:36.480,0:38:39.655
if you started to do some fuzz testing on them.

0:38:39.655,0:38:47.182
So SS7 unfortunately isn't really prime for open[br]research. It actually requires what I showed

0:38:47.182,0:38:53.211
on the first slide, kind of a co-evolution where[br]the networks let the hackers in, so that they

0:38:53.211,0:38:57.834
then learn what other hackers could have[br]done to them, and I don't see many networks

0:38:57.834,0:39:00.579
to be ready for that yet.

0:39:00.579,0:39:06.920
Definitely a topic with lots of low hanging fruit,[br]but no easy way to research it.

0:39:06.920,0:39:09.468
Signal angel: Okay, thank you.

0:39:09.468,0:39:12.461
Signal Angel: Should we go on with the second one?[br]Karsten: Yes

0:39:12.461,0:39:18.051
Signal Angel:Has there been any testing using[br]parallel application only SIM card overlay

0:39:18.051,0:39:23.334
to block apps on the primary SIM card[br]so that's probably a strange question,

0:39:23.334,0:39:28.749
but the MuVuCo? project is mentioned here, or[br]did you investigate any other simple way to block

0:39:28.749,0:39:31.267
the Java card bits?

0:39:31.267,0:39:37.281
Karsten: So I think I understood the question as,[br]is there any easy way of putting in another layer

0:39:37.281,0:39:42.798
of protection just in front of your SIM card? I guess[br]we can't ask the person asking the question right?

0:39:42.798,0:39:48.224
But if that were the question then the answer is,[br]of course you can put all kinds of proxy stuff

0:39:48.224,0:39:54.310
in between your phone and your SIM card, there's[br]a nice open source project called SIMtrace,

0:39:54.310,0:39:58.959
That then means you carry a little computer next[br]to your phone whenever you use it and of course

0:39:58.959,0:40:04.877
that's impractical, so that would be a forensic tool[br]perhaps to investigate what people are currently

0:40:04.877,0:40:08.519
doing to your SIM card, when you already have[br]a suspicion that something is going on, but

0:40:08.519,0:40:14.923
there's no practical way to get a phone to give[br]you that level of access, even on android, the part of

0:40:14.923,0:40:24.139
the operating system, the system that speaks with[br]the SIM card is usually more baseband than android

0:40:24.139,0:40:32.872
or at the very least a proprietary device driver type.[br]So I can't think of any usable phone where

0:40:32.872,0:40:38.690
you could easily implement a SIM card firewall[br]for instance, but I'd love to learn about them

0:40:38.690,0:40:41.748
if they do exist.

0:40:41.748,0:40:45.331
Herald: Okay we take a question from microphone four.

0:40:45.331,0:40:49.731
Question: Did you investigate any upstream[br]vulnerabilities from or to the baseband

0:40:49.731,0:40:56.437
or to the average phone OS, so for instance[br]if you have infiltrated the SIM card can you do

0:40:56.437,0:40:59.642
any stuff to an iPhone or something?

0:40:59.642,0:41:05.764
Karsten: Good question, and no we haven't and[br]I wouldn't think that that would be the most

0:41:05.764,0:41:11.180
fruitful vector, because the interface between[br]a SIM card and a phone is pretty defined,

0:41:11.180,0:41:17.803
very narrow channel. So I'd think that a phone[br]baseband is much easier exploited like Ralph did it

0:41:17.803,0:41:23.780
a couple of years ago, emulating a network and[br]sending commands, that interface is much wider

0:41:23.780,0:41:28.773
and has many more protocols running that[br]could potentially be exploit targets.

0:41:28.773,0:41:30.678
Good question though, thank you.

0:41:30.678,0:41:33.490
Herald: Okay, number three please.

0:41:33.490,0:41:38.684
Question: You showed the map broken down by[br]country, would it make sense to look at smaller

0:41:38.684,0:41:44.377
districts or regions, do we have differences[br]within one country for example the US.

0:41:44.377,0:41:49.661
Karsten: That's a good question, and we have[br]occasionally come across a country where

0:41:49.661,0:41:54.336
there's configuration differences in different[br]parts of the country, like for instance in Germany

0:41:54.336,0:42:00.424
right now, two of the network operators are[br]rolling out A5/3, but they go location by location.

0:42:00.424,0:42:07.543
So there's two zones right now, but those are[br]going away over time because the goal of course is

0:42:07.543,0:42:13.782
to implement the security feature everywhere.[br]There are networks though where they

0:42:13.782,0:42:18.199
purchase one part of the country from one vendor[br]and another part from another vendor, and

0:42:18.199,0:42:23.347
where security patches just don't get deployed[br]everywhere, and we would like to track that

0:42:23.347,0:42:28.884
more accurately. Currently it's just averaged.[br]What we need to track it more accurately is

0:42:28.884,0:42:34.813
constant measurements from more places. So[br]currently what our metric does is try to fairly

0:42:34.813,0:42:40.133
combine information from different location[br]and then average them even though for instance

0:42:40.133,0:42:46.783
in Germany, of course Berlin is dominating in[br]our measurement set, and some other locations

0:42:46.783,0:42:52.780
I think, thank you CCC Munich, are contributing[br]too, but if there were somewhere in

0:42:52.780,0:42:59.170
the middle of Germany, some extra security[br]feature, we would not learn about it for a long time.

0:42:59.170,0:43:08.147
You see this route? This is from last years trip from Hamburg[br]to Berlin, when everybody came to the CCC. <i>laughter</i>

0:43:08.147,0:43:13.846
So we are not distinguishing by country yet,[br]but if the information is ever there to see

0:43:13.846,0:43:17.298
a clear border we'll definitely do that.

0:43:17.298,0:43:20.001
Herald: Question from number four please.

0:43:20.001,0:43:25.840
Question: Yes, I wanted to ask, you showed that[br]you were simulating a BTS somewhere around

0:43:25.840,0:43:31.968
the middle of the talk, and I was wondering where[br]you using any of the known OpenBTS or OsmoBTS

0:43:31.968,0:43:35.221
solutions or anything else?

0:43:35.221,0:43:44.790
Luca: It's a patched version of OpenBSC. It's just[br]a few lines, there is a nice function that triggers

0:43:44.790,0:43:50.540
the software to send the SMS on queue for a[br]user as soon as the user logs in, and as soon as

0:43:50.540,0:43:55.789
the user does this I put a lot of SMS's[br]in the queue, so I can send it.

0:43:55.789,0:44:03.572
Karsten: Yeah there are OpenBSC, OpenBTS,[br]OsmocomBB project, they are an enormous help in

0:44:03.572,0:44:09.336
our research, we could have done none of this,[br]had we had to implement all of this in open source.

0:44:09.336,0:44:14.826
So they're very, very useful, and thank you[br]to everybody who've contributed to them.

0:44:14.826,0:44:17.231
Herald: Another question from number four please.

0:44:17.231,0:44:22.730
Question: Banks and other organisations love[br]to send one-time tokens via SMS, from what I

0:44:22.730,0:44:32.658
understand the talk, would it be in the range of the[br]regular criminal to exploit this and steal those tokens?

0:44:32.658,0:44:39.995
Karsten: With GSM intercept yes, you can read[br]other people's SMS when they're A5/1 encrypted,

0:44:39.995,0:44:47.273
however you have to be close to them, in a[br]proximity of let's say two kilometers, and it's probably

0:44:47.273,0:44:52.957
unlikely that the person who infected your online[br]banking credentials, stole them from your infected

0:44:52.957,0:44:59.536
computer, is also your neighbour. Those two[br]groups seem to overlap in locations.

0:44:59.536,0:45:03.970
With the SIM card vulnerabilities though,[br]you can do lots of stuff, you can send SMS,

0:45:03.970,0:45:09.248
you can redirect calls, you can steal decryption[br]keys, the only thing you can't do is read people's

0:45:09.248,0:45:14.507
incoming SMS. So banks got lucky there.

0:45:14.507,0:45:19.580
Q: Thanks[br]Herald: We have another question from the internet.

0:45:19.580,0:45:26.524
Q: Wouldn't it be easier to just reinvent maybe a more[br]nerd driven mobile network from scratch, than

0:45:26.524,0:45:32.612
to mess around with all this industry stuff[br]that has piled up for years now?

0:45:32.612,0:45:39.256
Karsten: Well, that's interesting, things do not[br]really pile up as people imagine them, so the

0:45:39.256,0:45:45.147
One of the big drivers of the OpenBSC project[br]I understand was the availability of really cheap

0:45:45.147,0:45:49.453
base stations. Why were they available? Because[br]people threw them away and replaced

0:45:49.453,0:45:53.858
them with newer base stations, and they do[br]that every time they add a new technology.

0:45:53.858,0:45:58.510
So when they added 3G they threw away the 2G[br]base stations, and replaced them with combined

0:45:58.510,0:46:02.210
2G/3G base stations, same with 4G now.

0:46:02.210,0:46:07.693
So as 4G is being rolled out all over Germany,[br]everything gets thrown away and

0:46:07.693,0:46:14.046
replaced. There isn't so much legacy in terms of[br]installed boxes, the legacy is more the protocol,

0:46:14.046,0:46:21.523
so if you throw away one end of the connection[br]and not the other you maintain the old protocol,

0:46:21.523,0:46:26.685
but then when you throw away the other side,[br]you again maintain it because it's kind of the logical

0:46:26.685,0:46:36.922
legacy. So I don't think there's an easy fix to that.[br]This is just very high-scalability engineering where

0:46:36.922,0:46:43.963
things have to work in extreme corner cases, and I[br]think all the tools are there for the existing networks

0:46:43.963,0:46:50.521
to get fixed, it's just a question of priority. At the[br]investment that a 4G network costs, a single one,

0:46:50.521,0:46:56.704
you can probably make the entire world use[br]A5/3 and upgrade to secure SIM cards.

0:46:56.704,0:47:01.958
So the money is there, it's just a question of[br]priority that keeps the networks away from

0:47:01.958,0:47:04.223
deploying these software patches.

0:47:04.223,0:47:07.718
In the end it's single lines of code.

0:47:07.718,0:47:11.488
Herald: Ok, we have another question in[br]the room from microphone number three.

0:47:11.488,0:47:17.543
Q: Quick question, for tools that you are offering[br]can they work with some kind of passive recording

0:47:17.543,0:47:25.459
device, for example can you collect data for gsmmap[br]using the OsmoSDR tools? The ones that use

0:47:25.459,0:47:30.965
the simple DVB-tuners to listen to the spectrum.

0:47:30.965,0:47:36.632
Harald: Luca, do you know OsmoSDR?[br]Luca: Yeah, I think that's more focused on being

0:47:36.632,0:47:42.823
a BTS than a sniffer device, but I think you can use[br]it as a sniffer device, it's just that then you need

0:47:42.823,0:47:49.433
to process the data in a different way, really the[br]easiest is to use the Osmocom mobile phone,

0:47:49.433,0:47:55.356
and it does this and it's what we use for the[br]Live-ISO. There are many models actually, so.

0:47:55.356,0:47:59.920
Karsten: What would you consider the[br]advantage of using an OsmoSDR?

0:47:59.920,0:48:04.865
Q:It's mostly because it doesn't require a phone[br]or a SIM card or anything, The question is can it

0:48:04.865,0:48:08.318
work passively without being,[br]without sending anything?

0:48:08.318,0:48:13.126
Karsten: Yeah, the phone he just held up,[br]that captures traffic with no SIM card and

0:48:13.126,0:48:21.204
without connecting to a network, it does so passively[br]by latching on to a cell, passively, just hearing what

0:48:21.204,0:48:27.964
is happening on the broadcast channel, and as soon[br]as the cell starts communicating with another phone

0:48:27.964,0:48:33.909
it jumps to that frequency and also listens to[br]the traffic. So that's already a passive setup.

0:48:33.909,0:48:40.173
And the C139 I think is the most available Osmocom[br]phone, you can still get that for twelve dollars

0:48:40.173,0:48:46.977
in China. So I don't think there's any reason to[br]reimplement that for any other platform if there's

0:48:46.977,0:48:49.181
already a twelve dollar solution.

0:48:49.181,0:48:53.606
Q: Thank you.[br]Herald: And we take another question from the internet

0:48:53.606,0:48:57.905
Q: Actually some people are complaining that[br]they have no signal in this room, could that be

0:48:57.905,0:49:02.417
caused by you, or is the range not that large?

0:49:02.417,0:49:08.636
Karsten: Well, we add choices for signal, we don't[br]take them away, so this is just an additional BTS.

0:49:08.636,0:49:10.143
<i>laughter</i>

0:49:10.143,0:49:12.145
Q: Okay, thank you.

0:49:12.145,0:49:18.027
Herald: Ok, are there any other questions,[br]now is the time to ask. If not I ask you again

0:49:18.027,0:49:21.779
for a warm round of applause for Karsten and Luca

0:49:21.779,0:49:24.924
<i>applause</i>

0:49:24.924,0:49:33.532
subtitles created by c3subtitles.de