*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*