Time Synchronization of TESLA-enabled GNSS Receivers

TL;DR

This work tackles secure time synchronization for TESLA-enabled GNSS in broadcast-only settings by introducing a GNSS-independent clock (GIC) and provably secure Loose-Time Synchronization procedures. It extends TESLA and Network Time Security (NTS) concepts to GNSS, deriving bounds on clock drift and measurement times that preserve receipt safety even under delay-capable adversaries. The authors present clock-certification and safe-synchronization algorithms, prove receipt-safety, and analyze vulnerabilities such as $ au_1$ leakage, offering mitigations including nonce usage and randomized query timing. The results demonstrate how to safely assert message authenticity from TESLA-enabled GNSS, applicable to multi-cadence TESLA schemes, with experimental validation and concrete receiver-implementation guidance. Overall, the paper provides a rigorous, implementable framework for secure GNSS authentication in broadcast-only environments with practical impact for safety-critical systems.

Abstract

As TESLA-enabled GNSS for authenticated positioning reaches ubiquity, receivers must use an onboard, GNSS-independent clock and carefully constructed time synchronization algorithms to assert the authenticity afforded. This work provides the necessary checks and synchronization protocols needed in the broadcast-only GNSS context. We provide proof of security for each of our algorithms under a delay-capable adversary. The algorithms included herein enable a GNSS receiver to use its onboard, GNSS-independent clock to determine whether a message arrived at the correct time, to determine whether its onboard, GNSS-independent clock is safe to use and when the clock will no longer be safe in the future due to predicted clock drift, and to resynchronize its onboard, GNSS-independent clock. Each algorithm is safe to use even when an adversary induces delays within the protocol. Moreover, we discuss the implications of GNSS authentication schemes that use two simultaneous TESLA instances of different authentication cadences. To a receiver implementer or standards author, this work provides the necessary implementation algorithms to assert security and provides a comprehensive guide on why these methods are required.

Figures (15)

• Figure 1: A conceptual diagram of our expectation of the future. We expect certain systems will need to use the authentication provided by current and future TESLA-enabled GNSS. Some receivers, such as autonomous cars, will have continuous access to a time server allowing for continuous checking to enforce the TESLA loose-time synchronization requirement. Other receivers, such as aircraft, might not have continuous access to a server but will use periodic maintenance and low-drift GICs between maintenance sessions to enforce the TESLA loose-time synchronization requirement. An adversary can delay the receipt times of synchronization signals to and from a synchronization server.
• Figure 2: A conceptual diagram of Algorithm \ref{['alg: nts']}: NTS. The diagram depicts increasing time from left to right in the provider and receiver clock frames, and the messages shared between them. The protocol presumes provider and receiver have already established a cryptographic authentication instance to protect the content of the messages transmitted. The protocol is susceptible to adversary-induced delays in message transmission (like in Figure \ref{['fig: cert attack']}.
• Figure 3: A conceptual diagram of TESLA's message, commitment (e.g., HMAC), delay-release key transmission cadence from provider to receiver (m, h, k in the diagram, respectively). The transmission arrows approach vertical for the conservative case with a zero-latency adversary as $\varepsilon \rightarrow 0$, which aids in the conciseness of the proofs provided in Section \ref{['sec: clock check']}. The fixed commitment delay is set constellation-wide as $\Theta = \min (t_k-t_h, t_k-t_m)$ among all tuples, determining the requirements on receiver GICs.
• Figure 4: A conceptual diagram of the spoofing scenario as a GNSS message traverses to the receiver. GNSS transmits commitment $h$, which the adversary delivers to the receiver with an adversary-selected delay $\Delta$. The adversary and scenario have latencies $\varepsilon$. We allow $\varepsilon \rightarrow 0$ for the sake of proving the worst case. Commitment $h$ is transmitted and received at time $t_h$ and $t_h'$, respectively, in the clock frame provided by GNSS. Commitment $h$ is measured to have been received at $\tau_h'$ under a clock offset of $\theta$. If the receiver accepts $h$ after GNSS releases $k$, then the receiver would accept an arbitrary forgery, which occurs when $\Delta \geq \Theta$. $\Theta$ is the system-wide minimum time spread between the transmission of the last bit of $h$ and the first bit of $k$.
• Figure 5: Conceptual Diagram Depicting Safety Regions Among Adversary-selected Delay And GIC Clock State. Among the the adversary-selected state $\Delta$ and the GIC drift state $\theta$, there must be constraints to prohibit forgery. The figure shows the safety condition line and labels regions of interest. While our selected decision line is shown, the GNSS designer can shift the regions left or right. Here, the uncertainty of the clock drift is evenly spread to accommodate unbiased clock drift in the context of false alarms. The entire region Forgery Accepted is outside the time synchronization bound. As time progresses, the decision the decision line will move down, expanding the False Alarm region until the GIC must synchronize.