Satellite Phone Encryption Cracked

New submitter The Mister Purple writes "A team of German researchers appears to have cracked the GMR-1 and GMR-2 encryption algorithms used by many (though not all) satellite phones. Anyone fancy putting a cluster together for a listening party? 'Mr. Driessen told The Telegraph that the equipment and software needed to intercept and decrypt satellite phone calls from hundreds of thousands of users would cost as little as $2,000. His demonstration system takes up to half an hour to decipher a call, but a more powerful computer would allow eavesdropping in real time, he said.'"

Comments

Now that the secret is out...

[houstonbofh]

Now that the secret is out, just buy a used one off eBay from the NSA.

Security through obscurity

[munozdj]

These guys have once again proven that security through obscurity is not a sensible strategy. If the codes were published in due time, the flaw could have been found with enough time to allow for preventive measures to be deployed. (I know there are a lot of inferences in the sentence, but it seems plausible to me, taking into account what has happened with other algorithms (DES, anyone?))

Re:Security through obscurity

[saleenS281]

You're assuming they want it truly secure. Reality is governments around the world want backdoors.

Re:Security through obscurity

[fauxhemian]

Truth: http://mediafilter.org/caq/cryptogate/

Re:Security through obscurity

[slew]

(...taking into account what has happened with other algorithms (DES, anyone?))

Not sure you really have a good example there. Apparently, the NSA helped IBM select the S-box for DES and didn't give any explaination for this. Contemporary cryptographers (e.g, Diffie and Hellman) were up-in-arms that the NSA was trying to put a backdoor into DES and questioned the secrecy of the development of the process. Little did they know that the NSA was just collaborating with IBM to avoid a potential weakness in the random S-boxes to be more robust against differential analysis attacks.

Certainly as a general rule security through obscurity is not a great general strategy, however, DES probably isn't a good example to illustrate this since at the time, the NSA knew much more about breaking encryption than contemporary public cryptographers.

To me, it's like you're a CPA/EA and letting your know-it-all teenager check over your tax return. Maybe they'd find some mistake or deduction that you didn't find, or maybe they will figure out how much money you make and want a raise in their allowance. It's a tradeoff for sure. But it isn't like taking your return to H&R Block and asking them to check it over. Maybe it's more like the H&R Block situation now, but with DES back in the 70's, it was sorta more like the teenager situation.

Re:Security through obscurity

[AHuxley]

Re : "IBM to avoid a potential weakness in the random S-boxes"
http://cryptome.org/nsa-v-all.htm "For this reason IBM developed Lucifer* with a key 128 bits long. But before it submitted the cipher to the NBS, it mysteriously broke off more than half the key."
"As a result of closed-door negotiations with officials of the NSA, IBM agreed to reduce the size of its key from 128 bits to 56 bits. The company also agreed to classify certain details about their selection of the eight S-boxes for the cipher." *Lucifer was first sold as a cash-dispensing system.

Re:Security through obscurity

[hairyfeet]

While i'm sure that is true to a point, everyone seems to forget just how fricking fast we jumped on computing power. When i first started toying with computers in the early 80s we measured memory in bytes and the multimillion dollar supercomputers had less computing power than that $8 calculator at Fred's. In just 30 years we went from computers measured in single digit MHz cost nearly as much as a car to being able to build a DIY PC for $1000 that could run every single major OS of the last 20 years at the same time. Hell just look at the beginning of this century, where we had just broken the GHz barrier and having 512Mb of RAM meant you had some cash to blow. Who would have thought then that just 12 years later we'd be looking at machines with dozens of CPUs and huge pools of RAM and hundreds of specialized graphical cores we could run our own code on?

The sat phone system IIRC was designed in the mid 80s and put up in the early 90s correct? i can see them simply not seeing the huge leaps that we would make nor would the tech of the time have been able to process crypto hard enough not to be at risk from these modern monsters. If we keep leaping ahead with regards to computing power as we have been these past 15 years I don't even want to think about how big and complex an encryption system you'll need to protect yourself from what the average geek will have sitting on his desk in 2030.

Is sensible encryption really that hard?

[mark-t]

Is it really so hard to use an encrypted key exchange, such as DHKE, to establish a completely private connection on something that you are broadcasting, and do not know who might be listening in?

Such key exchanges practically scream "USE ME" for situations like encrypting anything being transmitted over the air, such as cell phone usage.

Of course, it also means that the police wouldn't be able to listen in either without setting up a fake cell phone tower to be a MitM, at least not until somebody develops an other efficient algorithm to solve the discrete log problem, or unless they had a quantum computer on the job that is more powerful than any ever yet built,

