Let me introduce Matt Blaze. He told us he's a professor at UPenn where he does various kinds of hackery.
And I have to say, one of the very few times I'm ever going to say this,
if there's an academic paper with this man's name on it and you like what he's talking about,
you probably want to read it, especially all this fun B-25 stuff, but quite a bit of other things.
It's very interesting. And just the silly things this man does to get himself in trouble
but somehow gets out of trouble, I really can't speak too highly of his work.
So today we'll be talking about SIGINT for the rest of us. So thank you very much, Matt.
Okay, so thanks. Hope you can hear me. Hi, morning. Congratulations for making it up before the crack of noon,
which is an accomplishment, at least for me.
So I'm going to talk a little bit about some work I did in my lab
with a bunch of people.
I've got a bunch of incredibly talented other people, including Sandy Clark, Mouse,
who I think everybody either knows or should know, and she's around somewhere,
and Travis Goodspeed, a hacker of ill repute who is also around,
as well as Perry Metzger, Zach Wasserman, and Kevin Zhu,
who are undergraduates in my lab.
So I got this grant from the...
from the National Science Foundation.
There's nobody from the National Science Foundation here, right?
Okay. So they gave us this pile of money to look at security in open telecommunications networks.
And basically that kind of meant, I think they thought that that meant, cell phone networks.
And I thought, okay, that's kind of interesting to look at.
But we decided to start out by looking at other kinds of wireless networks.
Wireless communications networks.
And I just decided to, you know, kind of on a lark,
to look at the security standards used by public safety two-way radios.
In particular, the P25 standard.
And so, you know, that was kind of an excuse to buy lots of RF equipment
and start playing with it in the lab and putting antennas up
and doing all sorts of fun stuff that, you know, you kind of...
Otherwise, you don't normally get to call research.
And, you know, as soon as I put in a receiver,
we turned it on and noticed that we could demodulate a digital signal
and there's this, like, surveillance operation going on literally, like, two blocks away.
And they're reading off license plates and describing people.
And I could look out the window and see them.
I could see the people they were describing.
And this was, like, literally in the first 45 minutes
after unpacking this fancy pants piece of RF intercept gear that we had picked up.
And I thought, hmm, that's interesting.
I'll bet they think that this is secure.
And so what is this?
So there's a system called APCO Project 25,
which is the successor
to something called APCO Project 16.
So I'm not sure why...
what happened to nine of them in there along the way.
This is the current standard
for digital two-way radio
for public safety and federal users.
And so there are two kind of dominant standards
for digital land mobile radio.
One of them is DMR.
A lot of hams like DMR.
An incompatible but remarkably similar standard
is called APCO Project 25.
It started a little bit earlier.
The standards started in the early 1990s.
And the intention
was to be a drop-in replacement for analog FM radio,
which means narrowband channels,
12.5 kilohertz channel spacing,
and some modulation technique
that would fit into the same size channel
as an existing narrowband FM,
but also allow it to be digital,
allow a messaging service,
but the primary application
being the same kind of two-way voice.
Okay, so this is, first of all,
an interesting limitation right from the beginning,
because if you were designing
a digital communication system completely from scratch,
and you just had all the spectrum in the world
that you might want,
you would probably prefer
a spread-spectrum style option,
which has all sorts of properties
that are, in a lot of ways,
much more favorable
than individual channelized spectrum use.
But this is, you know, starting out
with a kind of legacy problem.
But this is the state of the art.
Now, they added, later on,
cryptographic security options
to the P25.
So this was, you know,
not exactly an afterthought,
but it wasn't part of the initial standard.
So they kind of figured out the bearer channels
and all of the basic signaling
and the modulation and the vocoder,
and then they said,
we should definitely get a working group
to come up with crypto standards for this.
So throughout the 1990s,
they were kind of grafting on
more and more crypto standards,
and then 2000,
kind of the first encrypted versions
of P25 equipment.
Started to become commercially available
on a wide scale
and deployed on a wide scale.
And the encryption standards,
the security standards group,
working on P25,
continues its work today.
So this was not something
that security was really designed in,
talked about them from the beginning.
So here we are,
a group of radio geeks
at a security geek-oriented conference,
and you can kind of,
from the beginning,
your skepticism should be
heavily attuned.
Okay, so here's some examples
of typical P25.
This is a Motorola XTS5000.
That's the radios that the goons use here.
So this is kind of a first generation
or second generation
of the subscriber equipment that's available.
Motorola is by far the dominant vendor,
although there are other vendors
of the equipment.
Motorola is also, interestingly,
the only vendor that produces key loaders.
So if you want to use the encryption option,
you're kind of bought into Motorola
as it is because they're the only company
that actually makes the equipment
that can load keys into the radios.
So there's a fairly wide range of equipment.
All of it is shockingly expensive.
The, you know, here's,
these can be bought on the surplus market
for, you know, in the neighborhood of 500 bucks.
This is the current latest and greatest version of this.
This is an all-band.
That is VHF, UHF, 700, 800 megahertz P25 radio.
It has speakers on both sides
and a keypad and a fancy display.
And, you know, it costs some shockingly large
amount of money.
But anyway,
it can, you know, interoperate with anything.
So there's a fairly wide range of equipment available.
And, you know, they look like walkie-talkies
from police movies in the 1980s
because they're all kind of big and clumsy.
Okay.
Now, the P25 is intended not just,
is intended primarily for public safety users.
That's the sort of, and like for police, fire,
ambulance services.
Not all of them need security options.
And the basic model for it, you know,
is assuming things like traffic analysis and so on,
even for the encrypted users,
are not a particular threat.
But in fact, if you kind of poke around,
you can see that, well,
here's an encrypted radio standard that exists
and you can just buy off-the-shelf equipment
and it has some security options.
So it has more users than it was,
more different kinds of users than it was designed for.
Here's a picture from,
I believe this was from Afghanistan.
And if you look really closely,
you can see one of those XPS 5000s
on the front of that war fighter.
Here's a photo from a White House event.
This is the back of a, whoops,
back of a Secret Service agent
who has a P25 radio in her evening gown
with one of those little earphones.
So these are used by everything from the military
to the Secret Service to, you know,
pretty much all of the federal law enforcement agencies,
but also, you know, local police and fire and so on.
P25, by the way, can work with both trunked
and conventional systems.
So you can kind of drop it into a trunked system
or you can just drop it into conventional repeater
channelized options.
It has both.
For the most part,
state and local is using trunked systems
more than non-military federal.
Military is using chiefly trunked systems.
Federal law enforcement is using chiefly conventional systems,
although, you know, this varies based on area.
So how does this work?
Okay, so basically,
you have an existing narrowband channel.
And so the first question is how much bandwidth
can you fit in there digitally?
And they're being fairly conservative
in that they're using a 4,800 symbols per second.
Those are two-bit symbols.
So that's 9,600 bits per second for the encoding,
which pretty comfortably fits into a 12.5 kilohertz channel
if you kind of do the Nyquist math.
And it can kind of coexist
relatively comfortably with analog FM
in that it, you know,
has a pretty similar shape of the curves
and the spillover to adjacent channels.
So the vocoder for the audio
is a proprietary system called IMBE.
Most DMR and so on is using AMBE.
This is very, very similar, except it's incompatible.
That's its main difference.
But it's, you know, fundamentally very similar.
The audio sounds the same.
It does a respectable job of replicating human voice
in 9,600 bits per second.
Interestingly, it really, really, really
wants to be implemented in hardware.
If you do a software implementation,
you need a pretty fast computer
to keep up with the audio streaming,
particularly on the decoding side.
So you really want hardware
to be able to just do the vocoder
digital-to-analog conversion for that.
The way they do this is
they basically have
a train of voice frames
that are each 1,728 bits long,
which, if you divide this up,
is 180 milliseconds of audio.
So every 180 milliseconds of audio
is kind of separately encoded
into these two voice frames that they've got.
Now, it's not quite that simple.
In fact, there are two kinds of these voice frames
called a logical data unit one
and a logical data unit two.
They both contain 180 milliseconds of audio.
The difference is that half of the metadata
that's thrown along with it is in the first one
and half is in the second one.
And they keep repeating.
And the idea is that after two of these frames,
you've now got enough information
to start decoding the rest of it,
and you have all the metadata that's associated with it.
Now, another interesting kind of design constraint,
and this is no surprise to radio geeks,
but is a surprise to computer security
and protocol design geeks,
is that this is designed,
even though we call these things
two-way radios,
this is a one-way protocol.
This is a broadcast-oriented protocol.
And I'm stating the obvious kind of slowly,
partly because I'm a professor
and that's what I do for a living,
but also because this will be important
as we go forward.
When you're designing a security protocol,
almost all of the security protocols that we design
involve two-way handshakes
between the initiator and the researcher.
And we tend to design protocols
in which I say,
here's what I'm about to send you,
here's my key material,
send me yours back.
Oh, yes, we're happy to communicate.
Now we've done our handshake
and we are synced up.
And almost everything that we know how to design
starts with the premise that you can do round trips
between the sender and the receiver.
Here, even though all of the receivers
have the capability to do that,
or to transmit,
we're operating on a broadcast model
in which you basically put stuff over the air
and it is up to the recipient
to pick out everything they need to decode it
without any round trips with you.
And that's partly so that you don't have to know
who all the recipients are in advance
and you have kind of a standard broadcast model.
Now, there are a few things that do involve round trips
for the messaging protocols that are built on top of this,
but chiefly, this is basically
a one-way protocol for two-way radio.
Okay, so how does security get grafted onto this?
Okay, first of all, there is no public-key cryptography at all,
and that's unsurprising given that this is a one-way protocol.
Instead, it's built entirely based on symmetric encryption.
You know, it supports AES, DES,
and a couple of proprietary systems
that you'd never want to use.
Most of them are 40-bit RC4.
As well as an option to include type 1 classified ciphers
or suite A classified ciphers, as they now call them,
although I have never seen any evidence in the wild
of anything other than AES and DES
and god-awful RC4 being used out there.
Almost everybody on current systems
is using AES, DES or RC4 in practice.
The keys need to be loaded into the radio in advance
before being able to be using them,
and the sender and recipient have to share keys
because it's symmetric key encryption.
Now, keys can get into these radios in one of two ways.
One way is to use a key-loading device.
So if you were to look at these radios,
if you have very good eyesight, you can look at mine.
If you don't have good eyesight, buy one and look at it.
You can see there are a whole bunch of pins on here.
A couple of them are serial ports
that go directly into the encryption module.
So there's a kind of direct path into the encryption module
to the key-loader
that can blast key material into the radio.
Another way to do it is through an over-the-air protocol
called OTAR, over-the-air re-keying,
in which the radio has an initial key set up dedicated to it.
It can communicate with a base station
to get the current traffic keys to be used over the air.
And essentially, it's up to the radio
to have the correct keys
that are being used by whatever group they're communicating with.
And if you don't have the correct keys, you're out of luck.
And if you do, then great.
Now, again, there are no sessions in a communication
because this is a one-way protocol.
You just transmit, you encrypt,
and you now can be received by people who have the key material
who are tuned to the correct channel.
Okay, so that's the kind of security model.
Now, that security model means
the sender makes all the security decisions.
The recipient has no role in negotiating with the sender.
The sender basically has to select encryption to be turned on,
and it's up to the receiver to receive.
Now,
this design is intended for public safety users.
That is, the people who they were thinking of
when they designed this were cops and firefighters
and paramedics out there in the field.
And the model for them is
you want to err on the side of ability to communicate.
And so they made a design decision
that actually makes a lot of sense
for that category of users,
which is that receivers try aggressively to receive.
If you send something with a key
and the receiver has that key loaded in their radio,
they will demodulate it.
If you send something in the clear
and the recipient is set to encryption mode,
they'll demodulate it.
So we err on the side of demodulation,
and that kind of makes sense
because it's, you know, you're saying,
help someone shooting at me.
I hope my mic wasn't keyed.
Help someone shooting at me.
You really want people to be able to receive it
if your crypto switch was in the wrong place.
Okay.
So there's no authentication.
And there's no protection against things like replay
or anything like that
because those all require the concept
of a communication system.
There's no protection that doesn't exist.
Okay.
So we looked at this protocol
and we discovered a number of weaknesses of the design.
First of all, it's pretty ad hoc.
The security stuff was clearly grafted on at the end.
But interestingly, they seemed to make
all of the bearer channel encryption stuff
does not make a lot of the mistakes
that you could make.
For example, if you XOR the first frame
with the second frame,
the key doesn't fall out, right,
or anything like that.
So they seem to have done the actual AESDS encryption
reasonably competently
with the exception that there's no authentication built in.
But in terms of actually successfully encrypting
when the encryption is turned on,
it seems to actually do that
without any embarrassing cryptographic mistakes
that we've found yet.
You know, I have to add that.
But it does have some significant protocol weaknesses
that can be exploited in practice.
Some of them are consequences of the lack of authentication.
Some of them are consequences
of the enormous susceptibility to traffic analysis,
which I'll talk about in a second.
In particular, there seems to have been
a simple mistake made
that there's metadata sent
that includes a unique unit identifier
for every radio.
So your radio has a unique serial number
that it sends over the air with each packet.
If you turn encryption on,
that stays in the clear.
So even if you're encrypting,
somebody doing intercept
can kind of keep track of what units are in the area,
when they're on, when they're off,
what channels they're on, and who they're working.
And that appears to have simply been a design error
in the way it was constructed.
It doesn't appear to be necessary
for anything about how the system operates.
The second is we found that it was vulnerable
because of the way they're doing forward error correction.
Radio systems really need
some sort of error correction going on.
They do something very aggressive
in that they error correct
every metadata field separately.
So we send things like the unit ID,
and that has its own error correction.
And then we send the,
what kind of a packet is this?
And that's error corrected separately.
And then we have the bulk voice,
and that's sent separately.
And that turned out to allow for
a uniquely favorable to the attacker
denial of service attack,
where this is the only system I've seen
that requires less energy to jam
than it does to legitimately use.
So usually you want to design a system
where you need more energy to jam.
This actually requires less,
and I'll describe how you'd actually do that.
So here's some sort of,
here's the smart stuff we found.
Okay, first is that voice traffic
is not authenticated.
And one of the things that that means
is that you can replay
encrypted traffic at will.
So you might not be able to demodulate it,
but you can just grab the RF off of it
and play it back,
and it will happily do that
in the voice of whatever they said.
And if you can figure out what's going on,
you might be able to use that
to your advantage as an active attacker.
Another issue is the susceptibility
to both passive and active traffic analysis.
So passive traffic analysis is easy
because even when encryption is on,
the 24-bit unit ID is sent in the clear.
But that only works when they choose
to transmit.
So we also found an active attack
that allows you to ping radios to,
that allows you to ping radios
to basically induce them to transmit.
And the interesting thing about this
is that it takes advantage
of the one area of the data service
that does actually do authentication.
Except this system includes both AXE and NAXE.
So if I send you something,
a text message over this,
and you have the correct key material
to decrypt it,
you'll send back an,
I got your text message.
If I don't have the correct key material
to decrypt it,
it will send me back a,
get lost.
You don't have the right key material
with the unit ID helpfully included.
And so what that means is that
you can create kind of Harry Potter's Marauders map
of all of the local law enforcement agencies
by simply going down the list and pinging
and setting up a little system
to direction find and triangulate
where they're located.
And you can do that with kind of SDR equipment
and three or four base stations
at regular intervals
and do it infrequently enough,
occupy little enough bandwidth
that nobody is ever going to notice.
Okay, so that is probably more of a threat
for the military users
than it is for the local public safety
because police cars have like markings
that say police on the side
and lights and sirens.
So, you know, where they're located
isn't all that secret.
But military operations are often kind of concerned
with this sort of stuff.
Okay, so denial of service
was kind of the most fun
of the active attacks that we saw.
And so here's basically the idea.
So there's this aggressive error correction going on.
And what that means is every field
of these 1728-bit 180-millisecond frames,
every subfield of that is separately error corrected.
One of those subfields identifies
what kind of packet this is.
One of the types of packets is,
this is a voice frame.
And basically there's four bits encoded over 64 bits
that say, you know, this is a voice frame,
this is a text message,
this is something else.
If the recipient isn't able to decode that frame,
they ignore the rest of it
because it basically tells you
what the meaning of the rest of the frame is
sent toward the beginning.
Now, helpfully, this frame is sent
immediately after a synchronization
frame that tells you,
I'm about to send you this all-important
64-bit error corrected field
that you very definitely want to be able to receive.
So you could, in principle,
you know, jam 32 symbols
out of 864 symbols
and render the entire 864-bit
symbol packet unusable
by the recipient just by selecting
effectively at the right time
transmitting more energy than the recipient
for that brief instant of time.
And, you know, if you do a calculation,
that means the energy use
that you're using compared with the legitimate user
is 14 dBs less
than you're required to communicate.
So this is phenomenally awful
in terms of traffic analysis
and it's incredibly resistant.
And it helpfully provides a synchronization symbol
built in for you to use.
So we really wanted to kind of implement this attack.
And, you know, we were thinking about,
well, how do we implement this?
Well, we're going to have to build some sort of SDR
and we're going to have to load some custom FPGA in there
in order to be able to get the timing right
to decode this synchronization frame.
This is going to be really expensive.
We better ask the NSF for more money
so we can buy, you know, big racks of equipment.
And then Travis came along and said,
oh, I can do that.
And so what Travis did
is he took this little device called a girl tech
IME instant messenger,
which he observed has a chip in it
that does an over-the-air C4FM protocol
similar enough to P25
that it can be abused
into decoding it in real time.
And then he loaded some firmware.
This is the same device that a spectrum analyzer,
he also built a spectrum analyzer out of.
He loaded some firmware into it
to recognize the synchronization train
and transmit well above its designed maximum power
for the few milliseconds required
to jam those 32 symbols at just the right time.
Now, these devices are kind of interesting.
First of all, the chip that you want
is called a TICC1110,
but the chip costs more than these devices do
on the surplus market.
So you can buy these for about $10 a pair on eBay,
although after we give this talk,
the price goes up a little bit,
so, you know, wait a little while.
You can buy these things on eBay.
The development kit with a sample chip
costs about $40,
but you can get two of them for about $10 in these,
and this helpfully comes with a power supply
and a nice purple case.
And so we call it the My First Jammer,
and basically it will look for the synchronization train
on a given channel and transmit.
Now, that's sort of interesting
because this also gives you
about a 20 dB price advantage,
assuming that power supply
is money,
over the legitimate user as well.
The jamming equipment is both low energy
and phenomenally cheaper than this stuff.
And you can imagine sprinkling these
around a metropolitan area.
Ideally, you'd want to put them near the receivers of repeaters
so that they just jam the equipment
so that you can get the maximum energy advantage
that you'd have.
And this would be a fairly economical thing to do.
Don't do this, by the way.
Okay, so that was one thing you could do,
but okay, that just causes havoc.
That might not be...
Turning off your local FBI surveillance
or whatever is one thing,
but another more interesting use of this
might be to train your local law enforcement agency
that encryption doesn't work.
And so rather than just looking for the synchronization train,
what we looked for was the synchronization train
followed by the packet type that says this is encrypted
and only jammed encrypted traffic.
And so you can make...
You can selectively jam
only certain kinds of signals to train users
in various kinds of behavior that you'd like.
Now, we published this paper...
When we published this paper,
kind of an interesting side note,
we published this paper,
and at the same time our paper came out,
Kevin Mitnick's memoir of his life on the run came out.
And apparently, he was back in the old analog days
monitoring the FBI people who were looking for him.
And they had some encrypted radios as well at the time,
although this was before P25,
and he was really annoyed
when they would switch to encrypted mode.
And so he apparently got a walkie-talkie,
and any time he saw encrypted traffic,
he would jam it,
and eventually he would hear them in the clear say,
hey, is it working now?
I don't know, there was something wrong with the switch.
So it turns out we had a sort of parallel discovery
of the same attack,
except that we didn't actually go on the run
and field this, I will point out.
Okay, so how does this work in practice?
Okay, so this symbol
is the symbol on the encryption network
and the encryption switch.
As you can see, it's very obvious what it is.
So, you know, there are some potential usability problems
with these systems.
One is that there's poor feedback
about whether you're encrypted
when you're using the radio.
So basically, the recipient does nothing about this.
The transmitter makes all the decisions,
and whether it is in encrypted mode or not
depends entirely
on a toggle switch on the radio.
And I'll show you what that looks like in a bit.
The second problem is that
the over-the-air re-keying protocol
is used to very frequently re-key sensitive agencies,
because we all know that you're supposed to change
your passwords more frequently
to make them more secure.
And that is also federal practice
for crypto keys for sensitive agencies as well.
And the more sensitive the operation,
the more frequently they're expected to re-key.
Unfortunately, the over-the-air re-keying
is itself, oh, you are the best person on Earth.
Thank you, sir.
This is not vodka, right?
Okay.
Okay, so unfortunately,
the over-the-air re-keying protocol itself
is an unreliable protocol,
and what often happens is
some users re-key to the new key
while other users are left with the old key.
There's no mass synchronization
that causes everybody to switch over at the same instant.
And so if some users have old key material,
some users have new key material,
they can't interoperate with each other.
Now, there was a famous paper
by Alma Witten and Doug Tygar from 1999
called Why Johnny Can't Encrypt.
And the interesting thing is that this paper
made almost exactly the same observations
that we made about P25 radio usability
about PGP email usability.
And, you know, it is almost as if
the designers of the system looked at that paper
and said, well, we can't give them a monopoly
on these mistakes.
You know, we're going to do this ourselves.
So here's the Motorola XTS 5000 radio,
and this is how it is set up in clear mode.
And this is what it looks like
when you're using it in the clear mode.
And, you know, that's what the display looks like,
and that's what the radio looks like.
On the other hand, when it's in secure mode,
that's how you configure it.
Now, what's the difference between those two things?
Well, there are two differences
for those of you who are very sharp-eyed and pedantic.
One is that there's this little circle
with a slash through it
that shows up on the display,
and there's a toggle switch there
with a circle
versus a circle with a slash through it.
Now, the interesting thing is
that there appears to be great disagreement
among the users
about which one of these means encrypted
and which one of these means clear
or what it does at all.
The only precedent I can find
for these exact symbols being used
is car air conditioner vents
for open and close.
But, you know, so the metaphor
appears to be open
versus closed.
But on the one hand,
the circle with the slash through it
might mean don't
versus the open one meaning,
okay, go ahead and do.
And a lot of people have really said,
you know, that's obviously what it means.
Whereas other people think, well, obviously,
this means, you know,
don't means the circle
and the slash through it means do.
And so there's great disagreement
about which is which.
But it doesn't really matter,
because you're talking into
a different part of the radio
and can't see any of these things
when you're actually transmitting.
So what happens?
Well, it becomes very easy
for users of this system
to inadvertently use,
mix clear mode and encryption mode.
And we, you know, it's very easy
for one user to be in the clear
while other users are encrypted.
And if they all have the same key material,
they're communicating quite successfully
when they're doing this,
just with more people than they think they are.
And that happens,
as we will see in a moment,
fairly frequently.
The next problem is this cumbersome re-keying.
The over-the-air re-keying protocol
is unreliable.
Users tend not to have current key material.
And there's no real way to ad hoc re-key
in the field.
And so this is the Motorola
key loader.
It's kind of larger than the radio.
And they're really expensive and cumbersome.
And they erase keys on their own
fairly often.
And you kind of plug it into the radio
to load keys into it.
So that's one way.
The other is with this over-the-air protocol.
So one of the questions we wanted to ask
is we discovered a whole bunch of active attacks
and a whole bunch of passive attacks.
We discovered ways to jam these systems.
We discovered ways to see who is where
by pinging radios.
And we discovered
a number of ways in which encryption
potentially could be turned off.
Now,
I'm old enough
to have
been at the Crypto95 conference
in Santa Barbara.
And Crypto95 was particularly notable.
Crypto is the conference for crypto geeks.
They meet in Santa Barbara.
They're not Las Vegas.
They're smarter than we are.
Every year in August.
And have a big beach barbecue and give talks.
They invited as their keynote speaker
a fellow by the name of Bob Morris.
He used to work at Bell Labs
and then went to work for the National Security Agency.
So it was a kind of big coup
to get him to come and give a public talk
at the crypto conference.
And he said he would
and what he talked about was he said
OK, I'm going to tell you
got up on stage and he said
this is NSA's first rule of cryptanalysis.
And I got out my pen
and everybody said ooh
NSA's first rule of cryptanalysis.
This is going to be good.
This is NSA's first rule of cryptanalysis.
NSA's first rule of cryptanalysis
according to Bob Morris is
first, look for clear text.
And so
we decided
to
take that to heart
and see how successful
a SIGINT operation is
looks out there for SIGINT.
That is to say we decided to build
the wall of sheep
at a large scale.
So
how much
unintended
sensitive
P25 clear text
is there in the field?
So we don't
quite have the resources of NSA
and this was about 2010
that we kind of started to do this.
So we were looking at
2010 technology for our
model. So one question is
how would you build such a thing?
So first of all you'd need to get
some locations to put sensors
to put receivers.
And you know
if you were a national government
you might put them in your embassies
in different places or rent spaces
on towers or what have you.
We just used all of our
friends in as many cities as we could find.
And that basically means
we could find sites in Philadelphia
which is where we are.
And we had one up in New York
and one in central New Jersey
and we had one in Boston for a while
and Chicago for a while
and Berkeley for a while
and so on.
So we just ad hoc picked some
the metropolitan areas that we had friends
who were good enough friends
to say we're going to put this box
with an antenna in your apartment
don't ask any questions
and hook it up to your network.
And you know
we basically built a little
sensor monitoring network
in these various cities.
But now the question is
well what actually should we monitor?
So it turns out
there are two
frequency bands
used by the federal government
we decided to focus specifically
on federal law enforcement users
who are doing sensitive stuff
that is not ever supposed to be
in the clear.
And so
there are a lot of different
federal users
a lot of them are completely
unsensitive.
The post office trucks
have radios in them
and they use those frequency bands.
But those same frequency bands
are also used by Homeland Security
investigations and the Secret Service
and the FBI and the postal inspector
and customs
and all of these other various agencies.
So the first task
is to find out what channels
they're using.
There are about 2,000 discrete channels
allocated exclusively in VHF and UHF
to the federal government.
In the 162 to 174 band
and in the 406 to 420 band.
And you know
12 and a half kilohertz spacing
between them.
A lot of them are not in use
in any given area
a lot of them are used
by non-sensitive agencies
but mixed in there
are some that are used by sensitive agencies.
So today
if we were doing this
what I would do is go and buy
a sort of medium
end SDR
something along the lines of a LIME SDR
get one for each band
conceptually that has enough
output
throughput to be able to
record all of the spectrum
for later
offline analysis
within all of the federal frequency bands.
So in 2010
that wasn't quite true
in 2010 that would require
in the north of $100,000
level SDR equipment
today it's the south of $1,000
levels
would allow you to just record
all of that spectrum
and pick out the P25
signals later for offline analysis.
This was not practical
on our limited budget
because actually by the time
we started doing this all our money had run out.
So we
found that the best
price performance P25
receiver was a
consumer grade
ICOM software
controlled radio
called an R2500
sold to the
hobbyist market and it has a P25
board in it.
So it's not an SDR but it is a software
controllable radio
that has a remarkably
good RF front end.
For our purposes in our frequency band.
And so the first thing we did
was we configured this
to
identify every channel
with encrypted traffic on it.
Why did we want
encrypted traffic? Because
those are the channels that
have the sensitive operations on them.
And then
so we actually put
two of these in each location.
One scanning looking for encrypted traffic
on frequencies we don't know about
and another recording
all traffic and metadata
on every channel that we did know about
and that would allow us to not miss
very much. So this two receiver
configuration although a bit
clunky and suboptimal by modern standards
effectively would allow us
within a few weeks to discover
a large fraction of the
channels used for sensitive
things and then record
basically all the metadata and
unencrypted voice traffic
that appears
on them. Okay so
what did we discover?
So basically
what we discovered was that
with the exception
of
one agency
and I'll
leave you to wonder what agency that was
every
federal law enforcement
agency engaged in sensitive
operations
has
some
unintentionally clear
traffic
every day.
And sometimes it's
entirely clear
and sometimes it's clear mixed in
with
encrypted.
And invariably
the clear guy
would be the one who has the
transmissions along the lines of
okay everyone here's the plan.
And so okay everyone
here's the plan
was one of the most common things
that we would record along
with alright I'm in
encrypted mode now.
So
we would actually hear that and
if I were
less discreet than I am I would have
brought a greatest hits tape
of
those things. See me later.
Okay we would
get an average of about 30 minutes a day.
per agency
per metropolitan area
of just unintentionally
clear traffic. So how sensitive is
sensitive? What did we
discover? Well we
actually found kind of some of the
most sensitive stuff you could
imagine. So we would get
the names
and other identifying
features not only
of the targets of surveillance
but also of things like confidential
informants. So
we would hear
I've got Jose with me right
now. He's going to go and talk to
the target. You'll know him because
he's going to be the guy wearing the white hat
and
that sort of thing. So
that's kind of useful information if you're
the target and
not so great for Jose
if somebody
picks that up. We would
frequently get and
it was kind of like having your own private
version of the TV show The Wire
which was still on that time. We would
get the wire tap
plant that was set up to look at
a target would often set up a radio
base station and kind of broadcast
out a summary of
what's going on on the wire tap of the
target. So we would hear
the target has just gotten a phone call from
my favorite was
an operation in which
there was a
the target of the attack was named
some name like we'll call him
Bobby but he was
fencing stuff
that he was buying with stolen credit cards
and this was a large carding operation
and his fence
was named Louie
the fence which is like the
worst criminal name ever but
the
so you know
we would hear the ongoing
narrative of what was going on on the
target's wire tap quite frequently.
Body wires were
often so when they would wire up
an informant the audio from
an audio body wire would often be
sent over a local
tactical repeater more often
than not in clear mode
as well as traffic
for
things like protective details
of dignitaries
going all the way up to the president
so secret service and state department
protective operations
so you know we would you know one of the
interesting things is that during
the presidential
conventions we would know the code
names of the
candidates before they would get
leaked to the news media so
you know we would get a couple
secret service would start using them a few days
after a few days before they got made
public so that was
you know that was sort of entertaining but
we would also learn like where they were moving
to and what the plan was and so
forth so we would really
hear a lot of kind of some of the
most sensitive stuff ever
the interesting thing is we would
and it was easy to identify what
agency was what because we could
direction find to where it was and also
different agencies would be assigned
different blocks of user
IDs so we could use the
metadata to determine what agency
was operating on a
different channel because that's coordinated
across the entire federal government
and
interestingly there was one agency
that we have never
collected a single
clear transmission from
any I guess I've told
some people this but any idea
no actually the
CIA well the
CIA doesn't operate covertly within
the United States but the security
guards at CIA headquarters
do and
interestingly if you
if your car
runs out of battery in the CIA
parking lot they will help the
security guards will helpfully
jump your car for
you but they'll also read your license plate
out over their unencrypted
channel so no not the CIA
yeah
ATF is
very entertaining
the
the postal
inspector
don't mess with
the postal inspector
they know what they're doing
on encrypted radios and I actually was
wondering about this and I found out and I asked a friend
of mine who runs the radio system for
the police department he said
and he said oh yeah I met the radio
guy for the postal
inspector and he was just this
encryption fanatic and he
basically anytime they would get a radio
he would take some super glue
and glue the encryption switch
into the encrypted position
and apparently
that
continues to this day
and that's why the
postal inspector's office
don't mess with them
they're serious
okay so we found
basically what's going on we found basically
there are kind of three classes of
mistakes
going on here one is the kind of single
user error where the switch
is just in the wrong position for one user
in a group and invariably it's
the okay here's the plan guy
but
somebody is transmitting
part of the operation there's also
kind of a group error
where you have this
incorrect information about
what the encryption switch means
and what it doesn't
and you know
or nobody notices that they weren't
and then finally you have the keying
failure problem where a bunch of
users in a group have one key
a bunch have another key and the only
way they can all interoperate is to
switch to the clear because they're out
of sync on their key material
and we found that these
three categories of
when we would sample what was going on
it was roughly a third each
of these
of each of these things
and what's
interesting is that
if you go back to the standards
people and
say you know here's what we discovered about
this they'd say well great
it's all working properly right
because the standard
is
working according to spec
if you go to the radio vendor they say
we built radios according to the standard
and if you go
to the user community
you know they say well
these are the radios that we're able to buy
and if they have usability
problems you know this is what we're stuck
with we have no real control
over what the standard is
so this effectively ends
up being nobody's fault
which is familiar in
many security problems
okay so
um
the you know a couple of
you know kind of observation
this was a great
example of things
security being grafted on
later with compromises
from the beginning with
very predictable consequences
um
the um we're seeing
actually to this day our sensors are
still in most of our cities the sensors
are still running and what
we've seen is that I've gone
to every federal agency
that we're seeing sensitive
clear traffic to I've spoken
to some
senior person in charge of their
communication system which by the way
those are meetings which are really
fun to set up
you know when you call a
federal law enforcement agency
with lots of body armor and machine
guns and handcuffs and you try
to tell them that there's a mistake that they're making
it's helpful to have friends introduce
you um but
so you know I go to those meetings with some
trepidation but they're actually
very receptive to that
um but what I found
is that every time I you know when I
meet with an agency and discuss what
their real problems are and you know playing the
audio is very helpful in driving
home um some of
some of these things
um and in fact I remember one conversation
in which I was talking to an agent
and you know I was able to tell
her how she likes her coffee
um because
I've heard one of somebody getting coffee
for her during a surveillance operation
um the you know those
those you know that gets
driven home and what we found is that we
would see clear text go way down
for about two weeks
uh after um
we would talk to them and then interestingly
it would go up to a higher
level than we had seen
before why is that
well as far as I can tell it's that you know
the message goes out of exactly
what to do uh and
then um that
message gets a little bit garbled
over time and what people remember
is pay extra attention to
the position of that
mysterious switch
uh but they don't remember which position
it's supposed to be in um and
or they rekey more frequently
which has the effect of
taking making people go out of
sync more frequently um
and so um you know
these are really fundamental problems that
are easy to blame on the user
but um
aren't actually
you know but that would be a terrible mistake
um you know that would be a cop
out on the part of the
technology design uh
of these that they've made a system that's so much
easier to use or to
misuse than to uh than to use
um so you know
we've developed some mitigation strategies
uh for them you know
which which you know a kind of some
set of better practices
if not best practices but really
the protocol itself
needs to be and the usability
needs to be redesigned from scratch
so I also
spent some time working
with the P25 standards people
and you know as
receptive as
the federal agencies were
um this was a remarkably
different experience so I
had you know I had gone to a number of
federal law enforcement agencies spoke to them
about you know what some of our findings were
um and you know
everybody was very interested and you know
at least trying to fix the problem
and then I took a trip down to
uh uh to
uh Charleston
to the meeting of
the P25 security
working group um which
consisted basically of vendors
and a few assorted
others and
um the um first thing
is I spoke to some of the federal representatives
and I said you know these
protocols when I looked at them
it kinda looked as if there was
somebody from the NSA in the room
for the first two meetings
and then they stopped showing up
because all of the language of the standard
has words that kind of
look like
um good crypto speak
they talk about key material and they talk about
initialization vectors and it's all
it's got all the right Greek letters and
everything is um looks pretty good
but then everything is
just being used a little bit
wrong and they said oh yeah
that's actually exactly what happened he died
um and
um you know I mean that's very
sad um but it's
also very sad for the uh
design of the protocol itself
um and basically
was never replaced so they were kinda left
going on their own
the standards group itself consists
chiefly of vendors
and mostly
uh the meeting that I had with
them consisted of the first hour
and a half of them taking turns
introducing themselves
and telling me how utterly stupid
and off base I was and how none of this
is a problem and by the way you don't
understand decibels
um and um it was
incredibly so they would go one
after the other and just tell me
how utterly terrible it was
and how awful it was and oh and by the way
you know you're immoral because you're
making us look stupid
um and uh and so on
so it was a very very unproductive start
and then of course we retreat
to the bar and
that's where all the kind of interesting
uh work got done and so there's
there's some hope of
maybe the next generation
it won't be called P26 because they
apparently don't go by ones
so you know when they come up with P45
there's a chance that
there'll be a clean slate
but it looks as if this particular standard
is kind of set in stone
okay so what are the overall lessons
learned the first is
Bob Morris' first
look for clear text which
I thought was this trite joke
turns out to work
really well right
looking for clear text
in a sea of cipher text
with the practical things that exist
right now is a remarkably
productive strategy
um and in fact from the
standpoint of
the interceptor
um in the old days
when encryption wasn't
available
users of these
things doing sensitive stuff
had to be pretty circumspect
in what they would say over the radio
um because they knew that anybody
could listen
um now they have
what they believe to be reliably
secure communication
and are much much more open
in what they talk about
at the same time
intercept technology
um you know an SDR
you know an under a thousand dollar
SDR setup
is sufficient to
capture um in real time
all of the I and Q
from all of the raw
spectrum in the entire federal
um frequency band
and can um
then offline pick out all the
clear sensitive traffic
um at your leisure
or in real time depending
on what your application is
this is pretty much the you know
a budget equivalent of
precisely the sort of package
NSA is installing in agencies
around the world and the FSB
is installing in uh
in uh embassies in the US
except that you can do it on kind of a
hacker budget and
um so now we have people
who are very confident in
the security of their communication
and an intercept environment
that allows uh passive
intercept uh to
to happen very cheaply
and really quite comprehensively
um and so
um you know arguably
the situation is actually far worse
than it was back in the days when
when uh encryption
uh wasn't available um
you know the um
uh you know I joke that
you know this I'm looking into whether
you know bank robbery is more lucrative
than being a professor because this
could really kind of give you a leg up
um I don't make that joke in
any talks with the federal agencies
um the uh
uh so that's
kind of the first lesson look for clear text
works and it's a lot cheaper
to look for clear text
the second is the sort of crypto lesson
which is that grafting
um encryption and security
standards onto a legacy
system has a long
and distinguished history of failure
that is unbroken by
our experience with uh
uh P25 this
um this really doesn't work
and right now I'm just upgrading our sensor
network to capture
all of the uh traffic
for offline uh
analysis later and that seems to be
working um fairly
um straightforwardly
so we've got plenty of time if you want to ask
any questions or throw anything or
tell me why I don't understand decibels
I'm happy to but try to use the mic
or they'll yell at us
yeah just come to the mic cause it's just
is there any audio feedback
if the uh received
voice frames are not encrypted so
you can configure the radio so that
it'll beep on encrypted
received or
beep on encrypted
on unencrypted received and
there's disagreement about what the beep means
unfortunately the same
beep on the Motorola radios
exactly the same beep
is used to indicate low battery
um so
um it
you can't win um and uh
the other question is um
can you have multiple keys inside the radio
or is it one key for one group
um you uh depending on how the radio is optioned
you can um
you can load I think up to 64 keys
on the radio
very cool um in a in a case
of using AES
if we wanted to mitigate like constant
re-keying and all the crap that goes with that
what sort of interval
might you recommend
you know so I mean I think the
federal guidelines
basically have them re-keying about once a month
for most agencies
and the model appears to be kind of
based on this military model
in which you know some of your
agents are being captured by
the enemy right um which
you know mostly doesn't happen to FBI
agents um
you know as far as we know they do lose
radios uh from time to time
but you know you know it's about as
frequent as losing guns you know it
happens but just not that often um
you know and
the problem is that if you re-key
you're guaranteeing that lots of stuff
is going to go out in the clear because the
re-keying protocol isn't atomic
across everybody um
if you don't re-key
you're guaranteed that any of your lost radios
will be able to uh
receive stuff you know
that's less bad than guaranteeing
that everybody is going to be able to
receive stuff so you know I advocate
very long lived keys
and um but getting
that practice out in the
in the field is an uphill
battle changing federal
security standards is a
non-trivial process
yeah
so uh is the
over the air re-keying protocol secure
as far as you can tell like not subject to replays
no it's horrible um
the uh so
it's um it is vulnerable to
a large number of active
attacks and manipulations
um it does not appear to be
possible to load
selected selected chosen
key material but you
can do other kinds of mischief
that are just as effective in practice
in practice
yeah okay so
thanks I'll uh see you
next time
oh and I should I would be remiss
in saying come to the voting village