1
00:00:00,000 --> 00:00:03,280
Thank you

2
00:00:10,020 --> 00:00:11,000
very much.

3
00:00:11,000 --> 00:00:12,420
Can everybody see me?

4
00:00:12,420 --> 00:00:14,680
Can everybody hear me?

5
00:00:15,820 --> 00:00:17,120
Awesome.

6
00:00:17,820 --> 00:00:20,980
This microphone is kind of sketchy, but we'll deal.

7
00:00:21,180 --> 00:00:30,000
Our presentation is end-to-end voice encryption over GSM, a different approach.

8
00:00:30,640 --> 00:00:39,240
We have Wesley Tanner, who is a systems engineer for Software Divine Radio Company and has a BS in EE from RPI.

9
00:00:39,240 --> 00:00:40,120
There's me.

10
00:00:42,400 --> 00:00:43,920
RPI in the house, I see.

11
00:00:44,260 --> 00:00:48,660
Me, I'm not really a security engineer, but it says it on the slide anyway.

12
00:00:49,480 --> 00:00:55,200
I'm an engineer for a computer company in Cupertino, BS in computer science from UCSB.

13
00:00:55,600 --> 00:00:59,980
And we have Keith, who isn't here sadly, also from RPI.

14
00:01:00,900 --> 00:01:03,340
We love you, Keith, wherever you are.

15
00:01:05,780 --> 00:01:07,340
Presentation overview.

16
00:01:08,300 --> 00:01:12,650
We're going to go over the motivation, the need for cellular crypto.

17
00:01:12,940 --> 00:01:15,480
Current market offerings.

18
00:01:16,340 --> 00:01:21,180
And our approach, a different approach to the GSM voice channel modem.

19
00:01:21,180 --> 00:01:27,240
We're going to go over the details, the radio interface, traditional telephone modems over GSM.

20
00:01:27,280 --> 00:01:30,680
Some of the design choices and issues we're facing.

21
00:01:30,680 --> 00:01:37,680
We're going to go into the cryptographic design and hopefully we'll have some demonstrations that won't fail miserably.

22
00:01:38,040 --> 00:01:39,140
It'll work.

23
00:01:39,380 --> 00:01:40,740
I have faith.

24
00:01:41,980 --> 00:01:43,180
Motivation.

25
00:01:43,340 --> 00:01:46,960
Where is the end-to-end voice protection over cellular?

26
00:01:48,080 --> 00:02:00,220
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.

27
00:02:00,220 --> 00:02:02,520
The number one being price.

28
00:02:02,960 --> 00:02:05,020
We'll get into that later.

29
00:02:05,180 --> 00:02:12,620
We want to make cryptographic cell phones available for the discerning privacy-conscious consumer.

30
00:02:12,680 --> 00:02:13,540
One sec.

31
00:02:13,540 --> 00:02:15,240
It's okay for photographs.

32
00:02:17,300 --> 00:02:18,840
Thanks, Wes.

33
00:02:18,900 --> 00:02:20,180
It's a requirement.

34
00:02:20,180 --> 00:02:21,980
We have to say it.

35
00:02:23,740 --> 00:02:25,380
That was awesome.

36
00:02:25,380 --> 00:02:28,920
Here is an image of the GSM network.

37
00:02:28,920 --> 00:02:30,200
We stole it from Wikipedia.

38
00:02:31,080 --> 00:02:36,120
The only thing we wanted to point out is that here is the handset and here is the base station.

39
00:02:36,120 --> 00:02:39,800
Those are the only two things you need to realize.

40
00:02:41,960 --> 00:02:43,400
GSM cryptography.

41
00:02:44,040 --> 00:02:45,540
You're probably reasonably familiar.

42
00:02:45,540 --> 00:02:47,860
We have the A3 algorithm for authentication.

43
00:02:47,860 --> 00:02:53,360
The A5 for the actual encryption of the voice channel, or attempts at that.

44
00:02:53,360 --> 00:02:57,200
And the A8, which is key generation.

45
00:03:00,380 --> 00:03:03,340
A5 has been broken horribly.

46
00:03:03,400 --> 00:03:07,540
You have no voice protection on GSM.

47
00:03:08,280 --> 00:03:11,480
Even if you did, it's only over the air.

48
00:03:11,480 --> 00:03:16,620
Once the data actually reaches the network, you're in clear text.

49
00:03:17,040 --> 00:03:18,660
That should be fun.

50
00:03:18,660 --> 00:03:22,900
As the slide says, the moral of the story.

51
00:03:23,240 --> 00:03:30,560
GSM cryptography provides limited, if any, security to your voice channel.

52
00:03:30,560 --> 00:03:32,240
Something else is needed.

53
00:03:32,240 --> 00:03:36,400
A cryptographic layer on top of that, or a cryptographic data channel.

54
00:03:38,480 --> 00:03:40,860
More on the need of cellular cryptography.

55
00:03:40,940 --> 00:03:45,280
Cellular phones have completely supplanted PSTN.

56
00:03:45,280 --> 00:03:48,360
I don't think that many people in here have landlines.

57
00:03:48,360 --> 00:03:51,480
I sure don't, and I don't really know anyone that does.

58
00:03:52,440 --> 00:03:56,800
The cellular companies do not provide meaningful protection for that traffic.

59
00:03:57,800 --> 00:04:04,400
And the ease of interception of voice data is kind of ridiculously easy, as we'll see later.

60
00:04:07,180 --> 00:04:09,160
Two major classes of intercept.