Re:Is sensible encryption really that hard?

[slew]

The problem wasn't really the key exchange (which is also problematic as it uses the A3 authentication technique similar to SIM), but the actual cipher itself was weak.

As an example, you could use DHKE to exchange keys, but if you cipher is E(data) = ROT13(data^key), you have a problem.

Of course they didn't use that poor a cipher, but the cipher they did use was running in software on a dsp, so it had to be simple, so for GMR-1, they chose to XOR the data with a jittered LFSR (similar to GSM encryption). The techniques used to break GSM encryption apparently work great for GMR as well. I don't yet know many details about GMR-2, but it appears to have different weaknesses than GMR-1 (something related to being based on 8-bit math and incomplete key-data mixing).

However, yet they could have done better, but they probably just wanted something that could run on a low-power DSP that already existed on the phone.

Re:Is sensible encryption really that hard?

[mark-t]

You can't readily be an MitM for OTA broadcasts though, unless relays are involved, and you can guarantee to be able to fake one of the relays.

Re:Is sensible encryption really that hard?

[mark-t]

Oh, also, the purpose of a key exchange is *NOT* to protect you from an MitM. The purpose of a key exchange is to protect you from eavesdropping, since with a key exchange no unencrypted data *EVER* appears on the wire or in the broadcast. With an MitM, that wouldn't matter, since an MitM could intercept the communication and pretend to abide by the key exchange protocol for both sides, using the opportunity to actually acquire the encryption sequence that is to be used for the remainder of the transmission. You can't do that if you're only eavesdropping, because you're not actually sending any counterfeit data into the system.

Re:Is sensible encryption really that hard?

[tlhIngan]

Of course they didn't use that poor a cipher, but the cipher they did use was running in software on a dsp, so it had to be simple, so for GMR-1, they chose to XOR the data with a jittered LFSR (similar to GSM encryption). The techniques used to break GSM encryption apparently work great for GMR as well. I don't yet know many details about GMR-2, but it appears to have different weaknesses than GMR-1 (something related to being based on 8-bit math and incomplete key-data mixing).

Well, here are the problems.

First, the equipment and standards were designed in the 1990's with 1990's level embedded processors (think 386 and lower). You had a battery that had to last a pretty decent time because a lot of people carry satphones for emergency use (hikers, pilots, sailors, etc), so your processor has to basically be a fleapower one. This is especially considering the satellite is far away and you have to use a fair bit of power to reach it, which means a lot of battery power and less power for the electronics.

Oh yeah, the final bitstream is probably operating at 9600bps, and your encryption routine must work in real time on the embedded processor. This was also before dedicated cryptographic processors and accellerator hardware were readily available in embedded processors. So you must do it in software whilst handling all the other tasks at the same time.

GSM has the same problem. These algorithms were designed for computational efficiency and simplicity more than absolute protection. Reason being that once the call is over, it's over. The key won't be used again, the location of the phone is moving so people can't really capture long stretches of signal, etc.

For a satphone, receiving one end is easy due to the large footprint compared to a cellphone.

Re:sony's psn botnet

[BiggerIsBetter]

Yeah, 'cause downloading bad movies is more fun with 9,6kbps over iRIDIUM....

It would probably be cheaper to make the movie than download it over iRIDIUM...

Re:sony's psn botnet

[crutchy]

PSN is like SETI@HOME, except that rather than volunteering for a worthy cause, you pay for a corporation to take advantage of you

Doesn't Matter

[zulux]

The original Motorola Iridium satellite phone has a NSA high-encryption pack available for it that fits in the back - this model with the DOD pack or a a more modern Iridium phone with another type of sleeve that I've never seen myself, is how secure communication is done over the Iridium network.

Not exactly

[stooo]

As sat spectrum is severely limited, GMR transmits nearly no frames with (unused) fixed plain text.
So deciphering it using known plaintext is more difficult than for GSM.

So Yeah, it took them one month since that :
http://events.ccc.de/congress/2011/Fahrplan/events/4688.en.html

video :
http://28c3.mirror.speedpartner.de/CCC/28C3/mp4-h264-LQ/28c3-4688-en-introducing_osmo_gmr_h264-iprod.mp4
http://28c3.mirror.speedpartner.de/CCC/28C3/mp4-h264-LQ/28c3-4688-en-introducing_osmo_gmr_h264-iprod.mp4.torrent

Re:Forget that

[OrangeTide]

yea total rip off. Paying for a network that scales by about $5m for every 1000 concurrent callers you wish to add to your network should be free.