GalSAS-SDR-SIM: An End-to-End Simulation Platform for Galileo Signal Authentication Service
arXiv:2608.01901v1 [cs.CR] 3 Aug 2026
Haiyang Wang, Yuanyu Zhang, Wensen Du, Ji He, Pinchang Zhang, Ning Xi
Abstract—Galileo is developing a Signal Authentication Service (SAS) that integrates Open Service Navigation Message Authentication (OSNMA) on the E1 band with Spreading Code Authentication (SCA) on the E6 band to strengthen its resilience to spoofing attacks. As Galileo SAS is still under development, access to realistic and controllable SAS signals remains limited, hindering both the early development of compatible receivers and reproducible research on signal authentication. To bridge this gap, this paper presents GalSAS-SDR-SIM, an open-source software-defined radio (SDR) simulation platform that emulates the SAS workflow by coupling E6 code encryption with the OSNMA key-disclosure process. The platform allows flexible SAS configuration of code encryption parameters to accommodate receivers with different computational capabilities. It also supports the concurrent generation of Galileo E1, E5b, and E6 signals for user-defined locations and times, and OSNMA cross-satellite configurations. Experimental results demonstrate simultaneous verification of navigation messages and spreading codes. We further evaluate SAS authentication performance and computational resource costs under different SAS configurations. Implemented according to publicly available official specifications, GalSAS-SDR-SIM provides a practical tool for accelerating SAS-capable receiver development and supporting the research community in evaluating and improving Galileo signal-authentication techniques. Index Terms—Galileo navigation system, Signal authentication, Open-source test platform
I. I NTRODUCTION Global Navigation Satellite Systems (GNSS) have become a crucial foundation for intelligent transportation, unmanned systems, and logistics. Because traditional civilian GNSS signal formats and modulation methods are publicly available and lack encryption mechanisms, attackers can forge signals, deceiving GNSS receivers into calculating position and time solutions [1], [2]. Furthermore, successful spoofing attacks can propagate to upper-layer network services that rely on trusted time and location information, including vehicular communications, power grid systems, and financial systems [3], [4]. Galileo was the first navigation satellite system to introduce Open Service Navigation Message Authentication (OSNMA) This work was supported in part by the National Natural Science Foundation of China (No. 62220106004, 92467201), in part by the Fundamental Research Funds for the Central Universities (Grant No. QTZX25080, ZDRC2202), in part by Shaanxi Elite Talent Introduction Program (Youth Project), in part by the Young Talent Fund of Association for Science and Technology in Shaanxi, China. (Corresponding author: Yuanyu Zhang) H. Wang, Y. Zhang, W. Du, J. He, and N. Xi are with the School of Computer Science & Technology, Xidian University, Xi’an, Shaanxi 710071, China. P. Zhang is with the College of Cybersecurity, Tarim University, Xinjiang, China. Email: {hywang xdu, 25031212258}@stu.xidian.edu.cn, {yyuzhang, jihe, nxi}@xidian.edu.cn, [email protected].
for civilian users [5], [6]. Its OSNMA authenticates Galileo E1-B navigation data using the delayed key disclosure protocol and message authentication codes (MACs) [7], [8]. OSNMA substantially raises the bar for message-level spoofing because the attacker cannot forge valid MACs before the corresponding keys are disclosed [9], [10]. However, OSNMA cannot authenticate spreading codes or ranging measurements. Attackers can still use signal-level attacks to manipulate Galileo code phase while retaining valid navigation data to achieve spoofing [11]–[13]. The Galileo Signal Authentication Service (SAS) is being developed to address this gap by combining message authentication on E1 with spreading code authentication (SCA) on E6 [14], [15]. In the SAS, selected fragments of the encrypted E6-C code signal are re-encrypted with keys in the OSNMA and published as Re-Encrypted Code Sequences (RECS). A receiver downloads the RECS and related metadata in advance, records E6-C snapshots when the corresponding encrypted code fragments are transmitted, and later decrypts the RECS after the OSNMA key is disclosed. By correlating the recovered encrypted code sequence with the stored E6C samples, the receiver obtains an a posteriori check on the signal component that produced the ranging measurement. In this way, OSNMA and SCA can provide the authenticated navigation data and authenticated ranging evidence from which a receiver may construct an authenticated position, velocity, and time (PVT) solution. SAS services are expected to significantly enhance the security of Galileo navigation signals [16]. Motivation: Despite its promising future, SAS research currently faces a practical bottleneck: a lack of publicly available end-to-end testing environments. Operational SAS signals are not yet widely available to researchers and receiver developers, and public signal-in-space campaigns are limited in time, geometry, and configuration. Researchers cannot repeatedly adjust receiver locations and times, satellite visibility, E1/E6 channel quality, OSNMA configuration, SAS configuration, such as SCA sequence lengths, authentication frequency and windows. Therefore, receiver manufacturers cannot develop SAS-enabled receivers in advance, and thoroughly evaluate their performance and compare different receiver strategies, until SAS services are officially operational. This also hinders the research community from conducting performance evaluations, security analyses and optimizations for SAS. To address the gap, this paper presents GalSAS-SDR-SIM, an open-source software-defined radio (SDR) simulation platform for research on Galileo SAS 1 . The platform implements 1 https://github.com/Haiyang-Wong/GalSAS-SDR-SIM
the public SAS workflow by coupling E6 code encryption with the OSNMA key-disclosure process. The platform allows flexible SAS configuration of code encryption parameters to accommodate receivers with different computational capabilities. In addition, it also supports the concurrent generation of Galileo E1, E5b, and E6 signals for user-defined locations and times, OSNMA cross-satellite authentication, and signal transmission via SDR hardware. The platform supports receiverside verification that combines OSNMA authentication with E6-C code authentication. This platform does not claim to be an official implementation of the final operational SAS service, as its public parameters may still evolve. Instead, it provides a reproducible and extensible experimental tool that follows publicly available SAS principles and supports receiver prototyping, security analysis, and protocol exploration. The main contributions are as follows. • We design an end-to-end SAS research platform that jointly simulates Galileo E1, E5b, and E6 signals, integrates OSNMA message authentication with E6-C spreading code authentication, and supports both offline baseband generation and SDR-based over-air transmission. • We implement configurable OSNMA and SAS simulations. The platform allows configuration of RECS generation, scheduling and authentication cycle, OSNMA cross-authentication, correlation-based SCA verification, and scenario control over time, location, and satellite visibility. • We build a receiver-side evaluation workflow that verifies OSNMA-authenticated navigation data and authenticated E6-C code measurements. We conducted extensive experiments under different SAS configurations to analyze and evaluate aspects including authentication correctness, authentication latency, sensitivity to SAS parameters, and computational resource overhead. The remainder of the paper is organized as follows. Section II summarizes the SAS mechanism. Section III presents the design and implementation of GalSAS-SDR-SIM. Section IV describes the experimental methodology and evaluation results. Section V concludes the paper. II. SAS BACKGROUND AND M ECHANISM A. GNSS Authentication Goals GNSS navigation satellite broadcast signals contain navigation messages and pseudo-random noise (PRN) codes. The navigation message includes satellite clock and orbit information, while the spreading code phase can be used to estimate pseudorange measurements. GNSS receivers receive this signal and parse the navigation message and code phase to calculate the PVT solution. Because traditional GNSS signals do not encrypt the navigation message or the PRN code, attackers can simultaneously forge the navigation message and adjust the code phase to modify the pseudorange information, spoofing the receiver to arbitrary locations and times. The Galileo navigation system first uses OSNMA to verify navigation messages. OSNMA uses delayed TESLA keys
to generate MACs for the navigation message. The receiver collects the broadcast navigation data and MAC, waits for the delayed disclosure of the corresponding key to calculate the local MAC, and then checks if the received MAC matches the calculated MAC. If they match, the received navigation message is authentic. However, OSNMA does not prevent message-level replay attacks, which first forge the code phase and Doppler frequency but retain the original navigation message, then remodulate and retransmit the signal. Because the signal contains authentic OSNMA data, it can still pass the receiver’s OSNMA authentication and spoof the receiver’s position and time [12], [17]. Many recent attacks against OSNMA exploit this idea. The Galileo system further introduced SAS service, designed to supplement OSNMA by authenticating the code used for ranging. SAS uses the SCA mechanism to prevent attackers from directly forging pseudorange information by encrypting the spreading code. If both the navigation message and pseudorange information received by the receiver are authenticated, the receiver can use them as authenticated inputs to its PVT engine. B. OSNMA OSNMA authenticates Galileo E1-B I/NAV data through message authentication tags and delayed TESLA key disclosure. Each E1-B page contains a 40-bit OSNMA field, which is divided into HKROOT and MACK parts. HKROOT carries the signed root-key and configuration information, while MACK carries authentication tags and disclosed TESLA keys [18]– [20]. In OSNMA, the Galileo satellites disclose TESLA keys only after the authenticated E1 navigation data have already been broadcast. A receiver first verifies the key chain from the signed root key, then uses the disclosed key to check previously received tags [21]. OSNMA uses the Authentication Data and Key Delay (ADKD) type to define which navigation data are authenticated and which disclosed key should be used. Despite the different ADKD types, tag generation follows the same algorithm: T ag = truncT S (M F (K, mt )) ,
(1)
where M F is the configured MAC function, K is the delayed TESLA key, and truncT S (·) truncates the output to the configured tag size. The message input can be expressed as mt = P RND ||P RNA ||GSTsf ||CT R||navdata,
(2)
where P RND denotes the satellite whose data are authenticated, P RNA denotes the satellite transmitting the OSNMA data, GSTsf is the subframe start time of Galileo System Time (GST), CT R is the tag position, and navdata contains the selected navigation data. If P RND = P RNA , the tag provides self-authentication; otherwise it provides cross-satellite authentication. Since E5b and E1 broadcast the same I/NAV messages at the subframe level, E1 OSNMA also supports cross-band authentication of E5b messages.
C. SAS Basics OSNMA is the foundation of SAS because its delayed keys are used to protect selected E6-C encrypted code fragments. The public SAS workflow can be divided into two processes. In the offline process, the Galileo service selects future fragments of the encrypted E6-C signal, denoted as Encrypted Code Sequences (ECS). These ECS fragments are re-encrypted with keys derived from future OSNMA TESLA keys, producing RECS files. The receiver obtains RECS files, which contain RECS together with timing and processing metadata, via a secure server [14], [15]. A receiver downloads the files for the desired interval before or during operation. In the real-time process, Galileo satellites transmit E1 signal containing OSNMA data and the encrypted E6-C signal. When a RECS timestamp is reached, the receiver records an E6C sample snapshot around the expected ECS epoch. After the OSNMA key is disclosed, the receiver derives the RECS decryption key, decrypts the RECS into a local ECS replica, and correlates it with the recorded ECS snapshot. If the correlation peak is present at a delay consistent with the E1assisted timing, the receiver determines the corresponding E6C measurement is authentic. These authenticated E6-C measurements can then be combined with OSNMA-authenticated navigation data by a receiver PVT engine, as shown in Fig. 1.
E6 signal (SAS) E1 signal (OSNMA)
E1 message
parameters. Researchers can control satellite visibility, receiver target position, time, signal parameters, OSNMA parameters, and SAS parameters. Third, it must be reproducible. The same scenario should produce the same authentication events and receiver outputs, enabling controlled comparisons of different receiver designs. Fourth, it can publicly disclose intermediate states, such as visible satellite sets, generated tags, TESLA keys, RECS/ECS records, and measurements. III. P LATFORM D ESIGN AND I MPLEMENTATION A. Design Overview GalSAS-SDR-SIM is built on a modular architecture, including modules for scenario generation, navigation message generation, OSNMA authentication data construction, spreading code generation and encryption, observation estimation, baseband signal synthesis, and SDR transmission. Fig. 2 illustrates the architecture of the GalSAS-SDR-SIM platform. The platform takes receiver location, start time, duration, ephemeris source, visible satellite strategy, OSNMA configuration, and SAS configuration as input. It then generates synchronized E1, E5b, and E6 baseband signals. The E1 signal carries I/NAV and OSNMA data, the E5b signal is used for crossband authentication, and the E6 signal carries the researchoriented SCA component. To verify the effectiveness of the platform, we further developed a prototype receiver, based on the open-source GNSS-SDR software [22], that supports OSNMA authentication and SAS authentication.
OSNMA
OSNMA construction
Server
Authenticated message RECS
Authenticated code
ECS RECS
Message generation
Authenticated PVT
Correlate
Σ
E6 ECS
E1 signal synthesis E1/E5b/E6 I/Q baseband signal
Scenario generation (Location, OSNMA, SAS configuration)
Spreading code generation
E5b signal synthesis RECS file
Fig. 1: Galileo SAS operation. Several parameters in SAS directly affect satellite system and receiver behavior. The RECS period determines the frequency of spreading code authentication. The ECS length affects detection probability, storage, and processing cost. Randomization of RECS start times can reduce predictability but increases receiver scheduling complexity. These parameters prompted the development of a controllable simulator capable of implementing the SAS mechanism. D. Simulation Requirements The proposed SAS research platform meets the following requirements. First, it supports end-to-end signal simulation, generating signals that can be transmitted using SDR devices or processed offline. The receiver should be able to track the generated signals, parse navigation messages and pseudoranges, and perform authentication, rather than just isolated encryption tests. Second, it supports configurable
Observation estimation (code phase, Doppler)
E6 signal synthesis
Code encryption
Fig. 2: GalSAS-SDR-SIM platform architecture. Signal generation follows the Galileo open service signal ICD [23], while OSNMA follows the publicly available OSNMA ICD and receiver guidelines [18], [19]. The SCA components follow publicly available SAS documentation and supporting reproducible studies, such as encryption and scheduling of RECS/ECS and correlation-based verification [14]. B. Unified Signal Generation The unified signal generator is the entry point of GalSASSDR-SIM. Its function is to generate the Galileo band signals required for OSNMA and SAS based on the user-specified scenario. This is essential for SAS evaluation, because E1
OSNMA key disclosure, E6-C ECS transmission, and receiverside correlation must refer to the same satellite geometry, Doppler, and code-phase evolution. The generator first loads Galileo ephemeris from public RINEX files [24] and determines the visible satellites for a user-defined receiver position, start time, duration, and elevation mask [25]. It then constructs band-specific signal components. For E1, the platform generates E1-B I/NAV pages and inserts OSNMA fields. For E5b, it generates I/NAV pages for cross-band authentication. For E6, it generates the E6B/E6-C spreading-code components needed for SCA experiments. For every visible satellite, the platform computes pseudorange, code phase, carrier Doppler, and update intervals from the same scenario [26], [27]. These values drive sample-level synthesis for all enabled bands, so the generated E1, E5b, and E6 IQ files remain mutually consistent. The output can be stored as deterministic baseband files for offline GNSS-SDR processing or streamed through SDR hardware for over-air experiments.
The current scheduler uses a geometry-aware policy inspired by OSNMA cross-authentication analysis [28]. For each connected satellite, the platform ranks candidate disconnected satellites by inter-satellite distance and assigns the closest Nca candidates to available cross-authentication slots. A larger Nca increases coverage and redundancy, while a smaller Nca concentrates tags on satellites more likely to be jointly visible. Fig. 3 illustrates two allocation densities. This module gives the later evaluation a direct way to measure authenticatedsatellite availability, time to first authenticated fix, and robustness under partial OSNMA deployment. PRN6
PRN6
N
330°
PRN2
300° PRN3
PRN1
30°
PRN2
300° PRN3
60°
PRN1
PRN4
W
E
240°
PRN5
60°
PRN4
W
E
25°
25°
50°
120°
240°
50°
PRN5
PRN7
75°
C. OSNMA Design A complete OSNMA receiver check includes root key authentication, TESLA key chain authentication, and tag authentication. To keep the generated signal compatible with existing OSNMA receivers, GalSAS-SDR-SIM imports auxiliary OSNMA material, including signed root key information, TESLA key chain, and disclosure timing, from public test vectors or recorded Galileo data. The platform then regenerates authentication tags for the simulated navigation data while preserving the original root and key verification. The OSNMA module supports three authentication modes. In self-authentication mode, a satellite authenticates its own E1 I/NAV data. In cross-band authentication, the platform strictly ensures consistency between E1 and E5b navigation messages, thus naturally supporting the use of E1 tags to authenticate E5b navigation messages. In cross-satellite authentication, satellites transmitting OSNMA data (called connected satellites) authenticate navigation data from satellites that do not transmit OSNMA (called disconnected satellites). In addition to configurations with connected and disconnected satellite sets, the platform also supports cross-satellite authentication between connected satellites, or a fully connected configuration where all satellites transmit OSNMA data. This allows the platform to evaluate partial OSNMA deployments, reduced E1 availability, and authentication continuity. The main design issue in cross-satellite authentication is tag allocation. Each MACK message has a limited number of fixed and flexible tag slots determined by MACLT. These slots determine not only which satellites are authenticated, but also when their authentication tag becomes available to the receiver. GalSAS-SDR-SIM therefore implements a configurable tag scheduler. Users can select the connected satellites, choose the number of disconnected satellites assigned to each connected satellite, and evaluate different allocation policies.
N
330°
30°
75°
150°
210°
120° PRN7 150°
210°
S
Allocate 6 tags for the 6 nearest satellites
S
Allocate 3 tags for the 3 nearest satellites
Fig. 3: Cross-satellite authentication under different parameters Nca . Once the tag allocation strategy is determined, the platform generates corresponding tags for each subframe of all visible satellites based on Eq. 1. The platform embeds these tags into the corresponding position in the constructed OSNMA field based on the declaration of the MACLT parameters. Then, it embeds the reused root key and TESLA key into the constructed OSNMA field. Finally, the OSNMA field is embedded into the navigation message to support all OSNMA authentication steps, as shown in Fig. 4. Ki-2
Navdatai-2 Tagi-2
Ki-1
Ki
Ki+1
Ki+2
Ki+3
Navdatai-2
Navdatai-1
Navdatai
Navdatai+1
Tagi-1
Tagi
Tagi+1
Tagi-1
Ki-2
Navdatai-1 Tagi-1
Ki-1
Navdatai
Tagi
Ki
TESLA key chain
Navdatai+1 Tagi+1
Ki+2
E1 I/NAV message with OSNMA
Fig. 4: OSNMA generation process. D. SAS Design The SAS module is the core of the GalSAS-SDR-SIM platform. Public SAS studies describe a semi-assisted architecture, i.e., the system encrypts the Galileo E6-C signal, selects short encrypted fragments as ECS, re-encrypts these fragments as RECS using future OSNMA TESLA keys, and lets the receiver authenticate the stored E6-C snapshots after the corresponding
E1 key is disclosed [14], [15], [29]. GalSAS-SDR-SIM follows this logic, but implements it as a configurable SDR experiment platform rather than as a fixed service emulator. The SAS generation consists of two stages: E6-C encryption construction and ECS/RECS generation, as shown in Fig. 5. The first stage produces a continuous encrypted E6-C code stream. A configurable 256-bit master key is expanded into satellite-specific keys, and an AES-based stream is used to flip the E6-C codes for the selected satellites. This stage provides the unpredictable signal component required by SCA experiments. GST
0
+30 s
+60 s
+90 s
…
Ki
Ki+1
Ki+2
Ki+3
From E1 OSNMA
Encryped code ECSi
ECSi+1
ECSi+2
ECSi+3
encrypt
encrypt
encrypt
encrypt
RECSi
RECSi+1
RECSi+2
RECSi+3
…
Keycode
RECSi RECSi RECSi RECS
Fig. 5: SAS generation process. The second stage builds RECS records from the encrypted stream. For each authenticated satellite, the platform divides time into RECS periods and selects one ECS window inside each period. The selected ECS is re-encrypted with a key derived from the same OSNMA TESLA key schedule embedded in the generated E1 signal. In the current implementation, the delayed key setting is fixed to one TESLA disclosure interval in the evaluation, so the receiver can authenticate an earlier E6-C fragment only after the corresponding E1 key has been verified. This design keeps E1 message authentication and E6-C code authentication temporally and cryptographically coupled. TABLE I: Configurable SAS configuration fields exposed by GalSAS-SDR-SIM. Field RECS period ECS length Window position Configuration ID Randomization and noise
Function in the platform Controls the frequency of authentication generation; supported values include 100, 200, 500, and 1000 ms. Controls the duration of the encrypted code fragment; supported values include 4, 8, and 16 ms. Places the ECS at the beginning, second 16ms interval, or end of the RECS period. Identifies the active configuration and binds records to a specific experiment configuration. Support repeatable randomized windows and deterministic Additive white Gaussian noise (AWGN) experiments.
Following public SAS terminology, we distinguish ECS, RECS, RECS records, and RECS files. ECS denotes the encrypted E6-C code fragment selected from the signal timeline. RECS denotes the re-encrypted code sequence protected by an OSNMA-derived key. A RECS record refers to one
such authentication object for a specific satellite, ECS epoch, and key. In GalSAS-SDR-SIM, the receiver reads RECS files that store multiple RECS records together with the metadata needed for snapshot scheduling and ECS reconstruction. Thus, RECS is the authentication content, whereas a RECS file is a data product provided by the platform to the receiver. The RECS file makes the same SAS configuration usable by the generator and the receiver. Its header stores the sampling rate, RECS period, ECS length, window position, key timing, chip count, and payload size. Each record stores the satellite identifier, ECS epoch, TESLA key tag, initialization vector (IV), and encrypted ECS payload. The IV is derived from the authenticated GST time and record context using SHA-256, avoiding IV reuse when multiple satellites or multiple ECS windows share the same disclosed TESLA key. The receiver design is also configuration-driven. The modified GNSS-SDR receiver reads the SAS configuration from the RECS file rather than duplicating these parameters in a separate receiver configuration. It then dynamically sets the expected ECS chip count, ciphertext length, snapshot duration, padding check, replica construction, and correlation workload. In normal E1-assisted mode, the receiver is not allowed to read a local key chain file. It must obtain TESLA keys from the received E1 signal after OSNMA verification, including root key signature verification and TESLA chain validation. Inconsistent keys, times, IVs, record headers, or windows cause the receiver to fail closed and reject SAS authentication. Because the continuous E1/E6 IQ stream and the SAS configuration are decoupled, different configurations can be evaluated using the same underlying signal scenario while regenerating only the RECS file. Shorter RECS periods increase authentication freshness but increase file size, snapshot scheduling, and receiver workload. Longer ECS windows provide more samples for correlation, especially under noise, but increase storage and processing cost. Window placement affects snapshot timing and range-bias sensitivity. The exported CSV and summary JSON report PASS/WARMUP/FAIL/ERROR counts, effective authentication rate, correct-key and wrongkey correlation peaks, processing time, pending storage, authentication latency, and range-bias statistics. The configurable parameters supported by the platform are shown in Table I, which provides the basis for the evaluation in Section IV. IV. E XPERIMENT AND E VALUATION This evaluation has two goals. First, we verify that GalSASSDR-SIM can generate receiver-verifiable OSNMA data, because SAS relies on the E1 key-disclosure timeline. Second, we evaluate the SAS workflow itself, including end-to-end E1assisted E6-C authentication, configuration sensitivity, noise robustness, and receiver resource cost. The authenticated PVT calculation depends on the receiver-specific strategy and is not the focus of this evaluation. The experimental setup is shown in Fig. 6. We use three USRP B210s to transmit E1, E5b and E6 signals at their respective frequencies, and use another three USRP B210s to receive these signals. Two auxiliary OSNMA datasets are
TABLE III: Tag processing and authentication results.
used for evaluation: ESA public test vectors and self-collected datasets extracted from genuine Galileo signals on the rooftop of our laboratory. These datasets cover different OSNMA configurations, including different TESLA key chains. The evaluation metrics are shown in Table II.
Latency Resource cost
A. OSNMA Evaluation as the Authentication Backbone Although the paper focuses on SAS, OSNMA must be evaluated because it provides the navigation message authentication and the delayed keys used for RECS decryption. Therefore, we evaluate the performance of OSNMA authentication, focusing primarily on tag authentication and the visibility of connected satellites. As a representative case, the target position is set to (20◦ N, −51◦ E, 100 m), while the target start time is set to 2026-05-13 12:11:01 UTC.
18028 10504 7524 10391 2078 5559 4107 2078 4319 6284 1240
17951 10437 7514 10367 2074 5510 4091 2074 4272 6276 1238
99.57% 99.36% 99.87% 99.77% 99.81% 99.12% 99.61% 99.81% 98.91% 99.87% 99.84%
E36 E35 E34 E33 E32 E31 E30 E29 E28 E27 E26 E25 E24 E23 E22 E21 E20 E19 E18 E17 E16 E15 E14 E13 E12 E11 E10 E09 E08 E07 E06 E05 E04 E03 E02 E01
20 22 26 :0 -05 0: -1 00 3
20 21 26 :0 -05 0: -1 00 3
20 20 26 :0 -05 0: -1 00 3
20 19 26 :0 -05 0: -1 00 3
20 18 26 :0 -05 0: -1 00 3
Self-authenticated Cross-authenticated
20 17 26 :0 -05 0: -1 00 3
Range bias
25191 10797 14394 16789 2097 6305 4224 2097 4476 12565 1829
20 16 26 :0 -05 0: -1 00 3
Correlation margin
Total tags Self tag Cross tag ADKD=0 ADKD=4 ADKD=12 ADKD=0(S) ADKD=4(S) ADKD=12(S) ADKD=0(C) ADKD=12(C)
20 13 26 :0 -05 0: -1 00 3
Authenticated-satellite ratio
Success rate
Galileo navigation message authentication timeline
Galileo satellites
TTFAF
Meaning Per-record authentication status. WARMUP denotes records observed before the required OSNMA trust chain and disclosed key are available. Time to first authenticated fix obtained using OSNMA [30]. Fraction of time with at least four authenticated satellites available for positioning obtained using OSNMA [9]. Separation between correct-key and wrong-key E6-C correlation peaks. Difference between the E1-assisted expected delay and the accepted E6-C correlation delay. Time between ECS observation and availability of the corresponding authenticated result. RECS file size, pending snapshot storage, and receiver processing time.
Authen.
Table III summarizes the number of tags generated during the 10-hour simulation and the number processed and authenticated by GNSS-SDR. In total, the platform generates 25,191 tags, of which 18,028 are processed by the receiver and 17,951 are authenticated, corresponding to an overall success rate of 99.57%. Because some cross-authentication tags originated from satellites outside the field of view, the navigation data associated with these tags cannot be retrieved, resulting in a gap in the number of simulated and processed tags. Fig. 7 shows the authentication status timeline for visible satellites over a 10-hour period. At the beginning of the simulation, PRN 13, 15, and 30 do not transmit OSNMA data, but their tags are transmitted by PRN 2, 18, 27, and 34, so these satellites can still be authenticated through cross-satellite authentication.
TABLE II: Main evaluation metrics. Metric PASS/WARMUP/FAIL/ERROR
Processed
20 15 26 :0 -05 0: -1 00 3
The simulator generates synchronized Galileo E1, E5b and E6 baseband files from the same receiver location, start time, ephemeris, satellite visibility, pseudorange, Doppler, and code-phase model. E1 carries I/NAV and OSNMA, while E6 carries the encrypted E6-C component and the selected ECS windows. The receiver is the modified GNSS-SDR described in Section III. In normal E1-assisted mode, the receiver is configured with E1 samples, E6 samples, RECS files, and the public OSNMA verification material.
Sim.
20 14 26 :0 -05 0: -1 00 3
Fig. 6: Experiment setup.
Tag type
UTC Time
Fig. 7: OSNMA authentication timeline under 10 hours of simulation. We then count the number of simultaneously authenticated satellites every 30 seconds, which is important for continuous positioning. Fig. 8 compares the strategies of Nca = 4 and Nca = 6. In both strategies, the 95th percentile is 9 satellites. The time ratio with at least four authenticated satellites (i.e., Authenticated-satellite ratio) is 96.49% and 96.24%, respectively, and the average numbers of authenticated satellites are 6.69 and 6.47. We further evaluate the time to first authenticated fix (TTFAF) [30]. Since a GNSS receiver may be powered on at an arbitrary time, we generate signal segments from 13:00:00
Number of Simultaneously Authenticated Satellites
TABLE IV: Representative end-to-end SAS validation. Nca = 4
11
Nca = 6
10 9
Receiver status counts
8 7
Detection result
6 5
Mean correlation peaks Latency
4 3
Range-bias metric
2
Result 200-ms RECS period, 16-ms ECS, secondwindow ECS placement 4050 PASS, 4395 WARMUP OSNMA, 0 FAIL, 0 ERROR Probability of Detection (Pd ) = 100%, wrongkey Pf a = 0% Correct key: 0.317; wrong key: 0.004 Average 45.1 s; minimum 30.2 s; maximum 60.0 s RMSE 11.71 m; this metric is code-delay bias
1 0
3h 4h 5h 6h 7h 8h 9h 0h 1h 2h 31 31 31 31 31 31 31 32 32 32 5/1 5/1 5/1 5/1 5/1 5/1 5/1 5/1 5/1 6/0 6/0 6/0 6/0 6/0 6/0 6/0 6/0 6/0 202 202 202 202 202 202 202 202 202
5/1
6/0
202
UTC Time
Fig. 8: Number of simultaneously authenticated satellites over time.
UTC to 13:50:00 UTC on 2026-05-13, with a start-time interval of 1 minute. Each segment is processed independently to emulate a different receiver startup time. Fig. 9 presents TTFAF results from 102 independent experiments. For Nca = 4, the mean and median TTFAF are 108.47 s and 102 s. For Nca = 6, the mean increases slightly to 111.45 s, while the median remains 102 s. In both strategies, the minimum and maximum TTFAF values are 72 s and 162 s. 170 160
Nca =4 Nca =6
150 140
TTFAF (s)
Item SAS configuration
130 120 110 100 90 80
13:00 13:01 13:02 13:03 13:04 13:05 13:06 13:07 13:08 13:09 13:10 13:11 13:12 13:13 13:14 13:15 13:16 13:17 13:18 13:19 13:20 13:21 13:22 13:23 13:24 13:25 13:26 13:27 13:28 13:29 13:30 13:31 13:32 13:33 13:34 13:35 13:36 13:37 13:38 13:39 13:40 13:41 13:42 13:43 13:44 13:45 13:46 13:47 13:48 13:49 13:50
70
Signal Start Time (UTC)
Fig. 9: TTFAF under different Nca and signal start time. The platform also utilizes OSNMA authentication in E1 to authenticate navigation messages in E5b. Because the navigation messages and tags are matched, this verifies the simulator’s cross-band authentication path. We do not report a separate E5b performance study because SAS is the focus of this paper. These results show that the OSNMA module can generate receiver-verifiable authentication data and provide the key-disclosure timeline required by the SAS experiments. B. End-to-End SAS Validation The baseline SAS experiment validates the complete path from synchronized signal generation to receiver-side authentication. The simulator generates E1 OSNMA and encrypted
E6-C signals in the same scenario. It also produces an RECS file whose RECS records are protected using the same TESLA key schedule carried by E1. The receiver must first acquire and track E1, verify OSNMA root and TESLA-chain information, obtain disclosed keys from the received E1 signal, decrypt RECS records, reconstruct ECS replicas, correlate them with stored E6-C snapshots, and apply the range-gate and wrongkey checks. The representative baseline configuration uses a 200-ms RECS period, a 16-ms ECS length, the second-window position, and a one-interval key delay. In a 600-s run, the receiver produced 4050 PASS records and 4395 WARMUP OSNMA records, with 0 FAIL and 0 ERROR records, as summarized in Table IV. The WARMUP records correspond to the receiver startup interval before the OSNMA trust chain and the required disclosed keys became available. After warm-up, all 4050 measured records passed the authentication test, with a wrongkey Probability of False Alarm (Pf a ) of 0 and a mean correctkey correlation peak of 0.317 compared with 0.004 for the wrong-key control. This result indicates that the generated E1 key timeline, E6-C encryption, RECS file metadata, snapshot scheduling, and correlation search are mutually consistent. The average authentication latency is about 45.1 s, ranges from 30.2 to 60.0 s. This range is expected because SAS authentication waits for delayed OSNMA key disclosure rather than accepting an E6-C snapshot immediately. The effective authentication rate is 15 records/s for the target satellites under the 200-ms configuration, while the measured processing throughput is about 9.9 records/s on the evaluated receiver implementation. This result shows that the platform can evaluate both authentication correctness and the timing cost imposed by OSNMA key disclosure. C. SAS Configuration Sensitivity We next evaluate how SAS configuration affects authentication frequency, storage, pending snapshot memory, and perrecord processing cost. Fig. 10 shows the RECS-period trade-off using 16-ms ECS windows under clean (i.e., no noise) conditions. Reducing the period from 1000 ms to 100 ms increases the effective authentication rate from 3 records/s to 30 records/s. The cost is proportional growth in the receiver-facing data volume and pending snapshot cache: the RECS file grows from 12.4 MB to 124.0 MB, and the peak pending IQ storage grows from 236.0 MB to 2326.5 MB. The per-record processing time is
RECS sidecar size (bytes)
0
10
4
#10
9.8 9.6 9.4 9.2
100 200
500
RECS period (ms)
1000
All measured records pass under all configurations, which verifies that the RECS file generator and receiver parser remain consistent across different RECS periods, ECS lengths, and window positions. The range-bias root mean square error (RMSE) remains within a narrow interval of 11.70–12.04 m across these configurations, indicating that changing the SAS configuration does not introduce a systematic code-delay error in clean conditions. The most visible difference is resource cost. Setting ECS windows of 4-ms and 8-ms reduces the processing time and pending storage, while 100-ms RECS periods increase the number of authentication records and buffering demand.
10
5
0
2.5
#10
9
2 1.5 1
1
0.5 0
100 200
500
RECS period (ms)
1000
Fig. 10: Trade-offs introduced by the RECS period under clean conditions.
1
0.8
0.8
0.4 0.2 clean
0
45 dB-Hz
0.25 0.2 0.15 0.1 0.05 0
4
8
ECS length (ms)
16
0 -10
first
10
0
last
0.4 0.2
10
20
0.6 0.4
0 35
4
0
0.2
0
6
-10
Authentication range bias (m)
0.8
0.6
#104
-20
1
4 ms ECS 8 ms ECS 16 ms ECS
0.8
8
2
second
Window position
Fig. 12: Authentication range-bias distribution under different ECS window positions.
0.4
0
0.4 0.2
1
0.2
0.6
-20
0.6
35 dB-Hz
0.3
10
d
0.6
first second last
0.8
P
Wrong-key Pfa
1
Mean processing time (7s/record)
Mean correct-key peak
Detection probability Pd
dominated by correlation and ranges from 93 to 100 ms for 16ms ECS windows. Therefore, the RECS period mainly controls authentication density and buffering pressure, while the ECS length controls per-record computation.
20
Empirical CDF
10
#107
Wrong-key Pfa
20
15
Authentication range bias (m)
16 ms ECS
Peak pending IQ (bytes)
Mean CPU time per record (7s) Effective authentication rate (records/s)
30
40
C/N0 (dB-Hz)
45
35
40
C/N0 (dB-Hz)
45
Fig. 13: ECS detection probability and wrong-key false alarm probability under different C/N0 values. 4
8
ECS length (ms)
16
Fig. 11: Detection and processing trade-offs introduced by the ECS length. Fig. 11 compares ECS lengths of 4, 8, and 16 ms under a fixed 200-ms RECS period and second-window placement. Under clean conditions all three ECS lengths achieve 100% PASS and 0 wrong-key false alarms. However, the receiver workload scales strongly with the ECS length. The average total processing time increases from 24.8 ms for 4-ms ECS to 49.0 ms for 8-ms ECS and 98.0 ms for 16-ms ECS. The RECS file and pending storage show the same trend, increasing from 15.8 MB and 291.3 MB for 4-ms ECS to 62.0 MB and 1165.1 MB for 16-ms ECS. This indicates that shorter ECS windows are more efficient, while longer ECS windows can provide more samples for robust detection under noise.
Window placement affects where the encrypted fragment is sampled within a RECS period, so it is important to verify that this scheduling choice does not bias the accepted correlation delay. Fig. 12 compares first, second, and last window placements for the 200-ms/16-ms configuration. The empirical distributions almost overlap, and the RMSE values remain close to 11.7–11.8 m. This suggests that, in the current synchronized simulation and receiver implementation, window placement can be selected for scheduling convenience without producing a clear range-bias penalty. D. Noise Robustness and Wrong-Key Control The previous experiments show that SAS works under clean conditions. We further evaluate whether the correlation-based decision remains meaningful when the E6-C snapshots are degraded by deterministic AWGN. The noise experiments fix
Correct key RECS observation (time order) Wrong key RECS observation (time order)
4 ms ECS, E14
0
0.06 0.05
100
8 ms ECS, E14
0
0.06 0.05
100
0.03 0.02
300
200
0.03 0.02
300
-60 -40 -20
0
20
40
400
0
60
-60 -40 -20
0
20
40
60
Authentication range offset (m)
Authentication range offset (m)
0
0
0.014 0.012
100
0.01 0.008
200
0
20
40
0
60
Authentication range offset (m)
200
0.03 0.02
300
0.01
#10-3
400
-60 -40 -20
0
20
40
60
Authentication range offset (m)
0
0
#10-3 8
100
6
200
4
300
2
6
200
4
0.004 300
-60 -40 -20
0
100
2
0.002
400
0.04
8
0.006
300
0.05
100
0.01
0.01
400
16 ms ECS, E14
0.04
0.04
200
0
400
-60 -40 -20
0
20
40
60
Authentication range offset (m)
0
400
-60 -40 -20
0
20
40
60
0
Authentication range offset (m)
Fig. 14: Per-record correlation waterfalls for correct-key and wrong-key trials at 45 dB-Hz.
the RECS period to 200 ms and the window position to the second window, then vary the ECS length and C/N0 . Fig. 13 shows a clear detection boundary. At 45 dB-Hz, the detection probability is 88.9% for 4-ms ECS, 94.7% for 8-ms ECS, and 95.0% for 16-ms ECS. At 35 dB-Hz, none of the tested ECS lengths produces accepted records. Importantly, the wrong-key false alarm probability remains 0 in all tested noise configurations. This indicates that when signal is too weak, the receiver fails closed and rejects the record. Normalized correlation
0.06
4 ms ECS
8 ms ECS
V. CONCLUSION
16 ms ECS
Correct key Wrong key
0.05 0.04 0.03 0.02 0.01 0 -60 -40 -20
0
20
40
60
Authentication range offset (m)
-60 -40 -20
0
20
40
60
Authentication range offset (m)
-60 -40 -20
0
20
and 0.004. Fig. 14 further shows that this separation is not caused by a small number of outliers. Correct-key observations repeatedly form an aligned high-correlation band, while the wrong key observations do not produce a persistent rangeconsistent structure. These results validate the receiver-side wrong-key comparison and show that RECS file metadata, key timing, and E6-C snapshot selection are being processed consistently.
40
60
Authentication range offset (m)
Fig. 15: Mean correct-key and wrong-key correlation functions at 45 dB-Hz. The correlation traces explain why the receiver can reject wrong keys. In Fig. 15, the correct-key curves show a stable peak around the expected range offset, while the wrong-key control remains close to the noise floor. For example, at 45 dB-Hz the mean correct-key peak is about 0.055 for 4-ms ECS and about 0.054 for 8-ms and 16-ms ECS, whereas the corresponding wrong-key peaks remain around 0.007, 0.005,
This paper presented GalSAS-SDR-SIM, an open-source SDR simulation platform for research on Galileo Signal Authentication Service. The platform integrates synchronized Galileo E1, E5b, and E6 signal generation, configurable OSNMA authentication, research-oriented E6-C code encryption. By coupling E1 OSNMA and E6-C RECS through a shared TESLA key schedule, GalSAS-SDR-SIM supports end-toend experiments in which navigation-message authentication and spreading-code authentication can be evaluated together. Furthermore, the platform supports simulations at arbitrary locations and times, under both OSNMA and SAS configurations. The evaluation shows that the platform can generate receiver-verifiable OSNMA data and use the verified E1 key timeline to drive SAS authentication. The configurationsensitivity experiments further quantify how RECS period, ECS length, and window placement affect authentication rate, RECS file size, pending snapshot storage, processing time, and
range-bias behavior. Future work will extend SAS performance evaluation to more configurations and incorporate updated public SAS parameters. R EFERENCES [1] K. C. Zeng, S. Liu, Y. Shu, D. Wang, H. Li, Y. Dou, G. Wang, and Y. Yang, “All your {GPS} are belong to us: Towards stealthy manipulation of road navigation systems,” in 27th {USENIX} security symposium ({USENIX} security 18), pp. 1527–1544, 2018. [2] H. Sathaye, M. Strohmeier, V. Lenders, and A. Ranganathan, “An experimental study of {GPS} spoofing and takeover attacks on {UAVs},” in 31st USENIX Security Symposium (USENIX Security 22), pp. 3503– 3520, 2022. [3] A. Noah and M. Elmusrati, “Gnss spoofing and jamming mitigation: A comprehensive review,” in 2025 International Conference on Artificial Intelligence, Computer, Data Sciences and Applications (ACDSA), pp. 1– 9, IEEE, 2025. [4] C. Tibaldo, H. Sathaye, G. Camurati, and S. Capkun, “{GNSSWASP}:{GNSS} wide area {SPoofing},” in 34th USENIX Security Symposium (USENIX Security 25), pp. 7039–7058, 2025. [5] S. Damy, L. Cucchi, B. Motella, and M. Paonni, “Increasing osnma performance with galileo i/nav improvements: Tests in degraded reception conditions,” in Proceedings of the 2024 International Technical Meeting of The Institute of Navigation, pp. 390–402, 2024. [6] H. Llorca, M. López, E. Domı́nguez, T. Tisell, and P. Scheidemann, “Study on the benefits and uses of osnma in maritime navigation,” in Proceedings of the 36th International Technical Meeting of the Satellite Division of The Institute of Navigation (ION GNSS+ 2023), pp. 664– 677, 2023. [7] J. Simon, T. Rodriguez, A. Alvarez, L. de Filippis, P. d. Silva, F. Sbardellati, I. Fernandez-Hernandez, S. Damy, and G. Caparra, “The galileo open service navigation message authentication (osnma): the new global authentication service,” in Proceedings of the 38th International Technical Meeting of the Satellite Division of The Institute of Navigation (ION GNSS+ 2025), pp. 862–877, 2025. [8] C. O’Driscoll, I. Fernandez-Hernandez, J. Winkel, T. Willems, S. Damy, and J. Simon, “Galileo osnma as a contribution to resilient pnt,” in Proceedings of the 38th International Technical Meeting of the Satellite Division of The Institute of Navigation (ION GNSS+ 2025), pp. 1465– 1477, 2025. [9] T. Hammarberg, J. M. V. Garcı́a, J. N. Alanko, and M. Z. H. Bhuiyan, “An experimental performance assessment of galileo osnma,” Sensors, vol. 24, no. 2, p. 404, 2024. [10] A. Rusu-Casandra and E. S. Lohan, “Experimental assessment of osnmaenabled gnss positioning in interference-affected rf environments,” Sensors, vol. 25, no. 3, p. 729, 2025. [11] M. Lenhart, M. Spanghero, and P. Papadimitratos, “Relay/replay attacks on gnss signals,” in Proceedings of the 14th ACM Conference on Security and Privacy in Wireless and Mobile Networks, pp. 380–382, 2021. [12] M. Motallebighomi, H. Sathaye, M. Singh, and A. Ranganathan, “Location-independent gnss relay attacks: A lazy attacker’s guide to bypassing navigation message authentication,” ACM WiSec 2023, 2023. [13] H. Wang, Y. Zhang, Y. Shen, J. Zhu, Y. Chen, and X. Jiang, “Novel replay attacks against galileo open service navigation message authentication,” in Proceedings of the 36th International Technical Meeting of the Satellite Division of The Institute of Navigation (ION GNSS+ 2023), pp. 3897–3907, 2023. [14] I. Fernandez-Hernandez, J. Winkel, C. O’driscoll, S. Cancela, R. TerrisGallego, J. A. López-Salcedo, G. Seco-Granados, A. Dalla Chiara, C. Sarto, D. Blonski, et al., “Semiassisted signal authentication for galileo: Proof of concept and results,” IEEE Transactions on Aerospace and Electronic Systems, vol. 59, no. 4, pp. 4393–4404, 2023. [15] I. Fernandez-Hernandez, J. Winkel, C. O’Driscoll, G. Caparra, R. Terris-Gallego, J. A. López-Salcedo, G. Seco-Granados, T. Willems, B. Motella, D. Blonski, et al., “Galileo signal authentication service (sas),” in Proceedings of the 37th international technical meeting of the satellite division of the institute of navigation (ION GNSS+ 2024), pp. 3292–3307, 2024. [16] M. A. Ramı́rez, S. Cancela, D. Calle, I. Fernandez-Hernandez, T. Willems, J. Winkel, R. Terris-Gallego, and G. Seco-Granados, “Looking into the galileo signal authentication service: Early demonstration
of the service and experimentation,” in Proceedings of the 38th International Technical Meeting of the Satellite Division of The Institute of Navigation (ION GNSS+ 2025), pp. 82–91, 2025. [17] M. Lenhart, M. Spanghero, and P. Papadimitratos, “Distributed and mobile message level relaying/replaying of gnss signals,” in Proceedings of the 2022 International Technical Meeting of The Institute of Navigation, pp. 56–67, 2022. [18] European Union, “Galileo open service navigation message authentication (osnma) signal-in-space interface control document (sis icd), issue 1.1,” October 2023. [19] European Union, “Galileo open service navigation message authentication (osnma) receiver guidelines, issue 1.3,” January 2024. [20] A. Perrig and J. D. Tygar, “Tesla broadcast authentication,” in Secure Broadcast Communication: In Wired and Wireless Networks, pp. 29–53, Springer, 2003. [21] M. Götzelmann, E. Köller, I. Viciano-Semper, D. Oskam, E. Gkougkas, and J. Simon, “Galileo open service navigation message authentication: Preparation phase and drivers for future service provision,” NAVIGATION: Journal of the Institute of Navigation, vol. 70, no. 3, 2023. [22] C. Fernandez-Prades, J. Arribas, P. Closas, C. Aviles, and L. Esteve, “Gnss-sdr: An open source tool for researchers and developers,” in Proceedings of the 24th International Technical Meeting of The Satellite Division of the Institute of Navigation (ION GNSS 2011), pp. 780–794, 2011. [23] European Union, “EUROPEAN GNSS (GALILEO) OPEN SERVICE SIGNAL-IN-SPACE INTERFACE CONTROL DOCUMENT, Issue 2.2,” November 2025. [24] NASA. [Online]. Available: https://cddis.nasa.gov/archive/gnss/data/ daily/, 2026. Accessed Feb., 2026. [25] H. Sathaye, M. Motallebighomi, and A. Ranganathan, “Galileo-sdrsim: An open-source tool for generating galileo satellite signals,” in Proceedings of the 36th International Technical Meeting of the Satellite Division of The Institute of Navigation (ION GNSS+ 2023), pp. 3470– 3480, 2023. [26] E. D. Kaplan and C. Hegarty, Understanding GPS/GNSS: principles and applications. Artech house, 2017. [27] K. Borre, A software-defined GPS and Galileo receiver: a singlefrequency approach. Springer Science & Business Media, 2007. [28] A. Galan, C. O’Driscoll, I. Fernandez-Hernandez, and S. Pollin, “Sensitivity analysis of galileo osnma cross-authentication sequences,” Engineering Proceedings, vol. 88, no. 1, p. 12, 2025. [29] I. Fernandez-Hernandez, J. Winkel, C. O’Driscoll, T. Willems, S. Cancela, M. A. Ramirez, R. Terris-Gallego, J. A. Lopez-Salcedo, G. SecoGranados, F. Fuchs, et al., “Prototyping galileo signal authentication service: Current status and plans,” Engineering Proceedings, vol. 126, no. 1, p. 40, 2026. [30] A. Galan-Figueras, I. Fernandez-Hernandez, W. De Wilde, S. Pollin, and G. Seco-Granados, “Improving galileo osnma time to first authenticated fix,” IEEE Transactions on Aerospace and Electronic Systems, 2025.