I don't think this helps against someone receiving the signals (all satellites) and rebroadcasting them. The effect of that would be that any receiver of those rebroadcasted signals will believe they are located where the receiver of the rebroadcast is located (just the time is slightly off/late, but that doesn't help much without a reference to check against.)
It's been a few years since I've worked with this stuff but I'm under the impression that you can do this sort of replay only for a short amount of time. If so, is there a point?
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?
I did indeed mean instant replay, and yeah the better your clock in the receiver the narrower the window of delay that the spoofer has to work with. If you can get the time from a 5G network or NTP down to 10ms, that'd mean you can detect being spoofed at >=3km distance if the spoofer has 0 delay (which is doable with a plain analog rebroadcast).
> […] (just the time is slightly off/late, but that doesn't help much without a reference to check against.)
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.
If you wish to know how well Galileo+TESLA work, see perhaps:
> 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). […]
You're overestimating how precise the clocks in normal electronic devices are. A typical PC clock is +/-100ppm. After 1 hour that's 0.36s, which is roughly 100km in distance. A good electronic clock is a tenth that. An OCXO is in the 1ppm range, but that's still a kilometre per hour.
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.]
Yes, albeit 100ppm is bad/cheap crystals. 50-30ppm is normal.
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.)
> 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.
We're in agreement; 1ppm is 31.5s/yr so this lines up with OCXO performance / keeping the crystal at constant temperature. It's still 1km zone of spoofability per hour without resync.
I'm unaware of any technology between OCXOs and Rb standards. The latter have gotten smaller but not tiny and also need quite a bit of ongoing maintenance and calibration.
