> 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.