Securing Global Navigation Satellite System Signals: A Software Solution for Galileo Signal Authentication ^†

Abstract

The Galileo program is adding a layer of security through the Galileo Assisted Commercial Authentication Service (ACAS). This service complements Galileo Open Service Navigation Message Authentication (OSNMA) by introducing signal authentication through commercial service signals. In this framework, the ACAS employs a unique approach to protect pseudoranges by incorporating authentication features. These features are implemented at the spreading-code level, utilizing spreading-code encryption on the signal to perform spreading-code authentication. The service is based on the re-encryption and publication of short-duration spreading sequences from an existing encrypted signal, such as the Galileo E6C signal. The re-encryption process enables the receiver to autonomously retrieve the required sequences without continuous communication with an external server. This paper details a commercial software solution implementing the ACAS service, designed for integration across a wide array of applications. A comprehensive description of the ACAS software solution and testing in nominal scenarios will be presented, leading to conclusions that assess the software’s performance, capabilities in real scenarios, and suggestions for further improvements.

1. Introduction

In our daily lives, GNSS have become a fundamental technology for global infrastructure, supporting a wide range of applications across various sectors, including transport, telecommunications, and emergency services. In these areas, the reliability and accuracy of GNSS signals are vital not only for navigation but also for applications requiring temporal accuracy, such as financial transactions and network management. As this technological dependence grows, so does the need to ensure the security and integrity of the signals. This aspect of GNSS technology is becoming increasingly important, as potential vulnerabilities could lead to service disruptions that have economic repercussions or threaten public safety.

The objective of this paper is to address the need to secure GNSS signals using a robust software solution based specifically on the authentication of Galileo E1 and E6 signals that already have resources for this purpose. With this approach, the ACAS protocol is analyzed as a system that represents a significant advance in the security of GNSS signals by improving existing security measures through the integration of authentication directly into the signal, without altering the infrastructure or signal plan.

The proposed software solution leverages the capabilities of the ACAS to perform signal-level authentication, thus mitigating the risk of spoofing and jamming attacks. This solution includes advanced cryptographic techniques necessary for the use of the service, real-time signal integrity monitoring, and integration capability with existing GNSS infrastructure.

In the following sections, this document will delve into the technical fundamentals of GNSS security, provide a detailed description of the ACAS, and discuss the development and integration of the software solution, concluding with the results obtained in a controlled test scenario defined specifically for this purpose.

2. Overview of GNSS Security

It is crucial to understand that the global dependence on GNSSs exposes GNSS systems to multiple security vulnerabilities. Threats range from deliberate jamming to more sophisticated manipulations of signals, each with the potential to cause significant disruptions. The main ones are as follows:

• Jamming: This involves the intentional disruption of GNSS signals through interference, which can be executed even with low-power devices, leading to significant outages or loss of signal integrity.
• Meaconing: This is a type of interference attack on navigation systems. It involves maliciously re-radiating or repeating GNSS signals to deceive receivers, leading to incorrect position or time estimates.
• Spoofing: This involves attacks that generate false signals to mislead GNSS receivers about their position or real time. These attacks can divert users from their route or manipulate systems that rely on precise timing. There are two main types of spoofing attacks:

  -

  Data-Level Spoofing: This type of attack involves the manipulation of the data transmitted by GNSS satellites. Attackers alter navigation data such as satellite positions or time, which can lead to errors in how GNSS receivers determine position or time.

  -

  Signal-level Spoofing: Unlike data spoofing, signal-level spoofing involves the creation and transmission of fake GNSS signals. This type of attack does not require altering the actual data contained in the GNSS signal but focuses on mimicking the signal transmitted by the satellites. Receivers receiving these fake signals can generate erroneous measurements that affect the position or timing of the device.

Signal and Data Authentication with OSNMA

The Galileo program already has a Navigation Message Authentication Service (OSNMA) [1]. This service offers a layer of security by providing authentication of navigation data broadcast by Galileo satellites. Through the use of cryptographic keys, OSNMA allows GNSS receivers to verify the integrity and origin of navigation data. However, OSNMA does not directly address signal-level spoofing, where the integrity of the signal itself is compromised. For this type of threat, additional detection and mitigation techniques are required to ensure the authenticity of the received signals. The implementation of the ACAS complements OSNMA by allowing the detection of attacks that directly interfere with the integrity of the signal, providing more complete security for the Galileo system service.

3. Galileo Assisted Commercial Authentication Service (ACAS)

