Galileo OSNMA: Secure Navigation Messaging

• OSNMA is a cryptographic protocol that authenticates Galileo’s civilian navigation messages using the TESLA paradigm and public-key bootstrapping.
• It employs time-delayed symmetric key disclosure, truncated HMAC tags, and ECC-based digital signatures to enable data origin authentication and prevent replay attacks.
• The protocol carefully balances bandwidth constraints, strict time synchronization, and quantum threat considerations while evolving towards post-quantum resilience.

Open Service Navigation Message Authentication (OSNMA) is the European GNSS Galileo’s protocol for cryptographically authenticating civilian navigation messages. OSNMA is the first operational large-scale scheme of its kind in global navigation satellite systems, providing both data origin authentication and anti-replay protection for open-service signals. The protocol is based on time-delayed disclosure of symmetric cryptographic keys, the TESLA paradigm, and is bootstrapped by public-key signatures over each key chain’s root. OSNMA’s architecture, cryptographic primitives, operational workflow, and practical deployment constraints (e.g., bandwidth, time synchronization, clock model, quantum resilience, and vulnerabilities) reflect the particular requirements and attack surfaces of GNSS environments.

1. Message Authentication and Protocol Architecture

OSNMA’s design relies on the TESLA (Time Efficient Stream Loss-Tolerant Authentication) construction: a one-way chain of symmetric keys $K_0, K_1, \ldots, K_n$ is generated on the ground via iterated hashing,

$K_i = H(K_{i+1}), \quad K_n = K_\mathrm{ROOT},$

where $H$ is a cryptographic hash function and $K_\mathrm{ROOT}$ is the chain anchor.

Each navigation data block $m_i$ is authenticated by a truncated HMAC using the current key,

$$T_i = \mathrm{Trunc}_{l_T}(\mathrm{HMAC}_{K_i}(m_i)),$$

with tag length $l_T$. Keys $K_i$ are disclosed with a fixed delay $\Delta$, ensuring message tags can only be verified after key revelation, thus enabling delayed authentication immune to forgeries prior to disclosure.

TESLA initialization and root key validation are achieved via elliptic-curve digital signature (ECDSA, P256 or P-521): $$\mathrm{DS} = \mathrm{ECDSA\_Sign}_{sk_\mathrm{EC}}(K_\mathrm{ROOT}).$$ This signature ensures the authenticity of the TESLA key chain. Public key management is further strengthened by using a Merkle tree over 16 long-term EC public keys published by the Galileo Service Centre (GSC); regular rebroadcasts refresh the active public key, with cryptographic chaining to validate transitions (Junquera-Sánchez et al., 2023).

Galileo’s I/NAV message structure is divided into 30 s "subframes," each of 15 pages (2 s/page). Odd pages in E1-B signals dedicate 40 bits to OSNMA fields, which are split into HKROOT (root key, signature metadata) and MACK (message authentication codes and key fragments, up to 480 bits per subframe). The design supports cross-authentication MAC tags for satellites that cannot send their own tags.

Key management details, bandwidth minimization measures (truncated MACs, short-lived key/tag fields), and receiver-side synchronization requirements are central to protocol operation and security (Junquera-Sánchez et al., 2023, Galan et al., 2024, Ardizzon et al., 25 Jan 2025).

2. Cryptographic Assumptions and Quantum Threats

OSNMA’s cryptographic assurance is predicated on two main hardness assumptions:

• The security of ECDSA (against private key extraction under classical cryptanalysis), and
• The preimage/collision resistance of the employed hashes and HMAC (for symmetric key and tag durability).

Quantum adversaries, via Shor’s algorithm, break ECC and RSA—rendering ECDSA insecure and enabling attackers to forge $K_\mathrm{ROOT}$. Grover’s algorithm reduces the effective bit strength of symmetric primitives by roughly half, e.g., 256-bit hashes provide only 128 bits of quantum strength. For OSNMA, these advances threaten both asymmetric bootstrapping (forged roots enable arbitrary chain forgeries and navigation spoofing) and tag security (more feasible brute-force or preimage attacks).

For PQC readiness, key and signature size are critical bottlenecks:

