Bigger WTF is why critical systems still use unencrypted gps signal. It is like using plain SMTP emails for banking transactions, and relying on "sender" for authentification.
Of course, they dont protect against jamming.
> Because an attacker can just replay legitimate broadcasts with slightly skewed time and origin and introduce huge errors into the fix.
Galileo uses a signing system (Timed Efficient Stream Loss-Tolerant Authentication, TESLA) to protect the authenticity of its messages, including preventing replays:
* https://gssc.esa.int/navipedia/index.php/Galileo_Open_Servic...
* https://datatracker.ietf.org/doc/html/rfc4082 (TESLA)
* https://people.eecs.berkeley.edu/~tygar/papers/TESLA_broadca...
* https://users.ece.cmu.edu/~adrian/projects/stream/node1.html
If the receiver expects a key to have been revealed at a particular timestep, it won't accept a replayed message with that key after that, so you can't record and replay indefinitely.
EDIT: Unless you indeed meant to instantly replay - would the receiver accept the highest strength signal, ie. yours?
For most payloads and targets, this requires very little distortion.
The 'time sync' does not need to be done in the same absolutely sense (time_t is the same everywhere), but only in the relative sense:
Various approaches exist for time synchronization [15,16,17,18].
TESLA only requires the receiver to know an upper bound on the delay
of its local clock with respect to the sender's clock, so a simple
algorithm is sufficient.
Knowing the (rough) broadcast delay from sender to receiver is sufficient.
You're citing things without understanding them.
First, you've mangled that summarisation, knowing an upper bound on delay is not the same as knowing delay.
Second, that's true for using TESLA for data streams. Not for when the timing of the stream itself is the information content. That bound on delay translates into a spatial zone of spoofability. The RFC refers to the content being timely (not stale) and authenticated, but timely is not the same as using the timing itself as data.
> Global Navigation Satellite Systems (GNSS) are critical for infrastructure like energy, telecommunications, and transportation, making their accuracy vital. To enhance security especially against location spoofing, in 2024, the Galileo GNSS system adopted the Timed Efficient Stream Loss-Tolerant Authentication (TESLA) protocol, for Navigation Message Authentication (NMA). However, past and present TESLA versions have lacked formal verification due to challenges in modelling their streaming and timing mechanisms. Given the importance of formal verification in uncovering protocol flaws, this work addresses that gap by formally modelling and verifying the latest TESLA protocol used in Galileo; we verify Galileo’s TESLA protocol in the well-known Tamarin prover. We discuss our findings and, since this is work-in-progress, we contextualise them in terms of next steps for us, as well as for future Navigation Message Authentication protocols inside GNSS systems.
> Then, security-wise, via 8 lemmas, we show: […] timeliness of the messages: the receiver will reject messages (even when they have cryptographic integrity) if they were received outside of their validity time-interval; […] replay-related security: i.e., replay attacks are possible, but only if the acceptability time interval is not violated (i.e., messages replayed too late will be rejected). […]
There's a reason GPS satellites are used as reference clock for PPS, PTP and NTP. A naval vessel you could carry a Rubidium clock on, I guess. But on ground vehicles or mobile receivers... nope.
[ed.: OCXOs aren't that large, 1cm^3 box ballpark, too large* for a smartphone or laptop but not a problem on larger quadcopters, cars or military radio equipment. And 1ppm is long term drift, you can try compensating a bit beyond that, so - I guess it's a question of spending the money and energy** on OCXOs.
* thick specifically, can't easily be made thin AFAIK
** the first O there is Oven - roughly 0.5W continuous draw.]
Are you confident in these numbers? They add up to 52 minutes of drift/year.
Good modern quartz watches specify 5 seconds/year drift, almost 3 orders of magnitude better.
The difference with a quartz watch is that it's factory calibrated with the load capacitance on the crystal, and that it's a 32768Hz tuning fork. For a variety of reasons, generating higher frequency clocks off 32768Hz is... "annoying" (huge PLL ratio, very slow feedback loop step), and typical crystals in the 10-100MHz range are just less precise and thermally stable. (Not sure why, I'm not an oscillator manufacturer...)
(NB: you can of course correct for initial deviation in software. The actual problem is stability over temperature.)
Ed.: https://www.digikey.com/en/products/filter/crystals/171 (or, in the hopes the filter on the link works, https://www.digikey.com/en/products/filter/crystals/171?s=N4... ) - look at the options and prevalence for frequency stability & tolerance.
Ed.2: a wristwatch also benefits from being kept at constant-ish body temperature.
I think most quarts watches oscillate at 32 kHz = 2^15 Hz, high precision quartz watches at 8.4 MHz = 2^23 Hz.
> The actual problem is stability over temperature
Apparently, designers of these watches compensating for that somehow: https://en.wikipedia.org/wiki/Quartz_clock#Thermal_compensat...
> benefits from being kept at constant-ish body temperature
Some people take off their watches every day before going to sleep.
These high-end quartz oscillators are probably too expensive to use in commodity computers. Still, the cost shouldn’t look too bad when compared to a price or an airplane, marine vessel, or most military equipment.
(GPS sync is a question of nanoseconds.)
If you want to prevent replaying as well, add a counter.
Obviously not, but solving problems is always a cost benefit and we went from all spoofing is impossible to some spoofing is possible. What is the benefit of doing this and what is the cost?
> If you want to prevent replaying as well, add a counter.
It's not clear that would be able to prevent spoofing if the attacker could overwhelm and degrade the real signal.
(EDIT: I see the other reply thread is already asking the same thing, didn't intend to ask about the same thing)
There's another frequency they could be using that is higher power but hasn't been put into production yet.