New Attack Can Now Decrypt Satellite Phone Calls in 'Real Time' (zdnet.com) 50
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.
Re: (Score:2)
Re: (Score:3)
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 intrusi
Re:What would they have to do to fix this? (Score:4, Informative)
Re: (Score:2)
User data is not likely decrypted on the Satellite (Score:1)
The big geosync ones are just active retransmitters of radio spectrum. Even the switched ones have no
reason to decrypt the audio. A phone update for a more agile key might do the trick.
Change the cipher... (Score:4, Informative)
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.
Re: (Score:2)
I doubt that they really want strong encryption and will just stick another back-doored system in place of hte current back-doored system
The reality is that national actors probably don't care about the cryptography involved. They just pick up the call when it hits the PSTN. It's much easier, unencrypted, and you don't have to do any hard work to try and unite both sides of the conversation.
Re: (Score:2)
Communication between two sat-phone users never reaches a PSTN network.
Re: (Score:2)
That's only true on Iridium. All the other providers (Thurya, Inmarsat, and Globalstar) use bent-pipe satellites and do all the processing on the ground.
And, well, you had better believe that Iridium has "lawful" intercept capabilities. Iridium has two downlink stations, one in Tempe Arizona for all their civilian/commercial traffic, and the other in Hawai'i, owned and operated by DISA for the DoD phones.
Re: (Score:2)
Re: (Score:2)
Still doesn't mean it goes over a public switched telephone network
Re: (Score:2)
Uhmmm... that would be the point of using DHKE or one its variants, so that you *CAN'T* recover the unencrypted data without first intercepting the key exchange
Re: (Score:2)
Uhmmm... that would be the point of using DHKE or one its variants, so that you *CAN'T* recover the unencrypted data without first intercepting the key exchange itself that occurs at the beginning of the communication. This is quite trivially susceptible to MitM attacks without adding authentication steps to the process, but with wireless communication, setting up a man-in-the-middle to intercept the communication is not feasible, so authentication is moot.
I think you are perhaps missing the point. They can recover the key from the encrypted data using this attack. They don't need to attack the key exchange to make this attack work so anything making the key exchange "better" is pointless. The weakness is apparently in the GMR-2 stream cipher itself, so they *CAN* recover the unencrypted data w/o needing to intercept the key exchange or the session information.
Re: (Score:2)
The weaknesses of GMR2 is irrelevant. it is entirely possible to have a secured key exchange even over an entirely *PUBLICLY* visible communications channel, as long as you can somehow guarantee that the communication between two points cannot be intercepted. You get that guarantee for free with wireless communication, so you have the sender create a secret key that will be used to encrypt the communication, encrypt it locally via one-half of an asymmetric key that it has created or chosen for this sessi
Re: Change the cipher... (Score:2)
You are not understanding the nature of the attack. You statements are only true if there is no better attack on the encryption algorithm than brute force. Unfortunately that is exactly what this is. Go read up on ciphertext attacks.
Re: (Score:2)
I know exactly what this is... what I am suggesting could be quite easily layered over top of that by software running on the end point devices, and that is still able to effectively perform its tasks in real time,.using encryption bit widths that would take longer than the lifetime of the solar system to decrypt using current technology (let alone real time), the software taking full responsibility for its own encryption and decryption at the end points, exclusively.
And any failure of the underlying te
Re: (Score:2)
With what I was talking about, it doesn't matter how flawed the GMR-2 cipher is, or any underlying communications structure for that matter, because what I am suggesting could be layered entirely on top of that just by software running at the endpoints.
Obviously, this would require a firmware update, but it should still be doable with the existing hardware. You talk into the phone, it goes through the software and gets mangled by a secret key, and *THEN* gets sent... the receiver picks up, it gets muta
Re: (Score:2)
I know exactly what this is... what I am suggesting could be quite easily layered over top of that by software running on the end point devices...
That's the problem. They're satellite phones, so there's no "easily" in changing the endpoint software. Your solution amounts to "change the cipher to a more secure one". Well, yes, indeed, that's what we need to do.
That you can always run your own crypto on top of the one provided by the carrier is kind of trivially always true, but most often not a realistic option.
Re: (Score:2)
I wonder what supports:
in fact because of this [key scheduling] weakness, AES-256 may be even less secure than AES-192
No attack that I know makes AES-256 weaker than AES-192, or anything close to that (unless some rounds are trimmed).
Beside, attacks on AES key scheduling make the assumption that the adversary can impose some transformation of the key that she chooses, when the standard and practically relevant assumption is that the adversary can not influence the choice of key. Under that assumption, as far as I know, all three variants of AES are within 3 bit of its original security goal.
Re: (Score:1)
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
I recall reading somewhere, sorry don't have the reference here, that NSA has long had a low opinion of stream ciphers in general, viewing them as less secure than alternative methods. Possibly the only exception is the one-time pad, which remains just about the only cipher which is absolutely unbreakable if the procedures are followed perfectly and without error. The problems of course being that:
1. Procedures are rarely followed perfectly or without error ( VENONA [wikipedia.org] is a prime example of what can go wrong wh
Re: (Score:3)
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 some
Re: (Score:2)
I seriously doubt doing updates to the phones is a problem at all, I'll bet they push updates all the time. Satellites are routinely updated and I'm guessing is not a serious problem.
What really will be the problem is the common encryption problem of key distribution... Unless you can hide the keys from disclosure, your goose is cooked...
Re: (Score:2)
Why would you need to update the satellite? Typically, a satellite just relays traffic between a ground station and a particular device. It shouldn't need to understand the traffic, so all the encryption should be handled by the ground station on the other end of the satellite hop.
Re: (Score:2)
In this case, the Satiates are doing a bit more than just relaying data to a ground station, but they are acting more like cell towers, handing a call from one satellite to another as they move in low earth orbit. Also, the "ground station" may not be in view at all times, so they use the satellites to relay the call to one that has a ground station in view.
Now I'm not saying that the satellite treats the audio stream as anything more than packets of data, but the signaling portion IS important....
Re: (Score:2)
I seriously doubt doing updates to the phones is a problem at all, I'll bet they push updates all the time. Satellites are routinely updated and I'm guessing is not a serious problem.
For the Inmarsat service, it's likely to be very difficult, if not impossible. Inmarsat is generally considered a life-critical system for communications with ships at sea. The ground terminals used on the ships are based on designs that are on average probably at least a decade old, which means that the cipher and associated bits are most likely baked into the silicon, making it impossible to update. Forcing a global fleet-wide replacement is about as easy as calling an Internet flag-day and switching ever
Re: (Score:2)
Still... I'm not inclined to believe that Immarsat shipped "baked in" encryption technology based on implementation in silicon. What MIGHT be an issue is having the horsepower necessary to use a less easily broken encryption algorithm or longer key baked into the phone.
We've been shipping firmware driven DSP equipment since the advent of digital cell phone technology, which has been available for 25+ years and standard for the at least 20. Unless Immarsat was building their stuff based on the dark ages
Re: (Score:2)
They were most likely working in the "Dark Ages" because that's pretty much how the whole industry works. When I left the industry in 2013, companies were just discovering that IPv4 was still a thing, but even then they were generally handling it by pumping it through HDLC over satellite. I'd wager that 90+% of non-television satcom is completely unencrypted, with the exception of whatever crypto people run over it (https, VPN, whatever). One of the big challenges with dealing with Cryptography, even 3DES
Re: (Score:2)
Not really.
I'm sure the satellites are constantly being updated for one reason or another. If your $20 tablet gets firmware updates, you can be sure a multi-million-dollar satellite used for worldwide communication does too. Just of a higher quality.
Phones might be trickier, but not because of firmware, because they may just not have the oomph to encrypt things betters in real-time.
To be honest, anyone using them and expecting a real sense of security (because, after all, the satellite company and any num
In other words, not new... (Score:5, Interesting)
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.
Re: (Score:3)
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.
Re: (Score:2)
Re: (Score:2)