Starlink @ War

[steveleach]

A system designed to military standards.  For example, using secret keys to control spreading codes, timing, allocation of satellites and other protocol details so that an adversary without the key cannot do anything subtle and has to fall back on brute force.

A top-down hierarchical organization, such as the military, can handle key material that is impractical for civilian systems used by the general public.  It's still a hard problem, but it's not as hard a problem as giving a secret key to every random subscriber.

Wouldn't it be awesome if a standard for such Public Key Infrastructure already existed, widely used, and proven effective? Maybe we can do large scale tests using, let's say, almost all data that is transported over the internet?

It would be awesome, let me know when it happens.  PKI does not solve the problem of identity.

Why not? Why does a user certificate stored on a physical device (e.q. yubikey) not solve this? Why does a device certificate embedded in the hardware not solve this?

A certificate is not a public key. By definition it is conveyed out-of-band. From a security and key management perspective, this is equivalent to the "secret key" in a non-PKI crypto system.

Certificates containing private keys should indeed be distributed out-of-band, you are correct in that. Certificates, however DO contain a public key, and optionally come with a private key.
This certificate (containing the public key) is shared together with each blob of information the sender wants to share, together with a cryptographic signature based on the private key. Using the public key the receiver can both verify that the sender actually is in the possession of the correct private key (and thus verifying the sender's identity) and that the blob of information has not been tempered with. Actually encrypting the message is totally optional, either way both the sender and the validity of the content can be verified.

You seem to not understand the details of what you're talking about (PKI). (Side note on the previous reply: certificates should never come with private keys as that defeats the point.)

You are correct that the certificate includes the public key, but it's not shared with each blob of information. It's only shared at the beginning of a communication session.

The cryptographic signature is not based on the private key. It is based on a publicly known hash algorithm that anyone can use to verify the message if they know the hash algorithm (which is included in the hashed data signed by the signature). Signatures are just signatures, they are not directly related to encryption. You can put a cryptographic signature on any piece of data, including unencrypted data. Signatures are used to ensure that a message was not tampered with.

A public key is not used for verification. It is used to encrypt data being sent from the sender to the owner of the private key. It is unidirectional and cannot be used for bidirectional communication. (Bidirectional communication is established by the sender sending cryptographic information (pre-master secret) that is used to establish symmetric encryption method with a shared key.)

Public keys encrypt data while private keys decrypt data. The public key cannot decrypt data and the private key cannot encrypt data. So the receiver cannot use the public key to verify anything (and the sender doesn't use the private key anyway, the receiver uses the private key).

The public key cannot be used to test if the message has not been tampered with. If you ignore signatures and only use a public key to encrypt a message, a different person can intercept the message, delete it, and replace it with their own message signed with the same public key (it's public after all) and the receiver would be none the wiser.

You are correct that encrypting the message is totally optional (but defeats the point of the idea of secure communication) and that if you only use a signature you can ensure the message hasn't been tampered with, but you can't tell if the message hasn't been entirely replaced with a new one.

TL;DR Encryption is VERY difficult and the security industry has spent decades and decades patching holes in how it is performed. One tiny mistake and the entire house of cards falls down on itself and you can completely expose the contents of the encryption or man-in-the-middle the connection and fake and replace messages. There have been dozens and dozens of signature algorithms and encryption methods that have been tried, thought to be without issue, and then found to have problems several years later. It's not something you can just come up with on the spot. Also I left out a lot of details here (some of which I've myself forgotten and I'd have to refresh on and others I just never learned). The rabbit hole is very very deep.

(Source: Working on writing software for corporate encryption/decryption appliances was my day job. Note: If you use a corporate supplied laptop it's trivial for the corporation to spy on you and read all your communications. We sold hardware that was designed to do so for corporations/governments that were paranoid about their employees communications. If you don't own it, you can't trust it. Also don't install certificate authorities from your employer unless you're fine with them reading any communication you perform using that device.)

Side note: All of the above assumes we're talking about PKI. If we're not talking about PKI it needs to be clearly stated, as in encryption, every assumption relies on previous assumption and is an interlinked network of trust and assumptions. PKI usually only worries about verifying the identity in one direction (the client verifying the identity of the server). If you want PKI to also verify the client (the server verifying the identity of the client) then every client also needs their own certificate (and associated private key) distributed by the central issuing authority out-of-band. If all you want is encryption without verification of identity, client certificates are not needed.

Educating each other on how PKI works is probably off-topic for this forum, and I suspect all involved are being slightly imprecise in their wording and then arguing with each other's imprecise wording. Also, disparaging others and lecturing is rarely viewed favourably by the community.

Let's all move on.

[mlindner]

Educating each other on how PKI works is probably off-topic for this forum, and I suspect all involved are being slightly imprecise in their wording and then arguing with each other's imprecise wording. Also, disparaging others and lecturing is rarely viewed favourably by the community.

Let's all move on.

Pot and kettle?

Since when has this forum become a place where people attack people with knowledge in their fields? Don't attack someone correcting other people. That has never been how these forums work. (I spent a lot of time writing that informative post.)

I agree, let's move on, now that we've clarified the issues with the original idea, but it appears you didn't fully read my post before responding. In there are several questions to continue the conversation on regarding the encryption type used for the proposed use of Starlink for war, which is precisely on topic.

[launchwatcher]

Certificates containing private keys should indeed be distributed out-of-band

Can you identify a certificate standard that puts a private key *in* the *certificate*?   

The whole point of a certificate is something containing a public key that you can present to a relying party (alongside a message signed with the matching private key) that binds a particular public key to an identity and/or other attributes.    Putting a private key in there would allow any relying party receiving the certificate to impersonate you.

[steveleach]

Educating each other on how PKI works is probably off-topic for this forum, and I suspect all involved are being slightly imprecise in their wording and then arguing with each other's imprecise wording. Also, disparaging others and lecturing is rarely viewed favourably by the community.

Let's all move on.

Pot and kettle?

Since when has this forum become a place where people attack people with knowledge in their fields? Don't attack someone correcting other people. That has never been how these forums work. (I spent a lot of time writing that informative post.)

I agree, let's move on, now that we've clarified the issues with the original idea, but it appears you didn't fully read my post before responding. In there are several questions to continue the conversation on regarding the encryption type used for the proposed use of Starlink for war, which is precisely on topic.

How confident are you that you were correcting him, rather than just having misunderstood him?

[Edit: and yes, I shouldn't have attacked you in the way I did; for that I apologise]

[launchwatcher]

You are correct that the certificate includes the public key, but it's not shared with each blob of information. It's only shared at the beginning of a communication session.

The cryptographic signature is not based on the private key. It is based on a publicly known hash algorithm that anyone can use to verify the message if they know the hash algorithm (which is included in the hashed data signed by the signature). Signatures are just signatures, they are not directly related to encryption.

There are some significant errors and omissions in the above quoted section.

An entity which wishes to generate a digital signature needs a keypair; hash algorithms are almost always involved (to produce a fixed-size "fingerprint" or "message digest" of the signed message) but the private key is needed to generate the signature, and the public key is needed to validate it.

TL;DR Encryption is VERY difficult and the security industry has spent decades and decades patching holes in how it is performed. One tiny mistake and the entire house of cards falls down on itself and you can completely expose the contents of the encryption or man-in-the-middle the connection and fake and replace messages. There have been dozens and dozens of signature algorithms and encryption methods that have been tried, thought to be without issue, and then found to have problems several years later. It's not something you can just come up with on the spot. Also I left out a lot of details here (some of which I've myself forgotten and I'd have to refresh on and others I just never learned). The rabbit hole is very very deep.

This, on the other hand, is the absolute truth!

[mlindner]

You are correct that the certificate includes the public key, but it's not shared with each blob of information. It's only shared at the beginning of a communication session.

The cryptographic signature is not based on the private key. It is based on a publicly known hash algorithm that anyone can use to verify the message if they know the hash algorithm (which is included in the hashed data signed by the signature). Signatures are just signatures, they are not directly related to encryption.

There are some significant errors and omissions in the above quoted section.

An entity which wishes to generate a digital signature needs a keypair; hash algorithms are almost always involved (to produce a fixed-size "fingerprint" or "message digest" of the signed message) but the private key is needed to generate the signature, and the public key is needed to validate it.

Yes I agree with you here. When writing this I got fixated on the hash algorithm portion of the signing algorithm embedded in the certificate. It's "SHA256 With RSA Encryption" not just "SHA256" (to pick one example at random). It's been a couple years since I was last working on this and was just recalling from memories. Apologies. (Also to be honest, I think I was a bit too prideful in my earlier posts, I worked with this stuff but I would not classify myself as an expert. The rabbit hole is just too deep.)

Semi-related, for anyone interested, here's a byte by byte broken down explanation of the contents of a secure TLS1.2 handshake and also the broken down contents of a cryptographic certificate. I used to use these as useful references when I would forget some portion. https://tls12.ulfheim.net/ https://tls12.ulfheim.net/certificate.html

[AJW]

I didn't see this posted elsewhere on NSF.  If so, my apologies.

Chinese researchers say China's military must be able to destroy Elon Musk's Starlink satellites in a war

https://www.businessinsider.com/china-need-ability-to-destroy-elon-musk-starlink-researchers-say-2022-5

[Asteroza]

I didn't see this posted elsewhere on NSF.  If so, my apologies.

Chinese researchers say China's military must be able to destroy Elon Musk's Starlink satellites in a war

https://www.businessinsider.com/china-need-ability-to-destroy-elon-musk-starlink-researchers-say-2022-5

They're gonna need to non-destructively disable Starlink sats though, or risk damaging their own Guowang system, or a kessler syndrome cascade.

Though a ground based laser cooking the phased array panels or solar array would be a quickest way to mission disable a sat (can't transmit to terminals, or has insufficient power to operate the main payload), while leaving it mostly controllable. It then becomes an issue of when will most sats overfly the laser site.

As a countermeasure, Starlink sats could shift to a modified sharkfin mode pointing down, to present the least area to the laser site.


The ISL laser links might be a weakness, if something blocks the line of sight, forcing extensive gateway usage. A maneuvering blocker sat could park itself near a Starlink sat like an "inspector" satellite. Think a 6U version of the Planetary Society's 3U lightsail mission, using the addition 3U for electric propulsion and body mount solar arrays. Pop out the blocker sail when the shooting starts. Functionally similar to so called "inspector" satellites that serve an ASAT function. Would need to launch a swarm of smallsats to do that though, possibly on a responsive launch vehicle (which many of the solid fueled chinese commercial launchers could do for a surge launch in theory). Being able to differentiate that from something like a SDI-style "brilliant pebbles" surge will be hairy...

[Barley]

They're gonna need to non-destructively disable Starlink sats though, or risk damaging their own Guowang system, or a kessler syndrome cascade.

In a real war the side that is less reliant on satellites induces kessler syndrome.

[Robotbeat]

Starlink is surprisingly hard to kill.

[dondar]

They're gonna need to non-destructively disable Starlink sats though, or risk damaging their own Guowang system, or a kessler syndrome cascade.

In a real war the side that is less reliant on satellites induces kessler syndrome.

Kessler syndrome is a fantasy in practical sense. He had used fantastic sigmas and typical for physics impaired idiots exponential growth fallacy. (the pieces of something=/more of something).

Sometimes i think the modern science is hopeless. "Forresters are everywhere".

[Robotbeat]

Actual ASAT against Starlink or other US satellites would be an act of war.

[Greg Hullender]

Actual ASAT against Starlink or other US satellites would be an act of war.

Well, they did say "in a war."

[mlindner]

They're gonna need to non-destructively disable Starlink sats though, or risk damaging their own Guowang system, or a kessler syndrome cascade.

In a real war the side that is less reliant on satellites induces kessler syndrome.

This isn't directed at you specifically, but in general. It's become a pet peeve of mine of late. There's a lot of hot takes in the media and online posters of people constantly parading around kessler syndrome without seeming to understand that kessler syndrome is actually a statistical process and is actually probably already happening. It's a process that happens if you just say "If I stop maneuvering any satellites at all, and then just let the existing debris and satellites sit, what happens over long periods of time (decades/centuries)?". It's a war between how long the debris take to re-enter versus how often more debris are generated. People tend to imagine it like some kind of chain reaction like in an explosion when it's nothing like that.

The kessler syndrome has ZERO effect during a war. Wars, especially in modern times, happen in the timespan of weeks to months, and sometimes years. Trying to cause a kessler syndrome to take out a constellation is basically impossible as it just doesn't happen that fast.

[mlindner]

I didn't see this posted elsewhere on NSF.  If so, my apologies.

Chinese researchers say China's military must be able to destroy Elon Musk's Starlink satellites in a war

https://www.businessinsider.com/china-need-ability-to-destroy-elon-musk-starlink-researchers-say-2022-5

I suggest linking the original English language source. https://www.scmp.com/news/china/science/article/3178939/china-military-needs-defence-against-potential-starlink-threat

There's a slightly different title "China military must be able to destroy Elon Musk’s Starlink satellites if they threaten national security: scientists"

And importantly the first line of the article is

Chinese military researchers say the country needs to be able to disable or destroy SpaceX’s Starlink satellites if they threaten national security.

Emphasis mine. Disabling is a lot easier problem than destroying. Wide area jammers in Starlink frequency range would be very effective.

[DanClemmensen]

Emphasis mine. Disabling is a lot easier problem than destroying. Wide area jammers in Starlink frequency range would be very effective.

How so? Upward-pointing jammers will need to be in each beam footprint, so you need lots of them near the front. Satellite-based downward pointing jammers will need to be near each starlink satellite because the starlink terminals' phased-array antennas are highly directive and will reject any signal that is not within about 2 degrees of the satellite as seen by the terminal.

[launchwatcher]

I didn't see this posted elsewhere on NSF.  If so, my apologies.

Chinese researchers say China's military must be able to destroy Elon Musk's Starlink satellites in a war

https://www.businessinsider.com/china-need-ability-to-destroy-elon-musk-starlink-researchers-say-2022-5

The family of attacks I'd most worry about would be an attack on the control & management systems - along the lines of the attack Russia pulled off in February against Viasat, targeted against any part of the starlink system (satellites, customer terminals, ground stations, or other infrastructure).

[Barley]

They're gonna need to non-destructively disable Starlink sats though, or risk damaging their own Guowang system, or a kessler syndrome cascade.

In a real war the side that is less reliant on satellites induces kessler syndrome.

This isn't directed at you specifically, but in general. It's become a pet peeve of mine of late. There's a lot of hot takes in the media and online posters of people constantly parading around kessler syndrome without seeming to understand that kessler syndrome is actually a statistical process and is actually probably already happening. It's a process that happens if you just say "If I stop maneuvering any satellites at all, and then just let the existing debris and satellites sit, what happens over long periods of time (decades/centuries)?". It's a war between how long the debris take to re-enter versus how often more debris are generated. People tend to imagine it like some kind of chain reaction like in an explosion when it's nothing like that.

The kessler syndrome has ZERO effect during a war. Wars, especially in modern times, happen in the timespan of weeks to months, and sometimes years. Trying to cause a kessler syndrome to take out a constellation is basically impossible as it just doesn't happen that fast.

Mayb it's not exactly kessler syndrom, but consider dispersing a few tonne of 1mm BBs in 550x570km orbits.  Each starlink satellite will average about a hit a week.

You can make any problem far worse if you try hard enough.

[Robotbeat]

Nah, it ain’t that easy. I thought it was before thinking by about it and doing some calculations.

1mm BBs will decay very quickly, will take a while to disperse, and also wouldn’t do much damage.

Since we’re talking about future capabilities, might as well discuss the VLEO orbital altitude Starlink was/is eventually supposed to use for some satellites. At that altitude, the BBS would likely all reenter in just hours, maybe a few days. Not enough time to even disperse at all.

Additionally, if entering a known debris cloud, Starlink can enter streamlined mode which reduces orbital impact cross section by a factor of 20. Could also afford a small whipple shield in front, too, since they’ve already demonstrated visors.

Starlink, especially if some of the satellites are hardened, would be incredibly hard to kill. And can be replaced quickly.

Any kind of space based attack would likely cost more than the target. Any ground based attack would likely be defendable using some sort of coating or shield device, like the visors they had already demonstrated.

Starlink is way harder to kill than conventional satellites would be. No wonder China is panicking.

[aero]

Yes, and it won't be long before there are a few other constellations on orbit providing similar services. Quantity has a quality all its own.