Mobile network attack evolution

applause

Karsten: Thank you very much
and a very good evening.

We're here yet again to talk about mobile
network attacks, and we're going to give this talk

a somewhat different spin.

Instead of focusing on giving out new vulnerabilities,
and then hinting at how a fix could be,

and suggesting that somebody else would be
responsible for implementing these fixes.

We wanna look at those later stages of the
attack evolution today.

And make sure we don't keep re-creating new
results while old ones are not being resolved yet.

Rest assured there will also be new attacks.

We need to deliver on that every year.

But we want to make sure specifically, to introduce
some dynamics that help everybody,

for networks to become more secure.

My primary goal today is to enable all of you to help
with that evolution, and to do some of the research

that we've been doing in Berlin so far, all over the world.

There will be a couple of tool releases, and a
couple of, hopefully, evolution drivers

In the end, for us security researchers to be successful in
making the world better, we need industry.

As painful as that sounds, we need somebody to put
in a fix, and we haven't been very good

about keeping check on those people that need to put
in fixes for the research that we've been doing

over the last couple of years, and we're going
to complete the picture today.

by talking a little bit about what networks have
been doing around research in two areas.

SIM card attacks, a topic of this year where networks
found themselves in a critical situation

at risk of large parts of the subscriber base being
remotely infected, not in the phone, but in the SIM card.

So there has been fruitful discussion with industry,
and lots of responses, but not enough.

Much more so around GSM intercept, a topic that
probably the NSA discussions have moved

into everbodys mind again, but one that was really
luring for a decade now, that anybody can

intercept your phonecalls at any time.

and again, here we want to check on the network
operators, and make sure that they are

forced into putting in the protection that we deserve.

We first discussed SIM card attacks publicly in August
of this year, after a few months of

responsible disclosure, and we found
a combination of three vulnerabilities,

that led to a potentially terrible situation for networks.

The first fragment that we found was the ability
to send binary text messages from one subscriber

to really any other subscriber, so networks
allowed traffic that has no place to be routed

through networks, there's no such thing as network
neutrality in mobile networks of course,

they shouldn't be routing internal management applications through what basically is

the IP space, or the phone number space of subscribers.

The second thing we found is that the services that
these messages reach on the SIM cards are

often badly protected cryptographically. In particular
we were finding lots of cards that used DES keys

56-bit from the seventies, that has long been
phased out in pretty much any other application.

SIM cards still use old keys like that.

And thirdly we found that applications you
could install through those DES keys

can break out of the sandbox of the Java protection
parameter, and then access all kinds of data

on the SIM card that no Java was supposed to access.

And combining those three made for a remote
SIM cloning vector at massive scale.

And networks raced to fix those on at least
two of the three layers.

They put in filtering so the network, the SMS
messages would not reach the phone any more.

And they upgraded DES keys to triple DES keys.

But most networks left it at that without really
thinking through the problem and without really

understanding the root causes of what
made the SIM card so vulnerable.

So I want to go into the first two categories, since
the third one wasn't adressed even until today, and

show how the industry response
was in large part insufficient.

And I shouldn't generalise as I do now, because
some network operators have responded very

responsibly, but by and large networks shrugged
us off or put in quick fixes and then moved on to

their daily business of making networks faster
and faster and faster, but rarely more secure.

So let's look at filtering first, and what
goes wrong with filtering.

Networks, many networks started filtering at
around the time when we presented this publicly,

around Black Hat and OHM camp, and they put in
one specific filtering rule that was not surprisingly

the exact message that we used in demonstrations
at Black Hat and at OHM to demonstrate this

class of vulnerabilities, but did not understand
how much broader the vulnerabilty class is.

So to put this in a comparison to computer security,
if you tell somebody that they have a problem in a

TCP stack, let's say in the linux implementation,
and you demo it by sending packets to the ssh daemon,

the fix that they implemented is to block port 22, not
understanding that of course this exact same

vulnerability is also present on any
other exposed TCP service,

