Thank you very much. Can everybody see me? Can everybody hear me?
Awesome. This microphone is kind of sketchy, but we'll deal.
Our presentation is end-to-end voice encryption over GSM, a different approach.
We have Wesley Tanner, who is a systems engineer for Software Divine Radio Company
and has a BS in EE from RPI. There's me.
RPI in the house, I see.
Me, I'm not really a security engineer, but it says it on the slide anyway.
I'm an engineer for a computer company in Cupertino, BS in computer science from UCSB.
And we have Keith, who isn't here sadly, also from RPI.
We love you, Keith, wherever you are.
Presentation overview.
We're going to go over the motivation, the need for cellular crypto.
Current market offerings.
And our approach, a different approach to the GSM voice channel modem.
We're going to go over the details, the radio interface, traditional telephone modems over GSM.
Some of the design choices and issues we're facing.
We're going to go into the cryptographic design and hopefully we'll have some demonstrations that won't fail miserably.
It'll work.
I have faith.
Motivation.
Where is the end-to-end voice protection over cellular?
A lot of people want it, but a majority of the products in the market don't provide
in the sense that they fail in a lot of different areas.
The number one being price.
We'll get into that later.
We want to make cryptographic cell phones available for the discerning privacy-conscious consumer.
One sec. It's okay for photographs.
Thanks, Wes.
It's a requirement. We have to say it.
That was awesome.
Here is an image of the GSM network. We stole it from Wikipedia.
The only thing we wanted to point out is that here is the handset and here is the base station.
Those are the only two things you need to realize.
GSM cryptography. You're probably reasonably familiar.
We have the A3 algorithm for authentication.
The A5 for the actual encryption of the voice channel, or attempts at that.
And the A8, which is key generation.
A5 has been broken horribly.
You have no voice protection on GSM.
Even if you did, it's only over the air.
Once the data actually reaches the network, you're in clear text.
That should be fun.
As the slide says, the moral of the story.
GSM cryptography provides limited, if any, security to your voice channel.
Something else is needed. A cryptographic layer on top of that, or a cryptographic data channel.
More on the need of cellular cryptography.
Cellular phones have completely supplanted PSTN.
I don't think that many people in here have landlines.
I sure don't, and I don't really know anyone that does.
The cellular companies do not provide meaningful protection for that traffic.
And the ease of interception of voice data is kind of ridiculously easy, as we'll see later.
Two major classes of intercept.
The government-perpetrated intercept.
The TLAs, authorized and unauthorized.
I'm not sure I want to say that.
Non-government-perpetrated, the more interesting ones.
By private investigators, business partners, economic espionage and such.
The product on the right is a device you can buy for a couple of thousand dollars.
Yeah, these devices are relatively expensive.
But in the coming years, it's expected that with a cheap A to D converter and some special software, you can do this for a lot less money.
So it's going to become more of a reality for private intercepts.
Thank you, Mr. Tanner.
Government intercepts are probably the most common.
Undetectable. Sadly, untraceable.
Done on the higher levels of government.
Data for the reported intercepts.
In 2000, there were 1700 intercepts.
That covers everything.
1500 of those were portable devices.
Cellular, telephones, satellite phones, etc.
That's quite a large number.
Here is a chart of the increase in cellular wildtaps.
Actually, yes, cellular wildtaps, portable devices.
As you notice, intercepts have doubled since 2000.
The trend appears to show that it's increasing.
You could probably all notice that from the last slide.
What's interesting, though, is there's no massive jump after September 11th.
We won't go all tinfoil hat on you.
Which kind of implies they are obviously doing more wildtaps.
So those aren't getting released in those numbers.
There's also a GSM spec for lawful interception.
That's kind of interesting.
They make it rather easy.
It's actually built into the GSM specifications to get
output product, network data, which is your, you know,
location, type of call, parties, numbers, of course,
the product, which is the speech user data, SMS,
everything you take for granted to be reasonably private.
It's not.
Here is a diagram of a lawful interception.
Note the shady-looking law enforcement agent, the intercept request,
and the data coming back to the LEA.
Very interesting.
The moral of the story, too, is even if the GSM crypto is sufficient,
as I said earlier, the protection from the handset to the tower
is capable of being...
Even if the voice, the over-the-air voice crypto is secure,
you still have the over-the-wire cryptography.
Sorry, over-the-wire cleartext, which is easily interceptable,
as noted from the last diagram.
What's that?
There's a variety of products out there already that address this problem.
And we got a chance to see the CryptoPhone guys
present their products at Hope last year.
Apologies. Is it better?
The CryptoPhone guys presented their product.
It's slick. I've never used it, but it does address this problem.
There's the Sectera device by General Dynamics,
and that's really used more...
That's basically available to a military and government contract.
There's the Ancord crypto smartphone.
There's not a whole lot of information about this product out there.
It's kind of a... Well, I was unable to find anything about it.
And there's several other vapor products that have...
Their web presence has gone up and down, and they're no longer available,
so I can't say anything about those.
There's...
There's a government...
There's a new government standard
that's looking to replace the STU3,
which is what they use typically to provide type 1 voice crypto.
It's the Future Narrowband Digital Terminal standard.
This has a minimum requirement of 2,400 hertz for voice.
This is very standard things like MELP for voice encryption,
voice compression, and AES for voice encryption.
And there's more data about this on Wikipedia.
The problem with the current products...
They all probably work very well. I've never used them.
Oh, I've never seen them demonstrated.
But they use the circuit-switched data channel.
I was never offered this as part of my consumer package.
And I think... I've heard that you need to pay roaming charges
in some areas on this.
So it's not as ubiquitous as the voice channel itself.
There's longer call setup times associated with it,
because it's a modem.
It has to negotiate the connection. And there's a higher latency.
But it's better than the packet-switched services that we use
like GPRS for a typical internet over a cell phone.
Also, if you can get circuit-switched data,
it's usually rather expensive, which is kind of irritating.
And it's meant to carry data, not voice.
And data is not forgiving with bit error.
And voice is. You can have large numbers of bit errors
in your voice stream and have reasonable voice quality.
So you don't need it to retransmit.
And for data, you do.
And the biggest problem is that these products are
not available to you or me. They're very expensive.
Or they're for military or government use only.
And a solution should be available to you and me.
3G will probably take care of a lot of these problems.
Because it is a high bandwidth data.
And the data suggests that it will be low latency as well.
It hasn't been rolled out everywhere. It actually is in San Diego.
And I believe San Francisco. I don't have it, but...
It may solve the problems, but again, it's not available to everybody today.
And we're proposing a solution, which is what we've been researching
for the last couple months.
It's developing a modem
that will work over the 2G voice channel
and the 3G voice channel.
And it involves a bunch of technical disciplines,
which makes it an interesting problem.
And that's all I want to say about that.
Basically, the voice channel on GSM
is a subset of a generic voice channel.
Basically, the tricky part about the GSM channel
is that it's highly compressed.
And if we get a product to work on the GSM channel,
we can use it on anything. You can use it over 2-way radio,
voice over IP, or
normal packet switch telephone networks.
And the goal is to have an integrated thing
that works over all these protocols.
All these systems. That's the goal.
And this is the proposed system block diagram.
I don't know if it's easy to read.
But basically, you have your input voice stream
that goes into some kind of modem
and goes through the GSM channel, all through all the networks,
and comes out the other side undistorted.
The project goals are basically
to maximize the voice quality
and provide strong crypto
for privacy. And to minimize the distortion.
So you want to have good sounding quality audio
and have it very secure.
I'm going to blow through some of these quick
because it's highly involved
and takes too much time. But basically,
the GSM voice channel is a low latency,
highly available channel.
It has a friendly billing system. You can use your minutes
instead of more expensive data packages.
However, the voice channel uses
strong compression, which causes distortion
for certain types of signals that you pass through it.
And therefore, you need to pass through things that look like speech
so they're not distorted.
This is a pretty busy slide,
but it's basically calculating the data rate
over the GSM air interface.
And this is a breakdown of the GSM voice frame
by speech parameter.
It works out to 13 kilobits per second
and there's 260 bits per frame
and those are sent every 20 milliseconds.
And all these parameters here are what we're trying to exploit
to enable us to create a waveform
that will work over in this frame
without significant distortion when it goes through the channel.
And this just shows that there's an 8-to-1 compression.
Your input on a typical GSM handset
is 8 kilohertz sample rate audio
at 13 significant bits.
And that works out to an 8-to-1 compression
when you go down to 13 kilobits per second.
The official name of the 2G GSM voice channel
is the top bit.
It's a long way of saying that it uses
a complicated compression
to achieve its goal.
And the input is PCM
on a uniform quantized data.
This is another busy slide.
And this is from the 3GPP website.
A lot of this data is available there.
It's the voice encoder.
Your speech samples go in on the left
and the parameters that describe that speech
come out on the right.
And there's a bunch of complicated processing in the middle.
It's highly nonlinear.
And this is the speech decoder, the synthesizer.
It takes those input parameters
and spits out synthesized speech
that's a very clear representation
of what you originally put through the channel.
I'm going to blow through this one.
Basically, the processing involves
short-term algorithms
that determine what the short-term content is.
There's a long-term prediction that gives you your lag and gain.
And the coder also
determines the pitch of your voice.
And all this is fed through this coder.
You get a residual error signal out, and that's also encoded.
So all these parameters do a good job of representing speech.
When the voice packets go over your GSM radio,
some bits are protected
from transmission errors, and some are not.
The class A bits are.
I think it's about 36 bits
that are actually protected. Those are the most important bits.
If you flip one of those, it's impossible to have intelligible speech.
If the other bits are flipped, it's possible that you can actually
understand the audio coming out of the phone.
There's an RFC about this that goes into more detail.
And this is a slide
we threw in just showing a typical speech pattern.
It has a pretty distinct shape.
I'm sure a lot of you have seen that before.
This is 8 kHz sampling rate, and it's about 6 seconds of audio.
And this is a zoomed-in version.
It shows that there's a certain pitch
over the frame.
And I always wondered why you couldn't use
your traditional telephone modems over
the GSM channel.
So I'm going to talk about why this might not work.
Your typical telephone modulation schemes
are listed here in order of bit error.
I mean, bit rate.
There's the 300 all the way to the
56 kbit per second that we're pretty used to these days.
And they're listed by modulation type as well.
So they use different schemes to encode the audio.
And I'll give a quick description of
56 kbit per second modem.
It uses basically shaped voltages
or pulses over your analog pair.
And these represent bits that you're sending.
And those are converted to digital signal
when it gets to the telco office.
These voltages are held on the line for 125 microseconds
which is a pretty short amount of time.
And there's 8 bits per pulse. So there's 256 discrete voltages
that go over your line.
And in North America, we use only 7.
So we have 56 instead of 64 kbit per second.
But in reality, the analog lines are not able to discriminate.
It's hard to discriminate between the 256 levels.
So they typically use less.
And that's why it negotiates a slower connection.
And this is a high level diagram of
talking from one analog voice modem
V.90 modem to another.
And basically you can see the pulse.
You go through analog. Comes out digital. Goes back analog.
And one of the 1200 bit per second modems
they use a phase modulation scheme.
I just threw this one in.
It's a simulink model of a PSK modulator.
And it turns out that
voice codecs are not...
it's not important to preserve phase information
for voice traffic.
It's hard to perceive changes in phase and timing
on voice.
And so that information is not preserved over the channel.
And this is what PSK kind of looks like.
On the right is the time domain signal.
And you can see that it's a sinusoidal shape.
And there's discontinuities where we're adjusting the phase.
One phase represents a zero. One phase represents a one.
And the spectral content.
You can see the bandwidth it takes up.
So I'm blowing through these fast because I don't think we've got the time.
I want to run a demo right quick.
Of using frequency modulation
over GSM.
And what frequency modulation really is
you're encoding one tone as a zero
and another tone as a one.
And those tones are flipped back and forth at a certain rate
so that you send your data that way.
And we're going to show how the GSM channel distorts that signal.
Making it impossible to decode correctly.
That would have been bad.
Alright, this is a quick aside.
We did our modeling and work in Simulink and MATLAB.
It's a numeric processing tool that is
pretty quick to prototype on.
It allows you to rapidly throw something together
and throw information at the channel
and see how it behaves.
The actual voice channel we're using
our model came from the 3GPP website.
They have all the reference code available.
And so it's in C.
It compiles basically on any architecture.
And so we threw that code and put some glue into Simulink
so we could model this.
Alright, so this is running at 100 bits per second.
Hold on right quick.
This is the output special content
going through the voice channel.
But let me switch it over to
the straight pass through.
You can see the tones
going back and forth
between the 0 and the 1.
Closer to the 0 is a 0.
And further out in frequency is a 1.
You can see them flipping back and forth.
And you can basically determine at any given time
which one is which. It's easy to discern
when it's a 0 and when it's a 1.
If you put this through the voice channel itself
you can see that the pulses
they look a little more distorted.
It's harder to tell at any given time
what the actual tone is going through there.
There are these blips and blobs
and it's harder to pick them out.
That's just a visual representation of what kind of distortion
you'd expect to see on this channel.
I'll go into some technical details about what we're proposing to do
which is to make a modem, a modulation scheme
that will allow you to pass data undistorted
and cryptographically secured voice data through this channel
without having it flip bits.
There was a group in England, we discovered
that is doing the very same thing.
They've managed to get a 1200 bit per second link
over GSM using a similar scheme.
Basically what they do
they take their input encrypted voice
which is encoded at 1200 bits per second
which kind of sounds like a speak and spell
it goes through basically a codebook lookup system
where it has a list of waveforms
that will actually pass through the channel correctly
and it will synthesize speech based on some of those parameters.
It's a relatively simple approach
they're exploiting the fact that speech has very specific
qualities and parameters that you can
readily... the channel is able to
distinguish between those different things.
Our system is very similar
we're going to try to take what
they've done a certain thing, they've taken these parameters
they've synthesized things, we want to figure out a better way
to characterize the voice channel itself
and see if we can come up with a higher bit rate
we've decided that 2400 bit per second audio
is much better than 1200 bit per second audio
so much so that it's worth investigating how to make that happen.
And again, there's our proposed system block diagram
and this is a
high level diagram about the flow of data through the system
so you have a microphone at one end that's going into
an analog to digital converter
so you get your audio samples
you put that through a speech compression routine
and the output of that is the 2.4 kilobits per second
and you run that through some kind of crypto
and we're proposing AES block cipher
and run that through an error-corrective coding
I said more details on that later
and an error-corrective coding which basically means that
you can encode the data in such a way that if there are errors
on the channel, based on either
through the distortion of the GSM voice channel or
dropped frames over the air
as if you go through a tunnel or inside a building
it'll be able to correct those errors or at least detect them
and finally going through the modem that we're proposing to develop
that'll generate valid speech waveforms
that'll work over the channel
and those are fed through directly into the
speech codec on the GSM phone
and they go through to the decoder on the other side
which is basically the thing in reverse
this is showing
Let's do the demo first. I'm going to demonstrate some of the... basically using a simple
approach to the problem, trying to determine how the GSM voice channel will corrupt the
data that you pass through it. So what we're proposing is using the voice channel against
itself, using the speech decoder as the modulator and the speech encoder as the demodulator.
So we're going to fill the speech frame up with random bits and see how that will perform
over the channel and see what distortions happen. All right. This is another Simulink
model that we've thrown together that shows in the middle of this block right here is
the speech channel itself. And we're proposing to use the voice codec of GSM against itself,
the decoder is put on one side, and we're going to fill the frames up with random data
and see what happens on the other side. This is what it looks like on the output. Again,
this is random. We're filling the frames up randomly, and it's generating what looks like
valid speech information. It looks a lot like what we saw earlier as far as what the time
domain signal looks like. This scope shows the bit error rate through the channel. I'll
run this one more time so you can see it settling. It's taking the average bit error along the
X axis is the bit position inside of the frame, and into the page is the frame number, and
the amplitude is the number of bits that were flipped on average. Let's run this again.
Oh, it's very angry at me. I don't even know what that means. Anyway, the point being the
bit error rate settles to about 25%. One bit out of four is flipped when you put it through
using a rudimentary system like this. We propose that our research will continue as far as
developing a scheme that is able to pass a high bandwidth amount of data through that's
acceptable speech quality that will minimize that. 25% is far too high to pass meaningful
data through. MATLAB for Mac is not very good either, by the way. A side note on that,
there's a free MATLAB. I don't know if you guys know about Octave. It's basically MATLAB
minus the $100,000 fee. It's available online. You can search Google for Octave.
Thank you, Mr. Tanner. I want to take a slight segway for a second and go back to what he
was saying about 3G solving this issue. I think it will solve some of the issues, but
if you can purchase a data channel that is high bandwidth and low latency to do voice
over IP off a regular cell phone, that kind of cuts into the market that cell phone providers
have today. And I'm kind of worried that they might take steps to prevent that, but we'll
see when they actually start properly rolling things out. Here we have our network stack,
on the top, the voice channel, which is a low bit rate voice encoder, 2.4 kilobits per
second. The secure channel, which we'll go into in just a moment. The modulated data
channel, which is the voice modem and the ECC. And those are all on top of the GSM voice
channel and, of course, the GSM network. Otherwise the bits wouldn't go anywhere. Channel
expectations. We had to make some decisions and do some research on what we could expect
the lower levels to behave like. Detected and fixed bit corruption will be common.
Undetected bit corruption will be rare, but we'll deal with that. Undetected frame loss
depends on network quality and is reasonably common. You most likely hear dropped frames
during your cell phone conversations all the time. We hope to have no undetected frame
loss. As I said, frame loss and undetected bit corruption will produce gobbled speech,
which is pretty much similar to what you hear nowadays. So it's what cell phone users are
used to and is an acceptable error state. So our threat model. Who are we trying to
protect against? Of course, industrial espionage, foreign governments, anyone with $10,000
worth of equipment, and, of course, TLAs. Those damn TLAs. Three letter agencies, not
acronyms. What are we trying to protect against? Break of our privacy, loss of
confidentiality, break of authentication, loss of integrity. The threats in our threat model
are dropped frames, frame replay, frame bit corruption, partial frames, and, of course,
cryptographic attacks. So dropped frames, as I said earlier, we should be able to
deal with as we can detect and increment our counters for that. Frame replay will either
break the GSM, will either upset the GSM stack and break the call or will corrupt the
cryptographic channel, which will end up with an error state like the one we were talking
about moments ago. Bit corruption will just add slight blurbs or gobbled speech, which
shouldn't exactly deviate much from the error state as well. Partial frames will be
interesting. Probably end up corrupting the call as well or hopefully getting the GSM
call dropped. We're currently looking into that. Cryptographic attacks, those are the
fun ones, of course. We're hopefully picking strong enough crypto and strong enough
protocols so that these can be avoided. Of course, these are all closed source protocols.
I'm just kidding. Channel availability. Increasing the availability of GSM calls is really
kind of outside the scope of this project. It is ridiculously trivial to block GSM voice
channels, as you probably noticed from being inside casinos and getting no service. You
can purchase cell phone jammers, a lot of places have, for not too much money. You can
corrupt frames over the wire. You'd have to be a TLA to do that, probably. And you can also
just request from the service operator disables the voice channel or disables the account
altogether. So as you can see, it's not really practical for us to attempt to increase
availability of the voice channel. We're hoping, and it seems that channel will not
significantly decrease. The availability of the calls will not significantly decrease using
our scheme. Which is good. Secure channel. Secure channel provides voice privacy. It does not
provide message authentication. The reason being is we're working with a reasonably low
bandwidth and we don't have space for Macs or anything like that, sadly. So we're relying on
the authentication in the key exchange. And any manipulation of the data going over the air
will cause gobbled speech and will not break the cryptographic channel. Here is a wonderful
diagram of the initiation of the secure channel. Dig Helman, variable key size, being
hashed into our session key, into a send and receive key, and our two counters. Which you'll
see more of later. Here is a general diagram of our encryption model. This is for send, of
course. Session key is generating a send key through SHA, which is then used with AES and
a counter mode with our send counter. And I said before, when a frame is dropped, we will
have to increment the counter to stop from destroying the entire secure channel. Once the
key stream is generated, that is XORed with the voice data, which creates our cyber text,
which is passed off to the voice modem, the modulated data channel. There is many more
details in the white paper, which is available on the web page. Key exchange, we're
utilizing Ferguson Schneier key negotiation protocol, because it is a wonderfully strong
design. I like what Schneier and Ferguson have done. And the key size is flexible, which is
extremely key in this situation. We have two ends of this. We can have extremely limited
hardware, having a Bluetooth headset that's doing the voice encryption for you.
Extremely lightweight, and we need to save as much... use minimal CPU processing as
possible. And we have another end where you're running this on your laptop over your
generic landline. Not that any of you have a generic landline. So we want to have the
flexibility that that entails. The second choice was stationization protocol. I
definitely like the fact that you can encrypt the signatures in stationization, but it
lacks the key size flexibility, which really kind of killed it for me. Thanks for deleting
that slide, Wes. No problem. Oh, boy. Here's the key exchange. As described earlier, Alice
generating... I'm not even going to go into that. You can read details of that in the white
paper. I do want to make a comment on authentication. Most of the products and
the one even detailed by Zimmerman rely on you reading a section of text back over the
phone line to the other person to make sure the Diffie-Hellman key did not break. Sorry,
there was a man-in-the-middle attack on the Diffie-Hellman key exchange. I don't like
that. Not on a channel where you only have 2.4 kilobits of voice data going over. I
think the possibility of someone being able to spoof what your friend's voice sounds like on a
channel that's that low bitrate is quite possible, and that kind of scares me. So we're
attempting to use DSA for authentication rather than relying on the person reading the
keys back... sorry, reading the hash of the keys back over, which really kind of scares me.
Also, I think Cryptophone, G10 and the other products do that. They have better voice...
they have a higher bitrate voice encoding, which should make that not as easy an attack, but
it's still definitely possible, and that really kind of disturbs me. Conclusions and
questions? Also, if you have any questions via e-mail, we are available at info at
cellularcrypto.com, where the slides and all the other MATLAB code and Simulink code are for
your viewing pleasure. Also, the white paper will be up there momentarily, when I can
actually get onto the network. To reiterate, the point of this is to create a generic system
scheme. It will work over any type of voice link. It happens to be that GSM is pretty difficult
due to the large amount of compression. So if it works over GSM, it will work over anything
else. That's the idea, and that's what we are trying to do. Also, we only had about 50 minutes
to do this, and we had a lot of technical information that we had to gloss over, but
hopefully the point got across. It was hard for us to frame this in a way that people could
understand, just based upon the fact that a lot of it has to do with voice channel stuff.
It covers two areas, very complex GSM voice channel analysis and a voice modem, and then it
covers the cryptography. We attempted not to go into too much detail, but you can read the
majority of that on the white papers. We got a question, but we probably need a mic.
I'm not familiar with DECA. You, sir. We just tried, just for the demonstration purposes, a
test modem, basically just using the maximum amount of bits in that channel. If we were
sending data at the 13 kilobits per second, if you send data at 13 kilobits per second, you get
25% bit error. We need to generate a modem that is much more resilient to the distortion
involved. That probably implies using a lot less of the bandwidth available. Go ahead. No,
it's a work in progress. Yeah, we have not actually developed a 2.4 kilobit per second modem
as of yet. It's an ongoing process. We basically built the models to work on that kind of
design. We're at that point at the moment. Yes, we hope to have something that's usable.
Hopefully my graduate program will allow me to discover this stuff further and give me some
amount of funding. Good plan. Any more questions from the audience? You, sir.
In the back. I believe the question is, in our random test, how many bits were preserved?
We have a 25. If you use the entirety of the bits of the GSM frame and you twiddle those
randomly, you get one bit flipped out of every four. Those errors are basically distributed
evenly across the frame. There are some bits that are more persistent. They will stay. They will
not be as flipped as readily. For the most part, they are evenly distributed. I don't know if
that answers your question. Excellent. Any more questions? Closed. If anyone wants to talk
to us, we'll be in the bar for the rest of the week. Thank you. You've been a wonderful audience.
We love you. Especially you right there, lumpy lump. And Simon Cooper.
Fad. Total fad.
How's it going, mate?