A Surprising Amount of Satellite Traffic Is Unencrypted

Here’s the summary:

We pointed a commercial-off-the-shelf satellite dish at the sky and carried out the most comprehensive public study to date of geostationary satellite communication. A shockingly large amount of sensitive traffic is being broadcast unencrypted, including critical infrastructure, internal corporate and government communications, private citizens’ voice calls and SMS, and consumer Internet traffic from in-flight wifi and mobile networks. This data can be passively observed by anyone with a few hundred dollars of consumer-grade hardware. There are thousands of geostationary satellite transponders globally, and data from a single transponder may be visible from an area as large as 40% of the surface of the earth.

Full paper. News article.

Posted on October 17, 2025 at 7:03 AM17 Comments

Comments

KC October 17, 2025 10:30 AM

A little weird. From the paper: “From our conversations with vendors, no auditing tools exist that allow vendors to audit the security of their own satellite backhaul.”

From SATCOM Security’s FAQ:

Q: “Can you audit our network?”
A: “If you would like our assistance in determining whether your network traffic has been exposed, please get in touch.”

Wired article. Hacker News forum. 2022 GEO satellite security advisory.

Clive Robinson October 17, 2025 11:26 AM

Why change standard behaviour?

This is the same issue as “Signalling System 7″(SS7) and a multitude of still in use Internet and other Communications protocols.

People tend to forget that one way or another the US had until very very recently a “choke hold” and still does on what goes up in a satellite. And the use of encryption is fairly well frowned upon, as is cameras with even high end consumer grade camera resolution.

Then there are the National Telecommunications Regulations. Whilst it’s OK to transmit TV to set top boxes using fairly complex encryption, those links carrying “one to one” style comms are not allowed in many places to be encrypted.

But there is another aspect to consider. It cost something like $27million to put a rocket into space and the cost of doing the paperwork can also be shockingly high. Then there is “import taxes”, “insurance for launch”, “insurance for decommissioning” and various “license fees”. This quickly adds up to a “Metric 5h1t ton” of cash up front. Therefore the operators mostly want a 25year life span.

Thus a lot of still active birds were designed upto thirty or more years ago… When the Space Shuttle was still running on i486 and older technology.

Thus they needed to be technically robust and simplicity with parallel systems was the design style.

For various reasons symetric encryption just does not fall in with that style.

Plus even a decade and a half back the cost of technology to receive satellite transmissions was prohibitively expensive.

However the very rapid development of RF Grade ADCs and FPGA’s to do high rate DSP work at very low costs has given rise to “Software Defined Radio”(SDR) where you can buy an SDR that does 1MHz to 6500MHz wide band reception is actually less expensive than an HF Pocket Travelers Radio. And in fact be as little as 1/10th the price of suitable antennas.

This problem with “not encrypted” will continue to be an issue for at least another couple of decades.

But also consider a real problem of “Key Management”(KeyMan) how do you reliably get “Key Material”(KeyMat) upto a satellite not just securely but more importantly reliably?

Few software and hardware engineers actually know how to do this to the “availability levels” required for what could easily become a $50Million “hunk of junk” careering around and potentially crashing into other objects at between 3000 and 8000 meter per sec if they make even a simple mistake.

DS October 17, 2025 1:48 PM

You don’t need the satellite to do any encryption or decryption of data flowing through it; just the ground-based endpoints of the communication.

Pete October 17, 2025 2:31 PM

Advice to encrypt at each end is advice that only works for some geeks.

Are you trying to provide a baseline of privacy for non-tech-savvy customers? This is a problem.

Do you need to pass traffic to a receiver which lacks decryption capability? This is a problem.

Are you a Black Hat analyzing protocol meta-data? Even if both ends encrypt, this is a problem (that you like).

Tim October 17, 2025 4:40 PM

@DS – Encrypted data is supposed to be basically indistinguishable from random data, so it doesn’t compress well. Given the limited bandwidth on a satellite connection – and, I’m sure, the cost of that bandwidth – I’d expect they’d want to compress data as part of transmission and would therefore resist end-to-end encryption.

Offered as a possible reason, not as an excuse.

ResearcherZero October 17, 2025 11:10 PM

@KC

Said companies might need to perform comprehensive backups before first proceeding.

They may then have to send a fax and then look for a leak coming from the sky. Otherwise they could probe their own work practices to discover how they themselves communicate.

It is probably a very good excuse to implement some kind of security policy at work and audit the architecture and document all internal networks, hardware, software and 3rd party services. Replace EoL devices, renew all credentials and access controls. They may need a security team to do this and also assign an administration with appropriate annual budgeting.

KC October 18, 2025 12:49 AM

@ResearcherZero, All

re: security policy and documentation

I’m a little confused here… on page 11 of the paper, under section 6.1.1 T-Mobile Cellular Backhaul

‘The IMS traffic did have an IPsec layer, but it used a null cipher for encryption.’