And there's bunches of ways to format
an SMS to reach the SIM card.

Some have come out of the standard, others are
just fragments of wrong implementations on phones.

In particular some recent android phones will
route pretty much anything to the SIM card.

and that's pretty convenient, because the SIM card
will look at the message and then discard it, if it's not

properly formatted for a SIM card.

So the implementor of the android
phone took the easy way.

Just put everything to the SIM card, it will
decide what it wants and what it doesn't want.

Of course with a phone like that no level of network
filtering, no filtering whatever TCP port will protect it,

Since normal user messages sometimes
get forwarded to the phone.

So the industry response was a bit insufficient here
and we'd like to see more testing of networks

and when we talk about tools we will perhaps
enable you to do exactly that type of testing,

The second area where the industry response falls
way short of understanding the problem,

again I'm generalising here, is that the
configuration of the SIM cards.

We did discuss the problem with DES keys, that you
can break a 56-bit DES key in a minute or so using

a rainbow table, and that of course, this is terrible
if those services are reachable remotely.

And networks then went in to look at
configurations, and lot of them came out

saying "We made sure everything is
triple-DES on our SIM cards"

or at least a few places there was still DES in older
profiles, we patched them to now be triple-DES.

Again that falls way short of
understanding the core issue.

Here's a bit of technical background so you can
appreciate what's going on in the SIM card.

There's a collection of keys, up to sixteen keysets,
and each keyset can have keys for signing and

encryption and so forth, and those keys have
a specific type, DES or triple-DES for instance,

sometimes even AES on very new cards.

And then there's applications on the SIM card
and these applications, there's up to sixteen million

application identifiers.

Of course no sixteen million applications fit on a card,
so some of these are present on

every SIM card, and the application gets to
choose which keys get what level of access.

And what seems to have happened in August is that
the networks go through this first application,

the standard application and make sure that triple-DES
keys are required for signature or encryption or

better, even both. And then the DES keys they
had there, they upgraded to triple-DES.

However we find in a surprisingly large number
of SIM cards the following situation:

One of the other sixteen million applications says
we use this keyset, but we require none of it.

So you send a command to that SIM TAR specifying
this keyset, and you're not required to do

signatures or encryption.

And at that point it doesn't matter if you use triple-DES
or AES or whatever algorithm, this SIM card

will accept any command sent to it.

And again that kind of being obvious to check for
when you're going through your inventory of

SIM cards, but that requires a deeper level
of understanding of these attacks than most

operators seem to have developed for this issue.

So I hope this again helps to carry the point that to
drive the co-evolution of attacks and defenses,

industry is required to think through the attacks and
understand what exactly the attack parameter is.

To make sure it gets across very visually now, I'd like
to get Luca to demo the attack as we think

it would play out in the real world.

and just as one sentence of introduction perhaps,
this is coming from a very recent SIM card

one that we picked up when we started playing
with the iPhone 5 as fingerprint reader.

It's just an US SIM card, and Luca,
what are you going to do now?

Can you switch on his microphone please?

Luca: Ok, so as Karsten said we found this
particularily interesting SIM card and

the last one we found was very recent, it's a
nano SIM and it goes into an iPhone 5.

I'm going to show you what can we do to
bypass the filterset operators have now.

So we put it into the phone. I have here a BTS,
that emulates the real operator network.

Karsten: Of course that's a default way to bypass
any type of filtering that the real network may be

Luka: So now the mobile is connecting, and I'm trying
to show you better, my BTS is sending some SMS's,

as soon as the mobile is close to the BTS, and
it tries to register, because it thinks it is

the home network, I send my application, that
is completly installed without any warning,

or anything on the iPhone.

umm

I want to show you something here, so this is the
first command and it's a delete, since I've already

installed the application many times, I first delete it.

and then I install it again.

Karsten: So this is remote application management.

On a recent SIM card, that requires
no security whatsoever, you can put in