• ECDSA-P521 signatures (1,056 bits) fit in DSM-KROOT fields, but leading PQC alternatives (Falcon-512, Dilithium-2, SPHINCS+) have signature/key sizes from 666 B (Falcon) to over 8 kB (SPHINCS+), far exceeding current in-band message capacities (≤1,664 bits per DSM).
• Table of PQC signature/key sizes (Junquera-Sánchez et al., 2023):

Algorithm	Sig Size	Pubkey Size	CPU verify time
Falcon-512	666 B	897 B	~0.6 ms
Dilithium-2	2,420 B	1,312 B	~2-3 ms
SPHINCS+-128s	7,856 B	32 B	~8 ms

For full quantum resistance, the ICD must be updated—expanding DSM block IDs, reallocating bits, or incorporating out-of-band distribution. Until such upgrades, hybrid solutions (ECC/TESLA in-band, PQC sideband) and temporal mitigations (max tag lengths, fast chain re-keys, "hybrid-mode" signaling) are recommended (Junquera-Sánchez et al., 2023).

3. Time Synchronization, Receiver Clock Models, and Hold-Over

OSNMA’s security is intimately tied to loose time synchronization between the receiver’s local reference time (LRT) and system time (GST). Each authentication event, involving time-delayed key disclosure, requires that the receiver’s clock error $|\Delta T(t)| = |T_c(t) - t_\mathrm{sys}|$ remain within a bound $T_L$ (e.g., $T_L = 165$ s for "SLOW-MAC," $T_L = 15$ s for "FAST-MAC" modes).

Receiver clock error is modeled as the integral over frequency deviations

$$y(t) = \varepsilon_\mathrm{offset} + \varepsilon_\mathrm{ageing}(t) + \varepsilon_\mathrm{temp}(t) + \varepsilon_\mathrm{other}$$

$\varepsilon_\mathrm{offset}$ – residual calibration error; $\varepsilon_\mathrm{ageing}(t)$ – long-term crystal aging; $\varepsilon_\mathrm{temp}(t)$ – temperature-induced drift; $\varepsilon_\mathrm{other}$ – vibration, supply, gravity, etc.

Worst-case clock deviation over hold-over $T_R$ is bounded: $$|\Delta T(T_R)| \le Y_\mathrm{temp} \cdot T_R + \int_0^{T_R} Y_\mathrm{ageing}(\tau)\,d\tau + Y_\mathrm{offset} T_R + Y_\mathrm{other} T_R$$ Automotive-grade TCXO oscillators ($Y_\mathrm{temp}\approx0.5$ ppm, $Y_\mathrm{age}(1\mathrm{yr})\approx1.0$ ppm) permit $T_R\approx2$ years for $T_L = 165$ s; "FAST-MAC" requires more frequent calibration every $\approx110$ days (Ardizzon et al., 25 Jan 2025).

Receivers must not steer clocks using PVT during authentication validation, as this would use unauthenticated data. Workshop calibration or trusted external time is essential for maintaining synchronization (Ardizzon et al., 25 Jan 2025).

4. Practical Implementation, TTFAF, and Receiver Optimizations

OSNMA introduces a time to first authenticated fix (TTFAF), defined as the interval from signal acquisition to when the receiver can output a fully authenticated position using navigation data and matching tags/keys. In baseline ("hot start") mode, using a 30 s subframe and two disclosure delays, TTFAF ranges from 90 to ~119 s. The "loose time sync" threshold $T_L$ imposes a minimum delay for security.

Two major families of receiver-side optimizations are effective:

• Page-level processing and redundancy combining: Receivers recover partial subframes by collecting MACK/tag and key fragments at the page level from multiple satellites, reassembling the needed information as long as fragments are present.
• Exploiting IOD/COP fields: Intelligent use of Issue Of Data (IOD) and Cut-Off Point (COP) fields in tags provides linkages across subframes, allowing navigation data recovery even with missed subframes or partial page loss.

Best-case TTFAF is reduced from 70 s (standard OSNMA, $T_S$=30 s) to 44–46 s with COP+IOD optimizations ($T_S$=17 s), and average TTFAF in open-sky from 84.5 s to 68.8 s. In urban/fragmented scenarios, TTFAF drops by approximately 40–50% (e.g., hard urban mean from 266.1 s to 146.1 s). These techniques are implemented in the open-source OSNMAlib project (Galan et al., 2024).

