Hacker News new | ask | show | jobs
by new299 697 days ago
Can a future GPS replacement or extension use signed transmissions to help address this?
2 comments

The M-code from GPS (for military use) is almost certainly signed (as part of being encrypted), but unfortunately, while the latest L2C (civilian) has ECC, there is no signing.

I would suspect this is probably intentional, as it's difficult to imagine otherwise why this would be omitted in the latest standard.

The US probably wants the operational capability to spoof the civilian GPS; and signing would provide verifiable attributability.

They could still spoof an encrypted public signal as they would be the owners of the key.
Of course they could, but then you'd know it's the US doing it; with cryptographic evidence.

If there are covert operations going on somewhere in the world, where the US isn't publicly claiming to be (and I don't just mean DoD; but also CIA for example); this would be an irrefutable cryptographic trail.

Another case is unintended collateral damage; e.g. say a civilian airliner (with US citizens perhaps) goes down; the US can't have plausible deniability and suggest it was the enemy doing it.

Right but then it would be obviously them vs having the deniability to be like "well it got spoofed by someone who knows who might have interfered in your operation hmmm??"
Signed transmissions help with most spoofing, but it is still possible to replay (slightly out of date) signals received from the satellites, isn't it? Receivers with good internal clocks might be able to detect the delays, but they'd still be jammed.
> isn't it?

No, it isn't. Not unless you intentionally design the protocol to be vulnerable to replay attacks.

It's not really a replay attack. GPS is unique in that it's purely time sensitive, so unlike traditional cryptography you're not trying to replay the signal a second time, you're trying to delay the signal. Replay protection won't work - what an attacker would do is jam the original signal first for some minutes to introduce uncertainty, then replay with a slight delay. Now with experience from traditional cryptography we could think this is avoidable - you just have to detect this new delay. But relativity says you can't. The shift is fully consistent with you having moved, unless you know your position independently it's completely impossible to know if the relative delay changed due to a position change or due to an attack. This attack is pretty difficult to pull off, but it has been done. You can't protect against it cryptographically, but if you have a better INS and onboard clock with less drift you can make it harder.
How could you "jam and replay". It seems like you'd have to choose one or the other.
Why would you have to? You jam the target, not yourself, then you replay the signal louder (you could also be smarter in how you jam so your signal gets through)