The ACAS is based on total or partial spreading-code authentication, which is the most effective way to authenticate GNSS signals and measurements [2]. The satellite transmits an encrypted spreading code and NMA using the actual signal plan, satellite payload, or key management. In this case, the scheme on which this service is based is semi-assisted authentication, i.e., the service provider, which for Galileo is the GSC, provides the encrypted code sequences, herein called ECS, by re-encrypting these code sequences (RECS) using the Timed Efficient Stream Loss-tolerant Authentication (TESLA) key provided by the OSNMA protocol in the E1B signal. The user records a snapshot of the E6C signal, and once the OSNMA key is received by the I/NAV, RECS are decrypted, thus obtaining the ECS, which correlates with the pre-recorded signal, and if it is successful, calculates the E6C pseudoranges together with the I/NAV authenticated data.

3.1. Service Provider Side

The keystream to be transmitted by the satellites is generated by encrypting the spreading codes while maintaining the bandwidth of the data, as established in the Galileo signal plan [3]. From this keystream, certain sequences are selected that are re-encrypted with the NMA keys $K_j,K_{j+1},...$. These are transmitted via the OSNMA service such that the key used to encode each sequence is only obtained after the signal with the sequences encrypted with that key has been transmitted, as illustrated in Figure 1.

Figure 1. System operator process [2].

The RECS files are generated for each satellite for a specific operation time; a certain number of chips in the sequence, denoted as $N_{c,RECS}$; and the distance between sequences, defined as the RECS period, denoted as ${\tau }_{\mathrm{RECS}}$.

Additionally, the server provides the Bias Group Delay (BGD) files for the purpose of correcting the measurement in relation to the measurements obtained when processing the E1.

3.2. User Side

To use the ACAS, the receiver must have the ability to record and store snapshots of the signal to perform the correlation, which is performed after decrypting the RECS with the corresponding TESLA key. Normally, the RECS used during the operation time are pre-downloaded so that they are already available to the receiver. Once the receiver is synchronized with the satellite signal, snapshots are recorded and tagged with the corresponding epoch, and the RECS for that period are used. To perform the correlation, the RECS are first decrypted with the key corresponding to the subframe in which the signal was recorded, and with the ECS, the signal is correlated, as shown in Figure 2.

Figure 2. High-level ACAS receiver operation [2].

4. ACAS Solution Implementation

This section focuses on the implementation of the ACAS and the factors that must be taken into account to obtain the metrics properly.

The high-level design of the software is depicted in Figure 3 and is composed mainly of four modules. On one hand, the E1B and E1C measurements are commonly processed through acquisition and tracking processes. In this module, the reference measurements of the E1C signal are generated, and authenticated navigation data are obtained using the OSNMA protocol, providing this key to the main execution line of the ACAS. The RECS are an input to the decryption module, obtained from the service provider, in this case, the European GNSS Service Center (GSC). The decryption process is detailed in this section. Once the ECS is obtained, it is correlated with the recorded snapshot of the E6C signal, and along with the BGD also obtained from the GSC server, the authenticated solution is computed.

Figure 3. High-level ACAS module design.

4.1. RECS Decryption Process

The decryption key for the RECS is derived from the OSNMA key using the SHA-256 hash function. This ensures that the decryption key is only available once the corresponding OSNMA key is disclosed, thus maintaining security and integrity:

$$K_j^{\prime }=\mathrm{SHA}256\left(K_j\right)$$

(1)

where $K_j$ represents the OSNMA key for block j.

The decryption of the RECS is performed using AES in CBC mode, which requires an initialization vector (IV) and the RECS decryption key defined above:

$${\mathrm{ECS}}_{j,i}={\mathrm{AES}256}_{\mathrm{CBC}}^{-1}(K_{j+\mathrm{SLRECS}}^{\prime },{\mathrm{RECS}}_{j,i},\mathrm{IV})$$

(2)

This formula represents the decryption of the RECS into the original ECS, where IV is appropriately generated to ensure secure decryption.

RECS Time Randomization

To prevent predictable patterns in the placement of the RECS within the signal, the start times of the RECS are randomized within the bounds of $\Delta {\tau }_{\mathrm{MAX}}$. This randomization is crucial for enhancing security against pattern analysis and replay attacks:

$$\Delta {\tau }_i^k=B_i^{k}mod(\Delta {\tau }_{\mathrm{MAX}}+1)$$

(3)

where $B_i^k$ is a byte derived from a cipher block generated by AES in OFB mode. The index k specifies the satellite within a RECS period, ensuring that each satellite’s RECS timing is independently randomized.