61
00:04:09,160 --> 00:04:11,260
The government-perpetrated intercept.

62
00:04:11,280 --> 00:04:14,900
The TLAs, authorized and unauthorized.

63
00:04:14,900 --> 00:04:19,420
I'm not sure I want to say that.

64
00:04:19,420 --> 00:04:21,940
Non-government-perpetrated, the more interesting ones.

65
00:04:21,940 --> 00:04:25,740
By private investigators, business partners, economic espionage and such.

66
00:04:25,740 --> 00:04:31,960
The product on the right is a device you can buy for a couple of thousand dollars.

67
00:04:33,340 --> 00:04:36,200
Yeah, these devices are relatively expensive.

68
00:04:36,200 --> 00:04:44,360
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.

69
00:04:44,360 --> 00:04:48,120
So it's going to become more of a reality for private intercepts.

70
00:04:49,940 --> 00:04:50,800
Thank you, Mr.

71
00:04:50,800 --> 00:04:51,440
Tanner.

72
00:04:53,400 --> 00:04:55,340
Government intercepts are probably the most common.

73
00:04:55,440 --> 00:04:56,320
Undetectable.

74
00:04:56,380 --> 00:04:57,800
Sadly, untraceable.

75
00:04:58,380 --> 00:05:00,660
Done on the higher levels of government.

76
00:05:02,020 --> 00:05:04,020
Data for the reported intercepts.

77
00:05:04,020 --> 00:05:06,400
In 2000, there were 1700 intercepts.

78
00:05:06,400 --> 00:05:07,740
That covers everything.

79
00:05:08,380 --> 00:05:10,740
1500 of those were portable devices.

80
00:05:10,740 --> 00:05:15,000
Cellular, telephones, satellite phones, etc.

81
00:05:15,260 --> 00:05:17,100
That's quite a large number.

82
00:05:18,040 --> 00:05:23,540
Here is a chart of the increase in cellular wildtaps.

83
00:05:23,540 --> 00:05:26,240
Actually, yes, cellular wildtaps, portable devices.

84
00:05:26,240 --> 00:05:31,460
As you notice, intercepts have doubled since 2000.

85
00:05:31,700 --> 00:05:34,500
The trend appears to show that it's increasing.

86
00:05:34,500 --> 00:05:36,940
You could probably all notice that from the last slide.

87
00:05:37,580 --> 00:05:42,500
What's interesting, though, is there's no massive jump after September 11th.

88
00:05:42,500 --> 00:05:45,000
We won't go all tinfoil hat on you.

89
00:05:45,000 --> 00:05:49,300
Which kind of implies they are obviously doing more wildtaps.

90
00:05:49,300 --> 00:05:51,860
So those aren't getting released in those numbers.

91
00:05:53,460 --> 00:05:57,940
There's also a GSM spec for lawful interception.

92
00:05:57,940 --> 00:05:59,180
That's kind of interesting.

93
00:05:59,260 --> 00:06:00,940
They make it rather easy.

94
00:06:00,940 --> 00:06:17,240
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.

95
00:06:18,060 --> 00:06:19,040
It's not.

96
00:06:19,980 --> 00:06:22,380
Here is a diagram of a lawful interception.

97
00:06:23,080 --> 00:06:29,980
Note the shady-looking law enforcement agent, the intercept request, and the data coming back to the LEA.

98
00:06:30,300 --> 00:06:31,640
Very interesting.

99
00:06:31,640 --> 00:06:42,980
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...

100
00:06:43,520 --> 00:06:51,960
Even if the voice, the over-the-air voice crypto is secure, you still have the over-the-wire cryptography.

101
00:06:52,180 --> 00:06:57,720
Sorry, over-the-wire cleartext, which is easily interceptable, as noted from the last diagram.

102
00:06:59,880 --> 00:07:01,080
What's that?

103
00:07:02,660 --> 00:07:06,500
There's a variety of products out there already that address this problem.

104
00:07:06,820 --> 00:07:12,360
And we got a chance to see the CryptoPhone guys present their products at Hope last year.

105
00:07:12,840 --> 00:07:13,720
Apologies.

106
00:07:13,720 --> 00:07:14,640
Is it better?

107
00:07:15,920 --> 00:07:18,000
The CryptoPhone guys presented their product.

108
00:07:18,000 --> 00:07:18,660
It's slick.

109
00:07:18,660 --> 00:07:21,460
I've never used it, but it does address this problem.

110
00:07:21,500 --> 00:07:26,520
There's the Sectera device by General Dynamics, and that's really used more...

111
00:07:26,520 --> 00:07:29,820
That's basically available to a military and government contract.

112
00:07:30,500 --> 00:07:33,140
There's the Ancord crypto smartphone.

113
00:07:33,320 --> 00:07:35,860
There's not a whole lot of information about this product out there.

114
00:07:35,860 --> 00:07:39,720
It's kind of a... Well, I was unable to find anything about it.

115
00:07:39,880 --> 00:07:41,900
And there's several other vapor products that have...

116
00:07:41,900 --> 00:07:47,260
Their web presence has gone up and down, and they're no longer available, so I can't say anything about those.

117
00:07:50,720 --> 00:07:51,160
There's...

118
00:07:55,080 --> 00:07:55,960
There's a government...

119
00:07:58,740 --> 00:08:09,280
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.

120
00:08:09,480 --> 00:08:12,420
It's the Future Narrowband Digital Terminal standard.

121
00:08:13,000 --> 00:08:17,820
This has a minimum requirement of 2,400 hertz for voice.