whatever Java software you'd
like to run on this SIM card.

Luka: Ok, so it's finished, took a couple
of seconds, ten seconds, I dunno.

and now the SIM card is infected with a malware,
that every five minutes sends the current location of

the user to the attackers number.

Since the iPhone doesn't show anything, I'm
going to put this SIM card into another phone,

so you can see it better, and you can also
have a proof that it's on the SIM card.

It's not very easy with the nano SIM
into a normal phone.

so this is the other phone, I have a ok..

Karsten: So the virus stays with the SIM
card (when moved to) another phone

Luka:I'm going to turn it on now.

Yeah.

Hopefully it will register to the home network.

Yeah.

Karsten: Is it still set to manual?

Luka: Yeah, it did register.

Yeah,

So we are actually replaying the
attack again, just for fun.

Karsten: Oops.

Luka: [sigh]
Karsten: Bear with us, this is a complex demo

lots of moving parts.
Luka: What I can do is delete the SMS

Luka: So is it showing someting now?

Ok, I'll just try again.

Oh, actually I have a better idea,
so now I stop my fake BTS

Karsten: yeah, better connect to the real network.

Luka: and I let it connect to the real network.

Okay. Let's see.

Karsten: You're confident the virus
got deployed the second time?

Luka: Umm, that's actually a nice...

Okay, yeah that was a.

Karsten: Ok, lets come back to you
in a couple of minutes then.

When you've prepared this, but everybody
got the idea roughly right,

what should have happend; He's catching
the phone or any of your phones really,

he can test for vulnerabilities by sending
SMS, hundreds of them, not sixteen million,

he has to prepare a little bit, know where
a vulnerability could be, and then once

he finds an unprotected application, he just sends
a bunch of binary SMSs and combine that Java file.

and that java file installs on the SIM card and
it stays installed on the SIM card,

and it will every five minutes send the
current location via SMS to his number,

or do any other thing that the Java on
the SIM card is allowed to do.

It could even try to exploit the other parts of the SIM
card through that unpatched Java vulnerability that

a lot of these SIM cards still have.

Installing the virus again?

Luka: It's installing again.

Luka: This was just the best case we found so
you can actually install an application inside the SIM,

in case this is not available, another choice is just
reading the current ciphering key from the SIM.

Karsten: Yeah, so there's a lot of these..

Luka: So this is the message I was waiting for.

Karsten: So this older Nokia phone is the only phone
we ever found that asked whether you allow your

SIM card to send anything back to the attacker.
The iPhone just does it by default without asking you.

Luka: Press yes.

applause

Luka: Oh it's a bit small there. I try to copy

Karsten: Did you want to show more Luka?

Luka: Yeah the phone now sent the SMS to me,
and I want to show how it looks like, so

hmm no.

Something like this? Nope

sighs

I want to enlarge this, so in this little field, there is
the current network, the location area and cell-ID.

So basically it's a very precise location
information about the user.

applause

Karsten: thank you.

applause

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

So it goes through.

Karsten: So a persistant virus on a modern SIM
card, I think that's what was needed to

give the industry another nudge to
deeply understand this.

Now to create some further nudges from you all,
and to fulfill that goal that I stated going in,

to enable everybody to do these tests yourself,
we wanna release a tool today that condenses all

the SIM card knowledge that we collected
over the last couple of years.

It's an open source tool, written in Java, that was
the easiest to speak to SIM cards with, and it tests

for all the vulnerabilites we discussed in August,
including things like triple-DES downgrade which

a lot of operators seem to not
have understood quite yet.

But it also detects these more recent vulnerabilities.

Now scanning these sixteen million possibilites on
a SIM card, and each sixteen keys for them,

that takes a long time, and some older
slower SIM cards up to two weeks.

So one thing the tool does is pre-select these
TAR's smartly, so it only takes a couple of minutes.

It does run on a normal smart card reader,
PC/SC interface, as well as the Osmocom phone

awesome opensource project also.