4.2. Correlation Process

Due to hardware limitations related to the capacity and bandwidth for snapshot recording, continuous recording would require more extensive memory management. To optimize this process, various parameters are considered to determine the start and end times of the snapshot recording for subsequent correlation with the ECS generated by the process in the previous section. This section details how the acquisition of the encrypted signal is computed.

4.2.1. Snapshot Definition

The synchronization and correlation of the ECS with the signal snapshot are critical for verifying the authenticity of the received signal. This process adjusts the start time of the snapshot based on prior synchronization with the E1 signal and incorporates the random delay introduced. This adjustment ensures that the snapshot includes the entire ECS, allowing authentication, as shown in Figure 4, where each contribution to the snapshot timing is illustrated.

$$t_{\mathrm{start},j}^k={\mathrm{GST}}_j+{\delta }_{\mathrm{RECS}}+{\tau }_{\mathrm{prop}}^k-\delta t_{\mathrm{sat},E1}^k+\delta t_{\mathrm{rx},E1}+{\delta }_{E1,E6}^k$$

(4)

$$t_{\mathrm{end},j}^k=t_{\mathrm{start},j}^k+\Delta {\tau }_{MAX}+{\displaystyle \frac{N_{chips}}{R_c}}$$

(5)

$GS{T}_j$ refers to the Galileo system time at epoch j, which is used for authentication. ${\delta }_{\mathrm{RECS}}$ is the offset for the RECS within the signal, aligning the RECS timing with the receiver’s internal clock. ${\tau }_{\mathrm{prop}}^k$ represents the propagation delay for satellite k, accounting for the travel time of the signal from the satellite to the receiver. $\delta t_{\mathrm{sat},E1}^k$ adjusts for any discrepancies in the satellite’s clock for the E1 signal relative to satellite k. $\delta t_{\mathrm{rx},E1}$ compensates for any drift or bias in the receiver’s own clock. ${\delta }_{E1,E6}^k$ accounts for the differential delay between the E1 and E6 signals for satellite k.

$${\delta }_{E1,E6}^k=BG{D}_{\mathrm{sat},E1,E6}^k+\delta I_{E1,E6}+{\widehat{HWB}}_{\mathrm{rx},E1,E6}$$

(6)

where $\delta I_{E1,E6}$ represents the differential ionospheric delay between these bands and $HW{B}_{\mathrm{rx},E1,E6}$ denotes the hardware bias at the receiver affecting the E1 and E6 signals.

Figure 4. E6C snapshot definition.

$\Delta {\tau }_i^k$ introduces a random time offset for the i-th RECS of satellite k. $\Delta {\tau }_{\mathrm{MAX}}$ sets the upper limit for the random time offset, ensuring that the ECS remains within the snapshot window. $N_{\mathrm{chips}}$ determines the number of chips used for correlation, and $R_c$ is the chip rate of the E6 signal.

4.2.2. Encrypted E6C Signal Acquisition

The acquisition process is implemented through a circular FFT-based convolution between the recorded snapshot and an ECS obtained from the RECS decryption. The primary objective of this process is to provide a coarse estimation of the code phase and the Doppler shift associated with the received signal.

To optimize the correlation process, the system utilizes Doppler measurements from the authenticated E1 signal.

The mathematical representation of the acquisition process is given by the following formula:

$${\widehat{R}}_{xd}(f_D,\tau )={\displaystyle \frac{1}{K}}\sum _{k=0}^{K-1}{x}_{IN}\left[k\right]d[k{T}_s-\tau ]e^{-2\pi j{f}_{D}k{T}_s}$$

(7)

where $x_{IN}\left[k\right]$ represents the complex vector containing the IQ samples, d is the ECS from the decryption module, $T_s$ is the sampling period, $\tau$ is the code phase, $f_D$ is the Doppler shift, and K is the number of samples.

In this implementation, a resolution of 8IQ at 15 MHz is used, which provides detailed insights into the signal characteristics. As a result of the acquisition process, both the Doppler shift and code phase are determined.

4.3. Authentication Metrics

The authentication metrics within the ACAS are designed to validate various aspects of signal and data integrity. This section delves into the core methodologies applied in the ACAS software solution to authenticate the line of sight (LoS), the pseudorange measurements, and the position by cross-checking with the results obtained from processing the E1B measurements.

4.3.1. LoS Authentication

LoS authentication is based on the detection of the correlation peak, which indicates the alignment of the code sequence obtained from decryption with the recorded signal. This metric is generated from the correlation data by detecting the highest value in the set and comparing it with the base noise, following the equation

