All right.
Shh.
All right.
As a quick polite reminder to everyone here, if you are taking
photos, which you're more than welcome to do, make sure that
you have the consent of everyone in the frame.
That means everyone.
So if I took a photo up here right now, I'd have to talk to
each and every one of you beforehand and say, is it all
right to take a photo?
All right.
So, without any further ado, this is LTE versus Darwin by
Hendrik and Brian, so please.
Okay.
Thanks. Hello.
And welcome to our talk.
So my name is Hendrik and this is Brian.
We are both security researchers from Germany.
We are dealing with telecommunication networks.
So, for example, 4G LTE networks.
And this is a talk about our current research.
So we analyze the 4G LTE network in
backend and frontend and are searching for security problems.
This is, yeah, should be the first talk of some more and we
will see how it gets.
So some background about us.
We are old school network geeks dealing with a lot of
technology.
We are working for the company called ENW in Germany based in
Heidelberg.
And we are working on the security of the 4G LTE network
in Germany.
So we are working on the security of the 4G LTE network in
Germany.
And, yes, we make security assessments.
And if you want to make security assessments in deep, you have to
understand the technology in deep.
So we take a look at the technology and then we look at
security problems.
We are always talking about some topics, security topics on our
website, for example, if you are interested in talk with us,
have a discussion with us.
Also on the conference or, for example, who wants a deeper look
inside, we are involved in security in a research project
which has ended last year called Asmonia.
Okay.
So back to our talk.
Why 4G LTE?
Because it's a very interesting and new and very complex
technology.
It's a new one.
And it introduces a lot of very interesting features.
For example, self-organizing networks.
A security guy, if you have a self-organizing network, you are
thinking about them.
Is it really working?
So we take a look at it.
We are talking about trust, especially, and optional
controls mentioned in some specs.
So, yeah.
Enjoy the talk.
First of all, we thought each talk should have information.
And second, some kind of message.
And because of this, we have a comparison with Darwin.
Brian, we explain you.
Okay.
Yes.
So talking about evolution, I guess for most of you, Darwin
is a proper enemy for long-term evolution.
Main aspect we're actually looking at, whether we're
leaving in Darwin or not, doesn't make a difference for us.
Natural selection actually has a few, say, base drugs, which
we think are quite important.
In this case, it is taking oneself out of the gene pool.
Stupid things, especially in technology, shouldn't happen
more than once.
And you've got the bug, whatever the vulnerability that
was used, it should be fixed.
So second try, it shouldn't happen again.
The Darwin Award itself actually originated from a
use-net group from around about 1985 and has been, yeah,
developed further on since.
Simple things, stupid things, a nice guy who actually tried
to have some fun with firecrackers in his butt and kind
of blowing his balls off.
Now, the thing is you always hear these news and they could
be fake.
And most people think they're fake and most people actually
say hope that they're fake.
Problem actually then is quite often they aren't.
And I don't know which one of you would actually try it.
Not really the best thing to do.
So for us, quite simply the question is, is Darwin, is
natural selection the one enemy to take down long-term
evolution?
OK, back to the technology.
We will start with some basics.
Who of you knows the setup of a 4G ATE network?
Not much, I thought.
OK, so we start with some basics so everybody tries to
understand.
4G LTE first is specified by the 3GPP, the third generation
partnership and project.
And it really deals with LTE and HSDPA, for example,
UMTS networks.
But it's already starting with GSM.
Another important specification group is the ITU or in Europe
and the Etsy.
We are focusing on the specification on 4G LTE.
And this is only done by 3GPP.
Here are the 3GPP milestones listed.
It starts in 1999.
Here we see CDMA specifications, HSDPA up to LTE and LTE
advanced.
So we are talking about LTE, but LTE advanced is based on
it.
And LTE was finished about 2012, but it's still in progress.
So there are always changes to the specifications.
So it's always a bit tricky to find something there.
And LTE and further LTE research is going on there up to
2016 is the plan at the moment.
So the basic architecture.
The most important thing is that 4G is based on an IP
packet system.
So the old network, GSM, UMTS, for example, is based on a
circuit switch network.
And 4G LTE has IP communication.
So for all of us, it's quite better to understand.
We have on the left side, you see on the slide, the LTE
wireless network, for example, or non-3GP networks.
Non-3GP networks means some kind of untrusted networks
connected to the core system.
So for example, Wi-Fi clients on a hotspot or something
like that.
Then we have the packet core domain.
This is the core system of the LTE network.
And this system is connected to outside networks, other IP
networks, for example, internet.
Here in more detail, you don't have to understand everything
in detail now, but you see there are a lot of components.
And these are not all components specified by the
3GPP.
It's very, very complex.
But you have the terminals.
So the called UE user equipment.
This is connected to the access networks.
It's a radio access network.
So the wireless network, for example.
And this network has a base station, the antenna, for
example, and it's routing the packets to the core network.
The core network is the heart of the provider.
So there are all the management functionalities and routing
functionalities and services provided to the customer.
For example, the MME in the middle, it's a management
entity.
This is really the control function server for the whole
environment.
Then the SAE gateway in the middle of the right of the
MME.
It's part of the serving gateway and PDN gateway, packet
data network gateway, which has a core routing function.
And here all the calls are terminating and then routed to
other IP networks, for example.
And then there are a lot of more functions like charging
systems, the database, HSS, it's equivalent to the GSM
and UMTS network.
So you see there is really a bunch of components.
Another important point is that calls, for calls, voice
over IP is used.
This is placed in the IMS, intermediate subsystem.
And the PCRF has policies who is able to do something in
the network.
So these are the basics, just a little bit of them.
Now we come to the real, to the important stuff.
OK.
LTE in the field.
Now, first question is what do you actually see out in the
field?
The only things that you can really see are antennas and
the E-Node Bs.
The E-Node B is the actual AI interface.
It's the bit that's got the network cable on the one side
and the antenna on the other side.
They come in quite a few different shapes and sizes,
meaning you've got quite small boxes, say the size of a
laptop just a bit thicker, sum it up on a cell mast.
You've got ginormous 19-inch racks, what you've got for
every server system.
Or you've sometimes even really got portable E-Node Bs.
During our research, we actually found a few approaches
to say an E-Node B that could be carried for tactical
reason in a backpack for somebody out in the field and
kind of carrying its own LTE network wherever around
with it.
There are mainly four different types or four different
sizes of cells that are established by these E-Node Bs.
The macro cells are the, I guess, normal cells that you
have in every town.
With a race of more than 100 meters.
Then you've got the micro cells, which go up to 100
meters, which could be, say, if you've got a block of
houses that has to be covered.
Then you've got the Pico cells with 20 to 50 meters,
which are mainly intended for, say, company use, office
use.
So own company, you haven't really got a very good cell
phone reception, so you place a mast somewhere.
And then, of course, you've got the home E-Node Bs,
which are, let's say, femtocells.
The same principle.
The most important thing about an E-Node B, if you
think about it, it's somewhere out in the field.
I guess a few of you have seen cell masts and seen the
security measures around them.
Probably guard dogs and whatever.
That's the one point where all encryption coming from
the UE terminates and on the other side where all the
encryption from the back end terminates.
So say you've got access to an E-Node B, everybody using
it is yours.
Now, having all these different sizes of cells results
in heterogeneous networks.
You've got, above the normal LTE cells, you've got
systems like WiMAX and Wi-Fi, and they actually come up
in specifications.
So there are concepts that people can actually roam from
an LTE network over into your WiMAX network or into your
normal Wi-Fi network, which, of course, is quite a
complex situation.
And for that reason, you've got the functionality of
self-organizing and self-configuring networks,
which we'll have a look at later on.
Just as an example, a small E-Node B as you can really
find them outside.
An E-Node B has got ports for multiple antennas.
Simple reason on the one hand, LTE is a multiple input,
multiple output system.
So increasing throughput by using multiple antennas.
Above that, an E-Node B is able to establish multiple
phone cells.
Using directional antennas, you can actually go around the
cell mass in certain areas, and depending on which side
you're on, you've really got a different cell, which means,
of course, in areas where two cells would collide, you put
the cell mass in between, and you optimize coverage.
The E-Node Bs themselves are placed close to the antennas.
Smaller devices can sometimes really be placed up on the
cell mass.
Larger devices, of course, on the ground.
As I said before, connected via LAN.
Self-configuring, you've got stuff like DHCP running and
giving an E-Node B an IP address.
Interesting solution.
Now, what we had quite a good look at are, yeah, UE's.
Question, what do we have?
We've got phones.
Of course, phones are there to do phone calls.
We said it's an IP-based system.
So you've got voice over IP.
SMS are turned into zip messages.
Just the way it goes.
And above that, of course, you've got normal tablets and
slides, you've got your USB sticks and USB modems, 4G
cards, mobile hotspots.
And funnily enough, even an active relay node in an LTE
network will at some moment play a simple UE.
But we'll have a close look at that later.
Our scope, yeah, usually if you look at mobile devices, you
look at the software, you might have a look at hardware
attacks, and you'd probably have a look at apps installed.
We, on the other hand, are actually trying to have a look
at the equipment from the outside.
Say, what can we find out about a mobile phone without
having it in our hands?
And I'm thinking about what does the mobile phone actually
know about the network?
Typical data is the physical cell ID, the tracking area
code, normal signal strength measurements, and its own
position.
The cell ID, or physical cell ID, is round about similar to
the normal cell IDs you know from GSM networks.
A normal identifier to know where you are, and for the
backend to know where a mobile phone is.
In LTE, there are 504 different IDs.
So, of course, if you think about a large country, you'll
have far more cells than only 504.
The system there is by using automated neighbor relations
between E-Node Bs.
It's only important that you haven't got the same cell IDs
in adjacent cells.
So, you go further out, cell IDs can simply repeat.
Above that, nowadays, in LTE, you've got tracking areas.
Now, thinking about GSM, paging.
A phone call comes in for a mobile phone, which is usually
in standby mode, and it has to be woken up.
Paging messages send out, they used to go to a cell.
Nowadays, they go to a tracking area.
And if you think about it, that's a tracking area can
contain multiple cells.
It is actually quite interesting to try to work out how
large is the tracking area.
How far do I have to be away from a mobile phone to maybe
work out that he's actually being called at the moment?
Then you've got the signal strength.
Not a lot to be said about that.
I guess you really know how good the bars you've got on
your mobile phones are.
Mainly just fun.
Then you've got location.
Of course, mobile phone can get its own location using
systems like GPS, Galileo, or GLONASS.
But above that, you can use cell-net-based positioning.
For these approaches, there's the enhanced serving mobile
location center somewhere in the back end, which simply is
a system that will help a piece of equipment to find out
its own position.
The equipment can send out a request, and then the
ESMLC will do the rest.
Positioning itself is then done by observed time
difference of arrival.
So your mobile phone will get a list of certain ENodeBs that
are around you.
They'll wait for certain messages, and will just measure
the time difference in between.
And by that, a normal triangulation is possible again.
Then we've got the question accessing data.
If you've got your mobile phone, there are various ways
to really access the data that you'd like to have.
On iOS systems, you've got the very magic number that I'm
not going to read out now.
Giving out various information on the cell ID, the tracking
area, yes, on the second one, and just the stuff that we
want to have a look at.
On Android, you've got some extra apps.
I've just got an example here.
And then the big question, as I said, why do we actually
want this data?
I guess all of you know that it's quite important to know
how stuff works.
I guess that's how you would have known that it kind of
has got some recoil.
Nah.
For us with technology, you've got to do your homework
before you can do any kind of security assessment.
And of course, 3GPP has published stacks of documentation,
stacks of white papers and stuff.
But white papers really never show what's in the field.
So it's up to us to just have a look at it.
Our simple approach at the moment is to write a small app
for Android devices.
I know there are a few out on the market, but we just want
a minimalistic system.
Get all the cell mask information that it's got.
Get the current position.
Stick it all into an XML file.
Do some good old classic war driving.
You can do it simply on an Android app, or you can do it
manually using some kind of 4G modem or a mobile phone using
AT commands.
You've got this good old AT plus COPS question mark, which
will give you information on all its networks that a single
cell can see at the moment, or that a single mobile device
can see at the moment.
So that's one of the parts of research that we're currently
working on.
Just sit in our cars, have a look around.
When we've done, or when the app is finished and we've got
some data we'll publish in our blog, if you have interest, you
can have a look at it.
And of course, if you ever want to know what kind of LTE
systems are around them, give it a try and just see.
Now we've got the question third party awareness.
What can somebody else in a mobile phone network actually
see about my phone?
What data can you get?
LTE is an IP network, so of course, scanning is possible.
We'll have a look at that a little bit later on.
Of course, there are some sorts of access control lists out in
the field which work perfectly.
And this point, sorry, we're going to have a look at some
exemplary data, which is the attach procedure, meaning the
initial bearer setup.
Involve components, of course.
The whole back end is involved.
The E-Node B and of course the user equipment.
I've got the very simple scenario.
Some mobile phone is switched on.
It'll contact the E-Node B, send out the RLC connection
request, and at that stage will include some kind of
STMZ, a mobile temporary MZ number, or in some situations
simply a random row of digits.
Data is transferred over to E-Node B.
Initial connection is set up.
And then just as we're used to from GSM systems, the mobile
phone sends out its MZ number.
So at this point, we'd still be able to use some sort of LTE
MZ catcher to get this little number.
Above that, data is sent on from the E-Node B back into the
back end to the MME.
Just to think about it, communication relate from the
E-Node B to the MME, which is NEST messages is always
encrypted.
That's the way that it has to be.
Every packet needs an encryption header.
Problem justice, the algorithms that they've got on offer.
It has to be encrypted, so why give the option?
After that, of course, the MME in the back end fetches all
necessary keys for the mobile phone, fetches subscriber data,
passes it back onto the front.
E-Node B establishes the actual connection.
And from that moment on, all data transmitted is actually
encrypted, meaning still we can reach the MZ number, but
that's about it.
And especially going up the next level, it's an IP network,
so there isn't really a lot that you can catch over the air
if it's done properly.
If it is, the future will have to show.
Yeah.
Then we've got the paging process.
Paging process in GSM systems is quite interesting.
I think a tech was published last year simply using hacked
mobile phones answering all paging requests.
Kind of network says, hey, where's mobile phone ABC?
And some of the mobile phones says, hey, it's me.
And these mobile phones actually did that for all possible
phones around them.
Breaking stuff.
So the question is, how is paging actually here with us in LTE?
It is slightly similar, of course.
The UE is in some kind of standby mode and gets data
sent to it.
The UE wakes up from time to time periodically, gets the
stuff, and good.
Problem just is you haven't really got this hey, phone ABC
is a message for you anymore.
You've got a frame, and somewhere in this frame, there's
a little, to do it simpler, we call it a flag, saying, hey,
there's a message for you in that point.
So all mobile phones will get or can get the same paging
frames, but they'll only react to the data that's really for
them.
And of course, the frame to react to is slightly
obfuscated.
I've got to say I love all slides just with the formula on
it, so I just had to do it.
Finding the frame.
You've got a system frame number on every frame that goes
out.
You've got a DRX cycle of the UE, which is actually the
interval in system frames in which the UE wakes up and
checks for paging messages.
Then you've got the number of paging occasions per DRX, which
is the setting in the E note B.
You've got N, the minimum of the DRX cycles and the number of
paging occasions.
And you've got the so-called UE ID, which is imzimod1024.
So by this point, you'll have a slight problem identifying any
kind of mobile phone on the network.
It's not the imzic number that's used anymore.
It's the imzimod1024.
So actually reversing that to a 15-digit or breaking it down
to a 10-digit imzimod number, not really very easy to do
anymore.
Above that, you've got the paging occasion, meaning you've
got the whole frame.
This frame has got subframes, and the UE has to identify its
actual subframe that it's got to look at.
For that, you've got the next function looking at the whole
frame and then finding positions.
These subframes are, say, 10 elements long.
And you see it in the little table on there, which is actually
from the specs, that only in position 0, 4, 5, and 9, you can
have a paging occasion that you can react to.
Now, doing a little bit of maths, playing around with it,
you'll work out that there is a maximum of 8,160 paging
occasions.
So of course, you'd think, hey, that makes it easy for me to
find a mobile phone.
But yet again, as soon as a mobile phone roams, goes into a
different DNOB cell, the constants are different, so the
whole terms change.
So yet again, you can't track a device.
Above that, playing around with the numbers a little bit
further, you've got four possible paging locations.
Ends up that you can actually only have 32,640 different
paging codes in one single cell.
Which means if you'd have another mobile phone extra in
that cell, two phones would actually be paged by the same
message.
But even then, who cares?
What's the impact?
You lose a little bit of extra battery power.
But above that, it doesn't really make a lot of difference.
And at this point, we're going to jump back to the back end
structure.
Yeah.
Let's take a look at the other side, the back end structure.
The ENOB and the component behind.
You remember the structure.
Here we have one or more ENOBs connected to each other and
the back end of the provider.
All these components are talking to each other by so
called control plane.
The control plane means the plane where all the management
traffic is going over.
Then the other part is the user plane.
All the user traffic is going over.
And this traffic both should be protected by IPsec.
All the security in 4G for transmission protection is based
on IPsec.
And we all need to know how good this is working.
But we will see.
Some quotes from the specification about end point
security.
All ENOBs, for example, shall be authenticated and
authorized.
So the attackers shall not be able to modify the ENOB
settings.
Sounds good, I would say.
Shall be authenticated and authorized.
But what does it mean?
We as attackers want to have access to the devices.
So, okay, there's an authentication.
So we need a better access.
How we get access?
For example, this is a common security structure of an ENOB
standing somewhere in the forest, I would say.
You see the security mechanisms there.
Just jump over, open the door, and you have access.
And you have access to an IP network.
So somewhere there, an Ethernet switch is standing.
And you can plug in and see the traffic.
Okay.
There was one point.
It's IPsec encrypted.
So let's take a look at both the certificates and the
certificate chain.
How is it going?
How an ENOB gets its public and private key pair?
Usually the key pair is created locally.
So on the ENOB itself.
So it's okay.
And it should never reach outside.
So it never leaves the platform.
Then it is signed by the public key is signed by the
factory certification of the vendor.
And this certificate, the factory certificate, is
sent to the customer in a secure way, whatever this means.
On this secure way, it comes to the customer, so the
operator, and the operator stores the key as a high level
certificate in its key store.
Yes.
For a hacker, for an attacker, what does it mean?
This means on this point, if he gets the certificate, he
has a certificate near to the root.
Sounds nice.
So but whatever, just a bit of discussion to them.
It doesn't really matter.
Why?
Because in the specifications, they were standing that IPsec
must be used, so it's required to implement IPsec, but only
in tunneling mode.
And transport mode is better, but it's set to optional.
So in most cases, there will be some security gateways in
front of the ENOBs, and if you get between the ENOB and the
security gateway, you have unencrypted traffic.
Okay, nice.
Some more notes about that.
Again, some notes out of the specification.
If the control plane or the user plane are trusted, and we
know the trusted environment here it is, there is no need to
use protection.
That's how it's standing in the specification.
Embedder is a note just on the down.
In case S1 and X2 user plane are trusted, e.g. physically
protected, protection is not needed.
So this is a physical protection.
Some more words about security for the endpoints.
It's a really, really complex environment.
So DHCP is used, there are a lot of certificates.
There are a lot of
security gateways, and there are a lot of
auto-connection mechanisms are implemented and
auto-configuration mechanisms.
So there are a lot of servers always communicating with the
ENOBs.
And this is very, very complex, and the complexity is there are
often implementation failures.
So feel free to try it or something.
So this is a very complex environment.
And it's a very complex environment.
So there are a lot of common IP network problems and
vulnerabilities.
Here, for example, we have done some scans, some
scans, and the upper picture shows that the host is down, and
the picture on the bottom shows a scan from inside of the
provider's network.
So you see that there is a difference if you are in the
network, and you are connected via UMTS or LTE.
In this case, LTE.
So on the bottom picture, you see here is a host of the
provider, so some servers inside of the network with which
you can communicate.
And then you have access to the target, and yes, we know it
now, some vulnerabilities.
There is some kind of vulnerability testing necessary,
and you can explore some vulnerability, for example.
But it's illegal, too.
Here, for an example, you see an ATP CLI.
This is a Huawei BTS system we found.
Yes, we're still net open.
Nice, I would say, in an LTE network, whatever.
Why ever?
There is a problem, I would say.
And why is it so?
APNs, if somebody has heard of APNs, so APNs stand for
access point names.
Access point names is the gateway you are using at.
And depending on the gateway you are using at, you have
another access list.
So the firewall reset is a different one, for example.
And APNs usually are well known.
So you get an APN from the provider you are putting into
your phone, into your configuration, and then you
have a gateway.
But there are always some more gateways.
For example, there are hidden emergency call gateways you
can use with an anonymous SIM or without a SIM, and you can
do some phone calls.
And some, they have often some debugging APNs, for example, or
something like that.
And these APNs have a different and mostly open access list.
And if you find the APN name, you are on another point in the
network.
Here, for example, is a tool from NW called APNBF.
You can download it in CodeCafé.
This is a bruteforcer for APN bruteforcing.
So you can bruteforce and try to find such systems.
OK.
To do something against it, there is a specification from
CVGPP, but it's from the year 2013.
So it's really, really new.
It's a bit of a shame that it comes up in 2013, and not
earlier.
But now it's there, so OK.
And this specification shows up and recommends security
assurance methodology.
For example, lifecycle management process, security
compliance testing, basic vulnerability testing, and
enhanced vulnerability analysis.
So they are on the right way, I would say.
But it's not really, it's the theory, and we will see how
it's in practice in the next years.
Back to the S1 interface.
The S1 interface is the main control interface between the
base station, so the E0B, and the management entities.
It's based on, and there a new protocol is developed called
S1AP.
S1AP stands for S1 application protocol.
Therefore, to deliver the content, the management
traffic, STP destination port 36412 is used.
But what can attackers do?
So if an attacker gets access to the E0B, he can try to speak
S1AP.
On this point, we developed some scripts we wanted to show
you.
With this script, it is possible to fake S1AP messages.
I hope you see the demo.
Here I have a STP listener running locally.
And I use it in a tool called Dizzy.
Dizzy is a protocol father.
But it's always possible to send single messages to spoof
messages.
I have Wireshark open to demonstrate it.
Now you see that I have sent an S1AP message.
This, for example, here you see it, has all the items
included we need.
It talks to the E0B from the MME that the E0B should be
released a specific radio access.
A call will be dropped or a user will be dropped from a
session.
Sending these messages can interrupt or disrupt the E0B in
its work.
On the other side, you can speak with the MME and do some
kind of stuff.
So we developed some scripts to test it, to play around with
it.
There are a lot of nice messages, for example, we wrote.
You can initiate some handovers if you like to.
So you say the E0B, hey, give me a session, a call of
somebody, and hand it over to some other E0Bs.
An E0B of an attacker, for example.
So there are really a lot of them.
The scripts, I will publish them after the con on our blog.
Who is interested in?
You can really do a lot of them on the premise that you
have an E0B or an MME, for example.
Furthermore, it's possible to do some kind of implementation
testing with this tool.
So now it's looking like this.
We are sending a lot of different S1 IP messages.
And, yeah, feel free to look how the E0B is reacting.
So that's it.
Feel free to look how the E0B is reacting.
Okay.
Back to the slides.
So what does it mean?
In this case, it means that you have to understand how
technology really works.
So the providers should do some kind of implementation
testing, find out how this stuff works and how they
develop it.
Otherwise, this may happen.
And I think that's not good.
Okay.
Now to the next aspect, self-organizing networks.
I've got to admit, that's actually the first thing that
I got in contact with when talking about LTE.
And I've got to say, I just love the principle.
There are two things about it.
You've got the self-configuration aspect, which
is big style plug and play, big style as in cell phone
network.
The why, yeah.
Cost.
Just think about it.
You've got some technician going out with a normal GSM
cell mast.
He's got to put up the mast.
He's got to put up the antenna.
He's got to attach the BTS.
He's got a blooming configurate somewhere out in the
field.
And he's got to put configuration data in, which
means you've got some high-skilled technician somewhere
out in the woods doing the same job every day.
And that's actually quite expensive.
So what do you want?
You want a little black box.
You attach an antenna.
You attach a LAN cable.
You connect power, and the whole thing is up and running.
Truly sounds great.
An E-NodeB itself is kind of pre-configured.
It comes from a factory we've already set with a
certificate on it or a set of certificates.
It's got DHCP activated.
Can you imagine that?
A cell base station having DHCP on the back end.
Just imagine if somebody really gets access to one
single LAN socket, you might really be able to take down
the whole network.
Then the E-NodeB has got a hardware ID.
Depending on this hardware ID, the back end will publish
some kind of configuration, and the E-NodeB will be
quite quickly up and running.
The only thing missing is GPS data.
If you've got a network, and I said so before, that
different E-NodeBs are able to communicate with each other,
every E-NodeB has to know where it is.
So either you connect some external device on the
beautiful management interface, configure the
positioning data, or you simply use internal GPS receivers.
Why does the E-NodeB have internal GPS receivers?
Timing.
GPS still is one of the easiest ways to get actual time codes.
And cell phone systems are time critical, so you need
current times, you use GPS.
Then you've got relay nodes.
Somewhere in the beginning I actually said that a
relay node would be a UE.
In theory, it can really be.
Now, the relay node itself is a selective repeater.
So it will only repeat signal coming from one certain
E-NodeB or from one certain cell.
The problem then just is, how do you actually configure
it somewhere out in the field?
You connect it using a SIM card.
It goes to the back end, says, hey, I'm a relay node.
What am I supposed to do here?
It then gets some configuration data, gets the data
of this single E-NodeB that it's supposed to repeat,
and it's going to work like that.
So in the same mobile phone network that your phone is in,
there's configuration data configuring other cell phone
or cell network aspects.
Then you've got the wonderful self-optimization process.
Now, optimization is very important,
as everybody probably knows.
So self-optimization in wireless networks.
What do you want to do?
You want to avoid overlap.
It doesn't make any sense to have some area covered
twice or three times.
So what you do, you let the single cells communicate
with each other.
So two E-NodeBs will be able to talk and to share
both time and frequency domains in between them
and really reduce the signal strength.
Now, one quite funny aspect is how does an E-NodeB
see another one?
Well, by asking some user equipment,
hey, do you see any other networks?
And the cell phone says, yeah, hey,
there's another E-NodeB here.
And go on, kind of faking a few messages
and putting two E-NodeBs a little bit closer together
isn't really very or shouldn't be very difficult.
Then you've got the home E-NodeBs,
the connections that you've actually got
in your house at home.
Come on, you hack them.
They're able to speak the same protocols
as the proper E-NodeBs.
They come in over a different security gateway,
but you know how good gateways are.
Maybe having your own home E-NodeB at home
might enable you to take down a little LTE network.
Okay, on this point, having some fun.
X2, for example, is the interface for connecting
such devices to each other.
We developed some scripts for spoofing
and implementation testing for X2 AP
similar to S1 AP.
So they will be also published on our blog
in the future.
And yeah, it's working with management interfaces
equivalent.
Yeah, then we've got the simple question,
as I said, the attack procedures.
Faking the position of some E-NodeB,
trying to take down a whole network.
Future research.
Problem is we've got access to theoretical data,
but actually try to find some cell network operator
that allows you to have a look in their network.
So, yeah, that's the problem.
So, yeah, that's the problem.
So, yeah, that's the problem.
But actually, it allows you to have a look in their network.
It's quite hard to find.
And then we've got the very simple question,
LTE, will Darwin strike again?
So, overall, we would say it's a good concept.
So there was a like thought,
and there are good thoughts behind,
but there is really a high complexity.
And it's, for all the engineers who developed UMTS and GSM,
it's a really high complexity and a new technology.
Now it's IP network.
So we all are asked to take a look at.
And we've seen there are some things
which are a bit shocking,
like this self-optimization and self-organizing networks,
all the auto-configuration features, et cetera,
and the security may be some bit more optimized, I would say.
But we also can see they have learned.
So they go into the right direction.
They see the transmission of important traffic must be encrypted.
They have inserted tokens for better authentication and so on.
Coming back to our message.
Quite simply said, Darwin awards,
there are stupid things that if they've been done once,
they shouldn't be done again.
Why do you need optional encryption on critical devices?
Come on, you know if something is optional,
there will be a stupid guy not switching it on.
And as I said, we haven't had access to real cell phone networks yet, hopefully.
But you've got stacks of corporate experience.
Who really uses optional encryption?
Why make it possible to switch it off?
And self-optimization, organization, it's a very good idea,
but there is probably really a little bit more work and research
that has to be put into it.
So for this point, Darwin won't win.
LTE will survive, but I guess it might be able to change in future.
Thank you.
Applause
So we'd be done at this point.
Are there any questions that you've got to ask now?
Otherwise we'd be available after the talk.
Perfect.
Then have a great evening, enjoy the party,
and I think you've got to leave the room quite quickly
because all this stuff has to be got out of here.
Cheers.
Applause
That's right, he's in a boat.
Laughter