We patched it a little bit to now act as a smartcard
reader. So of course it can communicate

with a SIM card.

So if you have any of those; PC/SC reader or an
Osmocom phone and a couple of minutes of time,

download the software and please run the tests,
make sure you're not affected, and if you are

be very vocal to your network operator and
demand that these things get removed.

applause

Thank you.

Looking at similar technology or similar weaknesses,
let's revisit the topic of GSM intercept,

and I'll again try to make the point that networks may
be casually interested in fixing some bugs that

they may not have fully understood, so they only did
half the fixes or not at all and again I think this is

of high urgency, understanding now how many
people are intercepting our phone calls.

Network operators are supposed to protect us on
all the frequencies we use and while 3G and 4G

bring pretty ok cryptography with longer key
lengths, most of our calls still go over 2G,

this standard from the eighties.

It's the only technology that can cover large areas,
and even in cities where the cell sizes don't

have to be so large, these frequencies have to
get used because all frequencies are full.

We have a frequency scarcity, so 2G frequencies are
certainly still used by everybody, almost every day.

and on 2G there are two different encryption
standards that are found in the wild.

There's A5/1, the first encryption cipher, the one
that was originally invented along with GSM, back in

the eighties, and then there's A5/3, a ten year
old encryption standard, that's supported by

newer phones, I would say about half the phones
in current use support this A5/3 cipher.

where the other ones will always default to A5/1.

And the network would have to support both of them
in a secure way or as secure as possible way

to sufficiently protect their customers.

Let's visit each of them in turn.

To break A5/1 with tools like the ones we released
some five years ago now, you have to have

some attack surface. It's not enough to have
a tool that can break an A5/1 packet, you also

need to know what's inside the A5/1 packet.

So for one of all these packets you have to predict
the content, you break the key from it, and

then you can decrypt the rest of them as well.

So you've got to start somewhere
to then break the rest of it.

And I believe no spy agency would have a
better way of breaking A5/1 over the air.

They also have to rely on some attack surface.

So if everything is unpredicable, it basically
becomes XOR'ing random numbers.

The GSMA and later the 3GPP, the standardisation
bodies, that tried to make the mobile world

a little bit more secure, they worked hard
some five years ago to amend standards for

this attack surface to go away.

So in a standard trace as we see it in too many
networks pretty much everything that is

encrypted is predictable, at least in the call setup.

So the phone starts unencrypted, it receives
a ciphering mode command and it will then

encrypt every single packet it sends, and also
expect packets it receives to be encrypted,

including some that actually make sense, where it

says, "Here, you phone with that TMSI, have
another TMSI", but also things are

encrypted that carry not content whatsoever, like
a null frame, that says the network is supposed to

speak now, but it has nothing to say, but also things
with static content, like these system information

messages. This exact same message was sent
maybe a second earlier unencrypted.

And once it switches on encryption the phone
expects this also to be encrypted.

Then there's messages with very little content
and again null frames. Things that bascially have

no meaning whatsoever. Assignment to certain
frequencies, there are not many frequencies

to choose from so this is mostly predictable,
and all of this is to be considered attack surface.

And there are two standards, padding randomisation,
which takes shorter messages and

appends random bytes, and SI5 randomisation which
takes longer messages but scrambles that content,

that removes this attack surface almost entirely.

The little bit of attack surface that's left is due
to vendor specific communications, and

this needs to be fixed vendor by vendor.

But by just putting in those two standards,
A5/1 calls should be protected from at least

the tools that we can think of.

Now given that this is five years ago that these
were standardised and that there is a lot of

pressure on security these days. You'd imagine
that these fixes, just tiny software fixes,

would be deployed thoroughly, however we
rarely see networks that do either of them,

and we've never seen a network
that does both these fixes.

So somewhere along the way, between the
GSMA and 3GPP who write the standards

and you as a customer, that idea got lost.

And it's not a difficult idea, to throw in some
random numbers, instead of static values,

