Prototyping Galileo Signal Authentication Service: Current Status and Plans ^†

Abstract

The Galileo Signal Authentication Service (SAS) is the next new feature to be offered by Galileo, the European GNSS. Its signal-in-space initial capability is expected already in the next months of 2025, starting with the L3 (Launch 3) Galileo elliptical-orbit satellites. It is the first-ever navigation signal authentication feature offered globally and openly. Galileo SAS uses the existing Galileo E6-C signal to be encrypted, in combination with OSNMA (Open Service Navigation Message Authentication), through the so-called semi-assisted authentication concept. In this concept, portions of the E6-C are re-encrypted with OSNMA future keys and published in a server. The concept allows signal authentication openly and for free, and without private key management by users. In exchange, the time between authentications is 30 s, inherited from OSNMA, and it introduces a latency between the E6-C signal reception and its authentication down to a few seconds. This work presents the status of Galileo SAS. It outlines its latest technical definition, already shared in previous publications. It will also present the MMARIO (Message and Measurement Authentication Receiver for Initial Operations) project, developing the first SAS server, receiver and testing platform. The paper also outlines the Galileo SAS plans for the near future, up to the Initial Service Declaration.

1. Introduction

In view of the GNSS vulnerability to spoofing, more than a decade ago, the Galileo program proposed modifications to provide authentication capabilities, not originally foreseen, as part of the then-called Commercial Service. These modifications were formalized in the so-called Galileo Commercial Service Implementing Act (or Commission Decision) [1], which established a free data authentication service, and a signal authentication service originally for a fee.

Over the following years, the data authentication service was introduced in an I/NAV spare-bit capacity of 40 bits per page, in what later became Galileo OSNMA [2]. The fee-based signal authentication, called CS-Authentication, later CAS (Commercial Authentication Service), was based on a modification to encrypt the E6 pilot tone, or E6-C, at the expense of potentially degrading E6 carrier phase tracking, but with the advantage to provide signal authentication with the existing capabilities and signal plan. The encryption capability was already available, but applicable to either both data (E6-B) and pilot (E6-C) components, or neither. The apparently “minor” modification of encrypting only one signal component, instead of two, would enable signal authentication in combination with a payable PPP service in the E6-B, that later became Galileo HAS (High Accuracy Service) [3]. In 2018, the original Commercial Service Act was modified to provide HAS for free [4], as it is the case since its initial operational declaration in 2023.

Today, the spoofing threat, mostly theoretical and academic a decade ago, has fully materialized [5,6], with highly damaging consequences. Galileo has managed to put in place OSNMA and HAS [7], both working reliably and OSNMA waiting for its formal declaration. Therefore, out of the three capabilities described in the CS Implementing Act (data authentication, high accuracy, and signal authentication), the only remaining one is signal authentication.

The formerly fee-based authentication service has been redefined to be provided for free. This was formalized in 2024 by a new Implementing Act [8]. This free signal authentication service, now simply called Galileo SAS, has been defined and consolidated, and at the time this manuscript is written, is ready to start its initial capability (or Phase 0), pending implementation of the separate encryption feature in the system, first in the L3 (Launch 3) satellites and then in the full constellation.

This paper presents an overview of SAS as it stands today and its near-term prospects. The next section presents its current technical definition, including references to its latest technical specification and use cases, where the reader can find the full technical details. Then, the paper describes the latest research and development on SAS, mainly from the MMARIO project, including both lab and prototyping activities, and continues with the system activities in preparation of the initial capability. The paper continues with some receiver implementation considerations and finalizes with the conclusions.

2. Galileo Signal Authentication Service—Current Technical Definition

The Galileo SAS is based on the so-called “semi-assisted” concept. In this concept, the receiver downloads some re-encrypted code sequences (RECS) of the encrypted E6-C satellite signals to be transmitted soon. The receiver records an E6 signal snapshot and, some seconds later, it uses the OSNMA key to decrypt the RECS and perform the a posteriori correlation. This concept has been defined and evolved in several references. For more details, see ref. [9] describing the concept, refs. [10,11] for different spoofing mitigation levels including some detailed signal checks and ref. [12] for some early processing guidelines. In addition to the work by the authors, other initiatives have started to analyze SAS robustness and applications, such as [13]. Note that in the previous literature SAS has been formally called ACAS (Assisted Commercial Authentication Service).

