Comment by protocolture
1 day ago
Had a vendor offer a customer of mine a huge discount if they purchased radios without the encryption license in the year of our lord 2024.
Not even WPA or WEP. Just clear across the sky. And this is terrestrial.
My bet is that in space there would be a noticable increase in heat/energy if they did encryption by default. But its still incredible to see them pretend like space is impossible to get to, ultimate obscurity.
> My bet is that in space there would be a noticable increase in heat/energy if they did encryption by default.
Why would it? The data originates from earth, and should be encrypted during the uplink leg too, so the crypto should all happen in the ground segment (or even well before it reached anything that could be considered part of the satellite setup, honestly).
Satellites have long lifespans and have to outlast current crypto algorithms. Ideally they're nothing more than radio repeaters that rebroadcast the uplink signal.
Really depends on what the satellite does, and even for purely "dumb pipe" satellites you'll need some telemetry for stationkeeping, repositioning etc.
Practically, you'll also want to be able to reconfigure spot beam to backhaul mappings or even cross-connect some spot beams to cut satphone-to-satphone voice latency in half etc.
That's not even considering constellations like Iridium that do actual packet switching in space.
Correct. That is what almost all geostationary satellites are. If you want encryption, do it at the application layer.
That seldom works. Simple repeaters transmit the strongest signal they get and can be easily hijacked by a rogue ground transmitter. This is the main reason simple repeaters on orbit went out of fashion in the 1980s.
Exactly, and the little bit of data actually destined for satellites – which includes momentum wheel and booster control – is something you’ll definitely want to at least authenticate.
I believe that’s one of the few things that even amateur radio operators are allowed to encrypt for that reason.
The only thing I can think of is maybe the satellite company runs compression on the data. Encryption would prevent that.
Likely no consequences to the decision-makers for data exfiltration or other shenanigans happening, so there's nothing motivating a behavior change.
The reason security is so bad everywhere is that nobody gets fired when there's a breach. It's just blamed on the hackers and everyone just goes on with life singing "We take security very seriously--this happened because of someone else!"
Who do you imagine will get fired? The CISO who's been recommending various security imporvements and been trying to get them implemented, but been unable to do so due to a lack of C level interest in IT. Or the C level's who lack interest in IT security until it bites them in the investor?
At least here in the EU we're moving toward personal responsibility for C level's who don't take IT and OT security serious in critical sectors, but in my anecdotal experience that is the first time anything regarding security has actually made decision makers take it serious. A lot of it is still just bureaucracy though. We have a DORA and NIS2 compliant piece of OT that is technically completely insecure but is compliant because we've written a detailed plan on how to make it secure.
Who currently gets fired due to engineering malpractice? It would be the same thing if there was actual certifications and engineering sign-offs in cybersecurity or other critical areas of development.
I wont pretend that accountability in the physical engineering world is all smiles and rainbows but at least there are actual laws dictating responsibilities, certification and other real consequences for civil engineers. When a Professional Engineer in Canada signs-off (seal) on work they are legally assuming responsibility which means the practitioner could be held accountable in the event of professional misconduct or incompetence regarding the engineering work. There is no reason but corporate greed and corruption why there isn't similar legislation in North America for cybersecurity or software engineering where you have professional bodies certify people to be legally obligated to sign-off on work (and refuse work that isn't up to standards).
But this would require introducing actual legislation which god-forbid how could we do such a thing to the poor market! It would stifle their innovation at leaking everyone's data.
There's no reason we couldn't extend the same existing system of licensure [1] that professional engineers require.
Sure maybe its overkill for someone stringing together a python app, but if you're engineering the handling of any actual personal information then this work ought to be overseen by qualified, licensed and accountable professionals who are backed by actual laws.
[1]https://en.wikipedia.org/w/index.php?title=Regulation_and_li...
> nobody gets fired when there's a breach
this must mean the consequences of such a breach has either not produced any visible damage, or the entity being damaged is uncaring (or have no power to care).
If you fire people for stuff they didn’t maliciously introduced you will end up with no people to work with.
Imagine jailing doctors for every patient that died you would be out of doctors quite soon.
8 replies →
>this must mean the consequences of such a breach has either not produced any visible damage
Yeah lets say you were carrying unencrypted frames for Bills Burger Hut.
The largest extent of the damage might be sniffing some smtp credentials or something. Bill sends some spam messages, never figures out how it was done but their IP reputation is always in the toilet.
Lets then say instead of Bills Burger Hut, you are carrying traffic for critical mineral and food industries. The attacker isnt a scammer, but a hostile nation state. Customer never realises, but theres a large, long term financial cost because (TOTALLY NOT CHINA) is sharing this data with competitors of yours overseas, or preparing to drop your pants in a huge way for foreign policy reasons.
No one gets fired until after the worst case long term damage, and even then probably not.
In fact, the likely outcome is that the burden gets moved to the customer for L2 encryption and the cowboy never changes.
End user license agreements are a huge part of the problem. Ideally users could sue if our data is leaked - and the threat of being sued would put pressure on companies to take security more seriously. Ie, it would become a business concern.
Instead we're constantly asked to sign one-sided contracts ("EULAs") which forbid us from suing. If a company's incompetence results in my data being leaked on the internet, there's no consequences. And not a thing any of us can do about it.
2 replies →
Or, the entity being damaged is not the decision maker and has no power to hold the decision maker responsible.
Or the damage is diffuse whereas the costs of preventing the breach would be concentrated. Or the connection between the damage and the breach is difficult to prove.
That and h1b abuse.
Why does Space need to decrypt a vast majority of the traffic? Flow can be just as brick not-smart as fiber optic cables under the sea.
Now, management, control, etc? Yeah those you need to decode in orbit.
> Flow can be just as brick not-smart as fiber optic cables under the sea
Wouldn't this still leak metadata for routing?
Depending on the spot beam size, the only thing you'd always learn is the ground station's rough geographic location.
Anything else could be masked by metadata encryption, rotating lower layer identifiers, and cover traffic. Not sure if any actual protocols do that though.
It would not be perfect, but it wouldn't be purposefully shooting oneself in the foot.
The landing page has a Q&A. This is the relevant part of the response to the question, "Why aren't all GEO satellite links encrypted?"
>Encryption imposes additional overhead to an already limited bandwidth, decryption hardware may exceed the power budget of remote, off-grid receivers, and satellite terminal vendors can charge additional license fees for enabling link-layer encryption. In addition, encryption makes it harder to troubleshoot network issues and can degrade the reliability of emergency services.
So, the only suggestion that there would be greater heat/energy if they did encryption by default is the part about decryption (receiver) hardware having limited power budgets in some cases. There's more than what I copy-and-pasted above, but the overall message is that lots of organizations haven't wanted to pay the direct costs of enabling encryption... although they should.
EDIT: Link to Q&A https://satcom.sysnet.ucsd.edu/#qanda
It's not a spacecraft issue. Encryption can be done at the ground stations, and mandated as part of the standards for interfsce equipment, just like with DOCSIS. There's nothing, physically, to stop you passing unencrypted traffic down your DOCSIS cable, if you wanted to make a nonstandard modem and send unencrypted traffic on your local physical segment of the network. But the rest of the network will refuse to talk to it.
The same could have easily been mandated for satellite links - no encryption, your packet won't get forwarded to the internet at the ground station, and any packets sent to you from the internet will be sent to you encrypted. And all this can be implementd without needing to touch the satellite itself, which will continue to forward what it sees as unencrypted traffic without any design changes. It could even have been implemented incrementally on existing running services, with old and new equipment working side-by-side, but all new ground stations required to support encryption, and with a sunset date for old equipment, and a rolling upgrade program.
DOCSIS got this right in 1999; the satellite industry has had 25 yeqrs to catch up.
The encryption of the payload doesn't need to take place on the satellites
Thats very true.
Encryption is basically free as far as I know, but it is more complex and it must be hard to get software updates up there.
Here is their excuse:
> Panasonic told us that enabling encryption could incur a 20–30% capacity loss. In addition, when using IPsec, ESP and IP headers can introduce 20–30 bytes of overhead, which is nontrivial for small-packet applications like VoIP and video calls
> Panasonic told us that enabling encryption could incur a 20–30% capacity loss.
Wow, I guess they're still betting on customers sending tons of redundant data up/down that they can shave off via compression? That's such a 90s modem thing to do. ("Faster than 56 kbit/s!!")
It is almost free on modern CPUs that have hardware acceleration, yea
Space-faring electronics aren't exactly cost-sensitive - the cost of a cluster of crypto-accelerated CPUs or rad-hardened FPGAs is peanuts compared to the human and launch costs that go into these satellites.
1 reply →
Wireguard uses ChaCha20, which to my knowledge neither has nor requires HW acceleration to be fast.
2 replies →
I mean a bunch of those crypto systems turn out to be flawed though. So skipping the vendor implementation and using something in software instead could make sense.