122
00:08:17,820 --> 00:08:25,740
This is very standard things like MELP for voice encryption, voice compression, and AES for voice encryption.

123
00:08:25,940 --> 00:08:28,300
And there's more data about this on Wikipedia.

124
00:08:31,840 --> 00:08:34,080
The problem with the current products...

125
00:08:35,180 --> 00:08:36,720
They all probably work very well.

126
00:08:36,720 --> 00:08:37,840
I've never used them.

127
00:08:38,060 --> 00:08:39,640
Oh, I've never seen them demonstrated.

128
00:08:39,640 --> 00:08:42,720
But they use the circuit-switched data channel.

129
00:08:44,160 --> 00:08:47,340
I was never offered this as part of my consumer package.

130
00:08:47,680 --> 00:08:53,480
And I think... I've heard that you need to pay roaming charges in some areas on this.

131
00:08:53,480 --> 00:08:56,140
So it's not as ubiquitous as the voice channel itself.

132
00:08:57,260 --> 00:09:01,100
There's longer call setup times associated with it, because it's a modem.

133
00:09:01,880 --> 00:09:04,060
It has to negotiate the connection.

134
00:09:04,060 --> 00:09:05,340
And there's a higher latency.

135
00:09:05,680 --> 00:09:12,520
But it's better than the packet-switched services that we use like GPRS for a typical internet over a cell phone.

136
00:09:12,520 --> 00:09:19,020
Also, if you can get circuit-switched data, it's usually rather expensive, which is kind of irritating.

137
00:09:21,200 --> 00:09:23,460
And it's meant to carry data, not voice.

138
00:09:23,460 --> 00:09:26,780
And data is not forgiving with bit error.

139
00:09:27,280 --> 00:09:28,420
And voice is.

140
00:09:28,420 --> 00:09:34,500
You can have large numbers of bit errors in your voice stream and have reasonable voice quality.

141
00:09:34,500 --> 00:09:36,560
So you don't need it to retransmit.

142
00:09:36,560 --> 00:09:37,760
And for data, you do.

143
00:09:42,160 --> 00:09:46,800
And the biggest problem is that these products are not available to you or me.

144
00:09:46,800 --> 00:09:47,460
They're very expensive.

145
00:09:47,460 --> 00:09:50,600
Or they're for military or government use only.

146
00:09:50,900 --> 00:09:53,740
And a solution should be available to you and me.

147
00:09:55,640 --> 00:09:58,260
3G will probably take care of a lot of these problems.

148
00:09:58,720 --> 00:10:01,380
Because it is a high bandwidth data.

149
00:10:01,500 --> 00:10:04,160
And the data suggests that it will be low latency as well.

150
00:10:04,160 --> 00:10:05,660
It hasn't been rolled out everywhere.

151
00:10:05,660 --> 00:10:07,100
It actually is in San Diego.

152
00:10:07,160 --> 00:10:08,400
And I believe San Francisco.

153
00:10:08,800 --> 00:10:10,220
I don't have it, but...

154
00:10:10,220 --> 00:10:13,720
It may solve the problems, but again, it's not available to everybody today.

155
00:10:15,320 --> 00:10:20,600
And we're proposing a solution, which is what we've been researching for the last couple months.

156
00:10:20,600 --> 00:10:29,600
It's developing a modem that will work over the 2G voice channel and the 3G voice channel.

157
00:10:30,240 --> 00:10:34,240
And it involves a bunch of technical disciplines, which makes it an interesting problem.

158
00:10:34,860 --> 00:10:37,880
And that's all I want to say about that.

159
00:10:38,120 --> 00:10:47,680
Basically, the voice channel on GSM is a subset of a generic voice channel.

160
00:10:48,280 --> 00:10:52,920
Basically, the tricky part about the GSM channel is that it's highly compressed.

161
00:10:53,020 --> 00:10:57,440
And if we get a product to work on the GSM channel, we can use it on anything.

162
00:10:57,440 --> 00:11:05,040
You can use it over 2-way radio, voice over IP, or normal packet switch telephone networks.

163
00:11:06,000 --> 00:11:11,100
And the goal is to have an integrated thing that works over all these protocols.

164
00:11:11,600 --> 00:11:12,640
All these systems.

165
00:11:12,800 --> 00:11:14,280
That's the goal.

166
00:11:15,100 --> 00:11:18,520
And this is the proposed system block diagram.

167
00:11:19,060 --> 00:11:21,500
I don't know if it's easy to read.

168
00:11:21,640 --> 00:11:32,800
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.

169
00:11:37,520 --> 00:11:48,880
The project goals are basically to maximize the voice quality and provide strong crypto for privacy.

170
00:11:49,120 --> 00:11:50,640
And to minimize the distortion.

171
00:11:50,640 --> 00:11:55,580
So you want to have good sounding quality audio and have it very secure.

172
00:11:59,820 --> 00:12:07,160
I'm going to blow through some of these quick because it's highly involved and takes too much time.

173
00:12:07,160 --> 00:12:13,340
But basically, the GSM voice channel is a low latency, highly available channel.

174
00:12:13,460 --> 00:12:14,940
It has a friendly billing system.

175
00:12:14,940 --> 00:12:20,900
You can use your minutes instead of more expensive data packages.

176
00:12:21,740 --> 00:12:29,080
However, the voice channel uses strong compression, which causes distortion for certain types of signals that you pass through it.

177
00:12:29,760 --> 00:12:34,140
And therefore, you need to pass through things that look like speech so they're not distorted.

