Slashdot Mirror
New Attack Can Now Decrypt Satellite Phone Calls in 'Real Time' (zdnet.com)
Chinese researchers have discovered a way to rapidly decrypt satellite phone communications -- within a fraction of a second in some cases. From a report on ZDNet: The paper, published this week, expands on previous research by German academics in 2012 by rapidly speeding up the attack and showing that the encryption used in popular Inmarsat satellite phones can be cracked in "real time." Satellite phones are used by those in desolate environments, including high altitudes and at sea, where traditional cell service isn't available. Modern satellite phones encrypt voice traffic to prevent eavesdropping. It's that modern GMR-2 algorithm that was the focus of the research, given that it's used in most satellite phones today. The researchers tried "to reverse the encryption procedure to deduce the encryption-key from the output keystream directly," rather than using the German researchers' method of recovering an encryption key using a known-plaintext attack. Using their proposed inversion attack thousands of time on a 3.3GHz satellite stream, the researchers were able to reduce the search space for the 64-bit encryption key, effectively making the decryption key easier to find. The end result was that encrypted data could be cracked in a fraction of a second.
If this is what Chinese academics are publishing now, I wonder how long this has been possible in less-publicized circles.
Everybody knows that certain governments buy up crypto expertise as soon as the ink on the PhD dries. Or sooner, in some cases.
---
According to the latest ruleset, this post should be modded as Vorpal Flamebait +5.
Some variant of Diffie-Helman key exchange would probably do quite nicely... MitM attacks are typically considered the biggest weakness of DHKE, but with wireless communication, there's no opportunity for a man in the middle attack.
It may involve a firmware update, but it still seems doable.
Of course, if somebody installs some malicious software on the satellite, then snooping via MitM attack becomes possible that way.... Ideally, the people that run the satellite have secured it against such intrusion, and that they themselves will not install such software at any time in the future.
File under 'M' for 'Manic ranting'
I can assure you that satellites are well secured. Usually they have multiple out of band (i.e. on a separate frequency, and even a separate set of radios) RF administrative channels which are well encrypted and secured using multiple means. These channels are both time locked (i.e. only active at planned times) and require signing of each data packet and then require detailed knowledge of the communications protocol to actually do anything to the satellite. They are assets which are too valuable to just throw up there unprotected...
"File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
Some variant of Diffie-Helman key exchange would probably do quite nicely...
Sorry, no. The attack described is on the GMR-2 stream cipher itself, not the key exchange. Because of a weakness in the key schedule of the cipher, and the underlying structure of the encrypted data frame related to the key schedule, they can actually recover the key directly from they encrypted data frame ignoring the session key exchange entirely.
The fact that they are using some crappy secret stream cipher to sat-phones is a testament to how little research has gone into good stream ciphers (vs creating block ciphers like AES). Although we also shouldn't be too smug about AES either. In a similar vein, a weakness in AES block cipher key schedule was not detected until many years later made AES-256 less secure than its 2^256 key-space would indicate (in fact because of this weakness, AES-256 may be even less secure than AES-192). And AES is/was a heavily researched block cipher, not a "secret" satellite phone cipher.
For the most part, satellites in geosynchronous orbit (such as those used by Inmarsat) are generally bent-pipe designs, rather than carrying the equipment for onboard signal processing.
Demodulating, decrypting, processing, and remodulating the signal on board requires the relevant electronics to do so. This means that you're putting sensitive, power hungry electronics in a high radiation environment, where it's difficult to dissipate heat, your power supply is limited, and it's impossible to service if something goes wrong. It also generally means you're beholden to a specific technology for 15+ years.
Instead, the most common design is to follow the KISS principle for the satellite; it dumbly repeats whatever radio signal it receives, and put all the intelligence on the ground. In the literature I can find on the Inmarsat Satellites, they appear to be of the bent-pipe variety.
Now, even though the head end of the satellite phone is on the ground (and the satellite is a passive relay) that doesn't mean that it's necessarily easy to swap out ciphers for the phone portion of the system. It's quite likely that the system is baked into the silicon on the ground stations, and pushing out a firmware update for old systems is going to be quite difficult, especially because inmarsat is often considered to be a life-critical service. The amount of paperwork involved would be extreme, never mind the testing and so forth if it was even possible.
On the flip side, given the audience for this system, I'd wager that the vast majority of what you would hear would be mariners on the phone to their loved ones in the Philippines, yakking away in Tagalog.
...si hoc legere nimium eruditionis habes...
They're using that because the technology was developed 15 to 20 years ago. In the world of satellite communications technology moves a lot slower than it does for the rest of the industry. It's also very difficult to change the technology once its deployed.
The stream cipher used was most likely chosen because it provided sufficient security for their needs (basically privacy rather than real security), and was easy to implement in the hardware that was available when the service was being developed.
...si hoc legere nimium eruditionis habes...