1 00:00:09,249 --> 00:00:12,109 This talk will be by Sylvain Munaut 2 00:00:12,109 --> 00:00:14,859 who works with the Osmocom project. 3 00:00:14,859 --> 00:00:19,330 He will talk today about the osmo-gmr satellite phones. 4 00:00:19,330 --> 00:00:22,980 After the talk there will be the opportunity to ask questions. 5 00:00:22,980 --> 00:00:25,419 You can approach one of the microphones 6 00:00:25,419 --> 00:00:28,279 and then you have the chance to ask one question. 7 00:00:28,279 --> 00:00:32,860 Please give a round of applause to Mr Sylvain Munaut! 8 00:00:32,860 --> 00:00:35,760 *Applause* 9 00:00:36,360 --> 00:00:39,469 - Hi! Thank you for being here. 10 00:00:39,469 --> 00:00:44,750 As he said I'm going to talk about satellite phones today. 11 00:00:44,750 --> 00:00:50,060 I'll first talk with a quick recap of the previous work we've done. 12 00:00:50,060 --> 00:00:53,880 At 28C3 there was a presentation on this subject. 13 00:00:53,880 --> 00:00:56,030 But there were some pieces missing. 14 00:00:56,030 --> 00:00:58,799 So, I'm just gonna recap what we did previously 15 00:00:58,799 --> 00:01:00,749 and then move on to the new stuff 16 00:01:00,749 --> 00:01:03,370 which is the speech codec and cipher 17 00:01:03,370 --> 00:01:06,850 reverse engineering and cracking that's been done. 18 00:01:06,850 --> 00:01:09,819 First, what is GMR exactly? 19 00:01:09,819 --> 00:01:12,810 GMR stands for GEO-Mobile Radio and 20 00:01:12,810 --> 00:01:16,849 it's an ETSI standard for satellite phones. 21 00:01:16,849 --> 00:01:19,430 It's heavily inspired from GSM and 22 00:01:19,430 --> 00:01:21,339 if you read the GMR specs 23 00:01:21,339 --> 00:01:23,850 there is plenty of reference to go see the GSM spec. 24 00:01:23,850 --> 00:01:27,110 There is actually two standards named GMR: 25 00:01:27,110 --> 00:01:28,800 GMR-1 and GMR-2. 26 00:01:28,800 --> 00:01:31,010 They are not an evolution of one another. 27 00:01:31,010 --> 00:01:32,899 They are competing standards 28 00:01:32,899 --> 00:01:35,180 that have been developed by distinct companies 29 00:01:35,180 --> 00:01:38,110 and then both have been standardized to ETSI. 30 00:01:38,110 --> 00:01:41,380 Today, we're gonna be looking at GMR-1. 31 00:01:41,380 --> 00:01:46,420 That comes in 3 evolutions. It started with plain old GMR-1 32 00:01:46,420 --> 00:01:49,230 which is voice calls and SMS. 33 00:01:49,230 --> 00:01:52,820 It evolved to include packet data. That's called GMPRS. 34 00:01:52,820 --> 00:01:55,040 And then there was a later evolution 35 00:01:55,040 --> 00:01:57,570 to interconnect with the 3G core network 36 00:01:57,570 --> 00:02:01,470 and improve the air interface and that's GMR-1 3G. 37 00:02:01,470 --> 00:02:04,280 But we'll be mostly looking at the first version 38 00:02:04,280 --> 00:02:07,508 which is still used. 39 00:02:08,778 --> 00:02:13,350 Among the deployments the one we focused on was Thuraya. 40 00:02:13,350 --> 00:02:16,460 The reason why is that it's the most common 41 00:02:16,460 --> 00:02:19,099 commercial operator where you can actually buy SIM 42 00:02:19,099 --> 00:02:20,800 and place phone calls. 43 00:02:20,800 --> 00:02:23,200 The satellites are visible from Europe 44 00:02:23,200 --> 00:02:26,950 which is kind of a requirement for me to look at the signal. 45 00:02:26,950 --> 00:02:31,376 This operator is mostly active in the middle east, Asia and Africa. 46 00:02:31,376 --> 00:02:33,929 In Europe you don't see too many people 47 00:02:33,929 --> 00:02:37,279 with satellite phones because we have GSM coverage. 48 00:02:37,279 --> 00:02:40,659 But there are other operators and we actually read recently 49 00:02:40,659 --> 00:02:44,370 that there is a new deployment planned for Europe 50 00:02:44,370 --> 00:02:46,920 called Solaris Mobile and they said 51 00:02:46,920 --> 00:02:49,899 they're going to use GRM-1 3G 52 00:02:49,899 --> 00:02:52,920 but the satellite isn't launched yet. 53 00:02:53,110 --> 00:02:55,590 This is the coverage zone for Thuraya. 54 00:02:55,590 --> 00:02:58,499 As you can see Europe is very well covered 55 00:02:58,499 --> 00:03:01,219 so there is no problem if you want to receive the signal. 56 00:03:01,219 --> 00:03:04,299 If you are somewhere in that area you can see it. 57 00:03:04,299 --> 00:03:07,309 So, since it's so heavily inspired by GSM 58 00:03:07,309 --> 00:03:09,960 it makes sense to compare it to it. 59 00:03:09,960 --> 00:03:13,469 The first thing they did is to rename everything. 60 00:03:13,469 --> 00:03:15,950 So, instead of a base transceiver station 61 00:03:15,950 --> 00:03:17,719 you have a GEO transceiver station. 62 00:03:17,719 --> 00:03:19,559 Instead of a base station controller 63 00:03:19,559 --> 00:03:21,769 you have a GEO station controller. 64 00:03:21,769 --> 00:03:25,599 Instead of a mobile station you have a mobile earth station. 65 00:03:25,599 --> 00:03:29,580 Then they did some actual useful stuff like 66 00:03:29,580 --> 00:03:32,379 use specialized features for satellites. 67 00:03:32,379 --> 00:03:35,149 The first one is terminal-to-terminal calls. 68 00:03:35,149 --> 00:03:37,340 When you're usually placing a call 69 00:03:37,340 --> 00:03:40,159 your signal goes from your satellite phone to the satellite 70 00:03:40,159 --> 00:03:43,180 then it goes back to the core network on earth 71 00:03:43,180 --> 00:03:46,159 and then, if you're calling another satellite phone 72 00:03:46,159 --> 00:03:48,849 it would have to again go back up to the satellite 73 00:03:48,849 --> 00:03:51,389 and back to the other phone and that means that 74 00:03:51,389 --> 00:03:54,130 you pay 4 trips from earth to space 75 00:03:54,130 --> 00:03:56,849 and since the satellite is in geosynchronous orbit 76 00:03:56,849 --> 00:03:58,989 it's pretty far away. 77 00:03:58,989 --> 00:04:01,879 So, to reduce the delay in communication 78 00:04:01,879 --> 00:04:06,450 they have the so-called terminal-to-terminal calls where 79 00:04:06,450 --> 00:04:09,140 the call network will still handle establishing 80 00:04:09,140 --> 00:04:12,209 the channel but once the call is established 81 00:04:12,209 --> 00:04:14,989 the data is going directly from one phone to the satellite 82 00:04:14,989 --> 00:04:17,660 and directly back down to the other phone 83 00:04:17,660 --> 00:04:19,758 without any involvement from the network. 84 00:04:19,768 --> 00:04:21,990 It never even sees the packets. 85 00:04:21,990 --> 00:04:26,169 They also have this call called “High Penetration Alerting” 86 00:04:26,169 --> 00:04:29,189 That's because like in the movies you see people using 87 00:04:29,189 --> 00:04:31,599 satellite phones in bunkers and stuff like that 88 00:04:31,599 --> 00:04:34,379 in practice, as soon as you are inside 89 00:04:34,379 --> 00:04:37,430 you can't see the satellite and you can't place a call at all 90 00:04:37,430 --> 00:04:40,009 but you still might want to be able to at least… 91 00:04:40,009 --> 00:04:41,990 you know, you can't pick up the phone 92 00:04:41,990 --> 00:04:44,949 but you want to know that somebody is calling you 93 00:04:44,949 --> 00:04:47,560 and so they have this specialized channel 94 00:04:47,560 --> 00:04:51,419 which has an incredible amount of error correction on it 95 00:04:51,419 --> 00:04:53,620 so that even with very very low signal 96 00:04:53,620 --> 00:04:57,350 you can still get an indication that somebody is trying to call you 97 00:04:57,350 --> 00:05:01,270 please run outside so you can take the call. 98 00:05:01,270 --> 00:05:04,420 There's also a very tight integration to GPS 99 00:05:04,420 --> 00:05:07,309 For example, all the Almanac and Ephemeris data 100 00:05:07,309 --> 00:05:09,700 are actually broadcasted by the Thuraya satellite 101 00:05:09,700 --> 00:05:11,889 so that your phone can get a lock faster 102 00:05:11,889 --> 00:05:14,670 and when you place a phone call the very first thing 103 00:05:14,670 --> 00:05:19,049 that your phone will do is send your exact GPS coordinates 104 00:05:19,049 --> 00:05:22,409 in clear to the operator. 105 00:05:22,909 --> 00:05:25,229 They do this for two reasons: 106 00:05:25,229 --> 00:05:28,949 The first one is: If you're not on the right frequency 107 00:05:28,949 --> 00:05:31,969 for this particular geographic location they can tell you 108 00:05:31,969 --> 00:05:34,470 “OK. You shouldn't be connecting on this frequency 109 00:05:34,470 --> 00:05:36,860 use this one! It has a much better signal 110 00:05:36,860 --> 00:05:38,939 and you get better quality”. 111 00:05:38,939 --> 00:05:42,399 That's one reason. The other reason is purely commercial: 112 00:05:42,399 --> 00:05:44,740 It's for billing because if you're calling 113 00:05:44,740 --> 00:05:47,349 while you are in certain countries it's gonna cost more 114 00:05:47,349 --> 00:05:49,609 than if you are on the other side of the border 115 00:05:49,609 --> 00:05:51,600 and so they need to know where you are 116 00:05:51,600 --> 00:05:52,979 to bill you correctly. 117 00:05:52,979 --> 00:05:55,580 And then compared to GSM, of course, they introduced 118 00:05:55,580 --> 00:05:57,620 the two things we're gonna look at today: 119 00:05:57,620 --> 00:06:01,199 They changed the speech codec to something called AMBE 120 00:06:01,199 --> 00:06:03,740 and they changed the cipher. They are not using A5/1 121 00:06:03,740 --> 00:06:06,269 or A5/2 or A5/3 or that kind of stuff. 122 00:06:06,269 --> 00:06:10,040 They use something called A5/GMR-1. 123 00:06:10,300 --> 00:06:13,419 If you look at the protocol stack 124 00:06:13,419 --> 00:06:15,400 anything in the lower layers 125 00:06:15,400 --> 00:06:18,430 (radio modulation, TDMA frame structure) 126 00:06:18,430 --> 00:06:21,439 it's completely different because you have to deal with 127 00:06:21,439 --> 00:06:24,369 the particular of the satellite communication. 128 00:06:24,369 --> 00:06:26,379 You find the same kind of concept 129 00:06:26,379 --> 00:06:29,110 and you find the control channels and broadcast channels 130 00:06:29,110 --> 00:06:31,960 but their implementation is different. 131 00:06:31,960 --> 00:06:35,039 If you go up one layer to the data link layer 132 00:06:35,039 --> 00:06:39,319 you have something very similar to LAPDm. 133 00:06:39,319 --> 00:06:42,749 Again, they needed some minor adaptation 134 00:06:42,749 --> 00:06:44,960 because bandwidth costs a lot on a satellite. 135 00:06:44,960 --> 00:06:48,030 They reduce the size of the overhead by reducing the header 136 00:06:48,030 --> 00:06:50,039 and since you have so much delay 137 00:06:50,039 --> 00:06:52,620 going from your phone to the satellite and 138 00:06:52,620 --> 00:06:55,590 back down to the earth station then again to your phone 139 00:06:55,590 --> 00:07:00,439 you have something like nearly 500 ms of delay 140 00:07:00,439 --> 00:07:05,099 because you have basically 4… no 250 ms, sorry, 141 00:07:05,099 --> 00:07:10,330 because you have both paths up and down 142 00:07:10,330 --> 00:07:13,789 and so, with that delay you need more time for the acknowledgement 143 00:07:13,789 --> 00:07:17,389 to come in, so they increased the window size. 144 00:07:17,389 --> 00:07:19,440 Anything above that, so, layer 3 145 00:07:19,440 --> 00:07:22,170 radio resource, since it's managed the radio channel 146 00:07:22,170 --> 00:07:24,599 is still a bit different but anything above that 147 00:07:24,599 --> 00:07:28,279 is strictly the same as GSM. It actually interoperates 148 00:07:28,279 --> 00:07:30,589 with the GSM core network which means I can take 149 00:07:30,589 --> 00:07:33,819 my Belgian operator SIM put it into a Thuraya phone 150 00:07:33,819 --> 00:07:37,620 and I can roam onto the satellite and place calls 151 00:07:37,620 --> 00:07:40,400 which is really nice except for the price you pay 152 00:07:40,400 --> 00:07:42,809 at the end of the month. 153 00:07:42,809 --> 00:07:45,519 For packet data it's essentially the same thing. 154 00:07:45,519 --> 00:07:47,479 Anything that's close to the lower level 155 00:07:47,479 --> 00:07:50,219 like RLC and MAC is gonna be different, 156 00:07:50,219 --> 00:07:52,599 anything above interoperates with GSM 157 00:07:52,599 --> 00:07:55,829 so you're gonna be speaking to a GSM core network 158 00:07:55,829 --> 00:07:59,939 SGSN and GGSN and all that good stuff. 159 00:07:59,939 --> 00:08:05,349 So, osmo-gmr, what we presented last time, 160 00:08:05,349 --> 00:08:10,319 is essentially everything you needed to go from RF to wireshark. 161 00:08:10,319 --> 00:08:13,460 That includes the hardware setup 162 00:08:13,460 --> 00:08:19,949 (how you can build an antenna, what LNA to use, what SDR receiver to use) 163 00:08:19,949 --> 00:08:22,849 At that time we didn't actually have RTL-SDR, 164 00:08:22,849 --> 00:08:25,740 the cheap DVB dongle you can use as SDR. 165 00:08:25,740 --> 00:08:29,379 Nowadays we do which means that for less than 100 bucks 166 00:08:29,379 --> 00:08:32,900 you can get an antenna, LNA and SDR receiver and all 167 00:08:32,900 --> 00:08:36,040 that we need to listen to those signals. 168 00:08:36,040 --> 00:08:38,599 Then we did all the SDR processing which is 169 00:08:38,599 --> 00:08:41,470 taking that raw data, filtering it, selecting the channel 170 00:08:41,470 --> 00:08:45,350 doing the demodulation getting actual data bits out of it. 171 00:08:45,350 --> 00:08:48,480 Then, channel coding which is converting those data bits into 172 00:08:48,480 --> 00:08:52,380 layer 2 frames. Then, interpreting those layer 2 frames 173 00:08:52,380 --> 00:08:55,560 into channel assignment and follow those assignments 174 00:08:55,560 --> 00:08:58,650 into a demonstration application. 175 00:08:58,650 --> 00:09:01,880 And finally, the wireshark dissector which takes this 176 00:09:01,880 --> 00:09:05,460 and presents it nicely in a way you can read stuff. 177 00:09:05,460 --> 00:09:08,680 But there is two things we couldn't do: 178 00:09:08,680 --> 00:09:11,310 First, we couldn't see past the ciphering mode command 179 00:09:11,310 --> 00:09:13,529 which as soon as ciphering was enabled 180 00:09:13,529 --> 00:09:15,630 we couldn't see anything because 181 00:09:15,630 --> 00:09:18,310 we knew the key because it was our own calls 182 00:09:18,310 --> 00:09:20,319 and we can read the key from the SIM 183 00:09:20,319 --> 00:09:23,160 but we didn't know the algorithm that was used to cipher 184 00:09:23,160 --> 00:09:26,380 so there was no way for us to decipher that. 185 00:09:26,380 --> 00:09:29,350 And we also had no way to get the voice data, 186 00:09:29,350 --> 00:09:33,070 converting the frame into actual audio that we can listen to 187 00:09:33,070 --> 00:09:37,900 We couldn't do that and that's what we're gonna look into. 188 00:09:38,470 --> 00:09:44,320 So the first thing is the speech codec. 189 00:09:46,270 --> 00:09:50,959 It's called AMBE for Advanced Multi-Band Excitation. 190 00:09:50,959 --> 00:09:55,960 It's not a codec in itself. AMBE is more a family of codecs 191 00:09:55,960 --> 00:09:59,570 which means you have several codecs which are named AMBE 192 00:09:59,570 --> 00:10:02,220 which are different versions of one another 193 00:10:02,220 --> 00:10:05,410 slightly different so that they're not compatible. 194 00:10:05,410 --> 00:10:08,330 It's not documented in the standard 195 00:10:08,330 --> 00:10:11,749 which is really annoying. When I started working on GMR 196 00:10:11,749 --> 00:10:15,490 I really thought that the codec was in there 197 00:10:15,490 --> 00:10:19,570 and then I discovered it wasn't. That was a bad day. 198 00:10:19,570 --> 00:10:23,250 There is a bit of specification in there 199 00:10:23,250 --> 00:10:26,810 but it only gives a high level description like 200 00:10:26,810 --> 00:10:31,119 “The codec takes audio as input and produces 80 bits of output 201 00:10:31,119 --> 00:10:34,940 every 20 ms” but nothing that can be used to 202 00:10:34,940 --> 00:10:39,470 realistically implement a decoder. 203 00:10:40,650 --> 00:10:44,290 That codec is made by a company DVSI Inc. 204 00:10:44,290 --> 00:10:48,529 whose entire business is codecs. That's all they do 205 00:10:48,529 --> 00:10:51,410 which is probably why there are incompatible versions 206 00:10:51,410 --> 00:10:54,660 of AMBE because they can sell different versions. 207 00:10:54,660 --> 00:10:58,999 These guys, they do sell a small USB stick that 208 00:10:58,999 --> 00:11:02,440 can decode some of the variants. For example, you can decode 209 00:11:02,440 --> 00:11:06,660 DStar audio which is also another AMBE codec 210 00:11:06,660 --> 00:11:11,320 or P25 which is used in law enforcement radio in the US 211 00:11:11,320 --> 00:11:13,610 (it's also an AMBE variant) 212 00:11:13,610 --> 00:11:16,620 and the cheap USB stick can decode that. 213 00:11:16,620 --> 00:11:19,779 Unfortunately, it's incompatible with the GMR-1 variant 214 00:11:19,779 --> 00:11:22,329 because that's the first thing I did, I contacted DVSI 215 00:11:22,329 --> 00:11:24,850 to know what were my options. 216 00:11:24,850 --> 00:11:31,010 And short of buying a source code license which is just too expensive 217 00:11:31,760 --> 00:11:35,469 is buying the appliance which is called NET-2000. 218 00:11:35,469 --> 00:11:39,029 And not only does it cost like 2000 Euros 219 00:11:39,029 --> 00:11:42,850 which is way too much for a hobby project 220 00:11:42,850 --> 00:11:46,290 but you also have to special-order it with a GMR-1 firmware 221 00:11:46,290 --> 00:11:50,080 and you have to sign some non-reverse engineering agreement 222 00:11:50,080 --> 00:11:53,590 which… That wasn't an option. 223 00:11:53,590 --> 00:11:57,480 We still had some hope. The first hope we had is that 224 00:11:57,480 --> 00:12:03,210 as I said P25 uses an AMBE variant as well 225 00:12:03,210 --> 00:12:06,790 and this particular variant is actually documented. 226 00:12:06,790 --> 00:12:11,180 So you can download the standard for that particular 227 00:12:11,180 --> 00:12:15,199 variant of AMBE and you have all the math and all the specs 228 00:12:15,199 --> 00:12:18,459 so you can write a decoder and somebody actually wrote 229 00:12:18,459 --> 00:12:21,870 a decoder which is open source which is called ambelib 230 00:12:21,870 --> 00:12:27,670 and so we can use that code as a base to modify it. That was a lead. 231 00:12:27,670 --> 00:12:31,730 The other lead, of course, is that the codec is somewhere in the phone. 232 00:12:31,730 --> 00:12:33,940 The phone is obviously capable of decoding audio 233 00:12:33,940 --> 00:12:37,000 so maybe we can find it in there. 234 00:12:37,000 --> 00:12:40,939 But before we can start searching for the codec 235 00:12:40,939 --> 00:12:45,250 it's good to have a basic understanding of how the codec works 236 00:12:45,250 --> 00:12:47,899 so that we know what we're looking for. 237 00:12:47,899 --> 00:12:50,400 The first thing to understand: it's a vocoder. 238 00:12:50,400 --> 00:12:53,120 It's not a general-purpose audio codec 239 00:12:53,120 --> 00:12:58,000 which means if you try to feed it music it's gonna perform horribly 240 00:12:58,000 --> 00:13:01,380 because a general-purpose audio codec will try to model 241 00:13:01,380 --> 00:13:06,300 what your ear can actually hear and what it can't 242 00:13:06,300 --> 00:13:10,250 whereas a vocoder is gonna try to model the speech 243 00:13:10,250 --> 00:13:12,949 and reconstructs something that sounds like 244 00:13:12,949 --> 00:13:15,519 but is not actually the same thing. 245 00:13:15,519 --> 00:13:18,649 They will drop a lot of information. 246 00:13:18,649 --> 00:13:23,060 To do that the first thing they do is to split your speech 247 00:13:23,060 --> 00:13:25,850 into small segments which are compressed independently. 248 00:13:25,850 --> 00:13:31,920 In the case of GMR-1 those segments are 10 ms long and 249 00:13:31,920 --> 00:13:36,610 they are combined by pair and each pair is compressed 250 00:13:36,610 --> 00:13:40,800 into a single frame. And then, for each of those small segments 251 00:13:40,800 --> 00:13:45,740 they will represent it in 4 parameters. Those 4 parameters are 252 00:13:45,740 --> 00:13:52,389 the pitch which is the fundamental frequency 253 00:13:52,389 --> 00:13:56,089 of the periodic component of your voice, 254 00:13:56,089 --> 00:13:58,889 the gain which is how loud you are talking, 255 00:13:58,889 --> 00:14:01,429 something called voiced/unvoiced decision, 256 00:14:01,429 --> 00:14:03,700 we're gonna see what this is right after 257 00:14:03,700 --> 00:14:06,899 but essentially you have the fundamental frequency 258 00:14:06,899 --> 00:14:08,990 and for each harmonic, two times the frequency, 259 00:14:08,990 --> 00:14:11,339 three times the frequency, four times the frequency, 260 00:14:11,339 --> 00:14:16,300 you have a bit that says is that component voiced or unvoiced 261 00:14:16,300 --> 00:14:21,730 and then you have the amplitudes for the various harmonics. 262 00:14:22,420 --> 00:14:26,520 If you want to play back the voice you have to do 3 things: 263 00:14:26,520 --> 00:14:29,319 The first thing is unpacking. 264 00:14:29,319 --> 00:14:33,420 That's taking the 80 bits of the voice frame 265 00:14:33,420 --> 00:14:36,639 and reconstruct quantized parameters from it. 266 00:14:36,639 --> 00:14:40,290 All the parameters are not just put in order one after the other 267 00:14:40,290 --> 00:14:43,259 because some of the bits in a frame will receive more error correction 268 00:14:43,259 --> 00:14:47,230 than others and some of the bits are more sensitive to errors than others 269 00:14:47,230 --> 00:14:51,269 and so they will be placed at specific places in the frame 270 00:14:51,269 --> 00:14:54,720 so that if errors do happen, hopefully it will affect something 271 00:14:54,720 --> 00:14:57,190 that is not too important. 272 00:14:57,190 --> 00:14:59,629 That's the unpacking step. 273 00:14:59,629 --> 00:15:01,949 The second one is dequantization. 274 00:15:01,949 --> 00:15:04,960 That's going from the quantized, compressed parameters 275 00:15:04,960 --> 00:15:08,590 into floating point value or integer values 276 00:15:08,590 --> 00:15:10,899 which will represent the real parameters 277 00:15:10,899 --> 00:15:13,110 that are going to be used in the last step 278 00:15:13,110 --> 00:15:16,699 which is synthesis. And synthesis is taking those parameters 279 00:15:16,699 --> 00:15:23,069 and reconstructing actual audio that sounds like the original voice. 280 00:15:23,410 --> 00:15:26,459 To do a quick overview of the synthesis step 281 00:15:26,459 --> 00:15:29,420 what you do is you take for each possible harmonic, 282 00:15:29,420 --> 00:15:32,470 so, f0, 2 f0, 3 f0,… 283 00:15:32,470 --> 00:15:36,319 you have the voiced/unvoiced decision 284 00:15:36,319 --> 00:15:39,870 and what voiced means is that you're gonna reconstruct 285 00:15:39,870 --> 00:15:43,389 that particular frequency as a pure sinusoidal tone, 286 00:15:43,389 --> 00:15:49,600 and if it's unvoiced you're just gonna fill that small band with noise. 287 00:15:49,600 --> 00:15:55,129 And with that they can reconstruct human voice pretty well. 288 00:15:55,129 --> 00:16:00,320 So, now that we know more or less how the codec works 289 00:16:00,320 --> 00:16:02,679 and what we are looking for 290 00:16:02,679 --> 00:16:08,130 we can start looking at where we are gonna find this codec. 291 00:16:08,130 --> 00:16:13,340 The phone we looked at is the Thuraya SO-2510. 292 00:16:13,340 --> 00:16:16,830 We looked at it mostly because it was the cheapest phone on eBay. 293 00:16:16,830 --> 00:16:20,090 And that also means that it's the simplest 294 00:16:20,090 --> 00:16:25,480 which means you have less places to look into. 295 00:16:26,059 --> 00:16:30,600 We knew the codec was in the DSP. How did we know that is that 296 00:16:30,600 --> 00:16:33,399 there is simply no other places it could be. 297 00:16:33,399 --> 00:16:36,889 There are a bunch of chips on that phone, of course, 298 00:16:36,889 --> 00:16:39,769 there is only two where it could possibly be: 299 00:16:39,769 --> 00:16:42,069 the TI OMAP main processor, 300 00:16:42,069 --> 00:16:44,290 and then they also have like a small ASIC 301 00:16:44,290 --> 00:16:46,459 which is named the DALMA ASIC because 302 00:16:46,459 --> 00:16:49,779 there is a big DALMA marking on it. 303 00:16:49,779 --> 00:16:53,870 At first, we thought that that chip was the AMBE codec. 304 00:16:53,870 --> 00:16:58,139 But it turned out that we found some Korean paper 305 00:16:58,139 --> 00:17:00,029 from the phone manufacturer that described 306 00:17:00,029 --> 00:17:02,439 the phone architecture. And there is a schematic 307 00:17:02,439 --> 00:17:05,020 of the internals of that ASIC and it showed 308 00:17:05,020 --> 00:17:07,589 it only had satellite radio functions 309 00:17:07,589 --> 00:17:09,910 and absolutely nothing to do with the codec 310 00:17:09,910 --> 00:17:13,670 which means there was a good chance it was in the TI OMAP processor. 311 00:17:13,670 --> 00:17:17,170 Why in the DSP? Well, because it just makes sense 312 00:17:17,170 --> 00:17:20,260 to make the codec in the DSP especially since DVSI 313 00:17:20,260 --> 00:17:25,450 the company that makes the codec mostly sells those codecs as a 314 00:17:25,450 --> 00:17:30,360 DSP precompiled library that you can buy. 315 00:17:30,550 --> 00:17:38,520 Pretty standard process: We get the firmware update from the Internet. 316 00:17:38,520 --> 00:17:42,280 From there we can extract the actual DSP image 317 00:17:42,280 --> 00:17:46,000 which is the code that is loaded into the DSP. 318 00:17:46,000 --> 00:17:47,960 Thankfully it's supported by IDA 319 00:17:47,960 --> 00:17:50,770 which makes the whole process easier to reverse engineer. 320 00:17:50,770 --> 00:17:54,360 But it's still like 250KB of binary data 321 00:17:54,360 --> 00:17:56,870 and since it's a DSP it has no I/O 322 00:17:56,870 --> 00:18:01,220 which means there is not a single string in it. 323 00:18:01,220 --> 00:18:04,960 And also it's a DSP which means it's written in DSP assembly. 324 00:18:04,960 --> 00:18:08,070 I don't know if you ever tried to read that 325 00:18:08,070 --> 00:18:12,930 but it's not the most understandable thing in the world 326 00:18:12,930 --> 00:18:16,420 because it's highly optimized for speed, of course. 327 00:18:16,420 --> 00:18:19,400 And I actually looked at that code and went over it a few times 328 00:18:19,400 --> 00:18:22,000 and took a few hours and looked at it 329 00:18:22,000 --> 00:18:25,240 and I couldn't see anything in it. 330 00:18:25,240 --> 00:18:30,700 And one day I get an email from a colleague in OSMOCOM, 331 00:18:30,700 --> 00:18:34,640 Dieter Spaar, asking me if I had ever looked at that codec 332 00:18:34,640 --> 00:18:36,550 and I told him “yeah I looked 333 00:18:36,550 --> 00:18:38,330 but I couldn't really find anything. 334 00:18:38,330 --> 00:18:40,500 Do you see anything?” 335 00:18:40,500 --> 00:18:42,180 And six hours later he sent me 336 00:18:42,180 --> 00:18:43,950 “I think this is the entry point 337 00:18:43,950 --> 00:18:46,330 for the encoding and decoding functions” 338 00:18:46,330 --> 00:18:48,880 “Oh, OK. Good!” 339 00:18:48,880 --> 00:18:53,060 The way he found that from what I remember is that 340 00:18:53,060 --> 00:18:56,640 you look at what would a codec use. 341 00:18:56,640 --> 00:18:59,930 And of course it's gonna access the audio path 342 00:18:59,930 --> 00:19:05,850 so you can look at the audio DMA setup, and audio DMA interrupts. 343 00:19:05,850 --> 00:19:09,110 You can also look for constants that you know are used in the codec, 344 00:19:09,110 --> 00:19:12,450 for example, I said that the frames are 80 bits, 345 00:19:12,450 --> 00:19:15,170 so you can look for the constant 80 somewhere in the code. 346 00:19:15,170 --> 00:19:16,590 You can look at it. 347 00:19:16,590 --> 00:19:20,350 It will produce 160 audio samples per frame decoded 348 00:19:20,350 --> 00:19:23,400 so you can look at the constant 160. 349 00:19:23,400 --> 00:19:26,170 Once you actually found one function 350 00:19:26,170 --> 00:19:28,970 there is something that kind of stands out, 351 00:19:28,970 --> 00:19:32,330 it's that since they ship that as a binary library 352 00:19:32,330 --> 00:19:36,800 they don't really trust the guy who implements the rest of the DSP code 353 00:19:36,800 --> 00:19:38,940 to setup the C runtime properly 354 00:19:38,940 --> 00:19:43,230 and so what they do is they switch everything at each call into the codec. 355 00:19:43,230 --> 00:19:48,260 They switch the stack, they re-setup/reconfigure the C runtime, 356 00:19:48,260 --> 00:19:50,560 so that it's really independent. 357 00:19:50,560 --> 00:19:53,870 Once you find one function, finding the other is pretty easy, 358 00:19:53,870 --> 00:19:59,730 you can just look for that particular function prelude 359 00:19:59,730 --> 00:20:06,530 that happens at each call at the audio library. 360 00:20:06,530 --> 00:20:11,000 OK, so, we know where the code is 361 00:20:11,000 --> 00:20:12,930 but it's still a massive amount of code. 362 00:20:12,930 --> 00:20:17,680 I think it's like one third of the DSP code is the audio codec. 363 00:20:17,680 --> 00:20:24,180 So, It's not something you can easily reverse engineer in a few hours. 364 00:20:24,180 --> 00:20:29,120 So, before trying reverse engineering we just tried, 365 00:20:29,120 --> 00:20:31,790 OK, maybe we can just run it. 366 00:20:31,790 --> 00:20:34,810 It turns out that TI has this really nice program called 367 00:20:34,810 --> 00:20:38,550 TI Code Composer Studio which includes a simulator 368 00:20:38,550 --> 00:20:42,960 and it's a really nice piece of software because 369 00:20:42,960 --> 00:20:47,060 not only can you pretty accurately simulate any of the DSPs 370 00:20:47,060 --> 00:20:51,220 you can also completely configure the surrounding environment 371 00:20:51,220 --> 00:20:55,670 in which it runs so you can setup arbitrary memory map. 372 00:20:55,670 --> 00:20:59,400 You can also trace all memory access to see what part 373 00:20:59,400 --> 00:21:03,910 of memory is being read or being written or being executed. 374 00:21:03,910 --> 00:21:07,240 You can also access a file on your host system. 375 00:21:07,240 --> 00:21:09,010 So you can use fread and fwrite 376 00:21:09,010 --> 00:21:11,890 and the simulator would automatically translate those calls 377 00:21:11,890 --> 00:21:16,890 into actual reading from the audio, hard drive and write to your hard drive 378 00:21:16,890 --> 00:21:22,470 so you can read a compressed file that you saved 379 00:21:22,470 --> 00:21:28,250 and it will write an audio wave file at the output. 380 00:21:28,250 --> 00:21:32,230 And the way to do that is pretty straightforward. 381 00:21:32,230 --> 00:21:35,130 You essentially just need to take the binary dump that 382 00:21:35,130 --> 00:21:38,950 you have from the firmware update 383 00:21:38,950 --> 00:21:45,040 and you need to find a way to mix in your own custom code. 384 00:21:45,040 --> 00:21:51,380 The way to do that: You create a new object file like ELF 385 00:21:51,380 --> 00:21:55,090 except in this case it's called COFF, a common object file format. 386 00:21:55,090 --> 00:21:57,680 But it's the same idea. 387 00:21:57,680 --> 00:22:04,790 You can just link to it like you would link any other piece of binary. 388 00:22:04,980 --> 00:22:07,180 You write a simple main function 389 00:22:07,180 --> 00:22:12,010 that will basically fread your compressed samples, 390 00:22:12,010 --> 00:22:15,180 call the decoding function or at least what you hope 391 00:22:15,180 --> 00:22:19,660 is the decoding function and fwrite the audio samples. 392 00:22:19,660 --> 00:22:24,670 And surprisingly it worked. It didn't require that much effort. 393 00:22:24,670 --> 00:22:27,860 In like a couple of days it was all working. 394 00:22:27,860 --> 00:22:32,950 It didn't work on the first try. There was a couple of pitfalls. 395 00:22:32,950 --> 00:22:37,010 But essentially the IDE is there and it can probably be applied 396 00:22:37,010 --> 00:22:39,580 to other things as well. 397 00:22:39,580 --> 00:22:42,160 Of course there is some pretty big downsides. 398 00:22:42,160 --> 00:22:46,410 At first, it's pretty slow. Definitely sub-real-time 399 00:22:46,410 --> 00:22:50,550 even on a modern laptop. 400 00:22:50,550 --> 00:22:53,630 It also requires TI Code Composer Studio 401 00:22:53,630 --> 00:22:58,160 which is a Windows application and it's also not free. 402 00:22:58,160 --> 00:23:02,050 You have a 30 days evaluation period but that's about it. 403 00:23:02,050 --> 00:23:05,200 So it's really not that practical. 404 00:23:05,200 --> 00:23:07,550 But it was running in the simulator. 405 00:23:07,550 --> 00:23:10,880 There is no real reason it cannot run on real hardware. 406 00:23:10,880 --> 00:23:14,360 Of course, that's what we try next. 407 00:23:14,360 --> 00:23:16,800 Unfortunately, on real hardware 408 00:23:16,800 --> 00:23:20,380 you can't just put memory anywhere you want. 409 00:23:20,380 --> 00:23:24,080 When the codec runs in the phone, 410 00:23:24,080 --> 00:23:28,640 it runs inside a TI-OMAP which is an ARM plus a DSP 411 00:23:28,640 --> 00:23:31,250 and that chip has an MMU which means 412 00:23:31,250 --> 00:23:35,480 you can create any virtual memory you want. 413 00:23:35,480 --> 00:23:38,880 But if you're trying to run on a cheap DSP board 414 00:23:38,880 --> 00:23:42,420 that you can get for 50 bucks, 415 00:23:42,420 --> 00:23:45,530 those usually don't include an MMU at all 416 00:23:45,530 --> 00:23:47,640 which means you need to find a board 417 00:23:47,640 --> 00:23:49,640 which has memory at the right places 418 00:23:49,640 --> 00:23:54,970 because the binary you have has been linked to a specific physical addresses 419 00:23:54,970 --> 00:23:58,500 and it needs to run at that particular addresses. 420 00:23:58,500 --> 00:24:05,920 Thankfully, Dieter found one such board with a compatible memory map 421 00:24:05,920 --> 00:24:11,520 and it had SDRAM. Well, we needed it to have some memory. 422 00:24:11,520 --> 00:24:17,370 It also included Ethernet which means we can make some networked appliance 423 00:24:17,370 --> 00:24:20,390 where we submit samples and get them back. 424 00:24:20,390 --> 00:24:22,800 That was really nice. 425 00:24:22,800 --> 00:24:25,640 The process of migrating the code from the simulator 426 00:24:25,640 --> 00:24:28,650 to the board is actually pretty smooth because 427 00:24:28,650 --> 00:24:31,500 of the way TI Code Composer Studio works. 428 00:24:31,500 --> 00:24:34,090 You just basically select that as a target 429 00:24:34,090 --> 00:24:39,500 and since the memory was at the right place it pretty much worked. 430 00:24:39,500 --> 00:24:42,680 Now, it wasn't quite as fast as we want it 431 00:24:42,680 --> 00:24:47,570 because it was only running about real-time at the first try 432 00:24:47,570 --> 00:24:51,890 and that's because SDRAM is slow especially when you do 433 00:24:51,890 --> 00:24:56,650 a bunch of random accesses the SDRAM isn't really fast. 434 00:24:56,650 --> 00:25:00,390 The codec has unfortunately a lot of big data tables 435 00:25:00,390 --> 00:25:05,320 which are accessed constantly like to compute cosines. 436 00:25:05,320 --> 00:25:10,030 So, what Dieter did is basically identify a couple 437 00:25:10,030 --> 00:25:13,790 of those big tables that are accessed very often 438 00:25:13,790 --> 00:25:16,370 and then just migrated them to internal SRAM. 439 00:25:16,370 --> 00:25:19,470 You just find the one or two places 440 00:25:19,470 --> 00:25:22,190 where the code reads from those tables 441 00:25:22,190 --> 00:25:25,730 and just patch the address to another address 442 00:25:25,730 --> 00:25:28,510 and redirect it to there. 443 00:25:28,510 --> 00:25:32,770 And that got the code running much faster, about 16x faster than real-time. 444 00:25:32,770 --> 00:25:35,040 And honestly, that was good. 445 00:25:35,040 --> 00:25:39,380 I wasn't really planning on doing anything else on the hardware 446 00:25:39,380 --> 00:25:43,670 and so I ordered the same board… except I didn't. 447 00:25:43,670 --> 00:25:47,680 I somehow ended up clicking on the wrong button in the 448 00:25:47,680 --> 00:25:50,370 TI store or something and when the board arrived 449 00:25:50,370 --> 00:25:53,100 I didn't have the right one. 450 00:25:53,100 --> 00:25:55,846 At that point I had two choices: 451 00:25:55,846 --> 00:25:58,592 I could just order the same board 452 00:25:58,592 --> 00:26:01,080 and wait one more week, 453 00:26:01,080 --> 00:26:04,390 or I could try to run the code on it anyway. 454 00:26:04,390 --> 00:26:07,270 The second board didn't have Ethernet. It had USB. 455 00:26:07,270 --> 00:26:09,990 But most importantly it didn't have any SDRAM at all. 456 00:26:09,990 --> 00:26:12,300 It only had internal SRAM 457 00:26:12,300 --> 00:26:16,170 and unfortunately not at the right address. 458 00:26:16,170 --> 00:26:21,130 So I just figured: OK. I'm just gonna try to relocate the binary 459 00:26:21,130 --> 00:26:24,920 and make it run on another address. How hard can it be? 460 00:26:24,920 --> 00:26:27,850 It turned out to be pretty straightforward because 461 00:26:27,850 --> 00:26:30,600 in I think less than a day it was running 462 00:26:30,600 --> 00:26:34,200 and that's really thanks to IDAPython and the simulator. 463 00:26:34,200 --> 00:26:37,540 Basically what I did is in IDAPython which is the 464 00:26:37,540 --> 00:26:42,440 scripting language in IDA reverse engineering software 465 00:26:42,440 --> 00:26:46,410 you can iterate through all the opcodes, then for that 466 00:26:46,410 --> 00:26:50,290 opcode you can test: Is there an absolute memory reference 467 00:26:50,290 --> 00:26:53,420 somewhere in that opcode? If no, then don't do anything. 468 00:26:53,420 --> 00:26:56,020 If there is an absolute memory reference, 469 00:26:56,020 --> 00:26:59,520 is that reference falling somewhere in a place that 470 00:26:59,520 --> 00:27:02,000 I'm trying to relocate or not? If it is a place 471 00:27:02,000 --> 00:27:04,230 I'm trying to relocate then just patch that opcode 472 00:27:04,230 --> 00:27:07,490 and change the absolute memory reference to the new place. 473 00:27:07,490 --> 00:27:10,370 Go through all the code like that and try to run it. 474 00:27:10,370 --> 00:27:13,390 Of course, it didn't work the first time around 475 00:27:13,390 --> 00:27:19,530 because there was a couple of pitfalls in that approach 476 00:27:19,760 --> 00:27:25,430 but using the simulator it was pretty easy to find out where 477 00:27:25,430 --> 00:27:29,990 things were going wrong because you take the original code 478 00:27:29,990 --> 00:27:32,910 you run everything in the simulator and you trace every 479 00:27:32,910 --> 00:27:37,840 memory access, then you take your potentially relocated code 480 00:27:37,840 --> 00:27:42,320 you run it again in the simulator and trace every memory access 481 00:27:42,320 --> 00:27:45,480 Decoding the same frame it should be deterministic 482 00:27:45,480 --> 00:27:49,580 and so you should have the exact same memory access patterns 483 00:27:49,580 --> 00:27:52,990 in both cases. And as soon as you see that they are diverging 484 00:27:52,990 --> 00:27:55,700 you know that somewhere a branch wasn't taken or 485 00:27:55,700 --> 00:27:59,170 something went wrong and you can go at that place in your code 486 00:27:59,170 --> 00:28:03,040 look and see why the relocation didn't work. 487 00:28:03,040 --> 00:28:06,950 It only took two tries to have the code running. 488 00:28:06,950 --> 00:28:10,570 It was running on my board and I didn't have to order a new one 489 00:28:10,570 --> 00:28:13,220 which was pretty nice. 490 00:28:13,220 --> 00:28:15,760 So we have a hardware USB decoder 491 00:28:15,760 --> 00:28:19,430 which is very useful but you still have to carry it around 492 00:28:19,430 --> 00:28:23,220 or plug it into a network server or something 493 00:28:23,220 --> 00:28:26,230 which isn't necessarily something you want. 494 00:28:26,230 --> 00:28:32,470 I wanted something I could checkout into git, basically. 495 00:28:32,470 --> 00:28:38,740 So, I started reverse engineering the entire codec. 496 00:28:38,740 --> 00:28:43,170 Now, it turned out to be very painful. 497 00:28:43,170 --> 00:28:47,310 As I said, to reconstruct audio you have three main steps. 498 00:28:47,310 --> 00:28:50,960 The first one is unpacking and it's just basically bit shuffling. 499 00:28:50,960 --> 00:28:54,610 It's like the first thing the codec does which means 500 00:28:54,610 --> 00:28:58,020 it's really easy to find and it's really easy to follow. 501 00:28:58,020 --> 00:29:00,020 So, no problem there. 502 00:29:00,020 --> 00:29:04,230 The second step is dequantization and it took like 95% percent 503 00:29:04,230 --> 00:29:07,970 of the work because it's lot of math. 504 00:29:07,970 --> 00:29:12,000 It's all written in DSP assembly, in fixed-point 505 00:29:12,000 --> 00:29:15,140 and sometimes you're looking at a function to figure out 506 00:29:15,140 --> 00:29:18,590 what that function does you have to run it with different 507 00:29:18,590 --> 00:29:22,610 parameters to see what does that thing compute. 508 00:29:22,610 --> 00:29:26,040 Graphing is really useful for that. You just feed some 509 00:29:26,040 --> 00:29:29,140 inputs into the simulator see what output is generated 510 00:29:29,140 --> 00:29:32,970 and just plot it in PyLab or something. 511 00:29:32,970 --> 00:29:37,240 And then you can see, OK, that actually computes a logarithm. 512 00:29:37,240 --> 00:29:42,070 There is still a lot of code there and there was no 513 00:29:42,070 --> 00:29:46,010 other option for that part because the quantization step 514 00:29:46,010 --> 00:29:49,020 is completely specific to GMR. It's not shared with any 515 00:29:49,020 --> 00:29:52,130 of the other AMBE variants. 516 00:29:52,130 --> 00:29:55,170 The synthesis part is even more complicated, is even more 517 00:29:55,170 --> 00:29:58,470 code in the DSP but I really didn't want… 518 00:29:58,470 --> 00:30:01,540 after finishing the dequantization I really didn't want 519 00:30:01,540 --> 00:30:05,380 to the synthesis, so I just assumed that the synthesis step 520 00:30:05,380 --> 00:30:08,650 was gonna be very similar to the one in P25. 521 00:30:08,650 --> 00:30:13,900 So I took the mbelib existing open-source code for P25, 522 00:30:13,900 --> 00:30:17,860 I ripped out the unpacking and dequantization out of it. 523 00:30:17,860 --> 00:30:21,300 That's because it's the one for P25, of course. 524 00:30:21,300 --> 00:30:25,240 I just plugged in my own implementation 525 00:30:25,240 --> 00:30:28,200 and run it through the synthesis. 526 00:30:28,200 --> 00:30:31,480 There's a couple of things you need to take care of 527 00:30:31,480 --> 00:30:37,810 mostly because P25 uses 20 ms frames, GMR uses 10 ms frames. 528 00:30:37,810 --> 00:30:42,280 So, I basically dropped one frame every other frame in GMR 529 00:30:42,280 --> 00:30:46,130 and just used the 10 ms parameter synthesized 20 ms of speech 530 00:30:46,130 --> 00:30:48,880 but it produced something where you could follow 531 00:30:48,880 --> 00:30:51,600 a conversation and it worked. 532 00:30:51,600 --> 00:30:55,780 I was still not really happy about it because the code quality 533 00:30:55,780 --> 00:30:58,670 of mbelib was really not that good. 534 00:30:58,670 --> 00:31:01,420 Its performance is also not that good. 535 00:31:01,420 --> 00:31:05,190 It wasn't actually faster than the hardware decoder. 536 00:31:05,190 --> 00:31:09,760 So, in the end I went back to the actual P25 specifications 537 00:31:09,760 --> 00:31:13,920 that I had and rewrote a clean implementation 538 00:31:13,920 --> 00:31:17,010 of the synthesis step. I just guessed the difference. 539 00:31:17,010 --> 00:31:21,253 Every time it says 20 ms I just put 10 ms. When there is 540 00:31:21,253 --> 00:31:26,016 a 512-bin FFT I just put 256 541 00:31:26,016 --> 00:31:29,920 and adapted stuff as I went. 542 00:31:29,920 --> 00:31:33,670 And the resulting code is in the git 543 00:31:33,670 --> 00:31:37,420 and you can decode voice. 544 00:31:37,420 --> 00:31:40,143 I think it works pretty well. 545 00:31:40,143 --> 00:31:42,676 You can hear some subtle differences 546 00:31:42,676 --> 00:31:45,370 compared to the original codec 547 00:31:45,370 --> 00:31:48,400 because DVSI did do a bunch of stuff to 548 00:31:48,400 --> 00:31:51,480 improve the voice quality. It's their whole business. 549 00:31:51,480 --> 00:31:55,630 And I didn't go through all of that. 550 00:31:55,630 --> 00:32:00,070 But… From my point of view, I'm done on this and I'm not 551 00:32:00,070 --> 00:32:03,470 gonna go any further. We have C code we can run. 552 00:32:03,470 --> 00:32:05,850 So. That's good. 553 00:32:05,850 --> 00:32:13,030 *Applause* 554 00:32:13,800 --> 00:32:16,610 Thank you. 555 00:32:16,610 --> 00:32:20,500 Next, we move on to the cipher. 556 00:32:20,500 --> 00:32:24,000 We didn't reverse engineer the cipher. 557 00:32:24,000 --> 00:32:27,520 That was done by a team at the Bochum university 558 00:32:27,520 --> 00:32:30,410 led by Benedikt Driessen. 559 00:32:30,410 --> 00:32:34,250 Right after we publ… After 28C3, basically… 560 00:32:34,250 --> 00:32:38,380 Actually, at 28C3 we already had some contacts with them but 561 00:32:38,380 --> 00:32:41,150 the paper wasn't published yet. 562 00:32:41,150 --> 00:32:44,620 And we actually have them validate their data and their attack 563 00:32:44,620 --> 00:32:46,360 using osmo-gmr. 564 00:32:46,360 --> 00:32:49,610 I definitely encourage you to read the paper that they published 565 00:32:49,610 --> 00:32:52,430 because the method they used. They are actually the ones 566 00:32:52,430 --> 00:32:56,610 who extracted the DSP image which we used to reverse engineer the codec. 567 00:32:56,610 --> 00:33:02,320 They were the first ones to extract it from the 568 00:33:02,320 --> 00:33:05,110 file that you can download online. 569 00:33:05,110 --> 00:33:08,780 And then, there is some pretty interesting stuff in there. 570 00:33:08,780 --> 00:33:11,460 As I said, they also published an attack on that cipher 571 00:33:11,460 --> 00:33:14,040 which is a ciphertext-only attack 572 00:33:14,040 --> 00:33:18,030 and I'll show some of the results later on. 573 00:33:18,030 --> 00:33:23,210 So, what does the cipher look like? Well, it looks like that. 574 00:33:23,210 --> 00:33:27,260 If you are familiar with A5/2 or even A5/1 575 00:33:27,260 --> 00:33:29,970 that should look very familiar because 576 00:33:29,970 --> 00:33:32,400 it's pretty much the same thing. 577 00:33:32,400 --> 00:33:36,090 So you have 4 linear feedback registers. 578 00:33:36,090 --> 00:33:40,060 The first 3 ones are combined using a nonlinear output function 579 00:33:40,060 --> 00:33:44,000 into the actual key stream. And then you have a 4th register 580 00:33:44,000 --> 00:33:48,120 which a few of the bits are tapped. They go to a nonlinear 581 00:33:48,120 --> 00:33:50,630 clocking function and that function is gonna determine 582 00:33:50,630 --> 00:33:54,650 how fast the other registers are clocked. 583 00:33:54,650 --> 00:34:00,310 So, not all registers advance at each output bit. 584 00:34:00,310 --> 00:34:05,280 And as I said, it is very similar to… it's actually a copy of A5/2 585 00:34:05,280 --> 00:34:08,109 except they changed every number like… they don't… 586 00:34:08,109 --> 00:34:11,320 the polynomial for the linear feedback registers are different, 587 00:34:11,320 --> 00:34:14,429 which bits are tapped to combine into the output are different. 588 00:34:14,429 --> 00:34:18,050 Same thing for R4 but it's the exact same structure 589 00:34:18,050 --> 00:34:23,000 which means we can reuse the attack that works on A5/2. 590 00:34:23,000 --> 00:34:27,099 This cipher obviously has an initialization step 591 00:34:27,099 --> 00:34:30,249 where you basically take the key and the frame number 592 00:34:30,249 --> 00:34:32,419 that you want to encrypt 593 00:34:32,419 --> 00:34:36,039 and you have some process to initialize 594 00:34:36,039 --> 00:34:37,940 the LFSR with those data. 595 00:34:37,940 --> 00:34:39,940 But really the only thing to retain 596 00:34:39,940 --> 00:34:42,918 is that the initialization process is entirely linear. 597 00:34:42,918 --> 00:34:46,465 There is some XOR and LFSR being involved. 598 00:34:46,465 --> 00:34:50,012 So that's pretty much… 599 00:34:50,012 --> 00:34:54,289 …the thing to remember. 600 00:34:54,489 --> 00:35:00,160 The actual irregular clocking only is applied when you 601 00:35:00,160 --> 00:35:05,819 generate bitstream for encrypting the frame. 602 00:35:05,819 --> 00:35:10,110 Since we are gonna talk about attacks on ciphers 603 00:35:10,110 --> 00:35:14,529 in some details there are a few things that you may not remember 604 00:35:14,529 --> 00:35:18,369 if you don't do algebra all the time. 605 00:35:18,369 --> 00:35:21,430 This is a very very quick reminder. 606 00:35:21,430 --> 00:35:26,410 So, you should know is that when you see GF(2) that's 607 00:35:26,410 --> 00:35:28,269 just a fancy term for binary. 608 00:35:28,269 --> 00:35:31,690 What we call addition in GF(2) is just the XOR operation. 609 00:35:31,690 --> 00:35:33,909 Multiplication is just the logic AND 610 00:35:33,909 --> 00:35:36,120 and you can do everything with that. 611 00:35:36,120 --> 00:35:39,930 If you accept those definitions, then algebra over binary 612 00:35:39,930 --> 00:35:43,740 is gonna be pretty much the same as algebra over real numbers 613 00:35:43,740 --> 00:35:47,480 and all the nice properties are gonna be applicable 614 00:35:47,480 --> 00:35:50,450 to binary math as well. 615 00:35:50,450 --> 00:35:53,859 I mentioned previously “linear” and I will mention it 616 00:35:53,859 --> 00:35:56,400 several times in the rest of this talk. 617 00:35:56,400 --> 00:36:00,559 When I say “linear” it's either a constant, 618 00:36:00,559 --> 00:36:03,680 or a variable or unknown multiplied by a constant 619 00:36:03,680 --> 00:36:07,710 but you never have two variables multiplied together 620 00:36:07,710 --> 00:36:13,340 because then it becomes quadratic and it's not linear anymore. 621 00:36:13,849 --> 00:36:18,400 Being linear has some nice properties like linear systems of equations 622 00:36:18,400 --> 00:36:22,859 we have very fast algorithms to solve them 623 00:36:22,859 --> 00:36:27,759 and every linear operation can be represented as matrix operation 624 00:36:27,759 --> 00:36:31,009 which is especially useful… we're gonna be dealing with 625 00:36:31,009 --> 00:36:34,369 hundreds of unknowns and spelling them out is not an option. 626 00:36:34,369 --> 00:36:38,409 We have to have some way of representing that and that's 627 00:36:38,409 --> 00:36:42,400 matrix operations, essentially. 628 00:36:42,400 --> 00:36:45,979 One other important thing to know is: 629 00:36:45,979 --> 00:36:50,330 When you have an operation that adds redundancy, for example, 630 00:36:50,330 --> 00:36:52,670 channel coding where you add the CRC 631 00:36:52,670 --> 00:36:55,140 or where you do convolutional coding, 632 00:36:55,140 --> 00:36:58,470 adding error correction adds redundancy to your message 633 00:36:58,470 --> 00:37:01,439 and when you have redundancy you can create what's called 634 00:37:01,439 --> 00:37:05,109 a parity check matrix to check if that redundancy in that present. 635 00:37:05,109 --> 00:37:07,549 So, for a CRC you check the CRC for example. 636 00:37:07,549 --> 00:37:10,750 But it can be generalized to anything that adds redundancy. 637 00:37:10,750 --> 00:37:14,240 It can be checked. And that becomes very useful to 638 00:37:14,240 --> 00:37:16,860 make the attack much faster. 639 00:37:16,860 --> 00:37:21,380 So, a little more detail about what the guys at Bochum did. 640 00:37:21,380 --> 00:37:24,599 They published a ciphertext-only attack 641 00:37:24,599 --> 00:37:27,640 that means you only need to capture data off the air 642 00:37:27,640 --> 00:37:30,000 and directly with that you feed it to the attack 643 00:37:30,000 --> 00:37:32,029 and it can give you the key. 644 00:37:32,029 --> 00:37:34,869 Their target was called TCH3 frames 645 00:37:34,869 --> 00:37:38,299 and those are traffic frames, they're what carries the voice 646 00:37:38,299 --> 00:37:40,860 which means you have a lot of them because 647 00:37:40,860 --> 00:37:43,670 as long as the conversation is still going, 648 00:37:43,670 --> 00:37:46,130 frames that are being generated constantly, 649 00:37:46,130 --> 00:37:48,950 several tens of them per second. 650 00:37:48,950 --> 00:37:52,119 They didn't start from nothing. As I said 651 00:37:52,119 --> 00:37:54,639 the cipher is heavily based on A5/2, so, 652 00:37:54,639 --> 00:37:57,359 it kind of makes sense to read the papers 653 00:37:57,359 --> 00:38:00,670 that were published about A5/2 attacks. 654 00:38:00,670 --> 00:38:05,809 The most interesting one and one of the most advanced one is called 655 00:38:05,809 --> 00:38:12,119 “Instant Ciphertext-Only Cryptanalysis of GSM encrypted communication” 656 00:38:12,119 --> 00:38:15,930 It's kind of math-heavy but 657 00:38:15,930 --> 00:38:21,290 it provides an attack on A5/2 that recovers the key instantly 658 00:38:21,290 --> 00:38:23,549 which is really nice. 659 00:38:23,549 --> 00:38:26,349 They modified this attack. They tweaked it for GMR-1 660 00:38:26,349 --> 00:38:28,359 because the frames are different. 661 00:38:28,359 --> 00:38:30,350 There's different amount of bits. 662 00:38:30,350 --> 00:38:32,740 The cipher is slightly different. 663 00:38:32,740 --> 00:38:34,910 And they also did something a little weird. 664 00:38:34,910 --> 00:38:37,160 They tried to guess more bits 665 00:38:37,160 --> 00:38:39,339 some of the bits they tried to brute-force. 666 00:38:39,339 --> 00:38:41,720 I'm not exactly sure why. 667 00:38:41,720 --> 00:38:44,369 I think it's to reduce the number of unknowns. 668 00:38:44,369 --> 00:38:47,930 But I don't know if it actually had the desired effect. 669 00:38:47,930 --> 00:38:52,339 And in the RUB paper they published their result: 670 00:38:52,339 --> 00:38:59,569 With 350 GB of precomputed data using 32 TCH3 frames 671 00:38:59,569 --> 00:39:03,260 they managed to recover the key in something like 40 minutes 672 00:39:03,260 --> 00:39:06,309 which is not bad, definitely, and it works. 673 00:39:06,309 --> 00:39:09,399 But the original attack is named “instant”. 674 00:39:09,399 --> 00:39:13,039 40 minutes isn't instant – to me, at least. 675 00:39:13,039 --> 00:39:17,979 So, we started looking for a better attack. 676 00:39:18,349 --> 00:39:21,630 We started off the same paper because it's kind of 677 00:39:21,630 --> 00:39:24,650 the state of the art of A5/2 attacks 678 00:39:24,650 --> 00:39:27,469 but we really didn't do anything fancy. 679 00:39:27,469 --> 00:39:32,890 We just used it exactly as they said in the original paper 680 00:39:32,890 --> 00:39:36,559 and we just did the necessary tweaks for A5/GMR-1, 681 00:39:36,559 --> 00:39:39,910 changing the matrix and the length of the vector, 682 00:39:39,910 --> 00:39:42,499 really nothing fancy. 683 00:39:42,499 --> 00:39:46,269 We also decided to attack a different type of channel 684 00:39:46,269 --> 00:39:49,390 and this is probably what makes the most difference. 685 00:39:49,390 --> 00:39:52,130 We decided to target FACCH3 control frames 686 00:39:52,130 --> 00:39:54,710 instead of the TCH3 voice frames. 687 00:39:54,710 --> 00:39:58,690 There is a very big advantage to targeting those frames. 688 00:39:58,690 --> 00:40:02,990 First, they use a different kind of modulation and training sequence. 689 00:40:02,990 --> 00:40:06,440 From an RF point of view they are much easier to receive. 690 00:40:06,440 --> 00:40:09,940 And that's pretty important if you're trying to mount an attack because 691 00:40:09,940 --> 00:40:12,660 as soon as you have a bit error in the reception 692 00:40:12,660 --> 00:40:15,409 it will make your equations inconsistent 693 00:40:15,409 --> 00:40:18,600 and you won't actually be able to solve for the key as easily. 694 00:40:18,600 --> 00:40:21,880 So, this is a very nice property of those frames. 695 00:40:21,880 --> 00:40:24,569 The other very nice property is that we have known 696 00:40:24,569 --> 00:40:28,779 plaintext on the FACCH3 channel, the control channel. 697 00:40:28,779 --> 00:40:31,559 There are some predictable frames that we know will there 698 00:40:31,559 --> 00:40:33,379 and we know where they will be. 699 00:40:33,379 --> 00:40:35,589 the voice traffic is completely unpredictable. 700 00:40:35,589 --> 00:40:37,500 It's someone talking. 701 00:40:37,500 --> 00:40:41,190 The control traffic will follow some very known patterns 702 00:40:41,190 --> 00:40:46,260 and I'll show an example of plaintext which is really trivial. 703 00:40:46,540 --> 00:40:50,210 Some other of the nice properties of the control channel is: 704 00:40:50,210 --> 00:40:53,249 There is much more redundancy. 705 00:40:53,249 --> 00:40:57,759 In TCH3 not all the bits are actually error-corrected 706 00:40:57,759 --> 00:41:01,220 which means you don't have that much information 707 00:41:01,220 --> 00:41:05,450 while for the control channel each layer-2 bit that you transmit 708 00:41:05,450 --> 00:41:09,809 is almost quadrupled before you put it on the air 709 00:41:09,809 --> 00:41:15,130 which means you can build a lot of equations very fast 710 00:41:15,130 --> 00:41:20,380 without many bursts. In the RUB attack they needed 32 frames, 711 00:41:20,380 --> 00:41:26,599 probably because there is not much redundancy in the TCH3 frames. 712 00:41:26,599 --> 00:41:30,420 And also, as a nice bonus that we discovered later is that 713 00:41:30,420 --> 00:41:34,279 the FACCH3 control channel is also used to negotiate 714 00:41:34,279 --> 00:41:38,089 other types of channels like the channels that are used 715 00:41:38,089 --> 00:41:42,890 when you send FAX or when you establish a data call 716 00:41:42,890 --> 00:41:44,840 over satellite networks. 717 00:41:44,840 --> 00:41:48,359 It's actually negotiated using that type of control channel 718 00:41:48,359 --> 00:41:51,109 which means the same kind of attack can work to crack 719 00:41:51,109 --> 00:41:54,900 not only voice but also data calls and FAX. 720 00:41:54,900 --> 00:41:58,380 This is an example of the plaintext. 721 00:41:58,380 --> 00:42:00,779 I don't know if you can really see it. 722 00:42:00,779 --> 00:42:03,249 But essentially on the top you have the cipher mode command 723 00:42:03,249 --> 00:42:06,150 the first line in blue is the cipher mode command. 724 00:42:06,150 --> 00:42:08,630 So everything after that is in theory ciphered. 725 00:42:08,630 --> 00:42:10,700 This is, of course, the enciphered view. 726 00:42:10,700 --> 00:42:13,910 And the three marked packets in gray and black 727 00:42:13,910 --> 00:42:15,839 are the very predictable texts 728 00:42:15,839 --> 00:42:19,200 and what they are is acknowledgements. 729 00:42:19,200 --> 00:42:21,170 Because of the delay on the GSM channel 730 00:42:21,170 --> 00:42:23,089 there is some outstanding acknowledgement 731 00:42:23,089 --> 00:42:27,759 that still need to be sent when the ciphering is turned on. 732 00:42:27,759 --> 00:42:31,569 You get empty packets with incrementing sequence number 733 00:42:31,569 --> 00:42:34,769 and the ACK bit set. 734 00:42:34,769 --> 00:42:37,160 Something changes in them, the sequence number, but 735 00:42:37,160 --> 00:42:41,209 as soon as you can count, predicting them is trivial. 736 00:42:41,209 --> 00:42:45,400 This definitely works in practice like 100% of the time. 737 00:42:45,400 --> 00:42:49,770 I never really had any problem with that. 738 00:42:50,740 --> 00:42:56,190 So, how do you build a plaintext attack? 739 00:43:03,810 --> 00:43:07,849 The general goal is… what you're trying to achieve 740 00:43:07,849 --> 00:43:11,529 is build a giant system of equations that's linear 741 00:43:11,529 --> 00:43:13,320 and that you can solve. 742 00:43:13,320 --> 00:43:16,710 It's gonna have the form A * x = b 743 00:43:16,710 --> 00:43:21,450 b is the cipher stream that is generated by A5/GMR-1 744 00:43:21,450 --> 00:43:26,299 x is some representation of the internal state of the cipher 745 00:43:26,299 --> 00:43:28,269 that you are trying to find 746 00:43:28,269 --> 00:43:31,130 and A is a giant matrix that you can precompute 747 00:43:31,130 --> 00:43:35,309 that's only dependent on the structure of the cipher. 748 00:43:35,309 --> 00:43:39,650 Each row of A and b are gonna represent one bit of the output 749 00:43:39,650 --> 00:43:44,999 and how to combine that internal state to generate that cipher stream bit. 750 00:43:44,999 --> 00:43:48,470 As I mentioned, the initialization process is linear 751 00:43:48,470 --> 00:43:51,329 and that's very important for two things. 752 00:43:51,329 --> 00:43:54,360 First, from the internal state of the cipher 753 00:43:54,360 --> 00:43:57,950 you're gonna be able to recover the key 754 00:43:57,950 --> 00:44:01,540 which is not entirely true. There is one bit of the key 755 00:44:01,540 --> 00:44:04,789 that you can't recover because that bit of the key 756 00:44:04,789 --> 00:44:08,499 turns out to have absolutely no effect on the output whatsoever. 757 00:44:08,499 --> 00:44:12,322 so, you can't recover it but doesn't matter either. 758 00:44:12,322 --> 00:44:14,925 The other thing is that 759 00:44:14,925 --> 00:44:18,499 you're gonna need to build a lot of equations. 760 00:44:18,499 --> 00:44:20,689 That system is gonna be big. 761 00:44:20,689 --> 00:44:23,670 In a single burst of data you won't have enough equations. 762 00:44:23,670 --> 00:44:25,660 You're gonna need multiple of them. 763 00:44:25,660 --> 00:44:28,649 But, of course, those multiple bursts are gonna have different 764 00:44:28,649 --> 00:44:31,060 frame numbers because they're sequential. 765 00:44:31,060 --> 00:44:33,790 They're not gonna wrap before a long time. 766 00:44:33,790 --> 00:44:36,620 But since the initialization is entirely linear 767 00:44:36,620 --> 00:44:40,599 you can actually derive equation from one frame number 768 00:44:40,599 --> 00:44:44,380 from an equation built out of another frame number. 769 00:44:44,380 --> 00:44:49,859 But, of course, it would be too easy. The cipher isn't entirely linear. 770 00:44:49,859 --> 00:44:53,419 so, we have to “linearize” it and 771 00:44:53,419 --> 00:44:57,150 when I first started looking at a crypto attack on A5/2 772 00:44:57,150 --> 00:45:00,010 in the paper it was always one line that said 773 00:45:00,010 --> 00:45:02,539 oh yeah, we linearize the cipher 774 00:45:02,539 --> 00:45:06,350 and they kind of always assumed the readers know what that means 775 00:45:06,350 --> 00:45:08,890 which I didn't at the time. 776 00:45:08,890 --> 00:45:12,490 So, I decided to be a little more explicit. 777 00:45:12,490 --> 00:45:16,720 The two nonlinear elements are the output function 778 00:45:16,720 --> 00:45:20,400 which uses a majority function where you take three bits 779 00:45:20,400 --> 00:45:24,390 and it outputs whichever bit is more common 780 00:45:24,390 --> 00:45:27,450 and you can rewrite that majority function as being 781 00:45:27,450 --> 00:45:30,970 the sum of a plus b multiplied by c 782 00:45:30,970 --> 00:45:37,190 or if you wish a XOR b AND c. 783 00:45:37,190 --> 00:45:41,210 And the problem is the b multiplied by c because 784 00:45:41,210 --> 00:45:43,779 that's quadratic, that's not linear. 785 00:45:43,779 --> 00:45:46,309 That means that we can't introduce that. 786 00:45:46,309 --> 00:45:50,029 And the way to linearize that is to kind of ignore it. 787 00:45:50,029 --> 00:45:54,070 For every possible quadratic term that's gonna be generated 788 00:45:54,070 --> 00:45:57,690 by that nonlinear output function 789 00:45:57,690 --> 00:46:00,170 you generate a new unknown. 790 00:46:00,170 --> 00:46:03,290 In reality that unknown isn't really unknown. 791 00:46:03,290 --> 00:46:06,719 It's a function of your other variables but 792 00:46:06,719 --> 00:46:10,170 you can't represent it in a linear fashion. 793 00:46:10,170 --> 00:46:15,359 So, you just ignore it and say “OK, this is a new unknown, deal with it”. 794 00:46:15,359 --> 00:46:18,640 Actually, there is a lot of possible combinations 795 00:46:18,640 --> 00:46:21,999 which adds 594 new unknowns to your equation system 796 00:46:21,999 --> 00:46:25,279 which means that you're gonna need a bunch more equations 797 00:46:25,279 --> 00:46:27,539 to be able to actually solve it. 798 00:46:27,539 --> 00:46:32,279 But at least it makes it linear. So, there is hope. 799 00:46:32,619 --> 00:46:39,969 The other nonlinear thing in that cipher is the clocking. 800 00:46:40,170 --> 00:46:44,220 As I said, all the LSFR don't advance at the same rate. 801 00:46:44,220 --> 00:46:50,380 Some are clocked once or zero times at each output bit. 802 00:46:50,380 --> 00:46:55,880 And this is a function of the value of R4 at that particular time. 803 00:46:56,160 --> 00:46:59,689 So, how do we linearize that? 804 00:46:59,689 --> 00:47:04,559 Well, R4 is a 17-bit linear feedback register. 805 00:47:04,559 --> 00:47:08,960 So, we can know all its future states from any… 806 00:47:08,960 --> 00:47:12,890 As soon as we have a good state at one particular time 807 00:47:12,890 --> 00:47:15,789 you can predict all the future states 808 00:47:15,789 --> 00:47:19,300 because it's clocked all the time. 809 00:47:19,640 --> 00:47:23,620 And in those 17 bits the initialization step forces 810 00:47:23,620 --> 00:47:25,869 one of those bits to one. 811 00:47:25,869 --> 00:47:28,650 So, there is only 16 bits that you don't know 812 00:47:28,650 --> 00:47:32,980 which means there is only 65536 possible clocking 813 00:47:32,980 --> 00:47:35,710 patterns for the cipher. 814 00:47:35,710 --> 00:47:40,400 So, the way we approach that is we just brute-force it. 815 00:47:40,400 --> 00:47:43,339 You just assume that R4 is gonna be equal to that value 816 00:47:43,339 --> 00:47:47,819 after the initialization and you just assume that 817 00:47:47,819 --> 00:47:52,779 and try to solve and crack the cipher by using that assumption. 818 00:47:52,779 --> 00:47:56,369 And if you find the Kc, well, then maybe it's the right one. 819 00:47:56,369 --> 00:48:00,980 You just repeat that 65536 times and most of the time 820 00:48:00,980 --> 00:48:04,190 if your guess about R4 is incorrect 821 00:48:04,190 --> 00:48:07,170 the system will end up being inconsistent 822 00:48:07,170 --> 00:48:10,799 and you won't actually have any solution. 823 00:48:10,799 --> 00:48:17,509 But this still requires solving 65536 systems 824 00:48:17,509 --> 00:48:22,409 which is fast but not that fast. 825 00:48:22,409 --> 00:48:28,190 There is actually a trick that we can apply to do better guesses. 826 00:48:28,190 --> 00:48:31,789 When you build these giant equation systems 827 00:48:31,789 --> 00:48:34,869 it turns out that some of the equations that you construct 828 00:48:34,869 --> 00:48:37,549 they are not gonna be independent. Some of them are 829 00:48:37,549 --> 00:48:40,369 gonna be related to each other. 830 00:48:40,369 --> 00:48:44,700 And so some of the rows are redundant. And what's nice is: 831 00:48:44,700 --> 00:48:49,020 If they're redundant we can actually test for that redundancy. 832 00:48:49,020 --> 00:48:52,539 For the 65536 possible systems that you need to solve, 833 00:48:52,539 --> 00:48:55,249 you also have an An * x = b 834 00:48:55,249 --> 00:48:59,319 there is a bunch of rows in An that are gonna be linear dependent. 835 00:48:59,319 --> 00:49:03,660 So, for each of them you can build a parity check matrix Hn 836 00:49:03,660 --> 00:49:08,299 so that you have this nice property of a parity check matrix 837 00:49:08,299 --> 00:49:12,779 where you multiply b by Hn and you get a zero matrix. 838 00:49:12,779 --> 00:49:16,109 But all those Hn, you can precompute them. 839 00:49:16,109 --> 00:49:19,860 That's the offline data of the attack. 840 00:49:19,860 --> 00:49:23,009 You precompute those giant matrices, 841 00:49:23,009 --> 00:49:29,369 then you take b which is the cipher text you got from the cipher, 842 00:49:29,569 --> 00:49:33,289 you multiply it by this matrix and if it gives you zero, 843 00:49:33,289 --> 00:49:37,069 you know that this particular R4 value might be correct. 844 00:49:37,069 --> 00:49:38,940 You don't know if it's correct or not, 845 00:49:38,940 --> 00:49:40,579 but at least it might be. 846 00:49:40,579 --> 00:49:43,830 If the result is non-zero then you know that R4 is definitely 847 00:49:43,830 --> 00:49:46,869 not the correct R4 and so instead of solving an entire 848 00:49:46,869 --> 00:49:50,190 system of equations the only thing you need to do is 849 00:49:50,190 --> 00:49:54,339 do one matrix multiplication and that is pretty fast. 850 00:49:54,339 --> 00:49:57,819 And in the end you're gonna have a couple of possible matches 851 00:49:57,819 --> 00:50:01,520 so you're gonna solve like maybe 3 or 4 systems of equations 852 00:50:01,520 --> 00:50:05,239 instead of solving 65536 and that's much much faster. 853 00:50:05,239 --> 00:50:09,739 Now, how do you go from a known-plaintext attack 854 00:50:09,739 --> 00:50:12,960 to a ciphertext-only attack? 855 00:50:12,960 --> 00:50:16,190 I'm not gonna detail that much but essentially 856 00:50:16,190 --> 00:50:19,880 the channel coding operation introduces redundancy 857 00:50:19,880 --> 00:50:23,730 and you can kind of null out that… 858 00:50:23,730 --> 00:50:26,980 if you take the last equation you have 859 00:50:26,980 --> 00:50:29,750 H multiplied by y plus g. 860 00:50:29,750 --> 00:50:34,220 H is a function of the channel coding. 861 00:50:34,220 --> 00:50:36,289 You can compute it. It's known. 862 00:50:36,289 --> 00:50:40,339 y is the data that you received off the air. 863 00:50:40,339 --> 00:50:42,250 So, you know it as well. 864 00:50:42,250 --> 00:50:45,579 g is also a function of the channel coding operation. 865 00:50:45,579 --> 00:50:50,039 So, you know it. So everything on the left you know. 866 00:50:50,039 --> 00:50:54,689 And the last value is H multiplied by A 867 00:50:54,689 --> 00:50:58,149 which is what you had in the known-plaintext attack, 868 00:50:58,149 --> 00:51:00,200 so you know it as well. 869 00:51:00,200 --> 00:51:03,189 And everything you don't know is x and so, again, 870 00:51:03,189 --> 00:51:06,369 you have a linear system of equations that you can solve. 871 00:51:06,369 --> 00:51:09,629 And the same R4 quick-scan method can be applied 872 00:51:09,629 --> 00:51:14,090 to scan very quickly and not have to solve everything. 873 00:51:14,320 --> 00:51:17,070 So, this is the result. 874 00:51:17,070 --> 00:51:20,970 If you use the fact that you know some plaintext 875 00:51:20,970 --> 00:51:24,009 you need about 50 Megabytes of data precomputed, 876 00:51:24,009 --> 00:51:27,179 you need to receive 8 bursts or even 4 if you 877 00:51:27,179 --> 00:51:30,509 by any chance have the right frame number alignment, 878 00:51:30,509 --> 00:51:33,110 and in like 500 ms you can get the key back. 879 00:51:33,110 --> 00:51:35,820 And that's on a 6 year old laptop. 880 00:51:35,820 --> 00:51:39,849 On any recent machine it's really instant. 881 00:51:39,849 --> 00:51:43,199 If you want to use the ciphertext-only variant, 882 00:51:43,199 --> 00:51:46,059 and honestly I really don't know why you would 883 00:51:46,059 --> 00:51:50,370 because the known-plaintext works, so you might as well use it. 884 00:51:50,370 --> 00:51:53,750 But if you want it purely for academic purposes, 885 00:51:53,750 --> 00:51:57,130 then you need 8 bursts, 886 00:51:57,130 --> 00:52:00,510 about 5 Gigabytes of data, 887 00:52:00,520 --> 00:52:03,590 and then it takes a little longer 888 00:52:03,590 --> 00:52:08,719 like about 1 second to recover the key. 889 00:52:09,189 --> 00:52:12,769 A few things I would like to look at in the future, 890 00:52:12,769 --> 00:52:15,099 is C-band. 891 00:52:15,099 --> 00:52:19,539 The satellite has to talk back to the earth station 892 00:52:19,539 --> 00:52:22,540 and this happens in a different frequency band 893 00:52:22,540 --> 00:52:25,046 and this is what we would like to look at, 894 00:52:25,046 --> 00:52:27,042 essentially, the feeder link 895 00:52:27,042 --> 00:52:29,639 If any of you have a large dish, satellite dish, 896 00:52:29,639 --> 00:52:32,689 and want to provide data for us please contact us, 897 00:52:32,689 --> 00:52:34,560 we're looking for it. 898 00:52:34,560 --> 00:52:38,369 We're also started looking into packet data 899 00:52:38,369 --> 00:52:41,299 and some other stuff. 900 00:52:41,299 --> 00:52:45,279 A quick note about other satellite phone systems, 901 00:52:45,279 --> 00:52:48,340 please don't assume that just because Thuraya GMR-1 902 00:52:48,340 --> 00:52:50,869 is broken that the others aren't unless you have 903 00:52:50,869 --> 00:52:53,009 actual proof that they aren't because the only 904 00:52:53,009 --> 00:52:55,609 reason we chose Thuraya is because the phone was 905 00:52:55,609 --> 00:52:57,659 the cheapest on eBay. 906 00:52:57,659 --> 00:53:01,660 So, given that all the satellite phone systems also… 907 00:53:01,660 --> 00:53:05,519 you know, you can find commercial interceptors for them, 908 00:53:05,519 --> 00:53:11,029 there is a big chance that they're not much more secure. 909 00:53:11,029 --> 00:53:13,869 I like to thank a few people: 910 00:53:13,869 --> 00:53:19,390 Dimitry Stolnikov, the main other author in osmo-gmr 911 00:53:19,390 --> 00:53:22,960 doing a bunch of the RF capture stuff, 912 00:53:22,960 --> 00:53:27,790 Dieter Spaar for reverse engineering of the AMBE codec 913 00:53:27,790 --> 00:53:30,079 and all the help he provided there 914 00:53:30,079 --> 00:53:33,089 and the RUB team, of course, for their support in 915 00:53:33,089 --> 00:53:35,470 reverse engineering the cipher, 916 00:53:35,470 --> 00:53:39,529 and the organizer for having me 917 00:53:39,529 --> 00:53:42,540 and thank you for your attention! 918 00:53:42,540 --> 00:53:46,509 *Applause* 919 00:53:46,720 --> 00:53:52,410 - Thank you very much! We now have time for a few questions. 920 00:53:52,410 --> 00:53:56,949 First, are there questions from the Internet? 921 00:53:57,529 --> 00:54:00,579 Not yet. So, if you have a question, please 922 00:54:00,579 --> 00:54:03,059 approach one of the microphones. 923 00:54:03,059 --> 00:54:05,559 Yes, please, microphone number 3! 924 00:54:05,559 --> 00:54:12,639 - Yes, I have a rather not technical but political question: 925 00:54:12,660 --> 00:54:17,720 So, you said in the beginning there was like a short 926 00:54:17,720 --> 00:54:20,690 way of communication that only the satellite transmits 927 00:54:20,690 --> 00:54:24,630 the voice data, so there is no ground station involved? 928 00:54:24,630 --> 00:54:30,369 - Yes. - Do you think that this might upset some of the people 929 00:54:30,369 --> 00:54:34,089 who like to intercept calls because it makes intercepting 930 00:54:34,089 --> 00:54:36,489 the voice data much more complicated 931 00:54:36,489 --> 00:54:39,279 than just going to ground station and say 932 00:54:39,279 --> 00:54:41,090 “I want to listen to this”? 933 00:54:41,090 --> 00:54:44,289 - First, just because the satellite will send the data back 934 00:54:44,289 --> 00:54:45,999 directly to their mobile phone 935 00:54:45,999 --> 00:54:49,049 doesn't mean the satellite can't also provide a copy 936 00:54:49,049 --> 00:54:52,589 of it to the earth station. It just doesn't go through. 937 00:54:52,589 --> 00:54:56,089 But the satellite can obviously send a copy of it if they want to. 938 00:54:56,259 --> 00:54:59,699 - And probably there will be a possibility for the ground station 939 00:54:59,699 --> 00:55:02,339 to say “Don't do that direction connection”. 940 00:55:02,339 --> 00:55:05,740 - On the other hand they can also just intercept it off the air 941 00:55:05,740 --> 00:55:07,919 because it's so easy to listen to it. 942 00:55:07,919 --> 00:55:10,920 Last year there was a talk with somebody 943 00:55:10,920 --> 00:55:13,799 that looked at satellite pictures 944 00:55:13,799 --> 00:55:17,120 and they saw that one of the spy satellites was relocated 945 00:55:17,120 --> 00:55:21,839 like right next to the Thuraya-2 satellite. 946 00:55:21,839 --> 00:55:25,059 You can look that up. It was a presentation last year. 947 00:55:25,059 --> 00:55:28,509 It was pretty interesting to see that… yeah… 948 00:55:28,509 --> 00:55:31,319 If you want to listen to it you can do it. 949 00:55:31,319 --> 00:55:32,899 - Thank you! 950 00:55:32,899 --> 00:55:37,060 - Next question from microphone number 2! 951 00:55:39,349 --> 00:55:46,349 - I've two questions: Can you hear both sides of the conversation 952 00:55:46,349 --> 00:55:50,250 or only one side of the conversation? The second question is: 953 00:55:50,250 --> 00:55:53,119 How big of a dish do you need? 954 00:55:53,119 --> 00:55:55,199 - If you want to receive L-band which is 955 00:55:55,199 --> 00:55:58,420 just listen to the communication from the satellite to the phone 956 00:55:58,420 --> 00:56:02,099 you don't need a dish, you need like a small antenna. 957 00:56:02,099 --> 00:56:05,960 You can even do it with a modified GPS antenna and a piece of metal. 958 00:56:05,960 --> 00:56:09,529 So, it's really easy and really cheap to do. 959 00:56:09,529 --> 00:56:13,059 You can only hear the the part of the conversation 960 00:56:13,059 --> 00:56:15,759 that comes from the satellite to the phone. 961 00:56:15,759 --> 00:56:20,140 So, if by any chance that guy is speaking to another phone 962 00:56:20,140 --> 00:56:24,226 you can hear both sides because you can intercept both 963 00:56:24,226 --> 00:56:26,992 channels simultaneously. 964 00:56:26,992 --> 00:56:30,000 But in general, you either 965 00:56:30,000 --> 00:56:34,349 only hear one side or you can also be close enough to the 966 00:56:34,349 --> 00:56:38,749 actual satellite phones to receive the uplink 967 00:56:38,749 --> 00:56:42,930 that goes from the phone to the satellite. 968 00:56:42,930 --> 00:56:46,149 Dimitry showed me like a commercial intercept system 969 00:56:46,149 --> 00:56:50,609 where apparently they use like planes to intercept the uplink. 970 00:56:50,609 --> 00:56:53,739 They just fly over the area of interest 971 00:56:53,739 --> 00:56:58,550 so they can more easily receive the uplink from the phones. 972 00:56:58,550 --> 00:57:00,879 - One final question. Please make it short 973 00:57:00,879 --> 00:57:02,919 because we are running out of time. 974 00:57:02,919 --> 00:57:05,079 - I'll try my best. 975 00:57:05,079 --> 00:57:08,170 Launching your own satellite is certainly not an option 976 00:57:08,170 --> 00:57:11,099 but do you see any practical applications 977 00:57:11,099 --> 00:57:16,289 in terms of what you did with GSM? 978 00:57:17,349 --> 00:57:20,949 - Not really. It would be interesting to try start a net 979 00:57:20,949 --> 00:57:24,409 because there is nothing that says that you have to be on a satellite. 980 00:57:24,409 --> 00:57:27,900 You could technically start a base station on earth 981 00:57:27,900 --> 00:57:31,549 using that protocol and it would work. 982 00:57:31,549 --> 00:57:35,009 And the phones have much more power than a GSM phone. 983 00:57:35,009 --> 00:57:38,440 But other than that, you could build an IMSI catcher 984 00:57:38,440 --> 00:57:40,790 for satellite phones if you wanted to 985 00:57:40,790 --> 00:57:44,250 and you'd definitely beat the signal strength of the satellite 986 00:57:44,250 --> 00:57:46,659 with your own setup. 987 00:57:46,659 --> 00:57:48,340 - Thank you. 988 00:57:48,340 --> 00:57:53,959 - Please give the speaker another round of applause! 989 00:57:53,959 --> 00:58:06,000 subtitles created by c3subtitles.de Join, and help us!