178
00:12:35,600 --> 00:12:43,300
This is a pretty busy slide, but it's basically calculating the data rate over the GSM air interface.

179
00:12:43,940 --> 00:12:49,620
And this is a breakdown of the GSM voice frame by speech parameter.

180
00:12:49,980 --> 00:12:57,400
It works out to 13 kilobits per second and there's 260 bits per frame and those are sent every 20 milliseconds.

181
00:12:59,060 --> 00:13:11,320
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.

182
00:13:11,320 --> 00:13:15,240
And this just shows that there's an 8-to-1 compression.

183
00:13:15,240 --> 00:13:23,080
Your input on a typical GSM handset is 8 kilohertz sample rate audio at 13 significant bits.

184
00:13:23,080 --> 00:13:27,160
And that works out to an 8-to-1 compression when you go down to 13 kilobits per second.

185
00:13:28,320 --> 00:13:35,400
The official name of the 2G GSM voice channel is the top bit.

186
00:13:35,400 --> 00:13:42,800
It's a long way of saying that it uses a complicated compression to achieve its goal.

187
00:13:43,280 --> 00:13:48,120
And the input is PCM on a uniform quantized data.

188
00:13:49,120 --> 00:13:50,880
This is another busy slide.

189
00:13:51,240 --> 00:13:54,460
And this is from the 3GPP website.

190
00:13:54,460 --> 00:13:56,260
A lot of this data is available there.

191
00:13:57,320 --> 00:14:00,460
It's the voice encoder.

192
00:14:01,040 --> 00:14:08,580
Your speech samples go in on the left and the parameters that describe that speech come out on the right.

193
00:14:09,780 --> 00:14:12,200
And there's a bunch of complicated processing in the middle.

194
00:14:12,200 --> 00:14:13,680
It's highly nonlinear.

195
00:14:14,840 --> 00:14:17,680
And this is the speech decoder, the synthesizer.

196
00:14:17,680 --> 00:14:27,960
It takes those input parameters and spits out synthesized speech that's a very clear representation of what you originally put through the channel.

197
00:14:30,240 --> 00:14:31,860
I'm going to blow through this one.

198
00:14:31,860 --> 00:14:40,580
Basically, the processing involves short-term algorithms that determine what the short-term content is.

199
00:14:40,580 --> 00:14:43,840
There's a long-term prediction that gives you your lag and gain.

200
00:14:43,940 --> 00:14:48,800
And the coder also determines the pitch of your voice.

201
00:14:49,340 --> 00:14:52,240
And all this is fed through this coder.

202
00:14:52,240 --> 00:14:55,240
You get a residual error signal out, and that's also encoded.

203
00:14:55,240 --> 00:14:58,700
So all these parameters do a good job of representing speech.

204
00:15:00,620 --> 00:15:10,240
When the voice packets go over your GSM radio, some bits are protected from transmission errors, and some are not.

205
00:15:10,940 --> 00:15:12,660
The class A bits are.

206
00:15:12,940 --> 00:15:17,580
I think it's about 36 bits that are actually protected.

207
00:15:17,580 --> 00:15:19,200
Those are the most important bits.

208
00:15:19,200 --> 00:15:23,400
If you flip one of those, it's impossible to have intelligible speech.

209
00:15:23,400 --> 00:15:28,780
If the other bits are flipped, it's possible that you can actually understand the audio coming out of the phone.

210
00:15:29,780 --> 00:15:32,300
There's an RFC about this that goes into more detail.

211
00:15:34,300 --> 00:15:38,160
And this is a slide we threw in just showing a typical speech pattern.

212
00:15:39,020 --> 00:15:41,140
It has a pretty distinct shape.

213
00:15:41,140 --> 00:15:42,960
I'm sure a lot of you have seen that before.

214
00:15:43,100 --> 00:15:47,600
This is 8 kHz sampling rate, and it's about 6 seconds of audio.

215
00:15:48,480 --> 00:15:50,580
And this is a zoomed-in version.

216
00:15:50,580 --> 00:15:55,240
It shows that there's a certain pitch over the frame.

217
00:15:58,680 --> 00:16:06,200
And I always wondered why you couldn't use your traditional telephone modems over the GSM channel.

218
00:16:07,040 --> 00:16:10,000
So I'm going to talk about why this might not work.

219
00:16:10,780 --> 00:16:16,540
Your typical telephone modulation schemes are listed here in order of bit error.

220
00:16:16,540 --> 00:16:18,080
I mean, bit rate.

221
00:16:18,080 --> 00:16:24,860
There's the 300 all the way to the 56 kbit per second that we're pretty used to these days.

222
00:16:25,200 --> 00:16:27,980
And they're listed by modulation type as well.

223
00:16:27,980 --> 00:16:31,060
So they use different schemes to encode the audio.

224
00:16:33,020 --> 00:16:37,620
And I'll give a quick description of 56 kbit per second modem.

225
00:16:37,980 --> 00:16:44,320
It uses basically shaped voltages or pulses over your analog pair.

226
00:16:44,820 --> 00:16:48,060
And these represent bits that you're sending.

227
00:16:48,060 --> 00:16:51,820
And those are converted to digital signal when it gets to the telco office.

228
00:16:53,120 --> 00:16:58,140
These voltages are held on the line for 125 microseconds which is a pretty short amount of time.

229
00:16:58,180 --> 00:16:59,600
And there's 8 bits per pulse.

230
00:16:59,600 --> 00:17:02,780
So there's 256 discrete voltages that go over your line.

