 Okay, so this talk will be by Sever Muno, who works with the Osmocom project. He will talk today about the Osmo GMR satellite phones. After the talk, there will be the opportunity to ask questions, so you can approach one of the microphones and then you have the chance to ask one question. So please give a round of applause to Mr. Sever Muno. Okay, hi. Thank you for being here. So as I said, I'm going to talk about satellite phones today. I'll first start with a quick recap of the previous work we've done at 28c3. There was a presentation on this subject, but there were some pieces missing, and so I'm just going to recap what we did previously and then move on to the new stuff, which is the speech codec and the cypher reverse engineering and cracking that's been done. So first, what is GMR exactly? Well, GMR stands for Geomobile Radio, and it's an ETSI standard for satellite phones. It's heavily inspired from GSM, and if you read the GMR specs, there's plenty of reference to go see the GSM spec. There's actually two standards named GMR, GMR1 and GMR2. They are not evolution of one another, they're competing standard that have just been developed by distinct companies, and then both have been standardized through ETSI. Today we're going to be looking at GMR1. That comes in three evolutions. It started with just plain old GMR1, which is voice calls and SMS. It evolved to include packet data, and that's called GMPRS, and then there was a later evolution to interconnect with the 3G core network and improve the air interface and stuff like that, and that's GMR1-3G. But we'll be mostly looking at the first version, which is still used. Among the deployments, the one we focused on was Teriah. The reason why is that it's the most common commercial operator, where you can actually buy, see, and place phone calls. The satellites are visible from Europe, which is kind of a requirement for me to look at the signal. This operator is mostly active in the Middle East, Asia, and Africa. In Europe, you don't see too many people with satellite phone, just because we have GSM coverage. But there are other operators, and we actually read recently that there is a new deployment planned for Europe called Solaris Mobile, and they said they're going to use GMR1-3G, but the satellite isn't launched yet, so. So this is the coverage zone for Teriah. As you can see, Europe is very well covered, so there's no problem if you want to receive the signal. If you're somewhere in that area, you can see it. So since it's so heavily inspired by GSM, it kind of makes sense to compare it to it. The first thing they did is they renamed everything. So basically instead of a base transceiver station, you have a geotransceiver station. Instead of a base station controller, you have a geostation controller. Instead of a mobile station, you have a mobile Earth station. Then they did some actually useful stuff, like new specialized features for satellites. The first one is terminal to terminal calls. So when you're usually placing a call, the signal goes from your satellite phone to the satellite. Then it goes back to the core network on Earth, and then if you're calling another satellite phone, it would have to again go back up to the satellite and back to the other phone. And that means that you pay four trips from Earth to space. And since the satellite is in geosynchronous orbit, it's pretty far away. And so to kind of reduce the delay in communication, there's the so-called terminal to terminal calls where the core network will still handle establishing the channel and stuff like that. But once the core is established, the data is going to directly go from one phone to the satellite and directly back down to the other phone without any involvement from the network. It never even sees the packets. There's also this code called eye penetration alerting. That's because, I mean, like in the movies, you see people using satellite phones in bunkers and stuff like that. In practice, as soon as you're inside, you can't see the satellite and you can't place a call at all. But you still might want to be able to at least, you know, you can't pick up the phone, but you want to know that somebody is calling you. And so they have this specialized channel which has an incredible amount of error correction on it so that even with very, very low signal, you can still get an indication, yes, somebody is trying to call you. Please run outside so you can take the call. There's also a very tight integration to GPS. Like, for example, all the American Infirmary's data are actually broadcasted by the Theraeus satellite so that your phone can get a lock faster. And when you place a phone call, the very first thing that your phone will do is send your exact GPS coordinates in clear to the operator. And they do this for two reasons. The first one is if you're not on the right frequency for this particular geographic location, they can tell you, OK, you shouldn't be connecting on this frequency. Use this one. It has a much better signal and you'll get better quality. That's one reason. The other reason is purely commercial is for billing. Because like if you're calling while you're in certain countries, it's going to cost more than if you're on the other side of the border and so they need to know where you are to bill you correctly. And then compared to GSM, of course, they introduced the two things we're going to look at today. They changed the speech codec to something called AMBE. And they changed the cypher. They're not using A51 or A52 or A53 or that kind of stuff. They used something called A5GMR1. So if you look at the protocol stack, anything in the lower layer, so radio modulation, TDMA frame structure, all that stuff, it's completely different because you have to deal with the particular of the satellite communication. So you find the same kind of concept and you find the control channels and broadcast channels and that kind of stuff. But their implementation is different. If you go up one layer to the data link layer, you have something very similar to LAPDM against the needed some minor adaptation because bandwidth costs a lot on the satellite. They reduce the size of the overhead by reducing the error. And since you have so much delay, I mean, going from your phone to the satellite, then back down to the earth station, then again to your phone, you have something like, I think it's nearly 500 milliseconds of delay because you have basically four, no, 250 milliseconds, sorry, because you have both paths up and down. And so with that delay, you need more time for the acknowledgement to actually come in and stuff like that. So to increase the window size. Anything above that, so layer three, radio resource, since it's managed the radio channel is still a bit different. But anything above that is strictly the same as GSM. It actually interoperates with the GSM core network, which means I can take my Belgian operator SIM, put it in a Terrier phone and I can roam onto the satellite and place calls and stuff like that, which is really nice, except for the price you pay at the end of the month. For packet data, it's essentially the same thing. Anything that's close to the lower level like RLC and Mac, it's gonna be different. Anything above actually interoperates with GSM, so you're gonna be speaking to a GSM core network and SGSN and GGSN and all that good stuff. So Osmo GMR, so what we presented last time, essentially everything you needed to go from RF to Wireshark. That includes the hardware setup, or you can build an antenna, what LNA to use, what SDR receiver to use. At that time, we didn't actually have HL-SDR, which are the cheap DVB dongle you can use as SDR. Nowadays we do, which mean that for less than 100 bucks, you can get an antenna, LNA and SDR receiver and all that way you need to actually listen to those signals. Then we did all the SDR processing, which is taking that raw data, filtering it, selecting the channel, doing the modulation, getting actual data bits out of it. Then channel coding, which is converting those data bits into layer two frames. Then interpreting those layer two frames into channel assignment and follow those assignments and that kind of stuff into a demonstration application. And finally the Wireshark de-sector, which takes all of this and presents it nicely in a way you can actually read stuff. But there's two things we couldn't do is, first we couldn't see past the Cyphering mode command, which when as soon as Cyphering was enabled, we couldn't see anything because we knew the key because it was our own course and we can read the key from the SIM, but we didn't know the algorithm that was used to Cypher so there was no way for us to decipher that. And we also had no way to get the voice data, converting the frame into actual audio that we can listen to, we couldn't do that and that's what we're gonna look into. So the first thing is the speech collect. It's called AMBE for advanced multiband excitation. It's not a codec in itself, AMBE is not a codec in itself, it's more a family of codecs, which means you have several codecs which are named AMBE, which are actually different version of one another, slightly different so that they're not compatible. It's not documented in the standard, which is really annoying when I started working on GMR, I really thought that the codec was in there and when I discovered it wasn't, that was a bad day. There is a bit of specification in there, but it only gives a high level description like, okay, the codec takes audio as input and produce 80 bits of output every 20 milliseconds or stuff like that, but nothing that can be used to realistically implement the decoder. So that codec is made by a company, DVSI Incorporated, whose entire business is codec sets, that's all they do. Basically, which is probably why there's different incompatible version of AMBE is because they can sell different versions. These guys, they do sell like a small USB stick that can decode some of the variants. For example, you can decode D-star audio, which is also another AMBE codec or a P25, which is used in low-enforcement radio in the US. It's also an AMBE variant and the cheap USB stick can decode that. Unfortunately, it's incompatible with the GMR-1 variant because that's the first thing I did is I contacted DVSI to know what were my options. And basically, the short of buying a source code license, which is just too expensive, is buying the appliance, which is called Net2000. And not only does it cost like 2,000 euro, which is way too much for a hobby project, but you also have to special order it with a GMR-1 firmware, and you have to sign some non-reverse engineering agreement or that kind of stuff, which that wasn't an option. We still had some hope. The first hope we had is that, as I said, P25 uses an AMBE variant of Codex as well. And this particular variant is actually documented. So you can download the standard for that particular variant of AMBE and you have all the math and all the specs so you can write the decoder. And somebody actually wrote the decoder, which is open source, which is called mbeleave. And so we could use that code as a base, possibly to modify it or something. So that was the lead. The other lead, of course, is that the Codex is somewhere in the phone. I mean, the phone is obviously capable of decoding audio, so maybe we can find it in there. But before we can start searching for the Codex, it's good to have a basic understanding of how the Codex works so that we know what we're looking for. The first thing to understand, it's a vocoder. It's not a general purpose audio Codex, which means if you try to fit it music or stuff like that, it's gonna perform horribly. Because a general purpose audio Codex will try to model what you are here, can actually hear and what it can't. Well, on the other hand, a vocoder is gonna try to model the speech and reconstruct something that sounds like, but it's not actually the same thing. Like, they will drop a lot of information. To do that, the first thing they do is they split your speech into small segments which are compressed independently. In the case of GMR1, those segments are 10 millisecond long and they're combined by pair and each pair is compressed into a single frame. And then for each of those small segments, they will represent it in four parameters. Those four parameters are the pitch, which is essentially the fundamental frequency at which you, of the periodic component of your voice, if you will, the gain, which is what you're talking, of course, something called voice and unvoiced decision. We're gonna see what this is right after. But essentially for, you have the fundamental frequency then for each harmonic, so two times the frequency, three times the frequency, four times frequency, you have a bit that says, okay, is that component voiced or unvoiced? And then you have the amplitude for the various harmonics. So you have those parameters and if you want to actually play back the voice, you have to do three things. The first thing is unpacking and that's taking the 80 bits of the voice frame and reconstruct quantized parameter from it. So all the parameters are not just put in order one after the other because some of the bits in a frame will receive more error correction than others and some of the bits are more sensitive to errors than others and so there will be place at specific places in the frame so that if error do happen, hopefully it will affect something that is not too important. So that's the unpacking step. The second one is decontization and that's going from those quantized compressed parameters into actual floating point value or integer values which represent the real parameters that can be used for the last step, which is synthesis and synthesis is taking those parameters and reconstructing actual audio that sounds like the original voice. And so to do a quick overview of the synthesis step, what you do is you take for each possible harmonic, so F0, 2F0, 3F0, you have the voiced and unvoiced decision and what voiced means is that you're gonna reconstruct that particular frequency as a pure sinusoidal tone and if it's unvoiced you're just gonna fill that small bend with noise essentially and with that they can actually reconstruct human voice pretty well. So now that we know more or less how the codec works and what we're looking for, we can start looking at where are we gonna find this codec. The phone we looked at is the Toraya SO2510 and we looked at it mostly because it was the cheapest phone on eBay and that also means it's the simplest which means you have less places to look into. Now, we knew it was, the codec was in the DSP and how did we know that is that there's simply no other places it could be. There are a bunch of chips on that phone of course. There's only two where it could possibly be is the TI OMAP main processor and then there also have like a small ASIC which is named the Dalma ASIC because there's a big Dalma marking on it and at first we actually thought that that chip was the AMB codec but it turned out that we found some Korean paper from the phone manufacturer that described the phone architecture and actually has a schematic of the internal of that ASIC and it showed that it only had like satellite radio functions and absolutely nothing to do with the codec which means there was a good chance it was in the TI OMAP processors and why in the DSP? Well, because it just makes sense to make the codec in the DSP especially since DVSI, the company that actually makes the codec mostly sells those codec as DSP pre-compiled library that you can buy. So pretty standard process. We get the firmware update from the internet. From there we can extract an actual DSP image which is the code which is loaded in the DSP. Thankfully it's supported by IDA which makes the whole process easier to reverse engineer but it's still like 250 kilobytes of binary data and since it's the DSP, it has no IO which means there is absolutely there's not a single string in it and also it's a DSP which means it's written in DSP assembly and I don't know if you've ever tried to read that but it's not the most understandable thing in the world because it's highly optimized for speed, of course. And I actually looked at that code and went over it a few times and took a few hours and looked at it and I couldn't see anything in it. And one day I get an email from a colleague in the NLSMACOM, Ditaspar, asking me, yeah, if I had ever looked at that codec and I told him, yeah, I looked very accurately fine and I think, do you see anything? And like six hours later he sent me, oh yeah, I think this is the entry point for the encoding and the coding functions. Oh, okay, good. And the way he found that essentially at least from what I remember is that you look at what would a codec use, you know? And of course it's gonna access the audio path so you can look at the audio DMA setup and audio DMA interrupts. You can also look for constants that you know are used in the codec. So for example, I said that the frames are 80 bits so you can look for constant 80 somewhere in the code. You can look at, it will produce I think 160 samples per audio samples per frame decoded so you can look at the constant 160. That kind of stuff and once you actually found one function there's something that kind of stands out is that since they shipped that as a binary library they don't really trust the guy who implement the rest of the DSP code to set up the C run time properly and so what they do is they switch everything at each call into the codec is that they switch the stack and they reconfigure the C run time and that kind of stuff so that it's really independent. So once you find one function, finding the other is pretty easy because you can just look for that particular function, how is it called? Prelude or something that happens at each call at the audio library. Okay, so we know where the code is but it's still a massive amount of code. I mean, I think it's like one third of the DSP code is the audio codec so it's not something you can easily reverse engineer in a few hours. So before trying to actually reverse engineering we just tried, okay, maybe we can just run it. It turns out that TI has this really nice program called TI Code Composer Studio which includes a simulator and it's a really nice piece of software because not only can you pretty accurately simulate any of the DSPs, you can also completely configure the surrounding environment in which it runs so you can set up arbitrary memory map. You can also trace all memory access to see what part of memory is being read or being written or being executed, that kind of stuff. You can also actually access file on your host file system so you can use fread and fwrite and the simulator will automatically translate those calls into actual reading from your hard drive and write to your hard drive so you can just read a compressed file that you saved and it will write an audio web with file at the output. And the way to do that is pretty straightforward. I mean, you essentially just need to take the binary dump that you have from the firmware update and you need to find a way to mix in with your own custom code. The way to do that is basically you just create a new object file like you would create an ELF except in this case it's called a COFF for a common object file format but it's the same idea and you can just link to it like you would link to any piece of binary. You write a simple main function that will basically fread your compressed samples, call you the decoding function or at least what you hope is the decoding function and fwrite the audio samples. And surprisingly it actually worked and it worked pretty, it didn't require that much effort I think in like a couple of days it was all working. It didn't work on the first try, it was a couple of pitfalls and stuff like that but essentially the ID is there and that's probably something that can be applied to other things as well. Now of course there's some pretty big downsides that first it's pretty slow, definitely sub-real time even on a modern laptop. It also requires a TI code composer studio which is a Windows application and also not free so you have like a 30 days evaluation period but that's about it. So it's really not that practical. But I mean it was running in the simulator so there's no real reason it can't run on real hardware. So of course that's what we try next. Now unfortunately on real hardware you can't just put memory anywhere you want. In when the codec runs in the phone it actually runs inside an TI OMAP which is an ARM plus a DSP and that chip has an MMU which means you can create any virtual memory you want but if you're trying to run on a cheap DSP board that you can get for like 50 bucks or something those usually don't include an MMU at all which means you need to find a board which has memory at the right places because the binary you have it's been written to I mean it's been linked to a specific physical address and it needs to run at that particular addresses. Thankfully Deter found one such board with a compatible memory map and it had a SD RAM where we needed it to have some memory. It also included ethernet which means we can make some networked appliance where we submit samples and get them back and that kind of stuff. That was really nice and the process of migrating the code from the simulator to the board is actually pretty smooth because of the way the code composers studio works. You just basically set it as a target and since the memory was at the right place it pretty much worked. Now it wasn't quite as fast as we wanted because it was only about running about real time at the first try and that's because SD RAM is slow especially when you do a bunch of random accesses the SD RAM isn't really fast and the codec unfortunately has a lot of big data tables which are accessed constantly like to compute cost indices and stuff like that. So what Deter did is basically identify a couple of those big tables that are accessed very often and then just migrate them to internal SRAM. You just find one or two places where the code reads from those tables and just patch the address to another address and redirect it to there and then get the code running much faster about 16 times faster than real time. And honestly that was good. I wasn't really planning on doing anything else on the hardware and so I ordered the same board except I didn't. I somehow ended up clicking on the wrong button at the I store or something and when the board arrived I didn't have the right one. And at that point of course I had two choice I could just order the same board and just wait one more week or I could try to run the code in it anyway. Now the second board didn't have Ethernet at USB but most importantly it didn't have any SD RAM at all it only had internal SRAM and unfortunately not at the right address. So I just figured okay I'm just gonna try to relocate the binary and make it run under the right address so hard can it be. It turned out to be pretty straightforward because I think in less than a day it was running and that's really thanks to IDA Python and the simulator. Basically what I did is in IDA Python which is the scripting language for the IDA reverse engineering software you can basically iterate through all the upcodes then for that upcode you test okay is there an absolute memory reference somewhere in that upcode? If no, well then don't do anything. If there is an absolute memory reference is that reference falling somewhere in a place that I'm trying to relocate or not? If it is a place I'm trying to relocate then just patch that upcode and change the absolute memory reference to well the new place. Go through all the code like that and try to run it. Of course I didn't walk the first time around because there was a couple of pitfalls in that approach but using the simulator it was pretty easy to find out where things were going wrong because you take the original code you run it in the simulator and you trace every memory access. Then you take your potentially relocated code you run it again in the simulator and trace every memory access and I mean you're decoding the same frame it should be determinist and so you should have the exact same memory access patterns in both cases and as soon as you see that they're diverging you know that somewhere a branch wasn't taken or something went wrong and you can go at that place in the code look and see why the relocation didn't work. And it only took I think two tries or something to have the code running and it was running on my board and I didn't have to order a new one which was pretty nice. So we have a hardware USB decoder which is you know very useful but you still have to carry it around or if it plugged on a network server or something which isn't necessarily something you want. So I wanted something I could check out in the get basically. So I started reverse engineering the entire codec. Now it turned out to be very painful as I said to reconstruct audio you have three main steps. The first one is unpacking and it's just basically bit shuffling this is like the first thing the codec does which means it's really easy to find and it's really easy to follow so no problem there. The second step is decontization and it took like 95% of the work because it's a lot of math. It's all written in DSP assembly in fixed points and sometimes you're looking at a function and to figure out what that function does you basically have to run it with different parameters and stuff like that to see what does that thing compute. Graphing is really useful for that you just feed some inputs in the simulator see what output is generated and just plot it in a in pile up or something and then you can see oh okay so that actually computes a logarithm or something. So but I mean there's still a lot of code there and there was no other option for that part because the quantization step is completely specific to GMR it's not shared with any of the other AMB variants. The synthesis part is even more complicated it's even more code in the DSP but I really didn't want after finishing the decontization I really didn't want to do the synthesis so I just kind of assumed that the synthesis step was gonna be very similar to the one in P25 so I took the MPLA existing open source code for P25 I ripped out the unpacking and decontization out of it that's because it's the one for P25 of course I just plugged my own implementation and run it through the synthesis. I mean it's not, just a couple of things you need to take care of mostly because P25 uses 20 millisecond frames GMR uses 10 millisecond frames so I basically dropped one frame every other frame in GMR and just used the 10 millisecond parameter to synthesize 20 milliseconds of speech but it produced something where you could follow a conversation and it worked. I wasn't really, I was still not really happy about it because the code quality of MBLA is really not that good its performance is also not that good it wasn't actually faster than the hardware decoder so in the end I just went back to the actual P25 specifications that I had and rewrote a clean implementation of the synthesis step I just guessed the difference basically every time it says 20 milliseconds I just put 10 milliseconds when there is a 512 bin FFT I just put 256 and I had adapted stuff as I went and the resulting code is in the get and you can decode voice it works, I think it works pretty well you can hear some subtle difference compared to the original codec because DVSI did do a bunch of stuff to improve the voice quality I mean it's the whole business and I didn't go through all of that but there was, I mean from my point of view I'm done on this and I'm not gonna go any further we have decode that we can run so that's good, thank you so next we move on to the cipher now we didn't reverse engineer the cipher that was done by a team at the Bokim University led by Benedict Driessen right after 28 C3 basically actually at 28 C3 we already had some contacts with them but the paper wasn't published yet and we actually helped them validate their data and their attack using Osmo GMR I definitely encourage you to read the paper that they published because the method they used they're actually the one who extracted DSP image which we used to reverse engineer the codec they were the first one to extract it from the file that you can download online and then there's some pretty interesting stuff in there as I said they also published an attack on that cipher which is cipher text only attack and I'll show some of the results later on so what does the cipher look like? Well it looks like that if you're familiar with A52 or even A51 that should look very familiar because it's pretty much the same thing so you have four linear feedback registers the first three ones are combined using a non-linear output function into the actual key stream and then you have a fourth register which a few of the bits are tapped they go through a non-linear clocking function and that function is going to determine how fast the other registers are clocked so not all registers advance at each output bit and as I said it's very similar to it's actually a copy of A52 except they change every number like the polynomial for the linear feedback registers are different which bits are tapped to combine into the outputs are different same thing for A4 but it's the exact same structure which means we can reuse the attacks that work on A52 the cipher obviously has an initialization step where you basically take the key and the frame number that you want to encrypt and you have some process to initialize the LFSR with those data but really the only thing to retain is that this initialization process is entirely linear there's only XOR and LFSR being involved so that's pretty much the thing to remember the actual irregular clocking only is applied when you generate bit stream for encrypting the frame now since we're gonna talk about attacks on ciphers in some details there's a few things that you may not remember if you don't do algebra all the time and so this is a very, very quick reminder so what you know is that when you see GF2 that's just a fancy term for binary what we call addition in GF2 is just the XOR operation the multiplication is the logic end and you can do everything with that and if you accept those definitions then algebra of a binary is gonna be pretty much the same as algebra of real numbers and stuff like that and all the nice properties are gonna be applicable to binary math as well now I mentioned previously linear and I will mention it several times in the rest of this talk when I say linear it's basically it's either a constant or a variable or unknown multiplied by a constant but you never have two variable multiplied together or that kind of thing because then it becomes quadratic and it's not linear anymore being linear has some very nice properties like linear systems of equations we have very fast algorithm to actually solve them and every linear operation can be represented as matrix operation which is especially useful if you're dealing I mean we're gonna be dealing with hundreds of unknowns just spelling them out is not an option we have to have some way of representing that and that's matrix operation essentially one other important things to know is when you have an operation that adds redundancy for example channel coding where you add a CRC or where you do convolutional coding adding error correction adds redundancy to your message essentially and when you have redundancy you can actually create what's called a parity check matrix to check if that redundancy is in that present so for a CRC it would check the CRC for example but it can be generalized to anything that adds redundancy can be checked and that becomes very useful to make the attack much faster so a little more detail about what the guys at Bochum did they published a cipher text only cipher that means you only need to capture data of the air and directly with that you feed it to the attack and it can give you the key the target what's called TCH3 frames and those are traffic frames they're basically what carries the voice which means you have a lot of them because I mean as long as the conversation is still going you have frames are being generated constantly several tens of them per second they didn't start from nothing as I said the cipher is heavily based on A52 so it kind of makes sense to read the papers that were published about A52 attacks the most interesting one and one of the most advanced one is called the instant cipher text only cryptanalysis of GSM and cryptid communication it's kind of math heavy but it's it provides a take on A52 that's rock over the key as I said instantly which is really nice but they actually modified this attack they tweaked it for GMI1 because I mean the frames are different there's different number of bits the cipher is slightly different and that kind of stuff and they also did something a little weird is that they tried to guess more bits some of the bits they basically tried to brute force them I'm not exactly sure why I think it's to reduce the number of unknowns but I don't know if that actually had the desired effect and in the rub paper they published their result and basically with 350 gigabytes of pre-computed data using 32 TCH3 frames they managed to recover the key in something like 40 minutes which is not bad definitely and it works but I mean the original attack is named instant 40 minutes isn't instant to me at least so we started looking for a better attack now we started off the same paper essentially because it's kind of the state of the art for A52 attacks but we really didn't do anything fancy we just used it exactly as they as they said in the original paper and we just did the necessary tweak for A5 GMR1 we're just you know changing the matrix and the length of the vectors and that kind of stuff really nothing fancy we also decided to attack a different type of channel and this is probably what makes the most difference is we decided to target FACCH3 control frame instead of the TCH3 voice frames now there is a big very big advantage to targeting those frames is first there is a different kind of modulation and training sequence and from an RF point of view they are much easier to receive and that's pretty important if you're trying to mount an attack because as soon as you have a bit error in the reception it will basically make your equations inconsistent and you won't actually be able to solve for the key as easily so these are very nice properties of those frames the other very nice property is that we have known plaintext in I mean on FACCH3 channel on the control channels there's some very predictable frames that we know will be there and we know where they will be the voice traffic is completely unpredictable it's someone talking the control traffic will follow some very known patterns and I'll show some example of plaintext which is really trivial some other of the nice properties of the control channel is there's much more redundancy I mean in TCH3 not all the bits are actually error corrected which means you don't add that much information while for the control channel each bit that you try each layer 2 bit that you transmit is almost quadrupled before you you put it on the air which means you can build a lot of equations very fast without without the many bursts I mean in the rubber tag debasin they need a 32 frames that's probably because there is not that much that much redundancy in the TCH3 frames and also as a nice bonus that we discovered later is that the FACCH that control channel is also used to negotiate other types of channels like the channels that I use when you send FACCHs or when you send when you when you establish a data call over the satellite networks it's actually negotiated using that type of control channel which means the same attack can actually work to crack not only voice calls but also data calls and FACCHs so this is an example of the plain text I don't know if you can really see but essentially on the top you have the cipher mode command the first line in blue is the cipher mode command so everything after that is in theory ciphered of course is the uncycled view and the three marked packets in gray and black are the very predictable text and what they are is basically just acknowledgement because of the delay on the GSM channel there is some outstanding acknowledgement that still need to be sent once the ciphering is turned on and so you get basically empty packets with just incrementing sequence number and the akbit set and so something changes in them is the sequence number but you just as long as you can count predicting them is trivial and this definitely works in practice like 100% of the time never really had any problem with that okay so how do you build a plain text attack the general goal is what you're trying to achieve is build a giant system of equation that's linear and that you can solve and it's going to have the form a multiplied by x equal b b is the cipher stream that's generated by a5gmr1 x is some representation of the internal state of the cipher that you're trying to find and a is a giant matrix that you can pre-compute that's only dependent on the structure of the cipher essentially and each row of a and b are going to basically represent one bit of the output and how to combine that internal state to generate that cipher stream bit now as I mentioned the initialization process is linear and that's very important for two things is that first from the internal state of the cipher you're going to be able to recover the key which is which actually is not entirely true there is one bit of the key that you can't recover because that bit of the key turns out to have absolutely no effect on the output whatsoever so you can't recover it but it doesn't matter either so and the other thing is that you're going to need to build a lot of equation I mean that system is going to be big and in a single burst of data you won't have enough equations you're going to need multiple of them but of course those multiple bursts are going to have different frame numbers because they're sequential and they're not going to wrap before a long time so but since the initialization is entirely linear you can actually derive equation from one frame one frame number from equation built around another frame number but of course it would be too easy the cipher isn't entirely linear so we have to linearize it and when I first started looking at a crypto attack on A52 in the paper it was always one line that said oh yeah we linearized the cipher and they kind of always assumed that the readers know what that means which I didn't at the time so I decided to get a little more explicit so the two non-linear elements are the output function which uses a majority function where basically you take three bits and it outputs the whichever bit is more common and you can rewrite that majority function as being the sum of A plus B multiplied by C or if you wish eggs or B and C and the problem is the B multiplied by C because that's quadratic that's not linear that means that we can't introduce that and the way to linearize that is basically to kind of ignore it for every possible quadratic term that's going to be generated by that non-linear output function you generate a new unknown I mean in reality that unknown isn't really unknown it's kind of a function of some other your other variable but you can't represent it in a linear fashion so you just ignore it and just say okay this is a new unknown and deal with it and for me it is kind of there's a lot of possible combination which adds 594 new unknowns to your equation systems which means you're going to need a bunch more equations to be able to actually solve it but at least it makes it linear so there is hope the other non-linear thing in that cipher is the clocking as I said all the LFSR don't advance at the same rate some are clocked once or zero time at each output bits and this is a function of the actual value of air4 at that particular time so how do we linearize that well air4 is a 17-bit linear feedback register so we can know all its future state from any I mean as soon as you have a state at one particular time you can predict all the future states because it's clocked all the time and in those 17 bits the initialization step actually forces one of those bits to one so there's only 16 bits that you don't know which means there is only 65,536 possible clocking pattern for this cipher and so the way we approach that is we just brute force it you just assume that air4 is going to be equal to that value after the initialization and you just assume that for the and try to solve and crack the cipher by using that assumption and if you find a kc well then maybe it's the right one you just repeat that 65,000 times and most of the time if the air4 if your guess about air4 isn't correct the system will end up being inconsistent and you won't actually have any solution but I mean this kind of still requires solving 65,000 systems which is you know fast but not that fast so there is actually a trick that we can apply to do better guesses when you build this giant equation systems it turns out that some of the equation that you that you construct they're not going to be independent some of them are going to be related to each other and so some of the rows are redundant and what's nice is if they're redundant we can actually test for that redundancy and so for the 65,000 possible systems that you need to solve you saw you have an a n multiplied by x equal b there's a bunch of row in a n that are going to be linearly dependent so for each of them you can build a parity check matrix hn so that you have this this nice property of parity check matrix where you multiply b by hn and you get a zero matrix but all those hn you can pre-compute them that's the essentially the offline data of the of the attack you pre-compute those giant matrices and then you take b which is the the cipher text you got from the cipher you multiply it by this matrix and if it gives you zero you know that this particular f value might be correct you don't know if it's correct or not but at least it might be if the result is non-zero then you know that f4 is definitely not the the correct f4 and so instead of solving an entire system of equation the only thing you need to do is do one matrix multiplication and that is pretty fast and in the end you're going to have a couple of possible matches so you're going to solve like you know maybe three or four system of equations instead of solving 65 000 and that's much much faster now how do you go from you know known plaintext attack to a cipher text only attack yeah i'm not going to detail that much but essentially the channel coding operation introduces redundancy and you can kind of null out that if you take the the last equation the the last equation you have h multiplied by y plus g h is the function of the coding channel coding you can compute it it's known y is the data that you've received of the air so you know it as well g is also a function of the channel coding operation so you know it so everything in a on the left you know okay and the last value it's h which well you know it again it's it's the same h multiplied by a which is what you had in the known plaintext attack so you know it as well and the only thing you don't know is x and so again you have a linear system of equation that you can solve and the same four quick scan method can actually be applied to to scan very quickly and not have to solve everything so this is the result I mean essentially if you actually use the the fact that you know some plaintext you need about 50 megabytes of data pre-computed you need to receive eight bursts or even four if you just by any chance have the right frame number alignment and in like 500 milliseconds you can get the key back and that's on the six euro laptop I mean and any recent machine it's really no instant if you want to use the ciphertext only variants and honestly I really don't know why you would because the known plaintext just works so you might as well use it but if you want it to you know purely for academic purposes then you need you know eight bursts about five gigabyte of data and then it takes a little longer like about one second to recover the key so a few things we'd like to look at in the future is c-band so the satellite has to talk back to the earth station and this happened in different frequency band and this is what we'd like to look at essentially the field link if any of you have a large dish select dish and want to provide data for us please contact us we're looking for it we're so starting looking looking into packet data and some other stuff yeah a quick note about other satellite phone systems please don't assume that just because to write our gmr one is broken that the other aren't unless you have actually proved that they aren't because the only reason we chose to write is because the phone was the cheapest on ebay so given that all the satellite phone systems also you know you can find commercial intercepts interceptor for them there's a big chance that you know they're not that much more secure so I'd like to thank a few people Dimitri Stornikov for the made other author in Osmo gmr and doing a bunch of the RFCAP2 stuff Dieter Spa for reverse engineering of the AMB codec and all the help we provided there and the rep team of course for the support in reverse engineering decipher and the organizer for having me and thank you for your attention thank you very much we now have time for a few questions first are there questions from the internet not yet so if you have a question please approach one of the microphones yes please microphone number three yeah yes I have a rather not technical but political question so you said in the beginning there was like a short way of communication that only the satellite transmits the voice data so there is no ground station involved yes do you think that this might upset some of the well people who like to intercept chords because it makes intercepting the voice data much more complicated than just going to the to the ground station and say I want to listen to this first just because the satellite will send the data back directly to their mobile phone doesn't mean the satellite can't also provide a copy of it to the earth station it just doesn't go through but the satellite can obviously send a copy of it if they want to to uh and probably there will be a possibility for the ground station to say don't do that direct connection probably on the other hand they can also just intercept it off the air because it's so easy to listen to it I don't know if you see last year there was a talk with somebody that looked at satellite pictures and they saw that one of the spy satellite was relocated like right next to the Thuraya 2 satellite so you can look that up it was it was a presentation last year it was a pretty interesting to see that yeah if they want to listen to it they can do it even without thank you and next question from microphone number two I've two sorry I have two questions can you hear both sides of the conversation or only one side of the conversation and the second question is how big of a dish do you need okay so if you want to receive L-Band which is just listen to communication from the satellite to the phone you don't need a dish you need like a small antenna you can even you can even do it with a modified GPS antenna and a piece of metal so it's really easy and really cheap to do you can only hear the the part of the conversation that comes from the satellite to the phone so if by any chance that guy is speaking to another phone you can hear both sides just because you know you can you can intercept both channels simultaneously but yeah in general you either only hear one side or you can also be close enough to the actual satellite phones to receive the uplink that goes from the phone to the satellite if you look at and Dimitri showed me like a commercial intercept system where apparently they use like planes to intercept the uplink and so they just fly over the area of interest and so they can more easily receive the uplink from the the phones okay one final question please make it short because we are running out of time I'll try my best do you launching your own satellite certainly is not an option but do you see any practical applications in terms of what you did with GSM not really I mean it'd be interesting to try to start on it because there is nothing that says that you have to be on a satellite you could technically start a base station on earth using that protocol and it would work and the phones have much more power than a GSM phone but other than that I mean you could you could build a Nimzy catcher for satellite phones if you wanted to and you would definitely beat the signal strength of the satellite with your own setup okay so please give the speaker another round of applause when you leave thank you you