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!"

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

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.

There is in at least California, the EU, and China. A lot of clauses in EULAs aren't actually legal.

On the other hand you can't sue a company for losing your data in many EU companies. You can report them to whatever data protection agency your country has, and after an investigation they can fine, and/or, in more serious cases turn the matter over to the police for a criminal investigation.

The disadvantage of this is that the local data protection agencies haven't been handing out very big fines. Sometimes that's due to company law. In my country you'd fine the owning company, which in many cases will be a holding company. Since fine sizes are linked to revenue and a holding company typically has no revenue, this means fines are often ridicilously small.

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.

Or, the entity being damaged is not the decision maker and has no power to hold the decision maker responsible.

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

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.

The legal system already has sufficient cop-out: for anything that you should have been aware of, or would have been informed about.

Eg. doctors do get sued and fired for malpractice, if they did something no other skilled doctor would reasonably do ("let's just use the instruments from the previous surgery").

Here are a bunch more things to make you even more scared.

- Oops! mistakenly left some instrument inside and sewed up the patient - Junior begging to do certain step of the surgery while the anesthesiologist asking them to just get a move on. - Administered a drug to a newborn baby which was supposed to be given to the mother. (My sister's colleague did this with no consequences)

If the doctor is criminally negligent they could be jailed.

My sister knows a doctor who botched a surgery due to an argument with a junior who wanted to do some step of the surgery. The senior one was not having it at all and just threw the scalpel directly at him. Nothing happened to him because if we start firing doctors for this, we would be missing out on all the surgeries he did successfully.

> Nothing happened to him

There is a world of difference between "nothing happened" and being fired. Just like in the NBA, a fine (monetary penalty) of a sufficient size will get someone's attention without losing their skills forever.

That's kind of obvious, I didn't think it has to be spelled out.

My point is that something doesn’t have to be malicious to be criminally negligent, if the law says so. I’m suggesting that some of the security breaches we’ve seen ought to have been criminally negligent. Perhaps they weren’t under existing law, but I think they ought to be.

We don't get delivered to us 18-year-olds that happen to be in perfect health. And a lot of Americans don't believe in wellness visits. Although more and more it's the insurance companies that are practicing medicine. Sorry it's a sore subject with me lol

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

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?

It would not be perfect, but it wouldn't be purposefully shooting oneself in the foot.

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.

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.

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.

Issue is the satellite was launched 10 years ago with 20-year-old tech. So, calculations of today may not be applicable on them.

Wireguard uses ChaCha20, which to my knowledge neither has nor requires HW acceleration to be fast.

It's faster on CPUs without dedicated hardware than AES, but that doesn't mean that it's faster than fixed-function AES hardware.

> However, the software performance [of wireguard] is far below the speed of wire.

https://github.com/chili-chips-ba/wireguard-fpga

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!!")

The encryption of the payload doesn't need to take place on the satellites

Thats very true.

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

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.

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.

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.

Correct. That is what almost all geostationary satellites are. If you want encryption, do it at the application layer.

The only thing I can think of is maybe the satellite company runs compression on the data. Encryption would prevent that.

They could compress then encrypt before transmitting it over a radio link.

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.

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.