231
00:17:03,240 --> 00:17:05,740
And in North America, we use only 7.

232
00:17:05,740 --> 00:17:08,900
So we have 56 instead of 64 kbit per second.

233
00:17:08,900 --> 00:17:13,880
But in reality, the analog lines are not able to discriminate.

234
00:17:13,880 --> 00:17:16,160
It's hard to discriminate between the 256 levels.

235
00:17:16,160 --> 00:17:17,500
So they typically use less.

236
00:17:17,500 --> 00:17:19,960
And that's why it negotiates a slower connection.

237
00:17:21,560 --> 00:17:29,600
And this is a high level diagram of talking from one analog voice modem V.90 modem to another.

238
00:17:30,460 --> 00:17:31,780
And basically you can see the pulse.

239
00:17:31,780 --> 00:17:33,400
You go through analog.

240
00:17:33,400 --> 00:17:34,880
Comes out digital.

241
00:17:34,880 --> 00:17:36,200
Goes back analog.

242
00:17:39,350 --> 00:17:45,190
And one of the 1200 bit per second modems they use a phase modulation scheme.

243
00:17:45,190 --> 00:17:46,870
I just threw this one in.

244
00:17:46,870 --> 00:17:50,630
It's a simulink model of a PSK modulator.

245
00:17:51,810 --> 00:17:55,490
And it turns out that voice codecs are not...

246
00:17:55,490 --> 00:18:01,510
it's not important to preserve phase information for voice traffic.

247
00:18:01,510 --> 00:18:07,890
It's hard to perceive changes in phase and timing on voice.

248
00:18:09,510 --> 00:18:12,330
And so that information is not preserved over the channel.

249
00:18:12,430 --> 00:18:14,990
And this is what PSK kind of looks like.

250
00:18:14,990 --> 00:18:17,590
On the right is the time domain signal.

251
00:18:17,830 --> 00:18:20,810
And you can see that it's a sinusoidal shape.

252
00:18:21,090 --> 00:18:23,990
And there's discontinuities where we're adjusting the phase.

253
00:18:24,110 --> 00:18:25,530
One phase represents a zero.

254
00:18:25,530 --> 00:18:26,930
One phase represents a one.

255
00:18:27,210 --> 00:18:29,590
And the spectral content.

256
00:18:29,670 --> 00:18:31,510
You can see the bandwidth it takes up.

257
00:18:32,390 --> 00:18:35,290
So I'm blowing through these fast because I don't think we've got the time.

258
00:18:37,170 --> 00:18:39,550
I want to run a demo right quick.

259
00:18:41,010 --> 00:18:44,970
Of using frequency modulation over GSM.

260
00:18:45,050 --> 00:18:53,070
And what frequency modulation really is you're encoding one tone as a zero and another tone as a one.

261
00:18:53,070 --> 00:18:59,250
And those tones are flipped back and forth at a certain rate so that you send your data that way.

262
00:18:59,470 --> 00:19:04,050
And we're going to show how the GSM channel distorts that signal.

263
00:19:04,050 --> 00:19:06,810
Making it impossible to decode correctly.

264
00:19:20,440 --> 00:19:22,040
That would have been bad.

265
00:19:25,180 --> 00:19:27,120
Alright, this is a quick aside.

266
00:19:27,120 --> 00:19:30,720
We did our modeling and work in Simulink and MATLAB.

267
00:19:30,720 --> 00:19:35,840
It's a numeric processing tool that is pretty quick to prototype on.

268
00:19:36,200 --> 00:19:43,700
It allows you to rapidly throw something together and throw information at the channel and see how it behaves.

269
00:19:44,560 --> 00:19:49,600
The actual voice channel we're using our model came from the 3GPP website.

270
00:19:49,600 --> 00:19:51,580
They have all the reference code available.

271
00:19:52,080 --> 00:19:53,420
And so it's in C.

272
00:19:53,580 --> 00:19:57,000
It compiles basically on any architecture.

273
00:19:57,680 --> 00:20:01,780
And so we threw that code and put some glue into Simulink so we could model this.

274
00:20:08,190 --> 00:20:10,650
Alright, so this is running at 100 bits per second.

275
00:20:21,500 --> 00:20:22,680
Hold on right quick.

276
00:20:24,620 --> 00:20:31,500
This is the output special content going through the voice channel.

277
00:20:31,500 --> 00:20:34,720
But let me switch it over to the straight pass through.

278
00:20:35,140 --> 00:20:36,180
You can see the tones

279
00:20:40,800 --> 00:20:42,960
going back and forth between the 0 and the 1.

280
00:20:43,520 --> 00:20:46,460
Closer to the 0 is a 0.

281
00:20:46,460 --> 00:20:48,960
And further out in frequency is a 1.

282
00:20:48,960 --> 00:20:50,900
You can see them flipping back and forth.

283
00:20:51,040 --> 00:20:55,160
And you can basically determine at any given time which one is which.

284
00:20:55,160 --> 00:20:58,500
It's easy to discern when it's a 0 and when it's a 1.

285
00:20:59,940 --> 00:21:03,520
If you put this through the voice channel itself

286
00:21:06,560 --> 00:21:10,720
you can see that the pulses they look a little more distorted.

287
00:21:10,740 --> 00:21:17,380
It's harder to tell at any given time what the actual tone is going through there.

288
00:21:17,500 --> 00:21:22,520
There are these blips and blobs and it's harder to pick them out.