5. Security Analysis: Spoofing, Replay, and Vulnerabilities

While OSNMA’s delayed-disclosure and cryptographic authentication substantially raise the bar against classic GNSS spoofing (e.g., Security Code Estimation and Replay—SCER attacks), targeted vulnerabilities and attack vectors remain:

• Replay/SCER detection: Receivers can exploit the unpredictability of MACK bits to detect SCER attacks via partial correlation techniques, with the $R_3$ mean-difference statistic being most effective; with 110–380 unpredictable symbols ($15$–$60$ s collection), detection probability $P_d\approx0.9$ for $P_{fa}=0.02$, even under challenging channel conditions or attacker C/N₀ advantages (Seco-Granados et al., 2020).
• Artificially-Manipulated Time Synchronization (ATS): The time sync (TS) requirement, $|t_\mathrm{GST}-t_\mathrm{LRT}|<B$, is vulnerable: attackers controlling LRT or maintaining replay delays within $T_L$ can pass TS checks, enabling TS-compliant replay (TSR) and TS-compliant forgery (TSF) attacks. These enable location spoofing and navigation data forgery under realistic hardware/software setups as long as the replay delay is maintained below the time-sync bound (e.g., $<30$ s for $T_L=30$ s) (Wang et al., 16 Jan 2025).
• Interruptible Message Authentication (IMA): Attackers can exploit OSNMA’s authentication suspension during broken/incomplete subframes to concatenate replayed messages (CR attacks). This enables signal tampering within a window (≤1.4 s) before resynchronization via valid key-chain continuity (Wang et al., 16 Jan 2025).

Countermeasures include:

• Tightening TS bounds ($T_L$, $B\ll T_L/2$), enforcing secure LRTs (authenticated NTP/NTS), and requiring continuous authentication (full root-key revalidation after data interruptions).
• Detection of replay/freeze jumps via cross-checks with GNSS/inertial/multi-constellation time and enhanced receiver design.

6. Evolution Roadmap and PQC Transition

Short- and mid-term security in OSNMA must grapple with imminent quantum threats and identified protocol limitations:

• Short-term: Hybrid classical EC + TESLA operation in-band, with PQC keys/signatures distributed out-of-band (e.g., via the Galileo Service Centre or the Internet). Temporal countermeasures such as maximizing tag length and reducing delayed key disclosure period must be enabled (Junquera-Sánchez et al., 2023).
• Mid-term: Redesign the message structure, e.g., expand DSM block ID from 4 to 7 bits, reallocating header bits to payload to enable full in-band Falcon-based (5,328 bits) signature support, albeit increasing key dissemination times but not impeding real-time navigation.
• Long-term: Full migration to post-quantum digital signature schemes (Falcon-512 or similar) in-band, eliminating the classical TESLA chain. This necessitates ICD revisions and protocol-level changes to accommodate key/signature size, computational cost, and backward compatibility.

In summary, the most viable quantum-safe path is a staged “crypto-agile” migration: initial hybrid schemes with sideband PQC, followed by ICD updates and full in-band PQC-based authentication, while sustaining short rekey intervals, maximal tag lengths, and robust out-of-band time synchronization (Junquera-Sánchez et al., 2023).

7. Implementation, Testing, and Standardization

OSNMA is now deployed in commercial receivers, with test vectors and open-source reference implementations (OSNMAlib) available for validation, development, and exploitation of advanced processing strategies. Receivers must accommodate for strict timekeeping, resilient page-level reconstruction, and robust cross-satellite redundancy collection. Automotive and regulated verticals (e.g., tachographs) require special consideration of RTC performance, hold-over calibration intervals, and secure workflow provisioning for clock resets (Ardizzon et al., 25 Jan 2025, Galan et al., 2024).

The core OSNMA architecture and its operationalization illustrate the balancing act between on-air bandwidth, cryptographic agility, clock discipline, threat landscape, and commercial device practicality. Continuous monitoring of attack vectors, post-quantum developments, and ongoing receiver/standardization work are essential for long-term GNSS authentication resilience.