or to take a message and scramble its contents.
These things should be pretty straight forward to

implement, and we've seen both ideas in the wild,
so there is proof that at least some vendors

have implemented these features.

However the networks do not
seem to be using them at all.

The same attack surface then would open up for
A5/3 if somebody had a much bigger computer

to decrypt it. And by much bigger
I mean about a million dollars.

So A5/3 is now ten years old and ten years
ago it seemed like a great idea to take

a 64-bit stream cipher and make a 64-bit block
cipher out of it, you don't have to mess

with key generation or anything, it becomes
much more secure, and in fact it did,

two million times more secure.

But guess who's going to spend a million dollars
to break your A5/3 encrypted call, this year right.

and not just that one agency, every agency has a
spare one million dollar to build an A5/3 cracker.

So industry took ten years to implement
this standard, and now that they do,

in Germany for instance two networks just
started this past month to roll out A5/3,

now it's already outdated.

Guess what, the next standard was developed
five years ago again. A5/4 it's called,

it blows up the key size to a good 128-bit,

it steals that from the 3G part of the SIM card,
but every SIM card these days is a 3G sim card.

So somehow we are always ten years behind
the state of the art in cryptography, and

ten years behind what even industry describes,
prescribes themselves to implement.

We want that to change, and again we want you
to help us change that by creating awareness

around where networks put in
what type of countermeasures.

It's not enough for them to standardise
padding randomisation and SI5 randomisation,

It's not enough for them to specify A5/3 and
A5/4, they actually need to deploy it.

And here's three tools you can
use to create some visibility.

The first two we're releasing today, and the
third one has always been available, there's just

an incremental patch from us today.

First one runs on an android phone and
it allows you to record network traces.

Those network traces of course tell you what type
of encryption is used, whether keys get rolled over,

whether your temporary identity gets
changed regularly, and so forth.

The second tool is basically the same running on a
linux computer, if you want to have the data for

further analysis, with the xgoldmontool,
Tobias Engel's tool.

And then the third possibility for aquiring
the same data, not just for your own phone, but

basically everybody in the cell you're connected to,
is the OsmocomBB open source project.

Sylvain put in a lot of work a few years ago
and created this burst_ind branch,

we extended it just a little bit to run much more
stable and to really help as a capturing tool.

So any of these tools now helps you to look at
what configurations your network is using,

and perhaps interpret this yourself, and to
check whether they are using the latest

encryption and what not.

We'd much appreciate if you shared some of
that information with us, and we could then again

help other by sharing this further and
interpreting the information, and to make that

even easier, we put all these tool in a Live-ISO
that you can put on a USB stick and boot

with it. That has all the tools on it, the network
measurement tools, it has the SIM tester on it,

it has all the stuff on it, catch-a-catcher to
find IMSI catchers in your vincinity.

It has an option to send data to a website called
gsmmap.org and along with all these tools we

are releasing today, a new version of the GSM
map website, much more colourful than before,

but also much more usable we hope.

So here's the new GSM map, and this now
interprets a lot of network traces that many of you

collected over the last couple of years, with Sylvains
burst_ind setup, and for those countries where

we have a little bit of data we do estimates,
these are the striped countries here,

and for those networks where we have a lot of data,
we try to track the network security over time.

So this for instance are the four german networks,
and you see how over time they actually do change

their security settings. T-Mobile for instance,
the high-flyer here, they had a big drop in

network security, intercept this is, by switching off some
of the randomisation, earlier this year, but then

after they did that they started rolling out A5/3,
so somehow they're trading in security features,

one for the other. This now on an aggregate level
tells you how secure your network currently is,

against intercept, basically spy agencies listening
in to your calls, impersonation, that is other

people using your phone identity to conduct
some transaction, and against tracking, that is

somebody following your whereabouts by electronic
means. Basically information exposed through

HLR queries remotely.

And you see how networks
differ in these catgories.

This map by the way is where contributions came
from. So a lot of these of course are collected