289
00:21:22,520 --> 00:21:27,580
That's just a visual representation of what kind of distortion you'd expect to see on this channel.

290
00:21:45,010 --> 00:21:58,810
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.

291
00:22:01,390 --> 00:22:05,490
There was a group in England, we discovered that is doing the very same thing.

292
00:22:05,750 --> 00:22:13,870
They've managed to get a 1200 bit per second link over GSM using a similar scheme.

293
00:22:14,310 --> 00:22:35,130
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.

294
00:22:35,450 --> 00:22:50,450
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.

295
00:22:51,130 --> 00:23:17,570
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.

296
00:23:18,470 --> 00:24:00,130
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,

297
00:24:00,130 --> 00:24:33,030
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

298
00:24:38,230 --> 00:24:42,850
this is showing Let's do the demo first.

299
00:24:44,630 --> 00:24:56,570
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.

300
00:24:56,570 --> 00:25:07,310
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.

301
00:25:07,310 --> 00:25:17,710
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.

302
00:25:38,680 --> 00:25:39,460
All right.

303
00:25:39,500 --> 00:25:48,320
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.

304
00:25:48,480 --> 00:26:00,080
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.

305
00:26:05,510 --> 00:26:08,730
This is what it looks like on the output.

306
00:26:09,310 --> 00:26:10,530
Again, this is random.

307
00:26:10,530 --> 00:26:16,130
We're filling the frames up randomly, and it's generating what looks like valid speech information.

308
00:26:16,130 --> 00:26:21,030
It looks a lot like what we saw earlier as far as what the time domain signal looks like.

309
00:26:27,100 --> 00:26:30,460
This scope shows the bit error rate through the channel.

310
00:26:30,460 --> 00:26:32,700
I'll run this one more time so you can see it settling.

311
00:26:32,700 --> 00:26:47,340
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.

312
00:26:51,040 --> 00:26:52,320
Let's run this again.

313
00:26:53,260 --> 00:26:54,700
Oh, it's very angry at me.

314
00:27:04,240 --> 00:27:05,780
I don't even know what that means.

315
00:27:05,780 --> 00:27:10,880
Anyway, the point being the bit error rate settles to about 25%.

316
00:27:10,880 --> 00:27:16,060
One bit out of four is flipped when you put it through using a rudimentary system like this.

317
00:27:16,100 --> 00:27:27,320
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.

318
00:27:27,320 --> 00:27:31,200
25% is far too high to pass meaningful data through.

319
00:27:33,180 --> 00:27:35,920
MATLAB for Mac is not very good either, by the way.

320
00:27:37,340 --> 00:27:39,680
A side note on that, there's a free MATLAB.

321
00:27:39,680 --> 00:27:41,280
I don't know if you guys know about Octave.

322
00:27:41,280 --> 00:27:45,920
It's basically MATLAB minus the $100,000 fee.

323
00:27:46,520 --> 00:27:48,320
It's available online.

324
00:27:48,520 --> 00:27:50,680
You can search Google for Octave.

325
00:27:55,720 --> 00:27:56,620
Thank you, Mr.

326
00:27:56,620 --> 00:27:57,280
Tanner.

327
00:27:57,480 --> 00:28:05,180
I want to take a slight segway for a second and go back to what he was saying about 3G solving this issue.

328
00:28:05,280 --> 00:28:26,120
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.

329
00:28:26,360 --> 00:28:33,000
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.

330
00:28:33,140 --> 00:28:43,940
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.

331
00:28:44,060 --> 00:28:48,660
The secure channel, which we'll go into in just a moment.

332
00:28:48,840 --> 00:28:53,420
The modulated data channel, which is the voice modem and the ECC.

333
00:28:56,240 --> 00:29:02,440
And those are all on top of the GSM voice channel and, of course, the GSM network.

334
00:29:03,740 --> 00:29:05,720
Otherwise the bits wouldn't go anywhere.

335
00:29:07,020 --> 00:29:09,040
Channel expectations.

336
00:29:09,780 --> 00:29:17,640
We had to make some decisions and do some research on what we could expect the lower levels to behave like.

337
00:29:18,480 --> 00:29:21,340
Detected and fixed bit corruption will be common.

338
00:29:21,340 --> 00:29:26,120
Undetected bit corruption will be rare, but we'll deal with that.

339
00:29:26,180 --> 00:29:32,720
Undetected frame loss depends on network quality and is reasonably common.

340
00:29:32,720 --> 00:29:38,320
You most likely hear dropped frames during your cell phone conversations all the time.

341
00:29:38,720 --> 00:29:42,160
We hope to have no undetected frame loss.

342
00:29:44,380 --> 00:29:52,540
As I said, frame loss and undetected bit corruption will produce gobbled speech, which is pretty much similar to what you hear nowadays.

343
00:29:52,560 --> 00:29:58,340
So it's what cell phone users are used to and is an acceptable error state.

344
00:30:02,330 --> 00:30:04,130
So our threat model.

345
00:30:04,730 --> 00:30:07,030
Who are we trying to protect against?

346
00:30:07,050 --> 00:30:17,270
Of course, industrial espionage, foreign governments, anyone with $10,000 worth of equipment, and, of course, TLAs.

347
00:30:17,270 --> 00:30:19,750
Those damn TLAs.

348
00:30:20,410 --> 00:30:22,790
Three letter agencies, not acronyms.

349
00:30:22,870 --> 00:30:24,510
What are we trying to protect against?

350
00:30:24,510 --> 00:30:31,990
Break of our privacy, loss of confidentiality, break of authentication, loss of integrity.

