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.