WEBVTT 00:00.000 --> 00:03.280 Thank you 00:10.020 --> 00:11.000 very much. 00:11.000 --> 00:12.420 Can everybody see me? 00:12.420 --> 00:14.680 Can everybody hear me? 00:15.820 --> 00:17.120 Awesome. 00:17.820 --> 00:20.980 This microphone is kind of sketchy, but we'll deal. 00:21.180 --> 00:30.000 Our presentation is end-to-end voice encryption over GSM, a different approach. 00:30.640 --> 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. 00:39.240 --> 00:40.120 There's me. 00:42.400 --> 00:43.920 RPI in the house, I see. 00:44.260 --> 00:48.660 Me, I'm not really a security engineer, but it says it on the slide anyway. 00:49.480 --> 00:55.200 I'm an engineer for a computer company in Cupertino, BS in computer science from UCSB. 00:55.600 --> 00:59.980 And we have Keith, who isn't here sadly, also from RPI. 01:00.900 --> 01:03.340 We love you, Keith, wherever you are. 01:05.780 --> 01:07.340 Presentation overview. 01:08.300 --> 01:12.650 We're going to go over the motivation, the need for cellular crypto. 01:12.940 --> 01:15.480 Current market offerings. 01:16.340 --> 01:21.180 And our approach, a different approach to the GSM voice channel modem. 01:21.180 --> 01:27.240 We're going to go over the details, the radio interface, traditional telephone modems over GSM. 01:27.280 --> 01:30.680 Some of the design choices and issues we're facing. 01:30.680 --> 01:37.680 We're going to go into the cryptographic design and hopefully we'll have some demonstrations that won't fail miserably. 01:38.040 --> 01:39.140 It'll work. 01:39.380 --> 01:40.740 I have faith. 01:41.980 --> 01:43.180 Motivation. 01:43.340 --> 01:46.960 Where is the end-to-end voice protection over cellular? 01:48.080 --> 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. 02:00.220 --> 02:02.520 The number one being price. 02:02.960 --> 02:05.020 We'll get into that later. 02:05.180 --> 02:12.620 We want to make cryptographic cell phones available for the discerning privacy-conscious consumer. 02:12.680 --> 02:13.540 One sec. 02:13.540 --> 02:15.240 It's okay for photographs. 02:17.300 --> 02:18.840 Thanks, Wes. 02:18.900 --> 02:20.180 It's a requirement. 02:20.180 --> 02:21.980 We have to say it. 02:23.740 --> 02:25.380 That was awesome. 02:25.380 --> 02:28.920 Here is an image of the GSM network. 02:28.920 --> 02:30.200 We stole it from Wikipedia. 02:31.080 --> 02:36.120 The only thing we wanted to point out is that here is the handset and here is the base station. 02:36.120 --> 02:39.800 Those are the only two things you need to realize. 02:41.960 --> 02:43.400 GSM cryptography. 02:44.040 --> 02:45.540 You're probably reasonably familiar. 02:45.540 --> 02:47.860 We have the A3 algorithm for authentication. 02:47.860 --> 02:53.360 The A5 for the actual encryption of the voice channel, or attempts at that. 02:53.360 --> 02:57.200 And the A8, which is key generation. 03:00.380 --> 03:03.340 A5 has been broken horribly. 03:03.400 --> 03:07.540 You have no voice protection on GSM. 03:08.280 --> 03:11.480 Even if you did, it's only over the air. 03:11.480 --> 03:16.620 Once the data actually reaches the network, you're in clear text. 03:17.040 --> 03:18.660 That should be fun. 03:18.660 --> 03:22.900 As the slide says, the moral of the story. 03:23.240 --> 03:30.560 GSM cryptography provides limited, if any, security to your voice channel. 03:30.560 --> 03:32.240 Something else is needed. 03:32.240 --> 03:36.400 A cryptographic layer on top of that, or a cryptographic data channel. 03:38.480 --> 03:40.860 More on the need of cellular cryptography. 03:40.940 --> 03:45.280 Cellular phones have completely supplanted PSTN. 03:45.280 --> 03:48.360 I don't think that many people in here have landlines. 03:48.360 --> 03:51.480 I sure don't, and I don't really know anyone that does. 03:52.440 --> 03:56.800 The cellular companies do not provide meaningful protection for that traffic. 03:57.800 --> 04:04.400 And the ease of interception of voice data is kind of ridiculously easy, as we'll see later. 04:07.180 --> 04:09.160 Two major classes of intercept. 04:09.160 --> 04:11.260 The government-perpetrated intercept. 04:11.280 --> 04:14.900 The TLAs, authorized and unauthorized. 04:14.900 --> 04:19.420 I'm not sure I want to say that. 04:19.420 --> 04:21.940 Non-government-perpetrated, the more interesting ones. 04:21.940 --> 04:25.740 By private investigators, business partners, economic espionage and such. 04:25.740 --> 04:31.960 The product on the right is a device you can buy for a couple of thousand dollars. 04:33.340 --> 04:36.200 Yeah, these devices are relatively expensive. 04:36.200 --> 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. 04:44.360 --> 04:48.120 So it's going to become more of a reality for private intercepts. 04:49.940 --> 04:50.800 Thank you, Mr. 04:50.800 --> 04:51.440 Tanner. 04:53.400 --> 04:55.340 Government intercepts are probably the most common. 04:55.440 --> 04:56.320 Undetectable. 04:56.380 --> 04:57.800 Sadly, untraceable. 04:58.380 --> 05:00.660 Done on the higher levels of government. 05:02.020 --> 05:04.020 Data for the reported intercepts. 05:04.020 --> 05:06.400 In 2000, there were 1700 intercepts. 05:06.400 --> 05:07.740 That covers everything. 05:08.380 --> 05:10.740 1500 of those were portable devices. 05:10.740 --> 05:15.000 Cellular, telephones, satellite phones, etc. 05:15.260 --> 05:17.100 That's quite a large number. 05:18.040 --> 05:23.540 Here is a chart of the increase in cellular wildtaps. 05:23.540 --> 05:26.240 Actually, yes, cellular wildtaps, portable devices. 05:26.240 --> 05:31.460 As you notice, intercepts have doubled since 2000. 05:31.700 --> 05:34.500 The trend appears to show that it's increasing. 05:34.500 --> 05:36.940 You could probably all notice that from the last slide. 05:37.580 --> 05:42.500 What's interesting, though, is there's no massive jump after September 11th. 05:42.500 --> 05:45.000 We won't go all tinfoil hat on you. 05:45.000 --> 05:49.300 Which kind of implies they are obviously doing more wildtaps. 05:49.300 --> 05:51.860 So those aren't getting released in those numbers. 05:53.460 --> 05:57.940 There's also a GSM spec for lawful interception. 05:57.940 --> 05:59.180 That's kind of interesting. 05:59.260 --> 06:00.940 They make it rather easy. 06:00.940 --> 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. 06:18.060 --> 06:19.040 It's not. 06:19.980 --> 06:22.380 Here is a diagram of a lawful interception. 06:23.080 --> 06:29.980 Note the shady-looking law enforcement agent, the intercept request, and the data coming back to the LEA. 06:30.300 --> 06:31.640 Very interesting. 06:31.640 --> 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... 06:43.520 --> 06:51.960 Even if the voice, the over-the-air voice crypto is secure, you still have the over-the-wire cryptography. 06:52.180 --> 06:57.720 Sorry, over-the-wire cleartext, which is easily interceptable, as noted from the last diagram. 06:59.880 --> 07:01.080 What's that? 07:02.660 --> 07:06.500 There's a variety of products out there already that address this problem. 07:06.820 --> 07:12.360 And we got a chance to see the CryptoPhone guys present their products at Hope last year. 07:12.840 --> 07:13.720 Apologies. 07:13.720 --> 07:14.640 Is it better? 07:15.920 --> 07:18.000 The CryptoPhone guys presented their product. 07:18.000 --> 07:18.660 It's slick. 07:18.660 --> 07:21.460 I've never used it, but it does address this problem. 07:21.500 --> 07:26.520 There's the Sectera device by General Dynamics, and that's really used more... 07:26.520 --> 07:29.820 That's basically available to a military and government contract. 07:30.500 --> 07:33.140 There's the Ancord crypto smartphone. 07:33.320 --> 07:35.860 There's not a whole lot of information about this product out there. 07:35.860 --> 07:39.720 It's kind of a... Well, I was unable to find anything about it. 07:39.880 --> 07:41.900 And there's several other vapor products that have... 07:41.900 --> 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. 07:50.720 --> 07:51.160 There's... 07:55.080 --> 07:55.960 There's a government... 07:58.740 --> 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. 08:09.480 --> 08:12.420 It's the Future Narrowband Digital Terminal standard. 08:13.000 --> 08:17.820 This has a minimum requirement of 2,400 hertz for voice. 08:17.820 --> 08:25.740 This is very standard things like MELP for voice encryption, voice compression, and AES for voice encryption. 08:25.940 --> 08:28.300 And there's more data about this on Wikipedia. 08:31.840 --> 08:34.080 The problem with the current products... 08:35.180 --> 08:36.720 They all probably work very well. 08:36.720 --> 08:37.840 I've never used them. 08:38.060 --> 08:39.640 Oh, I've never seen them demonstrated. 08:39.640 --> 08:42.720 But they use the circuit-switched data channel. 08:44.160 --> 08:47.340 I was never offered this as part of my consumer package. 08:47.680 --> 08:53.480 And I think... I've heard that you need to pay roaming charges in some areas on this. 08:53.480 --> 08:56.140 So it's not as ubiquitous as the voice channel itself. 08:57.260 --> 09:01.100 There's longer call setup times associated with it, because it's a modem. 09:01.880 --> 09:04.060 It has to negotiate the connection. 09:04.060 --> 09:05.340 And there's a higher latency. 09:05.680 --> 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. 09:12.520 --> 09:19.020 Also, if you can get circuit-switched data, it's usually rather expensive, which is kind of irritating. 09:21.200 --> 09:23.460 And it's meant to carry data, not voice. 09:23.460 --> 09:26.780 And data is not forgiving with bit error. 09:27.280 --> 09:28.420 And voice is. 09:28.420 --> 09:34.500 You can have large numbers of bit errors in your voice stream and have reasonable voice quality. 09:34.500 --> 09:36.560 So you don't need it to retransmit. 09:36.560 --> 09:37.760 And for data, you do. 09:42.160 --> 09:46.800 And the biggest problem is that these products are not available to you or me. 09:46.800 --> 09:47.460 They're very expensive. 09:47.460 --> 09:50.600 Or they're for military or government use only. 09:50.900 --> 09:53.740 And a solution should be available to you and me. 09:55.640 --> 09:58.260 3G will probably take care of a lot of these problems. 09:58.720 --> 10:01.380 Because it is a high bandwidth data. 10:01.500 --> 10:04.160 And the data suggests that it will be low latency as well. 10:04.160 --> 10:05.660 It hasn't been rolled out everywhere. 10:05.660 --> 10:07.100 It actually is in San Diego. 10:07.160 --> 10:08.400 And I believe San Francisco. 10:08.800 --> 10:10.220 I don't have it, but... 10:10.220 --> 10:13.720 It may solve the problems, but again, it's not available to everybody today. 10:15.320 --> 10:20.600 And we're proposing a solution, which is what we've been researching for the last couple months. 10:20.600 --> 10:29.600 It's developing a modem that will work over the 2G voice channel and the 3G voice channel. 10:30.240 --> 10:34.240 And it involves a bunch of technical disciplines, which makes it an interesting problem. 10:34.860 --> 10:37.880 And that's all I want to say about that. 10:38.120 --> 10:47.680 Basically, the voice channel on GSM is a subset of a generic voice channel. 10:48.280 --> 10:52.920 Basically, the tricky part about the GSM channel is that it's highly compressed. 10:53.020 --> 10:57.440 And if we get a product to work on the GSM channel, we can use it on anything. 10:57.440 --> 11:05.040 You can use it over 2-way radio, voice over IP, or normal packet switch telephone networks. 11:06.000 --> 11:11.100 And the goal is to have an integrated thing that works over all these protocols. 11:11.600 --> 11:12.640 All these systems. 11:12.800 --> 11:14.280 That's the goal. 11:15.100 --> 11:18.520 And this is the proposed system block diagram. 11:19.060 --> 11:21.500 I don't know if it's easy to read. 11:21.640 --> 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. 11:37.520 --> 11:48.880 The project goals are basically to maximize the voice quality and provide strong crypto for privacy. 11:49.120 --> 11:50.640 And to minimize the distortion. 11:50.640 --> 11:55.580 So you want to have good sounding quality audio and have it very secure. 11:59.820 --> 12:07.160 I'm going to blow through some of these quick because it's highly involved and takes too much time. 12:07.160 --> 12:13.340 But basically, the GSM voice channel is a low latency, highly available channel. 12:13.460 --> 12:14.940 It has a friendly billing system. 12:14.940 --> 12:20.900 You can use your minutes instead of more expensive data packages. 12:21.740 --> 12:29.080 However, the voice channel uses strong compression, which causes distortion for certain types of signals that you pass through it. 12:29.760 --> 12:34.140 And therefore, you need to pass through things that look like speech so they're not distorted. 12:35.600 --> 12:43.300 This is a pretty busy slide, but it's basically calculating the data rate over the GSM air interface. 12:43.940 --> 12:49.620 And this is a breakdown of the GSM voice frame by speech parameter. 12:49.980 --> 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. 12:59.060 --> 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. 13:11.320 --> 13:15.240 And this just shows that there's an 8-to-1 compression. 13:15.240 --> 13:23.080 Your input on a typical GSM handset is 8 kilohertz sample rate audio at 13 significant bits. 13:23.080 --> 13:27.160 And that works out to an 8-to-1 compression when you go down to 13 kilobits per second. 13:28.320 --> 13:35.400 The official name of the 2G GSM voice channel is the top bit. 13:35.400 --> 13:42.800 It's a long way of saying that it uses a complicated compression to achieve its goal. 13:43.280 --> 13:48.120 And the input is PCM on a uniform quantized data. 13:49.120 --> 13:50.880 This is another busy slide. 13:51.240 --> 13:54.460 And this is from the 3GPP website. 13:54.460 --> 13:56.260 A lot of this data is available there. 13:57.320 --> 14:00.460 It's the voice encoder. 14:01.040 --> 14:08.580 Your speech samples go in on the left and the parameters that describe that speech come out on the right. 14:09.780 --> 14:12.200 And there's a bunch of complicated processing in the middle. 14:12.200 --> 14:13.680 It's highly nonlinear. 14:14.840 --> 14:17.680 And this is the speech decoder, the synthesizer. 14:17.680 --> 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. 14:30.240 --> 14:31.860 I'm going to blow through this one. 14:31.860 --> 14:40.580 Basically, the processing involves short-term algorithms that determine what the short-term content is. 14:40.580 --> 14:43.840 There's a long-term prediction that gives you your lag and gain. 14:43.940 --> 14:48.800 And the coder also determines the pitch of your voice. 14:49.340 --> 14:52.240 And all this is fed through this coder. 14:52.240 --> 14:55.240 You get a residual error signal out, and that's also encoded. 14:55.240 --> 14:58.700 So all these parameters do a good job of representing speech. 15:00.620 --> 15:10.240 When the voice packets go over your GSM radio, some bits are protected from transmission errors, and some are not. 15:10.940 --> 15:12.660 The class A bits are. 15:12.940 --> 15:17.580 I think it's about 36 bits that are actually protected. 15:17.580 --> 15:19.200 Those are the most important bits. 15:19.200 --> 15:23.400 If you flip one of those, it's impossible to have intelligible speech. 15:23.400 --> 15:28.780 If the other bits are flipped, it's possible that you can actually understand the audio coming out of the phone. 15:29.780 --> 15:32.300 There's an RFC about this that goes into more detail. 15:34.300 --> 15:38.160 And this is a slide we threw in just showing a typical speech pattern. 15:39.020 --> 15:41.140 It has a pretty distinct shape. 15:41.140 --> 15:42.960 I'm sure a lot of you have seen that before. 15:43.100 --> 15:47.600 This is 8 kHz sampling rate, and it's about 6 seconds of audio. 15:48.480 --> 15:50.580 And this is a zoomed-in version. 15:50.580 --> 15:55.240 It shows that there's a certain pitch over the frame. 15:58.680 --> 16:06.200 And I always wondered why you couldn't use your traditional telephone modems over the GSM channel. 16:07.040 --> 16:10.000 So I'm going to talk about why this might not work. 16:10.780 --> 16:16.540 Your typical telephone modulation schemes are listed here in order of bit error. 16:16.540 --> 16:18.080 I mean, bit rate. 16:18.080 --> 16:24.860 There's the 300 all the way to the 56 kbit per second that we're pretty used to these days. 16:25.200 --> 16:27.980 And they're listed by modulation type as well. 16:27.980 --> 16:31.060 So they use different schemes to encode the audio. 16:33.020 --> 16:37.620 And I'll give a quick description of 56 kbit per second modem. 16:37.980 --> 16:44.320 It uses basically shaped voltages or pulses over your analog pair. 16:44.820 --> 16:48.060 And these represent bits that you're sending. 16:48.060 --> 16:51.820 And those are converted to digital signal when it gets to the telco office. 16:53.120 --> 16:58.140 These voltages are held on the line for 125 microseconds which is a pretty short amount of time. 16:58.180 --> 16:59.600 And there's 8 bits per pulse. 16:59.600 --> 17:02.780 So there's 256 discrete voltages that go over your line. 17:03.240 --> 17:05.740 And in North America, we use only 7. 17:05.740 --> 17:08.900 So we have 56 instead of 64 kbit per second. 17:08.900 --> 17:13.880 But in reality, the analog lines are not able to discriminate. 17:13.880 --> 17:16.160 It's hard to discriminate between the 256 levels. 17:16.160 --> 17:17.500 So they typically use less. 17:17.500 --> 17:19.960 And that's why it negotiates a slower connection. 17:21.560 --> 17:29.600 And this is a high level diagram of talking from one analog voice modem V.90 modem to another. 17:30.460 --> 17:31.780 And basically you can see the pulse. 17:31.780 --> 17:33.400 You go through analog. 17:33.400 --> 17:34.880 Comes out digital. 17:34.880 --> 17:36.200 Goes back analog. 17:39.350 --> 17:45.190 And one of the 1200 bit per second modems they use a phase modulation scheme. 17:45.190 --> 17:46.870 I just threw this one in. 17:46.870 --> 17:50.630 It's a simulink model of a PSK modulator. 17:51.810 --> 17:55.490 And it turns out that voice codecs are not... 17:55.490 --> 18:01.510 it's not important to preserve phase information for voice traffic. 18:01.510 --> 18:07.890 It's hard to perceive changes in phase and timing on voice. 18:09.510 --> 18:12.330 And so that information is not preserved over the channel. 18:12.430 --> 18:14.990 And this is what PSK kind of looks like. 18:14.990 --> 18:17.590 On the right is the time domain signal. 18:17.830 --> 18:20.810 And you can see that it's a sinusoidal shape. 18:21.090 --> 18:23.990 And there's discontinuities where we're adjusting the phase. 18:24.110 --> 18:25.530 One phase represents a zero. 18:25.530 --> 18:26.930 One phase represents a one. 18:27.210 --> 18:29.590 And the spectral content. 18:29.670 --> 18:31.510 You can see the bandwidth it takes up. 18:32.390 --> 18:35.290 So I'm blowing through these fast because I don't think we've got the time. 18:37.170 --> 18:39.550 I want to run a demo right quick. 18:41.010 --> 18:44.970 Of using frequency modulation over GSM. 18:45.050 --> 18:53.070 And what frequency modulation really is you're encoding one tone as a zero and another tone as a one. 18:53.070 --> 18:59.250 And those tones are flipped back and forth at a certain rate so that you send your data that way. 18:59.470 --> 19:04.050 And we're going to show how the GSM channel distorts that signal. 19:04.050 --> 19:06.810 Making it impossible to decode correctly. 19:20.440 --> 19:22.040 That would have been bad. 19:25.180 --> 19:27.120 Alright, this is a quick aside. 19:27.120 --> 19:30.720 We did our modeling and work in Simulink and MATLAB. 19:30.720 --> 19:35.840 It's a numeric processing tool that is pretty quick to prototype on. 19:36.200 --> 19:43.700 It allows you to rapidly throw something together and throw information at the channel and see how it behaves. 19:44.560 --> 19:49.600 The actual voice channel we're using our model came from the 3GPP website. 19:49.600 --> 19:51.580 They have all the reference code available. 19:52.080 --> 19:53.420 And so it's in C. 19:53.580 --> 19:57.000 It compiles basically on any architecture. 19:57.680 --> 20:01.780 And so we threw that code and put some glue into Simulink so we could model this. 20:08.190 --> 20:10.650 Alright, so this is running at 100 bits per second. 20:21.500 --> 20:22.680 Hold on right quick. 20:24.620 --> 20:31.500 This is the output special content going through the voice channel. 20:31.500 --> 20:34.720 But let me switch it over to the straight pass through. 20:35.140 --> 20:36.180 You can see the tones 20:40.800 --> 20:42.960 going back and forth between the 0 and the 1. 20:43.520 --> 20:46.460 Closer to the 0 is a 0. 20:46.460 --> 20:48.960 And further out in frequency is a 1. 20:48.960 --> 20:50.900 You can see them flipping back and forth. 20:51.040 --> 20:55.160 And you can basically determine at any given time which one is which. 20:55.160 --> 20:58.500 It's easy to discern when it's a 0 and when it's a 1. 20:59.940 --> 21:03.520 If you put this through the voice channel itself 21:06.560 --> 21:10.720 you can see that the pulses they look a little more distorted. 21:10.740 --> 21:17.380 It's harder to tell at any given time what the actual tone is going through there. 21:17.500 --> 21:22.520 There are these blips and blobs and it's harder to pick them out. 21:22.520 --> 21:27.580 That's just a visual representation of what kind of distortion you'd expect to see on this channel. 21:45.010 --> 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. 22:01.390 --> 22:05.490 There was a group in England, we discovered that is doing the very same thing. 22:05.750 --> 22:13.870 They've managed to get a 1200 bit per second link over GSM using a similar scheme. 22:14.310 --> 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. 22:35.450 --> 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. 22:51.130 --> 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. 23:18.470 --> 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, 24:00.130 --> 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 24:38.230 --> 24:42.850 this is showing Let's do the demo first. 24:44.630 --> 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. 24:56.570 --> 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. 25:07.310 --> 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. 25:38.680 --> 25:39.460 All right. 25:39.500 --> 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. 25:48.480 --> 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. 26:05.510 --> 26:08.730 This is what it looks like on the output. 26:09.310 --> 26:10.530 Again, this is random. 26:10.530 --> 26:16.130 We're filling the frames up randomly, and it's generating what looks like valid speech information. 26:16.130 --> 26:21.030 It looks a lot like what we saw earlier as far as what the time domain signal looks like. 26:27.100 --> 26:30.460 This scope shows the bit error rate through the channel. 26:30.460 --> 26:32.700 I'll run this one more time so you can see it settling. 26:32.700 --> 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. 26:51.040 --> 26:52.320 Let's run this again. 26:53.260 --> 26:54.700 Oh, it's very angry at me. 27:04.240 --> 27:05.780 I don't even know what that means. 27:05.780 --> 27:10.880 Anyway, the point being the bit error rate settles to about 25%. 27:10.880 --> 27:16.060 One bit out of four is flipped when you put it through using a rudimentary system like this. 27:16.100 --> 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. 27:27.320 --> 27:31.200 25% is far too high to pass meaningful data through. 27:33.180 --> 27:35.920 MATLAB for Mac is not very good either, by the way. 27:37.340 --> 27:39.680 A side note on that, there's a free MATLAB. 27:39.680 --> 27:41.280 I don't know if you guys know about Octave. 27:41.280 --> 27:45.920 It's basically MATLAB minus the $100,000 fee. 27:46.520 --> 27:48.320 It's available online. 27:48.520 --> 27:50.680 You can search Google for Octave. 27:55.720 --> 27:56.620 Thank you, Mr. 27:56.620 --> 27:57.280 Tanner. 27:57.480 --> 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. 28:05.280 --> 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. 28:26.360 --> 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. 28:33.140 --> 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. 28:44.060 --> 28:48.660 The secure channel, which we'll go into in just a moment. 28:48.840 --> 28:53.420 The modulated data channel, which is the voice modem and the ECC. 28:56.240 --> 29:02.440 And those are all on top of the GSM voice channel and, of course, the GSM network. 29:03.740 --> 29:05.720 Otherwise the bits wouldn't go anywhere. 29:07.020 --> 29:09.040 Channel expectations. 29:09.780 --> 29:17.640 We had to make some decisions and do some research on what we could expect the lower levels to behave like. 29:18.480 --> 29:21.340 Detected and fixed bit corruption will be common. 29:21.340 --> 29:26.120 Undetected bit corruption will be rare, but we'll deal with that. 29:26.180 --> 29:32.720 Undetected frame loss depends on network quality and is reasonably common. 29:32.720 --> 29:38.320 You most likely hear dropped frames during your cell phone conversations all the time. 29:38.720 --> 29:42.160 We hope to have no undetected frame loss. 29:44.380 --> 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. 29:52.560 --> 29:58.340 So it's what cell phone users are used to and is an acceptable error state. 30:02.330 --> 30:04.130 So our threat model. 30:04.730 --> 30:07.030 Who are we trying to protect against? 30:07.050 --> 30:17.270 Of course, industrial espionage, foreign governments, anyone with $10,000 worth of equipment, and, of course, TLAs. 30:17.270 --> 30:19.750 Those damn TLAs. 30:20.410 --> 30:22.790 Three letter agencies, not acronyms. 30:22.870 --> 30:24.510 What are we trying to protect against? 30:24.510 --> 30:31.990 Break of our privacy, loss of confidentiality, break of authentication, loss of integrity. 30:33.470 --> 30:43.570 The threats in our threat model are dropped frames, frame replay, frame bit corruption, partial frames, and, of course, cryptographic attacks. 30:47.510 --> 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. 30:57.490 --> 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. 31:13.350 --> 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. 31:22.530 --> 31:24.650 Partial frames will be interesting. 31:24.650 --> 31:30.750 Probably end up corrupting the call as well or hopefully getting the GSM call dropped. 31:30.750 --> 31:32.230 We're currently looking into that. 31:32.230 --> 31:36.590 Cryptographic attacks, those are the fun ones, of course. 31:36.590 --> 31:46.010 We're hopefully picking strong enough crypto and strong enough protocols so that these can be avoided. 31:46.450 --> 31:49.490 Of course, these are all closed source protocols. 31:49.490 --> 31:51.050 I'm just kidding. 31:51.250 --> 31:53.150 Channel availability. 31:53.270 --> 32:00.390 Increasing the availability of GSM calls is really kind of outside the scope of this project. 32:00.390 --> 32:10.070 It is ridiculously trivial to block GSM voice channels, as you probably noticed from being inside casinos and getting no service. 32:10.070 --> 32:15.830 You can purchase cell phone jammers, a lot of places have, for not too much money. 32:15.830 --> 32:18.710 You can corrupt frames over the wire. 32:19.530 --> 32:21.770 You'd have to be a TLA to do that, probably. 32:21.990 --> 32:28.830 And you can also just request from the service operator disables the voice channel or disables the account altogether. 32:30.550 --> 32:38.230 So as you can see, it's not really practical for us to attempt to increase availability of the voice channel. 32:38.530 --> 32:44.670 We're hoping, and it seems that channel will not significantly decrease. 32:44.670 --> 32:52.190 The availability of the calls will not significantly decrease using our scheme. 32:52.590 --> 32:53.710 Which is good. 32:53.910 --> 32:54.990 Secure channel. 32:54.990 --> 32:57.430 Secure channel provides voice privacy. 32:57.430 --> 33:00.670 It does not provide message authentication. 33:00.770 --> 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. 33:09.270 --> 33:12.970 So we're relying on the authentication in the key exchange. 33:12.970 --> 33:26.570 And any manipulation of the data going over the air will cause gobbled speech and will not break the cryptographic channel. 33:27.410 --> 33:32.010 Here is a wonderful diagram of the initiation of the secure channel. 33:32.170 --> 33:41.350 Dig Helman, variable key size, being hashed into our session key, into a send and receive key, and our two counters. 33:42.030 --> 33:43.930 Which you'll see more of later. 33:44.530 --> 33:48.610 Here is a general diagram of our encryption model. 33:49.770 --> 33:51.450 This is for send, of course. 33:51.750 --> 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. 34:01.410 --> 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. 34:10.510 --> 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. 34:22.210 --> 34:27.090 There is many more details in the white paper, which is available on the web page. 34:28.470 --> 34:35.690 Key exchange, we're utilizing Ferguson Schneier key negotiation protocol, because it is a wonderfully strong design. 34:36.130 --> 34:39.270 I like what Schneier and Ferguson have done. 34:39.290 --> 34:43.550 And the key size is flexible, which is extremely key in this situation. 34:43.550 --> 34:45.830 We have two ends of this. 34:45.830 --> 34:52.510 We can have extremely limited hardware, having a Bluetooth headset that's doing the voice encryption for you. 34:52.510 --> 34:59.570 Extremely lightweight, and we need to save as much... use minimal CPU processing as possible. 34:59.570 --> 35:05.170 And we have another end where you're running this on your laptop over your generic landline. 35:05.170 --> 35:07.230 Not that any of you have a generic landline. 35:07.230 --> 35:11.970 So we want to have the flexibility that that entails. 35:11.970 --> 35:14.350 The second choice was stationization protocol. 35:15.230 --> 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. 35:26.500 --> 35:29.280 Thanks for deleting that slide, Wes. 35:29.480 --> 35:30.620 No problem. 35:32.880 --> 35:34.220 Oh, boy. 35:35.880 --> 35:37.600 Here's the key exchange. 35:38.060 --> 35:44.000 As described earlier, Alice generating... I'm not even going to go into that. 35:44.000 --> 35:46.740 You can read details of that in the white paper. 35:46.880 --> 35:48.740 I do want to make a comment on authentication. 35:48.740 --> 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. 36:07.740 --> 36:11.500 Sorry, there was a man-in-the-middle attack on the Diffie-Hellman key exchange. 36:11.920 --> 36:13.560 I don't like that. 36:13.560 --> 36:19.400 Not on a channel where you only have 2.4 kilobits of voice data going over. 36:19.980 --> 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. 36:36.380 --> 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. 36:52.980 --> 36:57.940 Also, I think Cryptophone, G10 and the other products do that. 36:58.500 --> 37:02.440 They have better voice... 37:03.060 --> 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. 37:13.800 --> 37:15.460 Conclusions and questions? 37:17.580 --> 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. 37:29.840 --> 37:35.880 Also, the white paper will be up there momentarily, when I can actually get onto the network. 37:37.000 --> 37:45.400 To reiterate, the point of this is to create a generic system scheme. 37:45.620 --> 37:47.900 It will work over any type of voice link. 37:48.100 --> 37:52.580 It happens to be that GSM is pretty difficult due to the large amount of compression. 37:53.520 --> 37:56.200 So if it works over GSM, it will work over anything else. 37:56.920 --> 38:00.340 That's the idea, and that's what we are trying to do. 38:04.560 --> 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. 38:16.020 --> 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. 38:24.280 --> 38:35.280 It covers two areas, very complex GSM voice channel analysis and a voice modem, and then it covers the cryptography. 38:35.280 --> 38:41.360 We attempted not to go into too much detail, but you can read the majority of that on the white papers. 38:41.980 --> 38:44.300 We got a question, but we probably need a mic. 38:56.160 --> 38:58.720 I'm not familiar with DECA. 39:00.540 --> 39:01.920 You, sir. 39:13.480 --> 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. 39:22.980 --> 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. 39:30.820 --> 39:37.960 We need to generate a modem that is much more resilient to the distortion involved. 39:37.960 --> 39:42.280 That probably implies using a lot less of the bandwidth available. 39:43.820 --> 39:45.300 Go ahead. 39:50.130 --> 39:52.030 No, it's a work in progress. 39:53.130 --> 39:56.670 Yeah, we have not actually developed a 2.4 kilobit per second modem as of yet. 39:56.730 --> 39:58.630 It's an ongoing process. 39:58.630 --> 40:02.750 We basically built the models to work on that kind of design. 40:02.750 --> 40:04.190 We're at that point at the moment. 40:06.570 --> 40:10.190 Yes, we hope to have something that's usable. 40:11.470 --> 40:17.890 Hopefully my graduate program will allow me to discover this stuff further and give me some amount of funding. 40:19.030 --> 40:20.350 Good plan. 40:21.550 --> 40:23.730 Any more questions from the audience? 40:25.730 --> 40:25.910 You, sir. 40:25.930 --> 40:26.710 In the back. 40:48.090 --> 40:52.970 I believe the question is, in our random test, how many bits were preserved? 41:07.160 --> 41:08.020 We have a 25. 41:08.020 --> 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. 41:15.880 --> 41:19.260 Those errors are basically distributed evenly across the frame. 41:19.260 --> 41:22.100 There are some bits that are more persistent. 41:22.140 --> 41:22.860 They will stay. 41:22.860 --> 41:24.420 They will not be as flipped as readily. 41:24.480 --> 41:26.860 For the most part, they are evenly distributed. 41:28.240 --> 41:29.700 I don't know if that answers your question. 41:30.840 --> 41:31.640 Excellent. 41:31.740 --> 41:32.940 Any more questions? 41:34.900 --> 41:35.700 Closed. 41:36.060 --> 41:41.840 If anyone wants to talk to us, we'll be in the bar for the rest of the week. 41:43.280 --> 41:43.960 Thank you. 41:43.960 --> 41:45.220 You've been a wonderful audience. 41:45.220 --> 41:46.180 We love you. 41:47.280 --> 41:49.360 Especially you right there, lumpy lump. 41:50.220 --> 41:51.540 And Simon Cooper. 41:53.100 --> 41:53.960 Fad. 41:53.960 --> 41:55.240 Total fad. 41:56.000 --> 41:57.160 How's it going, mate?