Comment by tialaramex | Hacker News Reader

Comment by tialaramex | Hacker News Reader

Parent Full thread

> I thought the military GPS signals were encrypted

I'm sure this is true in the sense that general publications use "encrypted" to mean, "There was some sort of cryptographic stuff involved and it went over my head" rather than actually encrypted. Like they do when they tell you that the passwords stolen in a breach were "encrypted with bcrypt" for example.

The key thing to pay attention to here is that unlike say, TLS, this is not a conversation. A GPS receiver is just that, a receiver passively observing the signals. You would usually "bend" GPS by relaying signals from somewhere or somewhen else, and the passive receiver concludes that it must be where the signals it is receiving seem to suggest it is.

Take an easy scenario, imagine I'm in a warehouse that has been designed as a Faraday cage. You've fit a handful of transmitters to the warehouse, and you play back a recording of GPS signals received three weeks ago in the desert outside Las Vegas.

How does my GPS receiver know (using some hypothetical "encrypted military signal") that it isn't in fact near Las Vegas three weeks ago? That's what the signals seem to suggest and there is literally no contradictory data available.

I mean ... That's what's cryptography is for. Making sure that what you receive is from the sender you expect it from.

Ie sign the current data package plus the current time. Receivers ignore everything with an incorrect timestamp and/or wrong signature.

Now you only have to make sure that you don't lose your private keys.

But these signals are from the real GPS birds, and they are really the ones for Las Vegas three weeks ago. They are completely authentic.

It sounds like you are referring to a replay attack.

Mental model tweak: The signals aren't for a specific location, they are world-wide. So the "for Las Vegas" part doesn't work.

Replay attacks are just a kind of denial of service. In that case, you may as well just use jamming. Spoofing attacks are far more dangerous, and cryptographic signing defeats them effectively.

> The signals aren't for a specific location, they are world-wide. So the "for Las Vegas" part doesn't work.

The whole point of GPS is that the differential in signal timing between the signals from the transmitters on different satellites tells you how far you are from those satellites, and thus if you know where the satellites are supposed to be, that tells you where you must be.

As a result, recording the signals in a desert outside Las Vegas three weeks ago is by far the easiest way to get... drum roll... the signals which when received by your GPS receiver right now will convince it that right now it's three weeks ago and it is just outside Las Vegas.

> Replay attacks are just a kind of denial of service

Nope, as explained they're actually a very common and effective spoofing tactic. The receiver doesn't say "No service" it will tell you that you're outside Las Vegas three weeks ago.

> Spoofing attacks are far more dangerous, and cryptographic signing defeats them effectively.

Spoofing attacks use the same principle (although of course they'll tell your receiver it's a few milli-seconds ago and it is somewhere nearby, not outside Las Vegas three weeks ago).

Signatures make no major difference, this data is authentic it's just second hand. Everything checks out, that's why they do it.

Yep ... and they (should) contain signed timestamps from three weeks ago ... so you ignore them.

The thing with GPS is that it is also a time source, so you'd need a secondary source for your time to confirm that you are not off by three weeks.

GPS spoofing is the same signal, emitted at different time and space.

Which is why the GP mentioned encoding the timestamp and mentioned data packages (ergo package based one-directional communication). If by same signal you mean looking similar, but not containing the same data, then the problem is already solved. If you mean containing the same data, then there is no problem.

This requires a precise internal clock that is always correct. If that clock drifts or is reset because the battery dies, GPS receiver would stop working.

Wouldn't it suffice to have a rather imprecise time + counter in the GPS message? So if multiple messages arrives the one with the largest count is kept.

I wonder if the problem lies in a different aspect of needing to authenticate messages quickly enough and thus requiring more processing power.

This is not a packet switched network and you are not receiving nice neat little messages to decode, you've got a radio receiver, the real transmissions are from a satellite in space, while unfortunately your adversary is transmitting from radio towers or even a portable transmitter, much closer and able to be supplied with energy easily so more powerful, but on the same frequencies.

Also, be careful with assuming that late = imposter. The whole point of GPS is that signals take time to travel over distance, so, maybe the signal is late because you're further from that satellite instead, which is what you were trying to measure when you got distracted trying to prevent spoofing.

I agree that there is an issue with overwhelming the satellite transmission frequencies. However, the signal can never be delivered earlier by adversary as signal travelling in air is about the physical limit. Perhaps only a stalking satellite could intercept and deliver the message faster, but that seems like a sci-fi.

> got distracted trying to prevent spoofing

Indeed overwhelming the processing power with junk seems the important issue if crypto is added.

I do know the basics of GPS but not much further than this.

Wouldn't it be possible to embed a clock in a GPS receiver that gets used when decrypting the packets it receives? So instead of just receiving a encrypted packet and trusting it, it'll decrypt it and check when the message was from and if the slew is more than ~1 minute or whatever, then it is probably forged.

That would at least prevent the scenario that you're describing, but since I don't know enough about GPS, it probably introduces other problems.

Sure it's possible but GPS is all about time. Faking the time by a fraction of a second will break the whole protocol. 1min is enough to transport the signed packets across the world.

Sky basically if your only authentication scheme is time, and the protocol is all about getting the time, it is very hard to detect proxing from other locations because the bound of accepted times basically needs to be big enough that you can be spoofed a meaningful amount.

GPS receiver does not know exact time. It has a built-in clock, but that clock is not very precise and is only used to speed up signal acquisition. The exact time is determined from the received signals.

GPS receiver can determine its own position (and get exact time in the process) even after internal clock battery dies, or when internal clock drifts too much. Such cold start takes longer, but is possible.

The clock slew is how GPS works in the first place. You'd have nothing to compare it to.

Receivers and transmitters are synchronized in time, before they are used.

So if the timestamp of the signal deviates of GPS's internal clock, GPS receiver knows it.

Now for commercial receivers, they assume their internal clock is wrong, and set their own time to new GSP time.

Not sure what military GPS receivers do, but I imagine, they kind of thought about this, and just ignore signals that have timestamps that differ too much. This probably means that they need pretty accurate internal clock.

Another way to encrypt a signal is to just have an encrypted sequence going on. If you get a sequence you have already seen something is wrong. Think of it as hash+salt or something similar.

Reply on news.ycombinator.com