- Hello, this is Reza Soosahabi.
And with my colleague, Chuck McAuley,
we would like to present
our novel covert communication scheme
that exploits broadcast signals in LTE, 5G,
and other technologies.
I would like first,
give a little introduction about ourselves.
The application research team lead
at Keysight ATI Research Center.
I do open research on 5G RAN security
and develop algorithms to both make or break awesome things.
I come from math and signal processing background.
So I try to apply them to new problems
as much as I can.
And typically, I happen to be at the right time
and in the right place.
So I have been breaking things
and triggering rare events for fun.
When I become a dad,
and now I love spending time with my toddler son.
So I would like to turn to my colleague, Chuck.
Hi, I'm Chuck McAuley.
I'm a principal security researcher
at the ATI Research Center at Keysight.
My hobbies include skiing and breaking my Land Rover
and fixing it pretty frequently.
At Keysight, I'm involved in new product initiatives
and bring a long 20-year cybersecurity background
to everything Keysight works on and touches.
- I really would like to expand
on the ambitions and the thoughts behind this research
to encourage future research.
I believe this is as important
as the research I'm presenting here.
As my father always put it,
talking about fishing is more important
than talking about fish itself.
So I had some past academic research experience
in wireless security.
I published my work on IoT security in IEEE in the past.
So most of my work was deep in theories and math.
So I decided joining industry
to explore more practical problems out there.
And I was offering R&D consulting services
to mobile operators and was a 5G system engineer a while
before joining Keysight in 2018.
Without being officially in InfoSec,
I always had the tendency to break things around
for fun and curiosity.
So my new job at ATI enabled me to explore new ideas
lesser known in wireless community,
most notably protocol tunneling techniques
that are used for data exfiltration.
I was converging kind of my past and present experiences,
that one day in Fall 2019,
our cool boss invited me to take a lead
in a 5G security research project
and got me a lab with a super expensive
basement emulator in there.
So with that level of trust that he vested in me,
I decided to go after a 0-day vulnerability discovery
other than simulating existing ones.
So I discovered this vulnerability in 5G and LTE standards
the following winter,
and we successfully disclosed it with GSMA.
Things kind of went slow
due to pandemic and my parenting leave,
but after watching this interesting talk
in last year DEFCON
on eavesdropping satellite signals,
I got really excited and pumped
to put this work together
and present it for DEFCON this year.
I took a holistic approach of organizing
the existing work in the biggest possible picture,
or a call it a box,
and then discovered a hole in it.
So I realized that covert communication
is the biggest umbrella that I can put all techniques
for data exfiltration, command and control,
and other means of communications,
unauthorized communications,
all together in it.
So it's usually regarded as a potential threat
and taken seriously in the context of defense in depth.
When I serve a literature related to covert communication
or topics related to it,
I realize there are two dominant viewpoints
that are coming either from hackers or wireless engineers.
So people with hacker mentality, like Chuck,
(chuckles) have targeted software protocol stack,
most of the time.
So like message tunneling in L3-7 protocol,
such as ICMP, DNS, and et cetera.
A lot of cool techniques there.
They have barely looked below IP layer, in fact.
As we know it,
the security industry has actively been monitoring
the research in this area.
So they track and block malicious IP traffic
using boxes, like IPSs, IDSs, and lawful intercept.
On the other hand,
wireless engineers, such as myself,
are really fascinated with the beauty of radio systems,
internals, and physical layer.
So there is a huge literature
on coding and modulation techniques
to build optimal radios for covert communication.
These techniques usually involve low-power communication
and avoiding spectrum monitoring systems.
So devices such as like LoRaWAN, ham radios,
and other low-power technologies can be kind of retrofitted
and used for covert communication,
but their operational range dramatically degrades
when both sender and the receivers are at low altitudes,
where the signal, in fact,
is blocked by buildings and foliage.
Looking at the protocol stack,
I thought of a new viewpoint,
come up with a new viewpoint
that combines both mentalities.
So I come up with this question,
how about exploiting the MAC layer protocol weakness
in existing wireless infrastructure?
This was the big question that inspired this work.
It leads us to a new scheme that can be more effective
than existing ones in many aspects.
At this point,
I was almost certain that I can find
some simple example quickly in LTE and 5G standards
because I was very familiar with them.
So very related to the theme of DEFCON 29,
I developed a framework to exploit the unstoppable signals
from cellular base stations that are everywhere.
So height is what makes the RF signals unstoppable.
And operators spend big money
to mount antennas on tall com towers,
or recently, some companies are trying
to fly them on low-orbiting satellites.
And this is all about getting more and more coverage
to as many users as possible.
So let's look at this scenario
that we're gonna be using moving forward.
So Trudy has intruded a secure air-gapped building
with a program or device.
So she would like to send a message to her friend, Ricky,
with a passive sniffing device
sitting somewhere a few miles away,
like these anime geeks that we have
down below this frame.
The picture.
There is no radio signal path between them
due to buildings and foliage.
So however, both can send and receive signal
from a nearby cellular tower.
So what if Trudy send a special,
low-power (indistinct) signal that triggers
high-power broadcast signals from the tower
that then are received and decoded by Ricky?
So simple, right?
So this will create a mutual
covert communication channel between Trudy and Ricky.
And this is basically the description of the technique
that we are going to present here.
Putting it simple and memorable for you,
we are creating, in fact,
a reflection that are observable everywhere
around the cellular tower.
That's the key idea.
So think of a Batman movie.
They did not know where Batman is, right?
So they were reflecting this light beam off the sky
to make it visible everywhere,
so that he can see it.
So I would like to go and start talking about
the example that I've discovered in LTE and 5G standard.
So let's take a look at the protocol stack.
What is a MAC layer?
What does that mean, exploiting MAC layer?
So in protocol stacks,
some initialization or handshake steps
always happen within each layer
before it starts responding to data from the upper layers.
This is how protocol stack crank up,
always from bottom to the top.
So this work is related to the Layer 2 in OSI model,
often called the MAC layer.
And from operating system perspective,
this layer is whatever layer that enables devices
to send IP packets.
So they don't care what's happens in it.
They just look at it as an interface
or gateway to send IP packets.
In order to understand what we are talking about today,
it helps to understand the analogous version
of what happens when you connect
a ethernet cable to a switch.
Right when you plug in your cable,
before you get a green light on your switch,
indicating your link speed and duplexing,
a protocol negotiation has already taken place.
The radio signals have synced up
and found a signal in both directions.
So there are some messages,
such as like a rate, auto-negotiation,
that happened very early
that people normally do not care about them
or observing them in their packet captures.
So let's now talk about the LTE and 5G Big MAC layers.
something more delicious, right?
So this hairy-armed man
is searching for signal in the middle of nowhere.
So when he finally gets a signal,
before he's allowed to send a selfie to Instagram
about his situation,
it tries to attach to a cell tower, right?
And see if it allows to access it.
That mostly involves SIM card voodoo stuff.
The apps running on his phone
only care about sending IP packets to the internet, right?
So the apps do not care about whether it is WiFi or LTE
or what happens inside these protocols neither.
So they see all this voodoo stuff
happening below IP layer as a big MAC layer.
That's why they call it the Big MAC.
They do not care what's in it.
They just enjoy using it or what it delivers.
The commercial wireless infrastructure has many components,
such as cell towers and a bunch of coordinate work servers
whose job is managing millions of users across a wide area.
This Big MAC layer that we're talking about,
in cellular standards, has similar sublayer protocols in it,
like a Big MAC, right?
They define the interaction of user device
with various components of the operator's network,
but not the internet.
So this Big MAC is called control plane as well
Or sometimes, the people who built this network,
they call them Layer 2 and 3.
In the context of LTE and 5G, in particular,
related to our talk today,
these standards are made by a global organization
called 3GPP, for your information.
It uses a protocol known as the RRC,
or Radio Resource Control,
which is an access protocol
that is the toppest layer of this Big MAC,
or we can call it the bun layer (chuckles),
that works more like a RADIUS,
or messages in it, looks more like SNMP.
But this is not what this talk about today.
This talk today about is
the link establishment for RRC protocol,
the very initial MAC layer handshake
that happens very early on
before establishing an RRC connection.
This is what this call is about.
Think of it like a handshake
between a phone and a cell tower
before all other handshakes.
And it has some interesting features to it
that we are going to explore.
And in fact,
it does not travel to the operator's core network,
making it suitable for covert communication.
Some simple terminology notes in here.
So essentially, in the context of LTE and 5G,
we call all the devices that interact with the cell towers
UE, or user equipment,
whether it has a SIM card or doesn't have a SIM card.
Doesn't matter.
And there is another more important terminology note
that I'm going to talk about here,
is that the story of a NodeB.
So in LTE,
they call these cell towers or base stations eNobeB.
In 5G, they start calling them gNodeB.
And actually, when I was talking about 5G with Chuck,
Chuck said that, "What happened with the fNodeB?"
And I said, "Interesting. Nobody uses fNodeB."
So I decided to use fNodeB here
throughout the following presentation
to refer to both LTE and 5G.
So random access procedure is a common functionality
in wireless MAC layers.
So there is a small set of signals, called RACH,
that are reserved for the UEs
connecting to an fNodeB for the first time.
See? fNodeB.
All the fNodeBs respond to the signals
regardless of device type or identity,
even if it doesn't have a SIM card.
The diagram here shows the normal RRC connection procedure.
There are four Plain Text messages
exchanged between the UE and the fNodeB
before the UE creates an authenticated session
with the core network.
These messages serve similar purpose
to the ethernet auto-negotiation handshake,
which is setting up synchronization.
First, UE randomly sends a scrambled signal
from the RACH set,
and then fNodeB responds with more (indistinct) parameters
that helps the UE to fine-tune it's framing synchronization.
But these are not the important ones.
The important ones are the Message3 and 4.
They enable the fNodeB to resolve resource contentions
between UEs that are simultaneously attempting RACH.
Per standard,
the UE should send a 48-bit string
that contains a 40-bit random ID in it,
then wait for the fNodeB to broadcast Message4.
This string is called CRI,
or Contention Resolution Identity.
If the fNodeB replies with the same string in Message4,
it means that the UE can proceed with the RRC connection.
Otherwise, it knows that someone else
is supposed to go ahead
and this one has to stay and retry later.
I think probably by now you've guessed
what's wrong with this broadcast ping-pong
within Message3 and Message4.
So coming to the Trudy and Ricky's
covert communication scenario,
Trudy and Ricky can have prior agreement under target fNodeB
and Trudy's RACH signal selection.
Then Ricky is passively scanning
and decoding Message2 and 4 from the fNodeB
using it's low-power radio.
Instead of including random 40-bit identity in CRI,
Trudy can encode a short message in it
and sending it up in Message3.
This message can include a signature byte,
indicating it is made by her,
not by other users in this cell.
Then Ricky can pick up and decode the same message
from the fNodeB's message for broadcast
that happens immediately after.
Simple, right?
This is a kind of like an illustration
for a unidirectional channel,
but essentially, Ricky can repeat the same procedure
to establish a reverse link to Trudy
to kind of send information, like acknowledgement.
Looking at the history of this procedure,
we believe that this vulnerability may exist
in other wireless MAC layers as well.
This particular example has been in LTE and 5G
for over a decade.
But no worries.
I will share the remediation before this talk ends.
So exploiting, a little bit expanding on how,
what they can gain by using SPARROW.
A SPARROW UE can break long messages
into chunks of 40-bit messages
and send them in multiple RACH attempts.
Successive RACH attempts do not have much impact
on other users in the cell.
And there is a backoff also timer
that's built into the standard document,
as you can see the snapshot right below,
that the UEs have to basically pick up a random value
as a backoff timer.
But it's all been left to the user discretion,
and the eNodeBs or fNodeBs
do not have any way to enforce it.
So picking a backoff time, like 10 milliseconds,
usually the Message1 to 4 exchange
takes on average of like 30 milliseconds.
So in total,
this can give Trudy a one kilobit-ps throughput link
to reach messages to Ricky.
Very limited, but it's still comparable
to other low-power technologies, like LoRa.
Outdoor LTE and 5G base stations
operating at lower frequency bands,
particularly below two GHz are more suitable
for a SPARROW technique,
mainly because their signal can reach up to five miles
and also they can reach indoors very well.
5G New Radio,
and you'll reduce some new frequency bands
above six gigahertz.
That they involve lots of RF voodoo stuff,
like beamforming,
that making it difficult for Ricky
and his fellows down below
to decode and broadcast his signals.
There is also a new satellite-based 5G standard,
called 5G-NTN, which is in development.
That might actually give the SPARROW UEs
10 times more mileage.
Hopefully, we can get our remediation
built as a secure RACH option for that standard.
Also, benefits of using the SPARROW are really great.
So you can get really super stealthy with it.
No network footprint
because messages are local to the fNodeB,
and nobody is going to log the MAC layer messages
at the edge of their network.
Also, the SPARROW UE activity
is indistinguishable from the other UEs.
So no radio spectrum footprint that's going to be there
for external passive monitoring systems
to geolocate the transmitter.
These are the reason I call them SPARROWS.
So no need for expensive equipment, right?
So hundred bucks low-power SDRs can do the job.
They can also live off
rechargeable batteries or solar power.
No need for high-gain antennas
since they get their rebroadcast power
from the fNodeBs, right?
I will also show some more range expansion techniques
further in the presentation.
So they can get higher range per RF wattage
in a cluttered environment.
And that's a very key point,
compared to the other complex commercial radios,
like walkie-talkie or LoRa.
Who cares about the SPARROWs?
I mean, really, there are...
Sparrow birds are everywhere. They're among us, right?
Nobody cares about them.
I know, historically,
sometimes they cared about them for crops,
but nobody cares about them.
And this is the same with the SPARROW
with regards to cellular operators
because they do not see any immediate impact
on their networks, so they do not care about it.
And as a matter of fact,
any temporary solution to block the SPARROWs
kind of lead to some performance degradation to real users.
And we will talk about that.
But the remediations that we have developed
has to go be implemented at the standard level.
So so far, SPARROWs are unstoppable.
(keyboard clicking)
So here, I'm going to actually
turn the presentation to my colleague, Chuck,
to talk about our demo, and show the demo,
and also talk more about the use cases for SPARROW.
Chuck?
- Thank you, Reza.
So one of the benefits of working
at an organization like Keysight
is we get to play with a lot of cool tools.
Even though we were in the middle of a pandemic,
we were able to work with a lot of our peers
in different parts of the world.
And we were able to convince the GSMA
that we'd actually found a design flaw
in the RACH contention messaging structure.
So what you see here is our demo lab
that got set up for us by our peers in Italy.
At the bottom, you see something that we call a UXM.
Now this device allows us to emulate a eNodeB, a gNodeB,
and hopefully, in the future, even an fNodeB.
And what you can do with this device
is emulate a cell phone tower effectively.
And at the top,
(clears throat) you see what we call UE SIM,
which simulates whatever's gonna connect to a mobile network
and allows you to play with the messaging structure
and validate a fNodeB or a gNodeB or a eNodeB, right?
But what you can do
is if you take both of these two test validation systems,
you can put 'em together and build, effectively,
a cell network in isolation and test out some theories.
In the lower right-hand corner,
you can see sort of a screenshot here
of our test script that enables our UXM
to pretend to be a eNodeB
doing the rash contention messages.
And in our next slide,
well, not really a slide.
In the next video that's coming up right here,
we're gonna introduce our friend, Befekadu.
Befekadu works out of Italy,
and he has put together a quick video
demonstrating SPARROW working for us
that we then presented to the GSMA.
- My name is Befekadu Mengesha.
I'm an application engineer at Keysight Technologies.
In this video,
I am going to demonstrate the proof of concept
for the SPARROW Project.
With this (indistinct) graphical user interface,
we've configured a UE on a LSU,
and that's with an IP address of 10.40.88.70 as a TX.
Therefore, we set the mode as a TX
and the random access parameter to eight.
And the Plain Text message
to be sniffed by the receiver UE
is set to, "Welcome to the DEF CON!"
Similarly,
we have set the UE-B on LSU-B
with an IP address of 10.14.88.157 as an RX.
Therefore, we set the mode to RX
and the random access parameter ID to eight.
On the current (indistinct) side the fare,
the PRT script activated the 5G in a standard load cell
with the synchronization signal block
is broadcasted via the XM platform
with a periodicity of 20 millisecond.
If the master information blocks
is decoded with success on both UE,
two of the cells will get sync.
And in service,
if the System Information Block Type 1 is decoded.
Since both UE are in service,
it's in sync and idle,
we can connect the GUI to the Layer 3 test manager
and verify if the SIM is decoded.
Then the cell should get in service.
We can run the scenario from the RX side first now
and from the TX side.
It seems that the transmitted message
is with success from the TX side.
And let's verify if the receiver UE side
decoded the message successfully.
So from the scenario logger,
here we have decoded the message,
"Welcome to the DEF Conference!"
From the TX side,
it can be verified that the Message2
is decoded with the valid RAR.
Also, on the RX side, we can check.
The Message2 is decoded with the valid RAR
as a TX UE.
If this is the case,
we can also verify the Message3 is decoded
with success first from the TX side.
So here, we can confirm
that the UE contention resolution IDs
decoded with success on the TX side.
And let's see also on the RX side.
So the RX side Message3 is also decoded with success.
So since we have implemented a CRC decoding,
if the method is decoded,
we can see the message on the RX side,
So if you can see, the message is decoded successfully,
"Welcome to the DEF CON!"
- So there you saw Befe showing us
how you can bounce a message between two UEs
across a cell phone tower,
which is pretty wild.
So let's talk about what you could do
with this sort of technique.
A lot of the applications are pretty obvious
from the get-go,
but one that we thought was pretty neat to highlight
would be the ability to exfiltrate data
out of a secure site.
There are cell phone towers
that are doing these RACH procedures all the time.
So it'd be very hard for you to notice
an additional RACH procedure occurring with a cell site
from a specific UE at a specific location.
When you start thinking about the application layer
and digging into data in there,
you can either have a service provider
or a government entity intercept that communication layer
and prevent it in multiple different paths.
But at this low layer on the MAC layer,
this is happening before any of those things occur.
You could also this to easily trigger events remotely,
like opening a door or, more drastically,
triggering a bomb to occur.
(clears throat) And you can be well within,
say, five to 10 miles away from the site
in the event that you're triggering, right?
So that's a long distance to cover
and figure out the source of the message.
And lastly,
this could also be part of a supply chain attack,
where you actually bake in some kind of
remote control process into the device
and then access it at a later date, right?
Which is also a big risk these days
with our vast and multiple-country supply chains that occur.
But there's also good applications for this
that are used for good.
If a tower loses its uplink to the rest of the data network,
it still can provide some use.
Whereas before,
it might've been just a thing that just sits there
and waits until the connectivity's re-established.
So this could be used for broadcast messages
in case of disaster or emergency.
It could also be used to connect
emergency personnel themselves to each other
and tell 'em where help is needed
or what needs to be done,
which we think is a really neat application of this,
in general.
And then lastly,
we think that there's a lot of opportunities
for mischief here.
Instead of using LoRaWAN
or other IoT-based, low-bitrate protocols,
you could use someone else's cell phone tower
to provide the overlay network for your IoT devices,
and then simply have one device
that picks up all the signals
and transmits them on an internet uplink somewhere.
You could also use this to help improve a pager network.
This device here, this doesn't use it.
This uses LoRaWAN right now.
But it's made by Natural (indistinct),
and he uses it to pass messages back between
different devices at Shmoo and DEFCON.
You could easily hijack a cell phone tower,
and then instead of having a mile or two of distance
or a giant ugly antenna,
you could just be passing messages
with something a lot smaller and a lot neater.
And now I'm gonna bounce it back over to Reza,
who's gonna talk about increasing the signal boost
and some remediation.
- So in the case of LTE and 5G,
the SPARROW UEs can exploit kind of like multiple fNodeBs,
except the very rural areas.
It is common for a SPARROW to have access
to multiple LTE or 5G carrier signals
in any area within range of a few miles apart
when the UEs use are not that much far from each other.
So this can help them to essentially establish
parallel communication channels
and enhance their throughput above like one kbps
that we estimated.
Another cooler way actually for us to use multiple cells
is really to expand the range
beyond a single cell radius coverage,
like beyond five miles.
So for doing that,
in fact, the SPARROW, you will need to use SPARROW relays.
So SPARROW relays are dropped
basically where they can listen and transmit
and interact with multiple cell towers.
And their job is being Ricky in one cell
and being acting like Trudy in the other cell,
as you can see here.
So SPARROW relays can be small,
kind of like solar-powered devices
that are dropped on random places.
So to be more specific,
LTE cells are deployed in kind of like a hexagonal pattern
to cover an area.
So this picture that I'm going to show in the next slide
is going to show how the relay nodes can be placed.
As you can see in here,
so you have multiple ways in here to place them.
So you can actually place many of them
in where the actual sector coverage areas overlap
and create a mesh network,
so every node can talk to every other node
and relay messages.
Or you can actually create a specific chain
to expand the range between two endpoints.
But what is the remediation here?
I mean, with all what we said here,
what is the remediation?
So let's start before I get to the remediation,
I think there is a value to learn
in case what is the general weakness modeled
that has enabled the SPARROW in LTE and 5G.
And potentially it can exist in other protocols.
So I kind of spent some time and have formulated this,
and possibly I'm going to be publishing all this work
following the DEFCON.
But to kind of give you a general idea about it,
a wireless MAC layer protocol I found
is vulnerable to SPARROW technique.
If any of these procedures
allow forming two sets of uplink messages, that I call M,
and a downlink broadcast message, I call them B,
that satisfy the following conditions:
So the first one is a passive reception.
So every signal in B
should be receivable and decodable everywhere.
So it should be kind of like an omnidirectional broadcast
that any passive device anonymously can decode it.
Another key feature is, basically, we call it bijectivity,
but it's a one-to-one relation between them.
So essentially, if you have a set of 10 messages
in each of them,
each message B can only be triggered
by a specific message that is in the set M.
In other words, when a receiver receives B,
it can almost surely assume that
its intended transmitter has transmitted a specific message.
So that way they can have less error
during their communication channel.
Another one, which is a key important thing,
but it's kind of like optional,
but it is a good, important thing to have,
and we have it right now in the example
that I showed you in the SPARROW,
is that anonymous uplink.
So essentially, the transmitting device
doesn't have to attach to the network
or authenticate to the network
to be able to send those messages,
which actually we already constructed a message said,
which is actually the CRI
and that 40-bit string that they can pick
are going to form or superset
for set of messages that they can transmit.
Another key feature down here,
number four, is being stateless uplink.
It is important that the transmitter, or Trudy,
can successively send any messages from M, set M,
without protocol violation,
as we talked about is sending successive messages
and not caring much about the backoff in between them.
So all these four conditions together
if they apply in any specific wireless MAC protocol,
that means that some similar techniques to the SPARROW
can be formed around it for covert communication.
Any remediation should preserve the purpose of CRI.
So why we have this here?
Why we have that selective Message3 and Message4 ping-pong?
So as you can see, it's for contention resolution.
So there's more details about that.
So let's assume that two UEs are picking up
the same RACH signals to attempt with eNodeB.
So essentially, at this point,
eNodeB doesn't know there are two messages coming
because of the properties of the RACH signal.
Only one of them is going to make it to the eNodeB.
So eNodeB is going to send additional,
basically, fine-tuning parameters for one of them.
But the point is the Message2,
both of them are going to receive Message2.
So at this point,
both of them think that they are succeeding.
So that's the point that fNodeB actually has to have a way
to signal only one UE to proceed
and the rest of them to back off.
And that's the point that it requests every UE
to send 48-bit CRI message.
And then, it's just going to rebroadcast
the one that it has received.
That is going to surely indicate that one UE
is going to know it can succeed
and the rest of the UEs are going to basically
back off and retry.
So before getting to the solution that works...
I know maybe some of you already are thinking about
some solution ideas.
So let's talk about them
and talk about why they do not work.
So what about like presetting CRI, phone?
Why the phones have to randomly select them?
What if we hard-code all the phones
to make it like a MAC address,
so they have to use the same thing?
There are actually some privacy concerns with that.
There are already attacks in LTE and 5G on privacy,
and we have lots of techniques for catching people,
phone numbers and (indistinct).
So any tying up any fixed identity
that can be broadcasted everywhere,
that can lead to privacy issues for the users.
So this is not like a WiFi, which is a local network.
It is a global network.
Another one is shared secret.
No, there is no shared secret
between the UE and fNodeB at this point
because all the cell towers are required
to do these interaction with devices,
even if they don't have any identity or SIM card.
So what about like a crypto hashing and salting, right?
That's a to-go thing.
Crypto, the funnest stuff.
That in fact, doesn't work because first of all,
if you think about Message3 and Message4 broadcast,
if the fNodeB tries to basically hash
what it puts in into Message4
so that the designated UE can just check the hash
or recompute the hash and compare and proceed,
and the rest of them, they are going to back off,
it has to basically,
even if it just starts like using like a salting technique
down here with hash, the most sophisticated way to do it,
even if it is using salting,
it has to ship the salt string with the hash all together.
But does it really prevent Ricky and Trudy
from exchanging messages?
Not, not that much.
It just adds a little bit computational complexity
to the mix,
but in fact, the Ricky can still recompute
because it's going to have the hashing algorithm.
It's going to have the salt.
And it's going to be able to compute
these values for any set of known code book messages
that they decide to use,
and they can just stick to that code book.
So it can slightly slow them down,
but it's not going to solve the bigger problem.
Also, the fNodeB cannot distinguish
between the Trudy and the other users.
So any attempt to blocking some of the signals
if they repeat successively,
it is going to have a performance impact.
So the actual users have to pay the cost.
And as I've mentioned before,
the operators are reluctant to take such necessary steps.
So what is the real solution?
This is the solution I put together
to be proposed to the standards.
So the remediation has to come to the standard level,
which actually might have applications in other fields.
I call it Extensible Loss-Induced Security Hashing Algo,
like that.
What it does is just adding one layer of entropy
over that solving and hashing that we were talking about.
So the first few steps are very similar.
So we do some salting.
So once the fNodeB receives a Message3,
it's going to apply salting
and apply the crypto hash.
Right there, I kind of come up with a new salting algorithm
called Random Multiplicative Salting.
It's a kind of new algorithm that helps
reduce the collision probability
when you're using crypto hash functions
with shorter strings, like CRI.
And then after that,
it starts applying some random erasure
to the output of the hash function.
So it decides to not transmit all the bits
that come from the hash digest,
but randomly select a bunch of them
and send them out in Message4,
so that the intended UE can, you know,
essentially, has to have all the information
to repeat the same process and compare the output,
and if it matches, it can proceed.
If it doesn't match, it has to back off.
So that means that the salt, in addition to the salt,
we have to also ship basically a bit string
that indicates that which bits we have selected
and which bits we have not selected
from the output of the crypto hash
all together to the UE.
So that's what I call it, bit mask.
As you can see, in this case,
there are two advantages to this
that makes it impossible for Trudy and Ricky to communicate.
First of all, they cannot (vocalizes)...
They were reconstructing like a rainbow tables
and recomputing the hash for the code book.
But the point is that layer of the erasure
that we put in between,
they cannot create a code book
that both can be recomputed by a hashing algorithm
and at the same time,
have error-correcting features and capabilities in it.
So that kind of enabling those erasures and errors
in there, in their communication,
is going to totally reduce their chance
to correct those errors.
So that way, their whole communication scheme
is going to fall apart.
Another key point in here to mention
is about the cost, right?
I mean, always there is no free lunch out there.
So that's the whole point in engineering,
is that whenever we're trying to improve things,
we have to pay the cost.
But is it the cost we are paying is the right cost?
In this case, as you can see,
significantly increase the number of the bits
we are replying in the Message4
instead of replying by 48 bits.
So an example of like a MD5 hash,
instead of playing back 48 bits,
we might be playing back about like a 200 bits.
But that's not the problem with LTE and 5G.
And the amount of the bandwidth and resources
that are available for this,
this is not going to be a big cost to pay,
barely, for preventing this.
So as a matter of fact,
what we are proposing here is going to be
more of a optional, secure RACH.
So it doesn't have to be implemented
everywhere across the network,
but maybe the operators want to implement this
near some critical facilities and areas
where they are requested to do so.
So I would like to kind of
get to the wrap-up points in here.
So I'm going to turn quick to Chuck
to share his concluding bits about the story.
And he's been all along observing me, working through this.
So I would like to also share him
to share his feedback with you.
Chuck? - Thank you, Reza.
When Reza came to me and he talked about,
"I think I figured something out in the MAC layer,
"and we can smuggle messages in and out
"of a cell phone network,"
I was like, no, there's no way.
MAC layers are boring.
The best way you can do with anything like that
is get from Port 1 to Port 2 on a switch.
But just because it's Layer 2
doesn't mean that it's localized.
And I think that's something that I really sort of
took away from all of this.
We also really don't think that LTE and 5G
are the only systems that are vulnerable
to these types of attacks.
If you just start digging around some
of the MAC layer protocols that are used by satellites,
there seem to be about 10 to 20 of them,
and that would give you a lot for a lot farther reach
than anything that's terrestrial-based.
And there's a whole host of other radio broadcast signals
out there as well,
from 802.11 to Bluetooth to LoRaWAN
to other things that can probably be abused
in similar fashions.
Also, just to note,
LTE and 5G is now for everyone.
With a budget of about the same as a gaming computer,
you can buy enough equipment now
to build your own LTE network.
and even the FCC's granted spectrum
for you to go and play around with it
in your own sort of private space,
which is pretty wild.
So yeah, we'd like to also say thank you
to many people in our team,
including Befe and Luca.
And Reza would like to say thank you to a few others too.
- Yes. Thanks, Chuck.
I think I'm going to thank Chuck
for all the work and his support that he offered me
during the (indistinct) process
and putting all this talk together.
Also, the ATI management staff,
Chris, Steve McGregory,
the cool boss I mentioned early on
who kind of like inspired me
to go to this 0-day discovery.
And also I would like to thank
our Keysight IP Program Coordinator, Pete Marsico,
that he did a great job
of sticking to a very fast timeline
so that I can share the remediation bits
here with you, team.
And in general, I really thank DEFCON.
It's been a really great experience for me.
I really love to continue being engaged in the community.
Thank you.