Do you suppose it was for the sake of efficiency or economy? (these two “Impediments to Encryption” are covered in two short paragraphs on page 14)

Are you also reading that T-Mobile enabled encryption after being notified?

Clark Gaylord October 18, 2025 4:30 AM

An interesting wrinkle with satellite communications as it pertains to end-to-end encryption is the enormous (by terrestrial communications standards) amount of buffering required for effective throughput. This is simply a product of the speed of light and the bandwidth*delay product. The ground-satellite-ground round trip time for geostationary links is on the order of half a second! (cf https://datatracker.ietf.org/doc/rfc2488/)

The solution for reasonable throughput is inherently TCP oriented, with the terrestrial modems acknowledging to the endpoints using the respective terrestrial RTT, and then communicating to each other via satellite with huge buffers.

While not precluding encryption entirely, it does restrict effective satellite encryption to TCP based protocols, such as HTTPS. IPsec and other approaches are not feasible.

That said, obviously we use HTTPS all the time and the emphasis on end-to-end encryption it entails helps to mitigate the other noted challenges related to “link layer” encryption in satellite communications. The concerns regarding the risks link encryption would entail are very real and reasonable, and they emphasize what is in fact already true in any Internet application, that encryption must be — and can only be — effective in an end-to-end context.

Clive Robinson October 19, 2025 1:12 AM

@ KC, ALL,

With regards the “null cipher” this shall we say a “feature” of IPsec that should never have been.

Those that go back as far as this blog goes or earlier might well remember with a shudder the early days of IPsec in the late 1990’s.

To say “it was a disaster in the making” is, to put it politely, an understatement that got it either “not used” or “used incorrectly”.

In fact it was why Stunnel got the use it did and still does (an example from earlier this year, https://leosmith.wtf/blog/hiding-openvpn-traffic.html ).

IPsec was unfortunately “designed by committee” which is never a good thing to do when security is an issue. Because as so often happens it suffered the,

“All things to all men”

Issue of having “at least three kitchen sinks thrown into the blender” to keep vested interests happy. With that as oft happens, comes unnecessary complexity and ambiguity, by rather more than the proverbial bucket load.

Unfortunately as we know by long experience,

“Complexity creates dark places in which things can be hidden”

And there were stories that the NSA had “put in one or three back doors”. Whilst the details are sufficiently muddy other NSA activities that later got caught adds credence to the early claims.

But the simple fact is IPsec has many issues and thus for satellite links it would not be on my list to consider from a technical perspective.

However technical security is a much lower priority than almost everything else in business environments where “check-list auditing” is seen as the way to meet “business requirments”

So, because IPsec has become an Open thus Industry Standard… IPsec usually comes as an “out of the box” instal for “turn-key operation”…

With the “fallback of null cipher” for “setup and testing” such that those wrestling with getting things working can at least see if,

“The problem is leaving my end OK.”

However even after something like half a century, “Key Managment”(KeyMan) is still misunderstood and seen as “Harry Potter Dark Arts” by even many people working in ICTsec.

Thus they get it up and running with the “null cipher”, and find it all breaks when they try to use any cipher.

The result is the “null cipher” gets left in, and due to fallback or lack of effective KeyMan systems becomes the cipher of choice.

Which obviously pleases those who John Milton once observed

“They also serve who only stand and wait”

But listen silently to all that passes by…

But consider “fallback to null” is a rather nifty form of “Man In The Middle”(MITM) attack when it comes to defeating Crypto easily and in a way that looks accidental. You only need run it during the “negotiation phase” and then you can switch it out so it’s not detectable from effectively the get go onwards, it has next to no CPU load and will happily run on even low end routers and other network devices.

It’s a handy thing to have in your toolbox of tricks, even if your hat colour is purer than freshly driven snow.

Oh and the fact the “null cipher” has the lowest latency and highest through put when measured can make some “network / mangle-ment people” see it as desirable… Under the neo-con “best bang for your buck”, “leave no money on the table”, “ultra short term” business case thinking excused as “cost minimisation” where actual security is “A cost to far”…

As is sometimes said,

“Welcome to the corporate world, have a nice cost-cut day.”

But as we’ve recently seen with the alleged DOGiE experts such thinking quickly goes hellishly wrong.

Actual “Security” is one of those,

“You get what you pay for, technologies, so if you don’t pay you don’t get…”

KC October 19, 2025 4:08 AM

@ Clive, All

Re: the “null cipher,” a “feature” of IPsec

Thanks for your response. You know, this has me all turned around. A recent Slashdot post also has me re-looking at the Gizmodo article …

T-Mobile said in an emailed statement to Gizmodo … and we implemented nationwide Session Initiation Protocol (SIP) encryption for all customers to further protect signaling traffic as it travels between mobile handsets and the network core …

They didn’t mention IPsec. But I guess SIP encryption will prevent this, uh, from the paper …

The unencrypted traffic included unprotected IMS signaling as well as metadata and content of real user SMS messages, call metadata, browsing history, and unencrypted RTP voice streams

To be fair, I could myself use a crash course in secure cellular, satellite comms 🙂

Incidentally, T-Mobile is now purportedly obsessed with security. They have a new Cyber Defense Center, a ‘no passwords’ policy, an x-ray machine for inspecting products, a third-party risk team for their many, many suppliers …

https://www.fierce-network.com/wireless/t-mobiles-cyber-team-little-unicorn-and-security-obsessed

At least as far as monitoring for satellite signals in the clear, I would agree with the researchers: “A static snapshot of satellite spectrum is insufficient; instead, satellite security research requires a continuous and systematic monitoring paradigm.”

Clive Robinson October 19, 2025 7:41 AM

@ KC,

With regards VoIP encryption. Ascwith conventional PSTN systems there are two parts “signaling” and “traffic”. For “SIP Encryption”, you need to remember that in effect SIP provides the Signalling / control and RCP provides the transport of traffic voice/video etc.

Therefore you can encrypt one or the other or both…

Have a look at,

https://www.fuse2.net/biggest-sip-security-risks/#blog-content

It will give you an overview of some of the security issues with this type of VoIP system.

not important October 19, 2025 5:37 PM

@Clive
Could You please enlight me on ‘There are thousands of geostationary satellite transponders globally, and data from a single transponder may be visible from an area as large as 40% of the surface of the earth.’

Are those 40% coming out of the ‘cone’ when tip is transponder?

Are foreign geostationary satellites above sovereign territory of the country legitimate target for kinetic action or jamming?

Clive Robinson October 20, 2025 6:04 AM

@ not important,

With regards,

“data from a single transponder may be visible from an area as large as 40% of the surface of the earth”

I guess you want to know why only 40% not 50% as basic geometry of what is usually drawn as an “acute isosceles triangle” would suggest is possible if the base of the triangle is the same as the diameter of a sphere.

Well it mostly has to do with orbital hight and that the earth is not actually a sphere.

First though consider the fact the two equal sides of any isosceles triangle can never be parallel at less than infinite distance. So we are never going to get 50% coverage, always less.

Secondly the reality of practical Earth orbits is the cone section will mostly be “obtuse” not “acute”. That is they are considerably less than the radius of the earth above the earths surface. A simple sketch will show that the visible span across the earth from the satellite will be less than the diameter. Which means it has a radio / optical horizon less than the Earth’s radius.

Because the majority of satellites are actually in “Low Earth Orbit”(LEO) which is below 2000km above mean sea level. Or roughly 1/6th of the earths diameter. Their horizon is actually quite small, but also they tend to use “antennas with gain” giving an even more reduced coverage that is just a few percent of the earths surface.

You can either sit down and work out the equations to calculate from A^2 = (B^2 + C^2) or look them up in one of several Armature Radio books or have a hunt around on line.

Working out the equations from Pythagoras’s equation might appear daunting but I did it in my teens back in the 1970’s to write a satellite tracking and coverage program in BASIC that output maps in the HP plotter format which graphics plotters and drum plotters used back then. I actually did it for fun outside of “classwork” and that caused me a problem… My actual course work assigned project was dull and uninteresting lacking any kind of challenge. I did it but only with the intent to get a pass grade as it did not count to final grades (it was the first year the course had been run so we were in effect Alpha Testing). However a tutour from another course entirely took an interest in the things I was doing and put my project forward into a competition, which I won. Thus much interest from outside my course came in which embarrassed my tutors especially when they found out I was putting the finishing touches on another program this time for “astro navigation” that ran on an 8 bit personal computer. I was initially left with the impression “My goose was cooked” and that a boot would propel me out the door in a ballistic orbit. However it turned out that one of the other tutors was also a keen yachtsman as well, and asked for a demo, he was more than impressed that I’d already got my “offshore” and “yachtmasters” qualifications and took a keen interest in the program and talked the older tutors around (he was also later instrumental in getting me my first job working in the collage).

Warren October 21, 2025 2:07 PM

“Surprising”?

Why would this “surprise” anyone?

Until very recently, bandwidth (network and onboard processing) was simply too limited to encourage encryption

cls October 21, 2025 7:04 PM

@Clive:

With regards the “null cipher” this shall we say a “feature” of IPsec that should never have been.

nope. we use null cipher with real hashes in IPsec over packet radio. FCC does not allow any encrypted transmissions, but hashes are OK. we’re using PSK symmetric keys for the hashes, which we believe is OK because it is simply to confirm the message was correctly received.

also, in very early days of experimenting and configuring IPsec (2001 era), we didn’t know what we were doing, hello hello can you hear me now, etc., and null cipher was a good way to be able to confirm what went on which tunnel, etc.

overall it’s a reasonable compromise leaving it in the code but making it a compile time option so it is not available to be negotiated live.

Leave a comment

Blog moderation policy

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.