TESLA Protocol in Galileo Authentication

• TESLA Protocol in Galileo is a time-based broadcast authentication scheme that employs delayed key disclosure and one-way key chains for secure message verification.
• It utilizes cryptographic primitives such as HMAC-SHA256 and ECDSA, ensuring message integrity and resistance to replay and delay attacks through strict timing enforcement.
• Its practical implementation in OSNMA and ACAS highlights the need for precise time synchronization and hardware resilience to counter vulnerabilities like manipulated synchronization attacks.

The TESLA (Timed Efficient Stream Loss-tolerant Authentication) protocol is central to the design of broadcast authentication in emerging Global Navigation Satellite Systems (GNSS), most notably within the European Galileo system’s Open Service Navigation Message Authentication (OSNMA) service and the Assisted Commercial Authentication Service (ACAS). TESLA is engineered for the broadcast-only, asymmetric authentication of time-critical GNSS navigation messages using cryptographically enforced key schedules and delayed key disclosure, providing scalable and loss-tolerant message authentication without interactive communication or per-receiver state. Galileo’s adoption of TESLA in both OSNMA and ACAS exemplifies state-of-the-art message origin authentication under the constraints of space-based, high-latency, and delay-adversarial threat models.

1. Key Principles and Cryptographic Construction

TESLA in Galileo leverages a one-way key chain constructed by forward iteration of a hash function $H(\cdot)$: starting from a secret seed $K_N$, the operator derives $K_{n} = H(K_{n+1})$ down to a root key $K_0$ that is digitally signed. At interval $i$, the key $K_i$ is used to produce message authentication codes (MACs) but not disclosed until a predetermined number of intervals later.

Within OSNMA, the E1-B I/NAV message is structured into recurring 30-second subframes, each carrying fragments of navigation data, fragments of the root signature (HKROOT), key or tag fragments (MACK), and time. Each navigation data subframe is protected by per-segment truncated HMAC-SHA256 MACs keyed with $K_i$. The keys $K_i$ are disclosed two subframes (60 seconds) after use. Root key commitment $K_0$ and associated chain parameters are distributed via OSNMA fields and authenticated using ECDSA (Wang et al., 16 Jan 2025).

In the ACAS context, the TESLA key chain produced and signed via OSNMA is further used to “wrap” short, pre-extracted E6C encrypted code snippets (ECS). These are encrypted with AES-256 using a key $K'_j = \text{SHA256}(K_j)$ and published, while $K_j$ itself is disclosed in the OSNMA protocol after a delay, enabling receivers to decrypt, correlate, and authenticate received signal snapshots (Fernandez-Hernandez et al., 2022).

2. Key Disclosure Timing and Time Synchronization

TESLA’s security is fundamentally predicated on receiver compliance with a “loose” time synchronization (TS) bound. In Galileo OSNMA, each subframe carries the Galileo System Time (GST) stamp; the receiver maintains a local reference time (LRT). The protocol enforces $|t_\mathrm{GST}-t_\mathrm{LRT}| < B$, where $B \leq \Delta T/2 = 15$ s, ensuring keys are never accepted prematurely.

Delay-capable adversary modeling exposes the channel to message replay, delay, and mis-ordering, but not to disclosure of preimage-resistant hashes or MACs. Receipt safety—the property that data or MACs cannot be accepted post key release—is proved by enforcing two constraints at the receiver: (1) the onboard (GNSS-independent) clock is “safe” and within $B$, and (2) the latest received message timestamp precedes the associated key disclosure, minus half the allowed uncertainty window (Anderson et al., 18 Jul 2024).

Time synchronization is maintained by periodic two-way NTS-like exchanges, certifying offset bounds $|\theta| < \Theta/2$ given maximum drift rates and scheduling next resync deadlines. Implementations must reject authentication if drift bounds or timing intervals are ever violated.

3. Message Structure and Authentication Verification

The message and authentication flow comprise three main elements per 30 s subframe:

Subframe	Content	Purpose
$i$	Data $D_i$	Navigation message segments
$i+1$	MACs $\{\text{tag}_j\}$	Authentication tags for $D_i$
$i+2$	Key $K_i$	Key used for prior MACs

Each data subframe is partitioned into $M$ segments $S_1, ..., S_M$, with $m_j$ constructed as a concatenation of PRN identifiers, timestamps, and segment $S_j$. The tag is $\text{tag}_j = \text{HMAC-SHA256}(K_i, m_j)$, truncated (e.g., to 40 bits). On receipt of tags and, subsequently, $K_i$, the receiver validates the MAC, checks the chain linkage (i.e., $H^{(n)}(K_i) = K_{lv}$), and enforces TS. Any out-of-order or delayed key triggers discard of the corresponding material (Wang et al., 16 Jan 2025).