The latest SAS specification has been made available as part of EC procurement documentation [14] and has been openly described in a technical paper [15]. Apart from the E6-C signal specification [16], the SAS is defined through the RECS files, BGD (broadcast group delay) files and SLOG (status and log) files. The BGD files allow applying I/NAV navigation messages on the E6-C measurements, and the SLOG files provide an updated status of the service. They will be downloaded from the European GNSS Service Centre (GSC) through an HTTPS query. Once they are downloaded, the receiver can operate autonomously for as long as the RECS files are available, with a maximum duration of seven days at the moment. For completion, the SAS concept is illustrated in Figure 1, where step (1) shows the RECS download from the GSC server, step (2) shows the E6-C snapshot recording at the RECS pre-defined time, and step (3) shows the RECS decryption once the OSNMA key is received, and the correlation with the E6 snapshot to determine if it contains authentic signals.

The specification in [15] defines the RECS/BGD/SLOG file formats and cryptographic operations to process the data. It has remained stable since then, but there may be minor modifications for the initial capability (Phase 0) and Initial Service (Phase 1) versions, prior to the official publication of an ICD (Interface Control Document). In particular, all information transmitted from the GSC (RECS, BGD, and SLOG) will be digitally signed through the Galileo PKI (public key infrastructure) [17], as is the case for OSNMA cryptographic information available from the GSC, as described in the OSNMA Internet Data Distribution (IDD) ICD [18]. As the data is expected to be authenticated through the HTTPS protocol, this authentication feature will be provided on top of the authentication from HTTPS certificates. Further information will be provided when this feature is consolidated.

3. Galileo SAS Receiver and Testing Prototypes

This section describes the status of the SAS receiver, the SAS prototype server and the testing platform elements, all developed in the MMARIO (Message and Measurement Authentication Receiver for Initial Operations) project, procured by EC [19].

3.1. SAS Receiver

The SAS receiver includes a fully equipped platform to validate Galileo SAS within the MMARIO project and beyond, including support to the operational SAS validation.

The main elements of the SAS receiver are shown in Figure 2 and Figure 3. Figure 2 shows the receiver architecture with the main modules, and Figure 3 presents a picture of the already integrated prototype. All the elements are described hereafter, including a reference for the most relevant hardware components:

• The pre-selected antenna is a geodetic antenna HX-CVX603A, from Harxon Corp. (Shenzhen, China) [20], which includes E1-E5-E6 frequencies. The receiver will be tested with other non-geodetic antennas.
• The splitter allows the signal to be directed to two receivers, the actual SAS receiver, and a “ground truth” receiver used for validation purposes.
• The main block of the SAS receiver is GMV’s BROS receiver (Breadboard Receiver with OSNMA), which in turn is composed of a THOR Front-End developed by GMV, including three channels (E1, E5, E6), up to 10-bit I/Q samples at 100 Msps and highly configurable, with additional capability to record 200 ms snapshots every second, stored as sample files with 20 MHz bandwidth and 8 bit resolution (4-bit I/Q); a Mercury XU1 System-on-Chip with a compact, space-saving form factor, and based on a Zynq Ultrascale+ MPSoC; and a Mercury ST1 board to integrate XU1’s FPGA, including USB, HDMI and other connectors [21].
• A Septentrio Mosaic X5 reference receiver (Septentrio, Leuven, Belgium) is used as “ground truth”, allowing an independent RTK-based position as well as independent anti-jamming/spoofing checks for comparison purposes.
• A six-axes (3 × accelerometers/gyroscopes) Inertial Measurement Unit (IMU) MIKROE Me6DOF Click is included as a configurable input to the rest of the receiver, that is expected to also function without it.
• A real time clock RTC 8 Click from MIKROE is integrated, as a source of GNSS-independent timing, in addition to NTP/NTS [22].
• The IMU and RTC are connected to a Raspberry Pi (Raspberry Pi Trading Ltd, Cambridge, UK). This system is synchronized with the GNSS signal using the 1PPS provided by the BROS receiver.
• The main processing hardware is based on a ASRock NUC-155H motherboard, using an Intel Core Ultra 7 155H processor (Intel Corporation, Santa Clara, CA, USA). This is the board where the SAS PVT logic, consistency checks, and other processing takes place.
• The SAS receiver includes a switch allowing the connection by Ethernet of the three main modules: the BROS receiver, the ASRock processing hardware, and the Raspberry Pi, and externally to a controlling user laptop.
• Finally, a Wi-Fi hotspot allows wireless connection with the laptop and the processing hardware. It also allows downloading the RECS/BGD/SLOG files from the SAS server.

In addition to the above, and as mentioned above, a standard laptop can be connected to monitor and control the SAS receiver elements.

