4 ms·

>> An even bigger WTF is why GPS data isn't signed with some official key so spoofing is impossible. > Because an attacker can just replay legitimate broadcast

>> An even bigger WTF is why GPS data isn't signed with some official key so spoofing is impossible. > 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_Service_Navigation_Message_Authentication https://gssc.esa.int/navipedia/index.php/Galileo_Open_Servic... * https://datatracker.ietf.org/doc/html/rfc4082 https://datatracker.ietf.org/doc/html/rfc4082 (TESLA) * https://people.eecs.berkeley.edu/~tygar/papers/TESLA_broadcast_authentication_protocol.pdf https://people.eecs.berkeley.edu/~tygar/papers/TESLA_broadca... * https://users.ece.cmu.edu/~adrian/projects/stream/node1.html https://users.ece.cmu.edu/~adrian/projects/stream/node1.html

eqvinox 4mo ago
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.)
- rkourdis 4mo ago
  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?
  - eqvinox 4mo ago
    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).
  - 15155 4mo ago
    The point is to prevent missiles and drones from impacting their intended targets. For most payloads and targets, this requires very little distortion.
- DoctorOetker 4mo ago
  nobody would send a military vehicle (manned or drone) without initializing a proper clock, the replays would be stale.
  - eqvinox 4mo ago
    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.]
    - Const-me 4mo ago
      > A typical PC clock is +/-100ppm. After 1 hour that's 0.36s 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.
      - eqvinox 4mo ago
        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.) Ed.: https://www.digikey.com/en/products/filter/crystals/171 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=N4IgjCBcpgHAzFUBjKAXATgVwKYBoQB7KAbRHgHYBWMAFipAF0CAHNKEAZUwEsA7AOYgAvgTABOWOKQhUkTLgLFIZAAxNhokADYZPACYcAtGAit2kECAJoAnixwcRwoA 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.
- throw0101a 4mo ago
  > […] (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. * https://datatracker.ietf.org/doc/html/rfc4082#section-3.3.1 https://datatracker.ietf.org/doc/html/rfc4082#section-3.3.1 Knowing the (rough) broadcast delay from sender to receiver is sufficient.
  - eqvinox 4mo ago
    > 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.
    - throw0101a 4mo ago
      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). […] * https://www.ndss-symposium.org/ndss-paper/auto-draft-620/ https://www.ndss-symposium.org/ndss-paper/auto-draft-620/ * https://dx.doi.org/10.14722/spacesec.2025.23009 https://dx.doi.org/10.14722/spacesec.2025.23009

eqvinox 4mo ago

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

rkourdis 4mo ago
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?
- eqvinox 4mo ago
  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).
- 15155 4mo ago
  The point is to prevent missiles and drones from impacting their intended targets. For most payloads and targets, this requires very little distortion.
DoctorOetker 4mo ago
nobody would send a military vehicle (manned or drone) without initializing a proper clock, the replays would be stale.
- eqvinox 4mo ago
  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.]
  - Const-me 4mo ago
    > A typical PC clock is +/-100ppm. After 1 hour that's 0.36s 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.
    - eqvinox 4mo ago
      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.) Ed.: https://www.digikey.com/en/products/filter/crystals/171 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=N4IgjCBcpgHAzFUBjKAXATgVwKYBoQB7KAbRHgHYBWMAFipAF0CAHNKEAZUwEsA7AOYgAvgTABOWOKQhUkTLgLFIZAAxNhokADYZPACYcAtGAit2kECAJoAnixwcRwoA 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.
throw0101a 4mo ago
> […] (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. * https://datatracker.ietf.org/doc/html/rfc4082#section-3.3.1 https://datatracker.ietf.org/doc/html/rfc4082#section-3.3.1 Knowing the (rough) broadcast delay from sender to receiver is sufficient.
- eqvinox 4mo ago
  > 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.
  - throw0101a 4mo ago
    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). […] * https://www.ndss-symposium.org/ndss-paper/auto-draft-620/ https://www.ndss-symposium.org/ndss-paper/auto-draft-620/ * https://dx.doi.org/10.14722/spacesec.2025.23009 https://dx.doi.org/10.14722/spacesec.2025.23009