by us in Berlin.

But thank you so much to all of you who sent
in all these traces from all these places that

none of us have ever been to.

So it's absolutely fabulous to see what
coverage we've gained here.

Still a lot of striped and white countries,
so we hope to complete the picture, but

we need everybody's help.

And hopefully with the tools we released
today it becomes so much easier to push

data up here, that this will
soon be filled a lot more.

Now for those countries that we have a lot of
data, and that is twenty-seven countries total,

we are releasing detailed reports today
also, that interpret these measurements and

rank the networks, but also explain a little bit
of how we measure these things, but then give you

detailed technical measurements on what encryption
is used, for what types of transactions are

authenticated and so forth.

applause

Thank you.

applause

So if your country is one of the twenty-seven,
we'd love if you read the report.

If it isn't we'd love for you to download the tools
and make sure we can publish a report next month.

So these will be refreshed every month, hopefully
forever, or until every network fulfills every

security goal imaginable and then we
will shut down our website.

laughter

So that's GSM Map, the new website, and
you saw all the tools that are available now.

You may notice that GSM map does not
yet have a security metric on SIM cards.

Just because our measurements are
too sparse to paint a good picture.

We'd like to start calling out the networks that do
bad SIM card security, but again we need your help

to scan your SIM cards, and to make sure we get
some fair comparison among all the networks.

Just as a heads up, we found about in every other
network where we have a lot of SIM cards to test,

vulnerabilites like the ones we discussed today.

So there should be a good chance if you have
couple of SIM cards at home, to find at least a few

that are actually vulnerable.

And if you do you can start installing Java
on them and playing around with them.

Allright, that was everything we wanted to discuss.
A round of thank you, in particular to Lukas and Linus

who have put in many months of really hard work
to get these tools ready for release today,

they were just about ready this morning after many
months of working on them, so thanks to them.

But thanks to everybody else also, who were
involved. There's just a long list of people

who contributed a month or two of work.

Thanks to the open technology fund for sponsoring
this research and for helping us fight

bad security in the world and raising awareness
around where bad security is implemented.

Thank you to all of you for using our tools to take
this research to places that we could not have imagined.

Thanks.

applause

Herald: Thank you very much Karsten and Luca.
So we have quite some time left, so as always if

you have questions, in the room, please line up
behind the four microphones on the ground floor.

If you have questions from the web, or
if you have questions on the streams,

please write them on twitter or on IRC
and we will ask them here live in the room.

And I think we'll start with two
questions from the internet please.

Karsten: One quick...
Signal angel: Okay Herald angel: Wait please.

Karsten: One quick heads-up before the first
people start leaving, if you're interested in playing

with the tools or at least seeing them being
played with there's a workshop that will start

at six in Saal D, so if you want to see the live-ISO
and all its components and perhaps

take a USB stick home, we brought plenty to
play with, saal D is where we'll meet you in a few

minutes. Sorry, go ahead with the questions.

Herald: Okay, two questions
from the internet now.

Signal angel: So first one: there are still many low
hanging fruits, so what about SS7 networks, did you

investigate them and their way of communicating with
each other. Can you tell us anything what happened

with the industry in the last year there?

Karsten: Sure, yeah, SS7 is another decades old
technology that was built with a wrong threat model.

Basically everybody who connects to the network
is trusted, but you have to connect to every

other telco in the world to route calls to them,
so there's some disagreement in the threat model.

And people find SS7 vulnerabilites wherever
they look, both in the configuration, stuff like,

you know, the SIM filtering, the SMS filtering,
the same kinds of topics come up in SS7,

where of course you want to block unneeded traffic,
and networks are really bad at that typically.

But also people find implementation bugs on
boxes that are connected to SS7 and those are

really, really hard to research.

The boxes are very expensive, so you can't just
research it in isolation, and everybody who is

running a box like that, will probably put you
in jail if you ever attempted to break them,

if you started to do some fuzz testing on them.

