Competing with four free GNSS constellations is an interesting business model for sure...

I would guess the business model is 'pay us and we'll give you the encryption key to our coded transmissions'.

Those coded transmissions are far harder to jam unless you have the key. So it's all about selling to as many customers as possible whilst having not a single customer leak the key.

That's why militaries use keys that rotate daily and won't let anyone else use the military signal.

No they're harder to spoof. Jamming is easy, but requires more power to achieve a desired effect and as they note they're planning to operate a low altitude constellation with closer transmitters as a result, so harder to swamp the signal for the receiver.

Why wouldn't they use public key cryptography for that?

Your satellite doesn't want to be sending out lots of different signals - due to a limited power budget.

So you have to send out one (or maybe a couple) of signals protected by a key.

Yes, you can distribute that key individually to clients using public key cryptography over the same link (and many services like pay TV do exactly that).

But fundamentally any client who is able to decrypt the main stream can also share the key with someone evil who can use that info to jam the same stream.

Isn’t this the exact problem tree-based broadcast encryption schemes were designed to solve? You could surgically revoke the keys of a bad actor, and I’m not exactly sure, but I think the scope of their ability to affect the jamming resistance of other users is necessarily limited by the tree.

Indeed you can revoke anyone's keys any time with such a scheme. But a single leaked and unrevoked key is still enough to jam it for everyone.

Obviously you could have some "revoke each players keys in turn until the jamming stops" scheme, but it seems suboptimal.

I would think you could, in principle, deduce the bad key from a recorded segment of the jamming signal, and only revoke when identified.

I would have to look at the math more specifically, but I would think it would be impossible to both disguise the compromised key and take advantage of the key to interfere with the signal in the way its designed to prevent. And even if you did, I’m fairly sure the jamming would only affect users whose decryption runs through your branch, and in your geographic proximity so I don’t think it would have an advantage of countering the below the noise floor decryption designed to mitigate against jamming.

> jam the same stream.

To add to that, other people won't be able to spoof the original stream (as that needs the private key), but instead only jam it.

It would be the same failure mode as SSL certificates.

In the case of gnss systems, you can also spoof the stream, since the interesting bit of the stream is not the data contained inside, but instead the relative time of arrival of different streams from different satellites.

An attacker can record the streams and replay them milliseconds later.

A client can protect against this if they have an atomic clock, but that's only for clients willing to pay a decent amount.