$${\displaystyle \frac{max\left\{\mathrm{FFT}\right(n\left)\right\}}{\mathrm{RMS}\left(\mathrm{FFT}\right(n\left)\right)}}\ge \gamma \to {\xi }_j^k=1\left(\mathrm{satellite}\mathrm{authenticated}\right)$$

(8)

If the obtained factor is above the defined threshold, the signal received on that line of sight is considered to be the one originally transmitted by the satellite.

4.3.2. Pseudorange Authentication

Once the LoS is authenticated, the authentication of measurements is verified by comparing the measured pseudorange with the estimated range, using a predefined error threshold ${\gamma }_{\mathrm{auth}}$:

$$|{\rho }_{j,E1}^k-{\widehat{\rho }}_{j,E6}^k|\le {\gamma }_{\mathrm{auth}}\Rightarrow {\xi }_j^k=1\left(\mathrm{measurement}\mathrm{authenticated}\right)$$

(9)

This metric verifies that the code measurement obtained in the correlation process is similar to that obtained from the E1 signal, thereby confirming that the E1 measurement is reliable.

4.3.3. PVT Authentication

Finally, to obtain a global metric of the dataset, the user’s position is computed using the authenticated navigation data with the OSNMA protocol and the measurements authenticated by the ACAS from the E6C signal. This solution is then compared with the one obtained using the measurements from the E1 signal:

$$|{\overrightarrow{x}}_{E1}-{\overrightarrow{x}}_{E6}|=\Delta {\overrightarrow{x}}_{E1,E6}\le \gamma \to {\xi }_j=1\left(\mathrm{E}1\mathrm{position}\mathrm{authenticated}\right)$$

(10)

Likewise, the E1 position is also authenticated if it is computed using only the measurements authenticated with the pseudorange authentication:

$$\prod _{k=1}^k{\xi }_j^k=1\to \mathrm{E}1\mathrm{position}\mathrm{authenticated}$$

(11)

5. Testing and Validation

As previously mentioned, the ACAS is a Galileo service that is not yet operational as of the date of the tests presented in this document. Therefore, for the proof of concept, a static artificial scenario was generated following the considerations described in Section 4. For this purpose, the scenario was recorded with a receiver that logs the raw data of the transmitted signals and the observations for each satellite.

Figure 5 shows how the scenario was set up to simulate the use of the ACAS.

Figure 5. Outline of the ACAS software validation process.

First, an ECS was continuously generated for each satellite. These code sequences, along with the navigation data, were used as input for a signal generator tool that generated the necessary signal snapshots for the ACAS authentication process, with a resolution of 8IQ and a rate of 15 MS/s.

From the raw data, the navigation data and the transmitted OSNMA keys were decoded. The ECSs were re-encrypted with the OSNMA keys obtained from the scenario following the reverse process defined in Equation (2), thus generating the RECS files to be used.

After generating the necessary inputs offline, the ACAS module was launched, and the authentication metrics were generated and studied.

ACAS Solution Results

The correlation process generated the data in Figure 6, which shows the magnitudes of the acquisition metrics.

Figure 6. Doppler and acquisition metrics.

Figure 7 displays the results obtained by comparing the E1 pseudoranges generated by the receiver with the encrypted E6C pseudoranges calculated using the ACAS module.

Figure 7. Pseudorange authentication metrics.

Finally, Figure 8 shows the position differences between the observations from E1 and those calculated from the observations of E6C. In both cases, only satellites with navigation authenticated by OSNMA were used.

Figure 8. Position authentication metrics.

6. Conclusions

This paper presented the development of software designed for real-time position authentication using the ACAS together with the OSNMA protocol. The software utilizes the capabilities of the ACAS to ensure the integrity and authenticity of satellite navigation signals. Additionally, a defined procedure for utilizing the ACAS solution was outlined, generating several metrics at different levels to ensure an authentic and reliable solution for GNSS signal authentication.

While the current implementation of the software and procedures proved effective, there are several avenues for further enhancement and validation. Future work will include experimentation with various configurations of the ACAS to reveal insights into optimizing performance under different operational scenarios. Real encrypted signal validation will also be conducted to ensure the robustness and reliability of the software, pushing the boundaries of current testing environments. Additionally, extending tests to various environments will help assess the software’s adaptability and performance under diverse conditions, providing a comprehensive evaluation of its capabilities. These efforts will enhance the understanding of the ACAS’s potential and pave the way for its broader adoption in critical GNSS applications.