For ACAS, receivers buffer E6C signal snapshots at predetermined times, later decrypting published RECS segments with $K_j'$ after its disclosure, then verifying correlation timing against authentic signal arrival to threshold $\Delta\tau_j \leq Y_\mathrm{auth}$, enabling position authentication only if all satellites' tests pass (Fernandez-Hernandez et al., 2022).

4. Security Model, Parameters, and Adversarial Robustness

TESLA in Galileo explicitly models a Dolev-Yao adversary: able to delay or replay, but not cryptographically invert, and with perfect GNSS time knowledge. Security properties include:

• MAC integrity: Tags accepted only if MAC verification passes.
• Key-chain authentication: Each disclosed $K_{i}$ must chain to a signed anchor $K_0$.
• Receipt safety: Messages never accepted if their MAC arrives after the key is disclosed (modulo sync uncertainty).
• Drift tolerance: Permitted by the explicit synchronization bound $B$ and strictly enforced at the protocol level.
• Replay and delay-resilience: “Early enough” arrival required for authentication; any network or intentional adversarial delay cannot fool receivers adhering to protocol bounds (Anderson et al., 18 Jul 2024).

Trade-offs in security parameters include cadence and delay intervals, with two-TESLA-instance operation (fast, slow) enabling trade-offs between rapid authentication (requiring low drift, more frequent resync) and longer-drift channels for low-cost receivers.

5. Practical Implementation and Receiver Requirements

Receivers must implement the following core TESLA logic:

• Maintenance of a GNSS-independent clock, with drift modeling $B(\Delta t)$ (often as $|\theta(t) - \theta_\text{sync}| < \rho \Delta t$ for drift rate $\rho$).
• Time synchronization routines (modified NTS), including periodic two-way exchange and certified upper/lower clock offset bounds.
• Per-subframe message buffering until key and tags arrive, bounded by the allowed drift window.
• Enforcement of key and tag linkage by repeated hashing and MAC verification.
• Multi-cadence support: simultaneous handling of fast and slow TESLA streams, with strict per-channel receipt safety checks and drift-bound enforcement (Anderson et al., 18 Jul 2024).

Practical impact reflects the need for precise, hardware-resilient timekeeping, modest buffering (only a few subframes if processing latency is low), and cryptographic primitives standard to embedded security hardware (HMAC-SHA256, ECDSA over NIST curves).

For ACAS, receivers additionally require the storage of prepublished RECS segments (scaling with authentication autonomy), modest computational resources for AES-256-CBC and correlation, and precise authenticated time/position knowledge for correct thresholding. No changes to the Galileo RF signal or payload are required; implementation is by ground-side key/protocol orchestration and receiver-side cryptographic and clock management (Fernandez-Hernandez et al., 2022).

6. Vulnerabilities and Security Considerations

Recent analysis has revealed that the practical security of OSNMA’s TESLA deployment can be compromised via vulnerabilities in the time synchronization enforcement:

• Artificially-Manipulated Synchronization (ATS): Attackers can manipulate signals and/or the receiver’s LRT while still passing the enforced TS window, enabling compliant but falsified authentication.
• Interruptible Message Authentication (IMA): Message authentication can be interrupted and later restored, e.g., via concatenating replay tactics.
• TSR/TSF Attacks: Adversaries can replay ($TSR$) or forge with previously disclosed keys ($TSF$), synchronizing clocks to ensure protocol compliance, and thereby inject spoofed, authenticated-looking data.
• Practical Real-world Exploits: All proposed attacks were experimentally validated on commercial receivers and open-source SDR implementations, with the TSF attack capable of spoofing receiver location to arbitrary positions (Wang et al., 16 Jan 2025).

This analysis underscores the necessity of robust, GNSS-independent timekeeping and hardening time synchronization routines, as even small synchronization vulnerabilities may ubiquitously compromise TESLA-based broadcast authentication.

7. Broader Implications and Evolving Standards

The adoption of TESLA in Galileo introduces scalable, efficient, and loss-tolerant message authentication suitable for the unidirectional, open broadcast nature of GNSS. Key innovations include one-way key chains, time-delayed disclosure, strict but loose time synchronization enforcement, and the ability to trade off authentication latency for hardware requirements via multi-cadence operation.

Simulation and experimental results demonstrate provable resistance to delay and replay attacks under explicit drift and timing models; however, implementation details of time synchronization and side-channel resistance are critical. The evolution of semi-assisted schemes like ACAS further illustrates TESLA’s flexibility in hybrid cryptographic and signal-domain authentication models, enabling a continuum of performance vs. hardware requirement profiles compatible with current and future GNSS services.

Ongoing standardization and implementation efforts are focused on hardening time synchronization protocols, formalizing fast/slow TESLA cadence operation, and integrating comprehensive adversary modeling into specifications to address emergent threats revealed by recent research (Wang et al., 16 Jan 2025, Anderson et al., 18 Jul 2024, Fernandez-Hernandez et al., 2022).