3.2. SAS Prototype Server

The SAS prototype server, developed by GMV, includes the main functionalities of the future operational server integrated in the GSC. This includes RECS/BGD/SLOG provision in answer to the queries, and generation of RECS files from the E6-C encryption keys and OSNMA chain keys. It runs on an HPE ProLiant DL360 Gen11 8SFF (Hewlett Packard Enterprise, Spring, TX, USA) [23]. The server will mainly be in charge of receiving the OSNMA and E6-C encryption keys and regularly produce the RECS for the incoming periods. In addition to providing RECS/BGD/SLOG files, the SAS server will provide NTP/NTS synchronization, as will the operational SAS server. The SAS prototype server implements NTS as per RCF8915 [24] through a COTS (Commercial Off-The-Shelf) NTP server guaranteeing a synchronization of +/− 50 ns (at the server end). The NTP server will be connected to the SAS prototype server, providing NTP/NTS synchronization.

3.3. Testing Platforms

An independent SAS testing platform, developed by ADS (Airbus Defence and Space), allows testing of the SAS receiver and collecting data under nominal and adversarial conditions. In adversarial conditions, the SAS testing platform can generate and synthesize a signal or replay a real one, depending on the configuration. The counterfeit signal can be re-radiated through a transmitting antenna or introduced into the SAS receiver through the antenna cable, in isolation or in combination with the real signal using an RF combiner. The contractor selected two TeleOrbit MGSE units [25] that were combined with proprietary software and mounted in a box as per Figure 4.

In addition, UAB’s SPCOMNAV group has developed another testing platform for field testing. As opposed to the main MMARIO SAS testing platform abovementioned, which is intended to test the SAS receiver under all conditions, the UAB platform implements the main processes of an SAS receiver in post-processing mode, but with full flexibility. An early platform was developed with support of previous EC project PAULA [26,27] and has been evolved over the last years [28]. The current platform is composed of an E1/E6 antenna and an antenna splitter that splits the signal into two, feeding two Nuand BladeRF micro 2.0 SDRs [29], covering E1 and E6. It also includes a Raspberry Pi with an SSD allowing longer E6 snapshots than its predecessor, and a 10 MHz CITRINE OCXO, allowing to calibrate internal biases and synchronize the devices. It also allows NTP synchronization. The platform currently includes most features required in an SAS receiver, as shown in Figure 5: sending the query to the SAS server, parsing the received RECS files, recording the E6 snapshot, receiving E1 and performing a posteriori correlation and E1-E6 comparison. As E1 snapshots are also recorded, it allows anti-replay checks based on E1 unpredictability due to OSNMA [30], as the SAS receiver also does. For the RECS decryption, the OSNMA keys are retrieved using OSNMAlib [31,32].

3.4. MMARIO Testing Activities

The MMARIO elements (SAS receiver, SAS prototype server and testing platform) are already developed and undergoing per-element validation. In the next step, they will be integrated altogether, and following successful finalization of the testing, the experimentation phase will begin. During this phase, the SAS receiver will be tested in real time and through post-processing in nominal and adversarial conditions, including real signal-in-space data.

4. SAS Initial Capability and Next Steps Toward Service Declaration

In parallel to the MMARIO developments, the E6-C separate encryption has been implemented and is being tested in the operational system. This has required efforts in both the Galileo core infrastructure, in particular the GMS (Ground Mission Segment) and SS (Space Segment), and in the Galileo European GNSS Service Centre.

In the core infrastructure, the separate encryption required an update to Galileo Sensor Stations (GSS), allowing to process E6-B open and E6-C encrypted. It also required an adaptation of Galileo’s mission key management facility. In the space segment, the NSGU (Navigation and Signal Generation Unit) software has been modified to encrypt only the E6-C upon command from the control segment.

Originally the initial capability was scheduled to start in 2024 [14]. Despite the delays, at the time of writing this paper, the first end-to-end E6-C encryption tests are about to be performed for the first time on fully up-to-date software, hardware and operational procedures. These tests will be executed only with L3 satellites (E14 and E18). Following successful completion of the tests, initial capability will be provided but only in L3 satellites. Following this step, it is planned that initial capability will be provided from the full constellation in 2026. This capability will be supported by the MMARIO prototypes, in preparation of the development, testing and operational integration of the GSC 2.0, including the operational SAS server. GSC 2.0, currently under development, will be integrated into the operational chain in the second half of 2026, leading to the SAS Initial Service Declaration.

To summarize, the SAS main phases are:

-