351
00:30:33,470 --> 00:30:43,570
The threats in our threat model are dropped frames, frame replay, frame bit corruption, partial frames, and, of course, cryptographic attacks.

352
00:30:47,510 --> 00:30:57,290
So dropped frames, as I said earlier, we should be able to deal with as we can detect and increment our counters for that.

353
00:30:57,490 --> 00:31:13,210
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.

354
00:31:13,350 --> 00:31:22,530
Bit corruption will just add slight blurbs or gobbled speech, which shouldn't exactly deviate much from the error state as well.

355
00:31:22,530 --> 00:31:24,650
Partial frames will be interesting.

356
00:31:24,650 --> 00:31:30,750
Probably end up corrupting the call as well or hopefully getting the GSM call dropped.

357
00:31:30,750 --> 00:31:32,230
We're currently looking into that.

358
00:31:32,230 --> 00:31:36,590
Cryptographic attacks, those are the fun ones, of course.

359
00:31:36,590 --> 00:31:46,010
We're hopefully picking strong enough crypto and strong enough protocols so that these can be avoided.

360
00:31:46,450 --> 00:31:49,490
Of course, these are all closed source protocols.

361
00:31:49,490 --> 00:31:51,050
I'm just kidding.

362
00:31:51,250 --> 00:31:53,150
Channel availability.

363
00:31:53,270 --> 00:32:00,390
Increasing the availability of GSM calls is really kind of outside the scope of this project.

364
00:32:00,390 --> 00:32:10,070
It is ridiculously trivial to block GSM voice channels, as you probably noticed from being inside casinos and getting no service.

365
00:32:10,070 --> 00:32:15,830
You can purchase cell phone jammers, a lot of places have, for not too much money.

366
00:32:15,830 --> 00:32:18,710
You can corrupt frames over the wire.

367
00:32:19,530 --> 00:32:21,770
You'd have to be a TLA to do that, probably.

368
00:32:21,990 --> 00:32:28,830
And you can also just request from the service operator disables the voice channel or disables the account altogether.

369
00:32:30,550 --> 00:32:38,230
So as you can see, it's not really practical for us to attempt to increase availability of the voice channel.

370
00:32:38,530 --> 00:32:44,670
We're hoping, and it seems that channel will not significantly decrease.

371
00:32:44,670 --> 00:32:52,190
The availability of the calls will not significantly decrease using our scheme.

372
00:32:52,590 --> 00:32:53,710
Which is good.

373
00:32:53,910 --> 00:32:54,990
Secure channel.

374
00:32:54,990 --> 00:32:57,430
Secure channel provides voice privacy.

375
00:32:57,430 --> 00:33:00,670
It does not provide message authentication.

376
00:33:00,770 --> 00:33:09,150
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.

377
00:33:09,270 --> 00:33:12,970
So we're relying on the authentication in the key exchange.

378
00:33:12,970 --> 00:33:26,570
And any manipulation of the data going over the air will cause gobbled speech and will not break the cryptographic channel.

379
00:33:27,410 --> 00:33:32,010
Here is a wonderful diagram of the initiation of the secure channel.

380
00:33:32,170 --> 00:33:41,350
Dig Helman, variable key size, being hashed into our session key, into a send and receive key, and our two counters.

381
00:33:42,030 --> 00:33:43,930
Which you'll see more of later.

382
00:33:44,530 --> 00:33:48,610
Here is a general diagram of our encryption model.

383
00:33:49,770 --> 00:33:51,450
This is for send, of course.

384
00:33:51,750 --> 00:34:00,970
Session key is generating a send key through SHA, which is then used with AES and a counter mode with our send counter.

385
00:34:01,410 --> 00:34:10,090
And I said before, when a frame is dropped, we will have to increment the counter to stop from destroying the entire secure channel.

386
00:34:10,510 --> 00:34:21,590
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.

387
00:34:22,210 --> 00:34:27,090
There is many more details in the white paper, which is available on the web page.

388
00:34:28,470 --> 00:34:35,690
Key exchange, we're utilizing Ferguson Schneier key negotiation protocol, because it is a wonderfully strong design.

389
00:34:36,130 --> 00:34:39,270
I like what Schneier and Ferguson have done.

390
00:34:39,290 --> 00:34:43,550
And the key size is flexible, which is extremely key in this situation.

391
00:34:43,550 --> 00:34:45,830
We have two ends of this.

392
00:34:45,830 --> 00:34:52,510
We can have extremely limited hardware, having a Bluetooth headset that's doing the voice encryption for you.

393
00:34:52,510 --> 00:34:59,570
Extremely lightweight, and we need to save as much... use minimal CPU processing as possible.

394
00:34:59,570 --> 00:35:05,170
And we have another end where you're running this on your laptop over your generic landline.

395
00:35:05,170 --> 00:35:07,230
Not that any of you have a generic landline.

396
00:35:07,230 --> 00:35:11,970
So we want to have the flexibility that that entails.

397
00:35:11,970 --> 00:35:14,350
The second choice was stationization protocol.

398
00:35:15,230 --> 00:35:24,820
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.

399
00:35:26,500 --> 00:35:29,280
Thanks for deleting that slide, Wes.

400
00:35:29,480 --> 00:35:30,620
No problem.

401
00:35:32,880 --> 00:35:34,220
Oh, boy.

402
00:35:35,880 --> 00:35:37,600
Here's the key exchange.

403
00:35:38,060 --> 00:35:44,000
As described earlier, Alice generating... I'm not even going to go into that.

