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.

Comments

Re:What would they have to do to fix this?

[Aaden42]

I'll be the satellites see updates more often than some Android phones sold in the last year.

In other words, not new...

[EndlessNameless]

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:What would they have to do to fix this?

[mark-t]

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.

Re:What would they have to do to fix this?

[bobbied]

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:What would they have to do to fix this?

[ledow]

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 number of ground stations, repeaters, and the PSTN endpoint could listen in all they like) should have been wrapping their comms with their own encryption before sending it to a satellite.

People will eventually learn - use a transport stream that's potentially vulnerable, assume that's the case anyway, and then put upgradeable encryption on the endpoints under your own control that's nothing to do with the people supplying the transport stream.

I always used to VPN over my own wireless network, back in the early days of WEP, WPA, etc. It paid dividends in giving me security, layering, time to upgrade, the ability to change intermediate equipment without affecting the entire setup, etc. And there was basically zero downside, I used to game CS over that VPN and it added less than 1ms even with old ropey computers acting as the VPN server.

Trust. And then encrypt your own traffic anyway. Whether it's wireless, point-to-point, satellite, WhatsApp or anything else.

Re:What would they have to do to fix this?

[bobbied]

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...

Re:What would they have to do to fix this?

[dgatwood]

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.

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:What would they have to do to fix this?

[mark-t]

I wasn't suggesting that they weren't... but I felt I should acknowledge the point as a at least a theoretical vulnerability.

Re:Tragedy of the minority.

[flex941]

It's not that expensive to own and use a satellite phone. If you can buy new iPhone every year - then you can definitely afford a probably cheaper SAT phone (too).

User data is not likely decrypted on the Satellite

[Anonymous Coward]

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...

[slew]

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:Change the cipher...

[Strider-]

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:Change the cipher...

[mark-t]

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.

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.

Re:Change the cipher...

[viperidaenz]

Communication between two sat-phone users never reaches a PSTN network.

Re:Change the cipher...

[Strider-]

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:Change the cipher...

[slew]

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.

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:Change the cipher...

[mark-t]

Even over a pstn, there's no reason that the data needs to be unencrypted on it. Any data sent could be encrypted in real time directly by the sending phone and decrypted in real time directly by the receiving phone with a very simple algorithm. The secret key to be shared between the sender and receiver for encrypting the communication could itself be encrypted using a commutatve encryption scheme that guarantees that x enc A enc B dec A dec B == x, and the data stream is not decryptable in real time without a quantum computer, or unless you can intercept the communication. Intercepting wireless communication isn't possible, and unless you compromise the pstn itself to act as a MitM, the communication can be quite safe from eavesdropping in real time.

Re:Change the cipher...

[mark-t]

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 session, and send the encrypted data (so encrypted data is on the channel), the receiver re-encrypts it with one of an asymmetric key that it has created or chosen for the session and sends it back (so encrypted data is still on the channel), the sender then decrypts that content with the other half of its own key, and sends that back (so encrypted data is still on the channel), and then the receiver decrypts with the other half of its own key to obtain the original secret. This does require that both the encryption and decryption keys chosen by each side be commutative not only with respect to themselves but also with all other possible keys, but it is not that computationally intensive to find such a pair, and it only needs to be done once at the beginning of a session. It does not matter how easy it is to see what the content is that passes between the sender and receiver because at no point is any unencrypted data ever visible to anyone who might try and eavesdrop. The only systems that ever contain uncrypted data are the sender and receiver.

As long as the key length used for this encryption is wide enough, which is again entirely independent of how easy it might be to eavesdrop on data that is being sent, there are only two ways to currently decrypt this kind of communication in real time: 1) Either utilize a MitM to intercept the entire above key exchange and subsequent communication, or 2) to use a quantum computer. There are quantum-computing proof variants of the algorithm as well, however, although they are somewhat more expensive. As more powerful cpu's become ubiquitous, however, the only remaining weakness would be having a MitM. You cannot generlaly implement MitM attacks against wireless communication, however, so it's really quite perfect for wireless communication.

Re: Change the cipher...

[Lightn]

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:Change the cipher...

[fgrieu]

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: Change the cipher...

[mark-t]

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 technology or communications infrastructure to be properly secured against snooping would not impact the privacy of such a communication unless you could intercept the communication as a MitM.

Ciphertext attacks aren't going to do diddly squat at solving a problem that is no less difficult than factoring numbers that are the product of two unknown large primes. As quantum computing comes into the forefront, slightly more expensive algorithms could be employed which are resistant even to quantum computing efforts.

Re:Change the cipher...

[viperidaenz]

Still doesn't mean it goes over a public switched telephone network

Re:Change the cipher...

[Anonymous Coward]

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 is a prime example of what can go wrong when key materials in a one-time pad system are re-used for example).

2. Needing as much key material as message material is decidedly inconvenient, especially for large messages. This can make secure key handling and distribution much more difficult in some circumstances.

Re: Change the cipher...

[lars_stefan_axelsson]

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: Change the cipher...

[mark-t]

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 mutated back into the original through the software (easily done in real time by participating in a key-exchange at the beginning of a session), and they listen to the original. Someone communicating with a device that has not been upgraded could bypass the software encryption so that backwards compatibility is achieved.

Any existing flaws in the security of the communications system, even if they are in the hardware itself, would be entirely irrelevant, because what I am suggesting would be layered over top of that. At no time during a communication would any vulnerability in the underlying communication structure compromise the communication, even if one tried to snoop during the key exchange itself (unless one had a quantum computer, or was utilizing a MitM attack). Quantum proof algorithms exist as well, although admittedly these are probably less likely to work in real time on older hardware. MitM attacks are infeasible with wireless communication, so that's why I suggested it.

Re:What would they have to do to fix this?

[Strider-]

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.

Re:What would they have to do to fix this?

[Strider-]

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 everyone to IPv6. It ain't going to happen.

Inmarsat-B finally shut down in December 2016, at least a decade after the last terminal supporting it was sold.

Re:What would they have to do to fix this?

[bobbied]

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:The two biggest concerns:

[Strider-]

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:What would they have to do to fix this?

[bobbied]

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 of technology, they will be able to update software. They may not have the processing power to encrypt with the latest technology, but I'm sure they can field new firmware and fix the problem if their hardware has enough performance..

I'm sure they can support multiple encryption technologies at the ground stations pretty quickly, then if you don't care that Chia can listen in you can use the old equipment, or if you want a measure of privacy you can upgrade. So I doubt this is a huge issue for anybody.

Re:What would they have to do to fix this?

[Strider-]

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 (never mind AES, or whatever else), is that if it's in the hardware or even in the firmware, you start dealing with ITAR and all that bullshit.

For the satellite network I still operate, which were finally discontinued last year, the only cryptographic option would be to run 3DES, with static keys, and if and only if you bought the cryptographic version, which required you to sign an end user statement, and then you need to have special firmware that you have to request personally etc... The regulatory environment is a right total pain in the butt, but that's the way it is.

Re:So what?

[cryptizard]

But... nobody uses GSM any more? 3G, 4G, LTE, etc. all use encryption that is not currently broken.