Initial Capability (Phase 0): It starts with L3 satellites, and will later be extended to the full constellation. It will be based on the SAS prototype server and access will be limited. The access policy to the SAS server information is under definition but it is expected that it will be gradually opened during this phase.

-

Initial Service (Phase 1): It will start with the Initial Service Declaration by the end of 2026, allowing global and free use of SAS.

-

Full Service (Phase 2): It will start with the Full Service Declaration, introducing some improvements with respect to Phase 1. This is foreseen in the next years, and under consolidation with the Galileo 2nd Generation schedule.

In parallel to the operational development service definition, activities will continue for defining working points under which the service performance will be validated. These will cover the integration time used for the E6-C correlation (RECS length as per [15]), the time between authentications, and others. Also, the end-to-end logic will be formalized, based on the previous literature abovementioned, and all this information will be provided in a Galileo SAS ICD, receiver guidelines, and SDD (Service Definition Document), prior to service declaration.

5. SAS Receiver Considerations

This section provides an overview of the required Galileo SAS receiver capabilities. As an example, we analyze the hardware, storage and CPU requirements of a SAS receiver that works in standalone mode for one day, calculating a SAS PVT every 30 s.

On the RF hardware side, the receiver must be able to process the E6-C signal, centered at 1278.75 MHz, with a BPSK(5) modulation of 5115-chip codes every ms, with a RFFE (Radio Frequency Front-End) two-sided bandwidth of at least 10 MHz. In terms of storage, assuming the receiver selectively downloads for 10 satellites in view 8 ms RECS for each SAS PVT solution, it would require 10 · 8 · 5115 = 409,200 bits, or 51.2 Kbytes per PVT. For a one-day autonomy and a SAS PVT solution every 30s, it would therefore require 51.2 · 86,400/30 = 147.5 Mbytes of storage (excluding small overheads), which seems affordable nowadays even for small devices. For every PVT, the receiver stores a snapshot of some tens of ms, assuming the receiver “knows” when to correlate the RECS, which will differ from one satellite to another by the time of arrival (which may amount to 20 ms), plus satellite clock offset, which may amount to a few ms. For an 8 ms RECS length (and no randomization applied, see [15]), this should not exceed 40 ms. With complex sampling at 10 Msps (or a real sampling at 20 Msps), sufficient for the BPSK(5) signal, and a typical 2-bit quantization, this amounts to 0.04 · 2 · 2 · 10⁷ = 1.6 Mbits, or 200 Kbytes, which is also quite affordable.

Once the snapshot is stored, if the receiver is tracking E1-B/C (or E6-B in case of a Galileo HAS receiver, which is also possible), the receiver can perform the E6-C correlation around the time and frequency of the tracked signal, after application of the signal biases and differential ionospheric delays, as shown in [9]. Once the E6-C authenticated pseudoranges are obtained, the authenticated E6-C PVT is also standard receiver processing. Therefore, from the processing point of view, the additional operations do not significantly add CPU load. Extra CPU resources may be required if the receiver performs other anti-spoofing methods such as vestigial signal search (VSS) [11], which can be considered equivalent to another signal acquisition search every time VSS is performed. Note also that, as is the case for OSNMA receivers, the receiver needs a trusted reference time with a maximum delay of a few seconds.

Regarding SAS availability and accuracy, our SAS receiver study case relies on Galileo OS (E1-B) and OSNMA. The dependency on OSNMA to extract the keys and use authenticated data might decrease availability, but as shown in refs. [33,34], the use of OSNMA should not significantly decrease OS availability and accuracy. Regarding potential unavailability of the E6-C signal or the SAS server, these are expected to be highly available when SAS is operational, as for other Galileo services. Therefore, one can expect that SAS availability will be generally similar to OSNMA’s.

6. Conclusions

Galileo Signal Authentication Service is starting its initial capability (Phase 0), being the first-ever signal authentication service provided by a GNSS. It will be provided openly, worldwide, and for free.

In a first phase of this initial capability, only the E6-C component of the L3 satellites (E14 and E18) are encrypted. Later, E6-C will be encrypted for the full constellation in 2026. Initial Service Declaration is currently scheduled for early 2027.

The operational infrastructure is finalizing the adaptations required for E6-C separate encryption, including ground and space segments, and the GSC.

In parallel, the MMARIO project has developed the main elements allowing SAS testing and initial capability provision: a full SAS receiver, an SAS prototype server and a testing platform, allowing to test SAS in nominal and adversarial conditions. Future SAS receivers are not expected to significantly increase the hardware or CPU requirements of standard receivers.