So SS7 unfortunately isn't really prime for open
research. It actually requires what I showed

on the first slide, kind of a co-evolution where
the networks let the hackers in, so that they

then learn what other hackers could have
done to them, and I don't see many networks

to be ready for that yet.

Definitely a topic with lots of low hanging fruit,
but no easy way to research it.

Signal angel: Okay, thank you.

Signal Angel: Should we go on with the second one?
Karsten: Yes

Signal Angel:Has there been any testing using
parallel application only SIM card overlay

to block apps on the primary SIM card
so that's probably a strange question,

but the MuVuCo? project is mentioned here, or
did you investigate any other simple way to block

the Java card bits?

Karsten: So I think I understood the question as,
is there any easy way of putting in another layer

of protection just in front of your SIM card? I guess
we can't ask the person asking the question right?

But if that were the question then the answer is,
of course you can put all kinds of proxy stuff

in between your phone and your SIM card, there's
a nice open source project called SIMtrace,

That then means you carry a little computer next
to your phone whenever you use it and of course

that's impractical, so that would be a forensic tool
perhaps to investigate what people are currently

doing to your SIM card, when you already have
a suspicion that something is going on, but

there's no practical way to get a phone to give
you that level of access, even on android, the part of

the operating system, the system that speaks with
the SIM card is usually more baseband than android

or at the very least a proprietary device driver type.
So I can't think of any usable phone where

you could easily implement a SIM card firewall
for instance, but I'd love to learn about them

if they do exist.

Herald: Okay we take a question from microphone four.

Question: Did you investigate any upstream
vulnerabilities from or to the baseband

or to the average phone OS, so for instance
if you have infiltrated the SIM card can you do

any stuff to an iPhone or something?

Karsten: Good question, and no we haven't and
I wouldn't think that that would be the most

fruitful vector, because the interface between
a SIM card and a phone is pretty defined,

very narrow channel. So I'd think that a phone
baseband is much easier exploited like Ralph did it

a couple of years ago, emulating a network and
sending commands, that interface is much wider

and has many more protocols running that
could potentially be exploit targets.

Good question though, thank you.

Herald: Okay, number three please.

Question: You showed the map broken down by
country, would it make sense to look at smaller

districts or regions, do we have differences
within one country for example the US.

Karsten: That's a good question, and we have
occasionally come across a country where

there's configuration differences in different
parts of the country, like for instance in Germany

right now, two of the network operators are
rolling out A5/3, but they go location by location.

So there's two zones right now, but those are
going away over time because the goal of course is

to implement the security feature everywhere.
There are networks though where they

purchase one part of the country from one vendor
and another part from another vendor, and

where security patches just don't get deployed
everywhere, and we would like to track that

more accurately. Currently it's just averaged.
What we need to track it more accurately is

constant measurements from more places. So
currently what our metric does is try to fairly

combine information from different location
and then average them even though for instance

in Germany, of course Berlin is dominating in
our measurement set, and some other locations

I think, thank you CCC Munich, are contributing
too, but if there were somewhere in

the middle of Germany, some extra security
feature, we would not learn about it for a long time.

You see this route? This is from last years trip from Hamburg
to Berlin, when everybody came to the CCC. laughter

So we are not distinguishing by country yet,
but if the information is ever there to see

a clear border we'll definitely do that.

Herald: Question from number four please.

Question: Yes, I wanted to ask, you showed that
you were simulating a BTS somewhere around

the middle of the talk, and I was wondering where
you using any of the known OpenBTS or OsmoBTS

solutions or anything else?

Luca: It's a patched version of OpenBSC. It's just
a few lines, there is a nice function that triggers

the software to send the SMS on queue for a
user as soon as the user logs in, and as soon as

the user does this I put a lot of SMS's
in the queue, so I can send it.

Karsten: Yeah there are OpenBSC, OpenBTS,
OsmocomBB project, they are an enormous help in

our research, we could have done none of this,
had we had to implement all of this in open source.

