[00:00.000 --> 00:14.680] Thank you very much. Can everybody see me? Can everybody hear me? [00:15.820 --> 00:20.980] Awesome. 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:36.120] We have Wesley Tanner, who is a systems engineer for Software Divine Radio Company [00:36.120 --> 00:40.120] and has a BS in EE from RPI. 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 --> 01:53.880] A lot of people want it, but a majority of the products in the market don't provide [01:55.420 --> 02:00.220] 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:15.240] One sec. It's okay for photographs. [02:17.300 --> 02:18.840] Thanks, Wes. [02:18.900 --> 02:21.980] It's a requirement. We have to say it. [02:23.740 --> 02:25.380] That was awesome. [02:25.380 --> 02:30.200] Here is an image of the GSM network. 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:45.540] GSM cryptography. 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:36.400] Something else is needed. 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:51.440] Thank you, Mr. Tanner. [04:53.400 --> 04:55.340] Government intercepts are probably the most common. [04:55.440 --> 04:57.800] Undetectable. 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:03.840] It's actually built into the GSM specifications to get [06:03.840 --> 06:07.500] output product, network data, which is your, you know, [06:07.500 --> 06:10.820] location, type of call, parties, numbers, of course, [06:10.820 --> 06:14.640] the product, which is the speech user data, SMS, [06:14.640 --> 06:17.240] 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:27.240] Note the shady-looking law enforcement agent, the intercept request, [06:27.240 --> 06:29.980] and the data coming back to the LEA. [06:30.300 --> 06:31.640] Very interesting. [06:31.640 --> 06:36.360] The moral of the story, too, is even if the GSM crypto is sufficient, [06:36.360 --> 06:39.200] as I said earlier, the protection from the handset to the tower [06:40.960 --> 06:42.980] is capable of being... [06:43.520 --> 06:47.620] Even if the voice, the over-the-air voice crypto is secure, [06:47.620 --> 06:51.960] you still have the over-the-wire cryptography. [06:52.180 --> 06:55.600] Sorry, over-the-wire cleartext, which is easily interceptable, [06:55.600 --> 06:57.720] 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:09.140] And we got a chance to see the CryptoPhone guys [07:09.140 --> 07:12.360] present their products at Hope last year. [07:12.840 --> 07:14.640] Apologies. Is it better? [07:15.920 --> 07:18.000] The CryptoPhone guys presented their product. [07:18.000 --> 07:21.460] It's slick. I've never used it, but it does address this problem. [07:21.500 --> 07:24.940] There's the Sectera device by General Dynamics, [07:24.940 --> 07:26.520] 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:45.120] Their web presence has gone up and down, and they're no longer available, [07:45.120 --> 07:47.260] 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:00.720] There's a new government standard [08:00.720 --> 08:04.200] that's looking to replace the STU3, [08:04.200 --> 08:09.280] 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:20.920] This is very standard things like MELP for voice encryption, [08:20.920 --> 08:25.740] 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:37.840] They all probably work very well. 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:51.500] And I think... I've heard that you need to pay roaming charges [08:51.500 --> 08:53.480] 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 --> 08:59.980] There's longer call setup times associated with it, [08:59.980 --> 09:01.100] because it's a modem. [09:01.880 --> 09:05.340] It has to negotiate the connection. And there's a higher latency. [09:05.680 --> 09:08.480] But it's better than the packet-switched services that we use [09:09.240 --> 09:12.520] like GPRS for a typical internet over a cell phone. [09:12.520 --> 09:15.320] Also, if you can get circuit-switched data, [09:15.320 --> 09:19.020] 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:30.440] And voice is. You can have large numbers of bit errors [09:30.440 --> 09:34.500] 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:44.980] And the biggest problem is that these products are [09:44.980 --> 09:47.460] not available to you or me. 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:07.100] It hasn't been rolled out everywhere. It actually is in San Diego. [10:07.160 --> 10:10.220] And I believe San Francisco. 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:18.640] And we're proposing a solution, which is what we've been researching [10:18.640 --> 10:20.600] for the last couple months. [10:20.600 --> 10:23.600] It's developing a modem [10:24.320 --> 10:27.900] that will work over the 2G voice channel [10:27.900 --> 10:29.600] and the 3G voice channel. [10:30.240 --> 10:32.440] And it involves a bunch of technical disciplines, [10:32.440 --> 10:34.240] 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:42.540] Basically, the voice channel on GSM [10:42.540 --> 10:47.680] is a subset of a generic voice channel. [10:48.280 --> 10:51.040] Basically, the tricky part about the GSM channel [10:51.040 --> 10:52.920] is that it's highly compressed. [10:53.020 --> 10:56.440] And if we get a product to work on the GSM channel, [10:56.440 --> 10:59.900] we can use it on anything. You can use it over 2-way radio, [11:00.780 --> 11:02.220] voice over IP, or [11:02.960 --> 11:05.040] normal packet switch telephone networks. [11:06.000 --> 11:08.860] And the goal is to have an integrated thing [11:08.860 --> 11:11.100] that works over all these protocols. [11:11.600 --> 11:14.280] All these systems. 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:24.160] But basically, you have your input voice stream [11:24.160 --> 11:25.760] that goes into some kind of modem [11:26.480 --> 11:30.260] and goes through the GSM channel, all through all the networks, [11:30.260 --> 11:32.800] and comes out the other side undistorted. [11:37.520 --> 11:39.680] The project goals are basically [11:39.680 --> 11:42.480] to maximize the voice quality [11:43.940 --> 11:46.780] and provide strong crypto [11:47.500 --> 11:50.640] for privacy. And to minimize the distortion. [11:50.640 --> 11:53.060] So you want to have good sounding quality audio [11:53.640 --> 11:55.580] and have it very secure. [11:59.820 --> 12:01.360] I'm going to blow through some of these quick [12:01.360 --> 12:04.980] because it's highly involved [12:04.980 --> 12:07.880] and takes too much time. But basically, [12:07.880 --> 12:11.100] the GSM voice channel is a low latency, [12:11.100 --> 12:13.340] highly available channel. [12:13.460 --> 12:15.800] It has a friendly billing system. You can use your minutes [12:17.800 --> 12:20.900] instead of more expensive data packages. [12:21.740 --> 12:23.620] However, the voice channel uses [12:23.620 --> 12:26.780] strong compression, which causes distortion [12:26.780 --> 12:29.080] for certain types of signals that you pass through it. [12:29.760 --> 12:32.720] And therefore, you need to pass through things that look like speech [12:32.720 --> 12:34.140] so they're not distorted. [12:35.600 --> 12:38.060] This is a pretty busy slide, [12:38.060 --> 12:40.360] but it's basically calculating the data rate [12:40.360 --> 12:43.300] over the GSM air interface. [12:43.940 --> 12:47.780] And this is a breakdown of the GSM voice frame [12:47.780 --> 12:49.620] by speech parameter. [12:49.980 --> 12:52.520] It works out to 13 kilobits per second [12:53.100 --> 12:55.120] and there's 260 bits per frame [12:55.120 --> 12:57.400] and those are sent every 20 milliseconds. [12:59.060 --> 13:02.660] And all these parameters here are what we're trying to exploit [13:03.320 --> 13:06.420] to enable us to create a waveform [13:06.420 --> 13:08.320] that will work over in this frame [13:08.320 --> 13:11.320] 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:18.120] Your input on a typical GSM handset [13:18.120 --> 13:20.300] is 8 kilohertz sample rate audio [13:20.880 --> 13:23.080] at 13 significant bits. [13:23.080 --> 13:24.600] And that works out to an 8-to-1 compression [13:24.600 --> 13:27.160] when you go down to 13 kilobits per second. [13:28.320 --> 13:33.020] The official name of the 2G GSM voice channel [13:33.020 --> 13:35.400] is the top bit. [13:35.400 --> 13:37.200] It's a long way of saying that it uses [13:39.780 --> 13:40.880] a complicated compression [13:40.880 --> 13:42.800] to achieve its goal. [13:43.280 --> 13:45.600] And the input is PCM [13:46.140 --> 13:48.120] 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:02.900] Your speech samples go in on the left [14:02.900 --> 14:06.940] and the parameters that describe that speech [14:06.940 --> 14:08.580] 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:19.480] It takes those input parameters [14:19.480 --> 14:23.060] and spits out synthesized speech [14:23.060 --> 14:24.800] that's a very clear representation [14:24.800 --> 14:27.960] 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:34.680] Basically, the processing involves [14:34.680 --> 14:36.960] short-term algorithms [14:38.220 --> 14:40.580] 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:45.720] And the coder also [14:46.540 --> 14:48.800] 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:04.740] When the voice packets go over your GSM radio, [15:05.900 --> 15:07.620] some bits are protected [15:07.620 --> 15:10.240] from transmission errors, and some are not. [15:10.940 --> 15:12.660] The class A bits are. [15:12.940 --> 15:16.180] I think it's about 36 bits [15:16.180 --> 15:19.200] that are actually protected. 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:26.440] If the other bits are flipped, it's possible that you can actually [15:26.440 --> 15:28.780] 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:35.680] And this is a slide [15:35.680 --> 15:38.160] 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:53.800] It shows that there's a certain pitch [15:53.800 --> 15:55.240] over the frame. [15:58.680 --> 16:01.680] And I always wondered why you couldn't use [16:01.680 --> 16:04.060] your traditional telephone modems over [16:04.060 --> 16:06.200] 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:13.420] Your typical telephone modulation schemes [16:13.420 --> 16:16.540] are listed here in order of bit error. [16:16.540 --> 16:18.080] I mean, bit rate. [16:18.080 --> 16:20.480] There's the 300 all the way to the [16:21.320 --> 16:24.860] 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:35.160] And I'll give a quick description of [16:35.160 --> 16:37.620] 56 kbit per second modem. [16:37.980 --> 16:41.140] It uses basically shaped voltages [16:41.140 --> 16:44.320] or pulses over your analog pair. [16:44.820 --> 16:48.060] And these represent bits that you're sending. [16:48.060 --> 16:49.960] And those are converted to digital signal [16:49.960 --> 16:51.820] when it gets to the telco office. [16:53.120 --> 16:56.340] These voltages are held on the line for 125 microseconds [16:56.340 --> 16:58.140] which is a pretty short amount of time. [16:58.180 --> 17:01.500] And there's 8 bits per pulse. So there's 256 discrete voltages [17:01.500 --> 17:02.780] 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:24.280] And this is a high level diagram of [17:24.280 --> 17:27.340] talking from one analog voice modem [17:27.340 --> 17:29.600] V.90 modem to another. [17:30.460 --> 17:31.780] And basically you can see the pulse. [17:31.780 --> 17:36.200] You go through analog. Comes out digital. Goes back analog. [17:39.350 --> 17:41.550] And one of the 1200 bit per second modems [17:41.550 --> 17:45.190] 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:53.410] And it turns out that [17:53.410 --> 17:55.490] voice codecs are not... [17:55.490 --> 17:59.030] it's not important to preserve phase information [17:59.510 --> 18:01.510] for voice traffic. [18:01.510 --> 18:05.810] It's hard to perceive changes in phase and timing [18:05.810 --> 18:07.890] 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:26.930] One phase represents a zero. 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:43.310] Of using frequency modulation [18:43.310 --> 18:44.970] over GSM. [18:45.050 --> 18:46.790] And what frequency modulation really is [18:48.250 --> 18:51.090] you're encoding one tone as a zero [18:51.090 --> 18:53.070] and another tone as a one. [18:53.070 --> 18:56.590] And those tones are flipped back and forth at a certain rate [18:56.590 --> 18:59.250] 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:32.880] It's a numeric processing tool that is [19:32.880 --> 19:35.840] pretty quick to prototype on. [19:36.200 --> 19:39.600] It allows you to rapidly throw something together [19:39.600 --> 19:41.600] and throw information at the channel [19:41.600 --> 19:43.700] and see how it behaves. [19:44.560 --> 19:46.520] The actual voice channel we're using [19:46.520 --> 19:49.600] 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:00.400] And so we threw that code and put some glue into Simulink [20:00.400 --> 20:01.780] 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:28.320] This is the output special content [20:28.880 --> 20:31.500] going through the voice channel. [20:31.500 --> 20:32.960] But let me switch it over to [20:32.960 --> 20:34.720] the straight pass through. [20:35.140 --> 20:36.180] You can see the tones [20:40.800 --> 20:41.840] going back and forth [20:41.840 --> 20:42.960] 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:53.800] And you can basically determine at any given time [20:54.280 --> 20:56.080] which one is which. It's easy to discern [20:56.700 --> 20:58.500] 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:08.380] you can see that the pulses [21:08.380 --> 21:10.720] they look a little more distorted. [21:10.740 --> 21:13.020] It's harder to tell at any given time [21:13.920 --> 21:17.380] what the actual tone is going through there. [21:17.500 --> 21:20.500] There are these blips and blobs [21:20.500 --> 21:22.520] and it's harder to pick them out. [21:22.520 --> 21:25.720] That's just a visual representation of what kind of distortion [21:25.720 --> 21:27.580] you'd expect to see on this channel. [21:45.010 --> 21:48.050] I'll go into some technical details about what we're proposing to do [21:48.550 --> 21:51.030] which is to make a modem, a modulation scheme [21:51.030 --> 21:53.890] that will allow you to pass data undistorted [21:53.890 --> 21:56.830] and cryptographically secured voice data through this channel [21:56.830 --> 21:58.810] without having it flip bits. [22:01.390 --> 22:03.510] There was a group in England, we discovered [22:03.510 --> 22:05.490] that is doing the very same thing. [22:05.750 --> 22:10.250] They've managed to get a 1200 bit per second link [22:10.250 --> 22:13.870] over GSM using a similar scheme. [22:14.310 --> 22:15.250] Basically what they do [22:15.250 --> 22:17.850] they take their input encrypted voice [22:17.850 --> 22:20.850] which is encoded at 1200 bits per second [22:20.850 --> 22:22.670] which kind of sounds like a speak and spell [22:22.670 --> 22:27.030] it goes through basically a codebook lookup system [22:27.030 --> 22:29.050] where it has a list of waveforms [22:29.050 --> 22:30.930] that will actually pass through the channel correctly [22:31.690 --> 22:35.130] and it will synthesize speech based on some of those parameters. [22:35.450 --> 22:37.250] It's a relatively simple approach [22:37.250 --> 22:40.230] they're exploiting the fact that speech has very specific [22:41.090 --> 22:43.230] qualities and parameters that you can [22:45.290 --> 22:48.250] readily... the channel is able to [22:48.250 --> 22:50.450] distinguish between those different things. [22:51.130 --> 22:52.630] Our system is very similar [22:52.630 --> 22:56.390] we're going to try to take what [22:56.910 --> 22:58.850] they've done a certain thing, they've taken these parameters [22:58.850 --> 23:02.170] they've synthesized things, we want to figure out a better way [23:02.170 --> 23:04.630] to characterize the voice channel itself [23:04.630 --> 23:07.490] and see if we can come up with a higher bit rate [23:08.170 --> 23:11.090] we've decided that 2400 bit per second audio [23:11.090 --> 23:13.990] is much better than 1200 bit per second audio [23:13.990 --> 23:17.570] so much so that it's worth investigating how to make that happen. [23:18.470 --> 23:20.610] And again, there's our proposed system block diagram [23:22.190 --> 23:23.850] and this is a [23:23.850 --> 23:26.730] high level diagram about the flow of data through the system [23:26.730 --> 23:29.730] so you have a microphone at one end that's going into [23:29.730 --> 23:32.150] an analog to digital converter [23:32.150 --> 23:34.590] so you get your audio samples [23:34.590 --> 23:38.090] you put that through a speech compression routine [23:38.090 --> 23:42.010] and the output of that is the 2.4 kilobits per second [23:42.010 --> 23:43.830] and you run that through some kind of crypto [23:43.830 --> 23:45.930] and we're proposing AES block cipher [23:46.620 --> 23:49.550] and run that through an error-corrective coding [23:49.550 --> 23:52.910] I said more details on that later [23:52.910 --> 23:55.890] and an error-corrective coding which basically means that [23:55.890 --> 23:58.910] you can encode the data in such a way that if there are errors [23:58.910 --> 24:01.390] on the channel, based on either [24:01.390 --> 24:04.350] through the distortion of the GSM voice channel or [24:04.350 --> 24:06.610] dropped frames over the air [24:06.610 --> 24:09.570] as if you go through a tunnel or inside a building [24:09.570 --> 24:13.370] it'll be able to correct those errors or at least detect them [24:13.370 --> 24:16.870] and finally going through the modem that we're proposing to develop [24:17.590 --> 24:20.050] that'll generate valid speech waveforms [24:20.050 --> 24:21.030] that'll work over the channel [24:23.470 --> 24:25.870] and those are fed through directly into the [24:26.770 --> 24:28.690] speech codec on the GSM phone [24:28.690 --> 24:31.330] and they go through to the decoder on the other side [24:31.330 --> 24:33.030] which is basically the thing in reverse [24:38.230 --> 24:39.530] this is showing [24:40.530 --> 24:50.350] Let's do the demo first. I'm going to demonstrate some of the... basically using a simple [24:50.350 --> 24:55.250] approach to the problem, trying to determine how the GSM voice channel will corrupt the [24:55.250 --> 25:00.670] data that you pass through it. So what we're proposing is using the voice channel against [25:00.670 --> 25:07.310] itself, using the speech decoder as the modulator and the speech encoder as the demodulator. [25:07.310 --> 25:15.330] So we're going to fill the speech frame up with random bits and see how that will perform [25:15.330 --> 25:40.860] over the channel and see what distortions happen. All right. This is another Simulink [25:40.860 --> 25:46.260] model that we've thrown together that shows in the middle of this block right here is [25:46.260 --> 25:54.440] the speech channel itself. And we're proposing to use the voice codec of GSM against itself, [25:54.440 --> 25:57.900] the decoder is put on one side, and we're going to fill the frames up with random data [25:57.900 --> 26:09.690] and see what happens on the other side. This is what it looks like on the output. Again, [26:09.690 --> 26:14.550] this is random. We're filling the frames up randomly, and it's generating what looks like [26:14.550 --> 26:19.650] valid speech information. It looks a lot like what we saw earlier as far as what the time [26:19.650 --> 26:30.640] domain signal looks like. This scope shows the bit error rate through the channel. I'll [26:30.640 --> 26:35.760] run this one more time so you can see it settling. It's taking the average bit error along the [26:35.760 --> 26:43.220] X axis is the bit position inside of the frame, and into the page is the frame number, and [26:43.220 --> 26:52.320] the amplitude is the number of bits that were flipped on average. Let's run this again. [26:53.260 --> 27:08.940] Oh, it's very angry at me. I don't even know what that means. Anyway, the point being the [27:08.940 --> 27:13.420] bit error rate settles to about 25%. One bit out of four is flipped when you put it through [27:13.420 --> 27:18.800] using a rudimentary system like this. We propose that our research will continue as far as [27:18.800 --> 27:23.420] developing a scheme that is able to pass a high bandwidth amount of data through that's [27:23.420 --> 27:30.260] acceptable speech quality that will minimize that. 25% is far too high to pass meaningful [27:30.260 --> 27:38.460] data through. MATLAB for Mac is not very good either, by the way. A side note on that, [27:38.460 --> 27:43.120] there's a free MATLAB. I don't know if you guys know about Octave. It's basically MATLAB [27:43.120 --> 27:50.680] minus the $100,000 fee. It's available online. You can search Google for Octave. [27:55.720 --> 28:00.400] Thank you, Mr. Tanner. I want to take a slight segway for a second and go back to what he [28:00.400 --> 28:07.580] was saying about 3G solving this issue. I think it will solve some of the issues, but [28:07.880 --> 28:18.140] if you can purchase a data channel that is high bandwidth and low latency to do voice [28:18.660 --> 28:24.720] over IP off a regular cell phone, that kind of cuts into the market that cell phone providers [28:24.720 --> 28:30.080] have today. And I'm kind of worried that they might take steps to prevent that, but we'll [28:30.080 --> 28:36.100] see when they actually start properly rolling things out. Here we have our network stack, [28:36.100 --> 28:43.140] on the top, the voice channel, which is a low bit rate voice encoder, 2.4 kilobits per [28:43.140 --> 28:50.120] second. The secure channel, which we'll go into in just a moment. The modulated data [28:50.120 --> 28:59.120] channel, which is the voice modem and the ECC. And those are all on top of the GSM voice [28:59.120 --> 29:07.620] channel and, of course, the GSM network. Otherwise the bits wouldn't go anywhere. Channel [29:07.620 --> 29:15.320] expectations. We had to make some decisions and do some research on what we could expect [29:15.320 --> 29:21.340] the lower levels to behave like. Detected and fixed bit corruption will be common. [29:21.340 --> 29:27.640] Undetected bit corruption will be rare, but we'll deal with that. Undetected frame loss [29:28.520 --> 29:34.580] depends on network quality and is reasonably common. You most likely hear dropped frames [29:34.580 --> 29:41.220] during your cell phone conversations all the time. We hope to have no undetected frame [29:41.220 --> 29:49.660] loss. As I said, frame loss and undetected bit corruption will produce gobbled speech, [29:49.660 --> 29:54.860] which is pretty much similar to what you hear nowadays. So it's what cell phone users are [29:54.860 --> 30:05.750] used to and is an acceptable error state. So our threat model. Who are we trying to [30:05.750 --> 30:13.070] protect against? Of course, industrial espionage, foreign governments, anyone with $10,000 [30:13.070 --> 30:21.650] worth of equipment, and, of course, TLAs. Those damn TLAs. Three letter agencies, not [30:21.650 --> 30:26.970] acronyms. What are we trying to protect against? Break of our privacy, loss of [30:28.050 --> 30:35.470] confidentiality, break of authentication, loss of integrity. The threats in our threat model [30:35.470 --> 30:41.950] are dropped frames, frame replay, frame bit corruption, partial frames, and, of course, [30:41.950 --> 30:51.630] cryptographic attacks. So dropped frames, as I said earlier, we should be able to [30:51.630 --> 30:58.690] deal with as we can detect and increment our counters for that. Frame replay will either [30:58.690 --> 31:05.870] break the GSM, will either upset the GSM stack and break the call or will corrupt the [31:05.870 --> 31:11.410] cryptographic channel, which will end up with an error state like the one we were talking [31:11.410 --> 31:18.290] about moments ago. Bit corruption will just add slight blurbs or gobbled speech, which [31:18.290 --> 31:23.890] shouldn't exactly deviate much from the error state as well. Partial frames will be [31:23.890 --> 31:28.990] interesting. Probably end up corrupting the call as well or hopefully getting the GSM [31:28.990 --> 31:35.550] call dropped. We're currently looking into that. Cryptographic attacks, those are the [31:35.550 --> 31:41.910] fun ones, of course. We're hopefully picking strong enough crypto and strong enough [31:42.490 --> 31:49.490] protocols so that these can be avoided. Of course, these are all closed source protocols. [31:49.490 --> 31:58.250] I'm just kidding. Channel availability. Increasing the availability of GSM calls is really [31:58.250 --> 32:04.290] kind of outside the scope of this project. It is ridiculously trivial to block GSM voice [32:04.290 --> 32:10.790] channels, as you probably noticed from being inside casinos and getting no service. You [32:10.790 --> 32:16.090] can purchase cell phone jammers, a lot of places have, for not too much money. You can [32:16.090 --> 32:22.790] corrupt frames over the wire. You'd have to be a TLA to do that, probably. And you can also [32:22.790 --> 32:27.830] just request from the service operator disables the voice channel or disables the account [32:27.830 --> 32:35.550] altogether. So as you can see, it's not really practical for us to attempt to increase [32:35.550 --> 32:43.370] availability of the voice channel. We're hoping, and it seems that channel will not [32:43.370 --> 32:49.770] significantly decrease. The availability of the calls will not significantly decrease using [32:49.770 --> 32:57.970] our scheme. Which is good. Secure channel. Secure channel provides voice privacy. It does not [32:57.970 --> 33:04.210] provide message authentication. The reason being is we're working with a reasonably low [33:04.210 --> 33:10.610] bandwidth and we don't have space for Macs or anything like that, sadly. So we're relying on [33:10.610 --> 33:21.030] the authentication in the key exchange. And any manipulation of the data going over the air [33:21.030 --> 33:28.810] will cause gobbled speech and will not break the cryptographic channel. Here is a wonderful [33:28.810 --> 33:34.630] diagram of the initiation of the secure channel. Dig Helman, variable key size, being [33:34.630 --> 33:42.710] hashed into our session key, into a send and receive key, and our two counters. Which you'll [33:42.710 --> 33:50.750] see more of later. Here is a general diagram of our encryption model. This is for send, of [33:50.750 --> 33:58.790] course. Session key is generating a send key through SHA, which is then used with AES and [33:58.910 --> 34:04.830] a counter mode with our send counter. And I said before, when a frame is dropped, we will [34:04.830 --> 34:11.230] have to increment the counter to stop from destroying the entire secure channel. Once the [34:11.230 --> 34:17.730] key stream is generated, that is XORed with the voice data, which creates our cyber text, [34:17.730 --> 34:23.150] which is passed off to the voice modem, the modulated data channel. There is many more [34:23.150 --> 34:29.310] details in the white paper, which is available on the web page. Key exchange, we're [34:29.310 --> 34:34.610] utilizing Ferguson Schneier key negotiation protocol, because it is a wonderfully strong [34:34.610 --> 34:41.430] design. I like what Schneier and Ferguson have done. And the key size is flexible, which is [34:41.430 --> 34:46.790] extremely key in this situation. We have two ends of this. We can have extremely limited [34:46.790 --> 34:52.510] hardware, having a Bluetooth headset that's doing the voice encryption for you. [34:52.510 --> 34:59.050] Extremely lightweight, and we need to save as much... use minimal CPU processing as [34:59.050 --> 35:02.610] possible. And we have another end where you're running this on your laptop over your [35:02.610 --> 35:09.190] generic landline. Not that any of you have a generic landline. So we want to have the [35:09.190 --> 35:15.770] flexibility that that entails. The second choice was stationization protocol. I [35:15.770 --> 35:20.560] definitely like the fact that you can encrypt the signatures in stationization, but it [35:20.560 --> 35:27.660] lacks the key size flexibility, which really kind of killed it for me. Thanks for deleting [35:27.660 --> 35:42.180] that slide, Wes. No problem. Oh, boy. Here's the key exchange. As described earlier, Alice [35:42.180 --> 35:46.000] generating... I'm not even going to go into that. You can read details of that in the white [35:46.000 --> 35:50.540] paper. I do want to make a comment on authentication. Most of the products and [35:50.540 --> 36:02.860] the one even detailed by Zimmerman rely on you reading a section of text back over the [36:02.860 --> 36:08.060] phone line to the other person to make sure the Diffie-Hellman key did not break. Sorry, [36:08.060 --> 36:13.100] there was a man-in-the-middle attack on the Diffie-Hellman key exchange. I don't like [36:13.100 --> 36:20.520] that. Not on a channel where you only have 2.4 kilobits of voice data going over. I [36:20.540 --> 36:29.560] think the possibility of someone being able to spoof what your friend's voice sounds like on a [36:29.560 --> 36:37.840] channel that's that low bitrate is quite possible, and that kind of scares me. So we're [36:37.840 --> 36:47.060] attempting to use DSA for authentication rather than relying on the person reading the [36:47.060 --> 36:52.980] keys back... sorry, reading the hash of the keys back over, which really kind of scares me. [36:52.980 --> 37:02.440] Also, I think Cryptophone, G10 and the other products do that. They have better voice... [37:03.060 --> 37:09.280] they have a higher bitrate voice encoding, which should make that not as easy an attack, but [37:09.280 --> 37:14.480] it's still definitely possible, and that really kind of disturbs me. Conclusions and [37:14.480 --> 37:22.700] questions? Also, if you have any questions via e-mail, we are available at info at [37:22.700 --> 37:28.420] cellularcrypto.com, where the slides and all the other MATLAB code and Simulink code are for [37:28.420 --> 37:34.120] your viewing pleasure. Also, the white paper will be up there momentarily, when I can [37:34.120 --> 37:44.460] actually get onto the network. To reiterate, the point of this is to create a generic system [37:44.480 --> 37:50.220] scheme. It will work over any type of voice link. It happens to be that GSM is pretty difficult [37:50.220 --> 37:55.420] due to the large amount of compression. So if it works over GSM, it will work over anything [37:55.420 --> 38:07.420] else. That's the idea, and that's what we are trying to do. Also, we only had about 50 minutes [38:07.420 --> 38:11.700] to do this, and we had a lot of technical information that we had to gloss over, but [38:12.800 --> 38:19.340] hopefully the point got across. It was hard for us to frame this in a way that people could [38:19.340 --> 38:23.980] understand, just based upon the fact that a lot of it has to do with voice channel stuff. [38:24.280 --> 38:33.860] It covers two areas, very complex GSM voice channel analysis and a voice modem, and then it [38:33.860 --> 38:38.020] covers the cryptography. We attempted not to go into too much detail, but you can read the [38:38.020 --> 38:44.300] majority of that on the white papers. We got a question, but we probably need a mic. [38:56.160 --> 39:17.640] I'm not familiar with DECA. You, sir. We just tried, just for the demonstration purposes, a [39:19.300 --> 39:23.320] test modem, basically just using the maximum amount of bits in that channel. If we were [39:23.320 --> 39:28.700] sending data at the 13 kilobits per second, if you send data at 13 kilobits per second, you get [39:28.700 --> 39:37.280] 25% bit error. We need to generate a modem that is much more resilient to the distortion [39:37.280 --> 39:50.790] involved. That probably implies using a lot less of the bandwidth available. Go ahead. No, [39:50.790 --> 39:55.930] it's a work in progress. Yeah, we have not actually developed a 2.4 kilobit per second modem [39:55.930 --> 40:02.250] as of yet. It's an ongoing process. We basically built the models to work on that kind of [40:02.250 --> 40:10.190] design. We're at that point at the moment. Yes, we hope to have something that's usable. [40:11.470 --> 40:16.210] Hopefully my graduate program will allow me to discover this stuff further and give me some [40:16.730 --> 40:25.910] amount of funding. Good plan. Any more questions from the audience? You, sir. [40:25.930 --> 40:52.970] In the back. I believe the question is, in our random test, how many bits were preserved? [41:07.160 --> 41:12.260] We have a 25. If you use the entirety of the bits of the GSM frame and you twiddle those [41:12.260 --> 41:18.120] randomly, you get one bit flipped out of every four. Those errors are basically distributed [41:18.120 --> 41:23.040] evenly across the frame. There are some bits that are more persistent. They will stay. They will [41:23.040 --> 41:28.680] not be as flipped as readily. For the most part, they are evenly distributed. I don't know if [41:28.680 --> 41:37.280] that answers your question. Excellent. Any more questions? Closed. If anyone wants to talk [41:37.280 --> 41:45.220] to us, we'll be in the bar for the rest of the week. Thank you. You've been a wonderful audience. [41:45.220 --> 41:51.540] We love you. Especially you right there, lumpy lump. And Simon Cooper. [41:53.100 --> 41:55.240] Fad. Total fad. [41:56.000 --> 41:57.160] How's it going, mate?