404
00:35:44,000 --> 00:35:46,740
You can read details of that in the white paper.

405
00:35:46,880 --> 00:35:48,740
I do want to make a comment on authentication.

406
00:35:48,740 --> 00:36:07,140
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.

407
00:36:07,740 --> 00:36:11,500
Sorry, there was a man-in-the-middle attack on the Diffie-Hellman key exchange.

408
00:36:11,920 --> 00:36:13,560
I don't like that.

409
00:36:13,560 --> 00:36:19,400
Not on a channel where you only have 2.4 kilobits of voice data going over.

410
00:36:19,980 --> 00:36:36,380
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.

411
00:36:36,380 --> 00:36:52,980
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.

412
00:36:52,980 --> 00:36:57,940
Also, I think Cryptophone, G10 and the other products do that.

413
00:36:58,500 --> 00:37:02,440
They have better voice...

414
00:37:03,060 --> 00:37:12,460
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.

415
00:37:13,800 --> 00:37:15,460
Conclusions and questions?

416
00:37:17,580 --> 00:37:29,840
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.

417
00:37:29,840 --> 00:37:35,880
Also, the white paper will be up there momentarily, when I can actually get onto the network.

418
00:37:37,000 --> 00:37:45,400
To reiterate, the point of this is to create a generic system scheme.

419
00:37:45,620 --> 00:37:47,900
It will work over any type of voice link.

420
00:37:48,100 --> 00:37:52,580
It happens to be that GSM is pretty difficult due to the large amount of compression.

421
00:37:53,520 --> 00:37:56,200
So if it works over GSM, it will work over anything else.

422
00:37:56,920 --> 00:38:00,340
That's the idea, and that's what we are trying to do.

423
00:38:04,560 --> 00:38:14,720
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.

424
00:38:16,020 --> 00:38:23,980
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.

425
00:38:24,280 --> 00:38:35,280
It covers two areas, very complex GSM voice channel analysis and a voice modem, and then it covers the cryptography.

426
00:38:35,280 --> 00:38:41,360
We attempted not to go into too much detail, but you can read the majority of that on the white papers.

427
00:38:41,980 --> 00:38:44,300
We got a question, but we probably need a mic.

428
00:38:56,160 --> 00:38:58,720
I'm not familiar with DECA.

429
00:39:00,540 --> 00:39:01,920
You, sir.

430
00:39:13,480 --> 00:39:22,980
We just tried, just for the demonstration purposes, a test modem, basically just using the maximum amount of bits in that channel.

431
00:39:22,980 --> 00:39:30,520
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.

432
00:39:30,820 --> 00:39:37,960
We need to generate a modem that is much more resilient to the distortion involved.

433
00:39:37,960 --> 00:39:42,280
That probably implies using a lot less of the bandwidth available.

434
00:39:43,820 --> 00:39:45,300
Go ahead.

435
00:39:50,130 --> 00:39:52,030
No, it's a work in progress.

436
00:39:53,130 --> 00:39:56,670
Yeah, we have not actually developed a 2.4 kilobit per second modem as of yet.

437
00:39:56,730 --> 00:39:58,630
It's an ongoing process.

438
00:39:58,630 --> 00:40:02,750
We basically built the models to work on that kind of design.

439
00:40:02,750 --> 00:40:04,190
We're at that point at the moment.

440
00:40:06,570 --> 00:40:10,190
Yes, we hope to have something that's usable.

441
00:40:11,470 --> 00:40:17,890
Hopefully my graduate program will allow me to discover this stuff further and give me some amount of funding.

442
00:40:19,030 --> 00:40:20,350
Good plan.

443
00:40:21,550 --> 00:40:23,730
Any more questions from the audience?

444
00:40:25,730 --> 00:40:25,910
You, sir.

445
00:40:25,930 --> 00:40:26,710
In the back.

446
00:40:48,090 --> 00:40:52,970
I believe the question is, in our random test, how many bits were preserved?

447
00:41:07,160 --> 00:41:08,020
We have a 25.

448
00:41:08,020 --> 00:41:15,260
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.

449
00:41:15,880 --> 00:41:19,260
Those errors are basically distributed evenly across the frame.

450
00:41:19,260 --> 00:41:22,100
There are some bits that are more persistent.

451
00:41:22,140 --> 00:41:22,860
They will stay.

452
00:41:22,860 --> 00:41:24,420
They will not be as flipped as readily.

453
00:41:24,480 --> 00:41:26,860
For the most part, they are evenly distributed.

454
00:41:28,240 --> 00:41:29,700
I don't know if that answers your question.

455
00:41:30,840 --> 00:41:31,640
Excellent.

456
00:41:31,740 --> 00:41:32,940
Any more questions?

457
00:41:34,900 --> 00:41:35,700
Closed.

458
00:41:36,060 --> 00:41:41,840
If anyone wants to talk to us, we'll be in the bar for the rest of the week.

459
00:41:43,280 --> 00:41:43,960
Thank you.

460
00:41:43,960 --> 00:41:45,220
You've been a wonderful audience.

461
00:41:45,220 --> 00:41:46,180
We love you.

462
00:41:47,280 --> 00:41:49,360
Especially you right there, lumpy lump.

463
00:41:50,220 --> 00:41:51,540
And Simon Cooper.

464
00:41:53,100 --> 00:41:53,960
Fad.

465
00:41:53,960 --> 00:41:55,240
Total fad.

466
00:41:56,000 --> 00:41:57,160
How's it going, mate?