So they're very, very useful, and thank you
to everybody who've contributed to them.

Herald: Another question from number four please.

Question: Banks and other organisations love
to send one-time tokens via SMS, from what I

understand the talk, would it be in the range of the
regular criminal to exploit this and steal those tokens?

Karsten: With GSM intercept yes, you can read
other people's SMS when they're A5/1 encrypted,

however you have to be close to them, in a
proximity of let's say two kilometers, and it's probably

unlikely that the person who infected your online
banking credentials, stole them from your infected

computer, is also your neighbour. Those two
groups seem to overlap in locations.

With the SIM card vulnerabilities though,
you can do lots of stuff, you can send SMS,

you can redirect calls, you can steal decryption
keys, the only thing you can't do is read people's

incoming SMS. So banks got lucky there.

Q: Thanks
Herald: We have another question from the internet.

Q: Wouldn't it be easier to just reinvent maybe a more
nerd driven mobile network from scratch, than

to mess around with all this industry stuff
that has piled up for years now?

Karsten: Well, that's interesting, things do not
really pile up as people imagine them, so the

One of the big drivers of the OpenBSC project
I understand was the availability of really cheap

base stations. Why were they available? Because
people threw them away and replaced

them with newer base stations, and they do
that every time they add a new technology.

So when they added 3G they threw away the 2G
base stations, and replaced them with combined

2G/3G base stations, same with 4G now.

So as 4G is being rolled out all over Germany,
everything gets thrown away and

replaced. There isn't so much legacy in terms of
installed boxes, the legacy is more the protocol,

so if you throw away one end of the connection
and not the other you maintain the old protocol,

but then when you throw away the other side,
you again maintain it because it's kind of the logical

legacy. So I don't think there's an easy fix to that.
This is just very high-scalability engineering where

things have to work in extreme corner cases, and I
think all the tools are there for the existing networks

to get fixed, it's just a question of priority. At the
investment that a 4G network costs, a single one,

you can probably make the entire world use
A5/3 and upgrade to secure SIM cards.

So the money is there, it's just a question of
priority that keeps the networks away from

deploying these software patches.

In the end it's single lines of code.

Herald: Ok, we have another question in
the room from microphone number three.

Q: Quick question, for tools that you are offering
can they work with some kind of passive recording

device, for example can you collect data for gsmmap
using the OsmoSDR tools? The ones that use

the simple DVB-tuners to listen to the spectrum.

Harald: Luca, do you know OsmoSDR?
Luca: Yeah, I think that's more focused on being

a BTS than a sniffer device, but I think you can use
it as a sniffer device, it's just that then you need

to process the data in a different way, really the
easiest is to use the Osmocom mobile phone,

and it does this and it's what we use for the
Live-ISO. There are many models actually, so.

Karsten: What would you consider the
advantage of using an OsmoSDR?

Q:It's mostly because it doesn't require a phone
or a SIM card or anything, The question is can it

work passively without being,
without sending anything?

Karsten: Yeah, the phone he just held up,
that captures traffic with no SIM card and

without connecting to a network, it does so passively
by latching on to a cell, passively, just hearing what

is happening on the broadcast channel, and as soon
as the cell starts communicating with another phone

it jumps to that frequency and also listens to
the traffic. So that's already a passive setup.

And the C139 I think is the most available Osmocom
phone, you can still get that for twelve dollars

in China. So I don't think there's any reason to
reimplement that for any other platform if there's

already a twelve dollar solution.

Q: Thank you.
Herald: And we take another question from the internet

Q: Actually some people are complaining that
they have no signal in this room, could that be

caused by you, or is the range not that large?

Karsten: Well, we add choices for signal, we don't
take them away, so this is just an additional BTS.

laughter

Q: Okay, thank you.

Herald: Ok, are there any other questions,
now is the time to ask. If not I ask you again

for a warm round of applause for Karsten and Luca

applause

subtitles created by c3subtitles.de