An End-To-End Solution Towards Authenticated Positioning Utilizing Open-Source FGI-GSRx and FGI-OSNMA ^†

Abstract

This paper presents an end-to-end solution towards authenticated positioning using only Galileo E1B signal by utilizing the Open Service Navigation Message Authentication (OSNMA). One of the primary objectives of this work is to offer a complete OSNMA-based authenticated position solution by releasing FGI-GSRx-v2.1.0 (an open-source software-defined multi-constellation GNSS receiver) update. The idea is to bridge the gap between two open-source implementations by the Finnish Geospatial Research Institute (FGI): FGI-GSRx and FGI-OSNMA (an open-source Python software package). FGI-GSRx-v2.1.0 utilizes FGI-OSNMA as an OSNMA computation engine to generate the authentication events with the information of whether a tag is valid or not. FGI-GSRx computes the position authentication at the navigation layer with the Galileo E1B satellites that are OSNMA verified and have $C/N_0$ greater than 30 dB-Hz. OSNMA-based position authentication is shown through the findings from two real-world open sky use cases: (i) a clean nominal scenario and (ii) a spoofing scenario recorded during the Jammertest 2023 in Andøya, Norway. In the case of the spoofing scenario, the software receiver stops offering an authenticated position solution. A detailed comparison between the authenticated and non-authenticated position solutions also highlights the damage spoofing could cause to the end user in deviating the user’s position on a target spoofed location.

1. Introduction

In recent years, Europe’s strong presence in the global market for Global Navigation Satellite Systems (GNSSs) based services has been remarkable. With expected revenues of almost EUR 220 billion in 2022 and forecasted revenues of EUR 510 billion in 2032 [1], European companies hold a leading position in several sectors including GNSS component and receiver manufacturers in road, maritime and other system integrators in agriculture. With the increase in awareness and accessibility of jamming and spoofing methods and devices, the need to ensure secured GNSS data to improve robustness and resilience against such attacks is of utmost importance [2].

The Galileo satellites started the transmission of authentication features in open GNSS signals, by including the Open Service Navigation Message Authentication (OSNMA) data in the E1 OS Signal-in-Space (SIS) data message [3,4,5] service. OSNMA transmits cryptographic data, which allows the verification on the receiver side to confirm the authenticity of the received navigation messages. It is pertinent to mention here that OSNMA does not account for all possible attacks [6]; however, the authentication it provides generates significantly enhanced security and resilience. Galileo OSNMA is also expected to enable ranging signal authentication to enhance location security for Galileo users by utilizing the Timed Efficient Stream Loss-Tolerant Authentication (TESLA) key protocol of OSNMA for Spreading Code Authentication (SCA) in the form of an Assisted Commercial Authentication Service (ACAS) [7,8]. This feature has also sparked great interest with the GNSS receiver manufacturers to integrate OSNMA for assured position solutions like Septentrio Mosaic-X5 [9]. It has already found its application in various areas such as reliable and accurate GNSS-based localization information for road vehicles using Septentrio Mosaic-X5 receivers [10,11]. FGI developed an open-source Python library functioning as an OSNMA computation engine referred to as FGI-OSNMA [12], which can be implemented in real-world applications. For example, this was demonstrated by the integration of FGI-OSNMA into the GNSS-Finland service [12]. Another example is the experimental performance assessment of OSNMA via FGI-OSNMA by observing a ten-day-long dataset collected in static open-sky conditions in southern Finland [13]. The work presented in [13] utilizes the OSNMA-based authentication on the Receiver Independent Exchange Format (RINEX) observable files and then uses the RTKLIB [14] to process only the OSNMA-verified RINEX files to obtain the authenticated position solution.

The main purpose of the FGI-OSNMA software package is to decode the OSNMA information from a data stream to authenticate the navigation messages. It cannot be directly used to perform authenticated positioning which is the primary application of OSNMA. This motivated us to integrate FGI-OSNMA into a PVT engine to produce an authenticated position. For this purpose, we are using the open-source software-defined multi-GNSS-based receiver named FGI-GSRx [15,16] that was released by FGI in 2022. FGI-GSRx has already been actively used by the GNSS research community to develop, test, and validate novel receiver processing algorithms for resilient and precise Position, Navigation, and Timing (PNT) solution [17,18,19]. The primary goal of this work is to bridge the gap between the two open-source implementations by combining Python-based FGI-OSNMA with the MATLAB-based FGI-GSRx to provide an authenticated position solution. Therefore, all the receiver-specific implementations starting from the signal processing, and navigation message authentication to authenticated positioning will be carried out in FGI-GSRx. This feature will also be available in the latest release of FGI-GSRx. The OSNMA-based authenticated positioning solution by FGI-GSRx is presented in this research by investigating two scenarios. The first case considers a clean open sky signal recorded at FGI premises in Finland and in the second case a recorded spoofed signal from the spoofing test conducted during the ’Jammertest 2023’ in Andøya, Norway, is presented. This is followed by an in-depth analysis of the performance and verification of the positioning solution for each scenario.

The rest of the paper is organized as follows: Section 2 presents an overview of Galileo OSNMA protocol. Section 3 gives a brief insight into the working of the FGI-OSNMA Python engine. The architecture of FGI-GSRx-v2.1.0 is presented in Section 4, which is followed by the description of the experimental setup utilized for capturing the raw data in Section 5. Section 6 analyzes the results obtained in two different use cases mentioned earlier in the paper, followed by conclusions in Section 7.

2. OSNMA Overview

The Galileo navigation message authentication is carried out by using the TESLA protocol [20], shared by the Galileo satellites as a single one-way chain [21]. The navigation message and its corresponding OSNMA data [22] include authentication tags, a TESLA chain key, and a TESLA root key. The authentication tag for each navigation message is received before its associated TESLA chain key. The TESLA root key is verified by a public key which is available to the receiver through a web service, or possibly via SIS [23]. The receiver authenticates the TESLA chain key with the TESLA root key or with a previously authenticated key from the TESLA chain. The tags are then regenerated by the receiver with the verified TESLA chain key and navigation data. The receiver then checks whether the regenerated data coincide with the received tag. The navigation data are considered to be authentic if these steps are successful [21]. The tags and the TESLA chain key are broadcast every 30 s on a subframe basis. The OSNMA chain of trust is shown in Figure 1.

OSNMA Authentication Tags

Galileo satellites, which transmit OSNMA data, transmit authentication tags for their own navigation message (self-authentication) and also transmit authentication tags for other Galileo satellites that do not transmit OSNMA (cross-authentication). This cross-authentication may be theoretically utilized to authenticate navigation messages from other constellations as well, though this is not implemented at the moment [12]. OSNMA carries out navigation message authentication by utilizing various tags for different parts of the navigation message. These tags are associated with the Authentication Data and Key Delay (ADKD) values. Different ADKD values and their meanings are presented in the following.

• ADKD=0: Ephemeris, clock, and status of the satellite are authenticated in each subframe (or 30 s) delay. FGI-GSRx offers further subdivision of ADKD=0 into the following:

  -

  SelfAuthADKD=0: ADKD=0 authentication of the satellite is carried out by itself.

  -

  CrossAuthADKD=0: ADKD=0 authentication of the satellite is carried out by some other satellite.

• ADKD=4: Galileo constellation-related timing information is authenticated.
• ADKD=12: The same information as in ADKD=0 is authenticated, but there will be an additional 10 subframe (or 300 s) delay in transmitting the TESLA key needed to authenticate the tag. FGI-GSRx offers further subdivision of ADKD=12 into the following:

  -

  SlowSelfAuthADKD=12: ADKD=12 authentication of the satellite is carried out by itself.

  -

  SlowCrossAuthADKD=12: ADKD=12 authentication of the satellite is carried out by some other satellite.

3. FGI-OSNMA

In FGI-OSNMA the relevant information is decoded from the navigation pages and organized into four different data streams [12]. Associating data from these streams is required to perform authentication. The streams are as follows:

• Navigation data stream: the stream containing the navigation data to be authenticated.
• Tag stream: the stream containing the authentication tags.
• TESLA key stream: the stream containing the TESLA keys that are used to recompute the tags.
• Control stream: the stream contains the current protocol configuration and this stream handles events such as key and chain revocations.

The main output of FGI-OSNMA after OSNMA processing is the authentication events. The authentication events can be described by multiple possible outcomes in the authentication process. These include the following:

• Success: The ADKD=0 authentication was successful by self or cross-ADKD=0. The navigation message can be trusted.
• Failure: The ADKD=0 authentication was not verified by self or cross-ADKD=0. The navigation message cannot be trusted.
• Missing tag: The authentication of a given navigation message cannot be attempted because we are missing the corresponding tag.
• Missing navigation data: We have received a tag, but not the corresponding navigation data. As such, the authentication cannot be attempted.
• Failed Cyclic Redundancy Check (CRC).
• Success or failure to authenticate a TESLA root key.

4. FGI-GSRx-v2.1.0

The main objective of the FGI-GSRx-v2.1.0 update is to offer an authenticated position solution based on Galileo OSNMA. The MATLAB Engine API for Python allows the user to call MATLAB as a computational engine from Python, and similarly, one can access all standard Python library content and use functionalities in third-party or user-created modules from MATLAB. Therefore, FGI-GSRx-v2.1.0 offers an interface between the FGI-GSRx receiver and the FGI-OSNMA software package. The detailed data interaction and flow is depicted in Figure 2.

Initially, the raw intermediate frequency (IF) data are processed by the acquisition and tracking blocks of FGI-GSRx. The navigation message is then decoded in the ‘Frame Decoding’ block. This block generates an ASCII file which acts as an input to the FGI-OSNMA software package. The ASCII file consists of the satellite ID, week number, time of the week and the I/NAV nominal pages extracted from the Galileo E1B signal that is required to decode OSNMA bits. The structure of the generated ASCII data is shown in Figure 3. FGI-OSNMA receives the ASCII input and generates authentication events corresponding to each satellite. The main role of the FGI-OSNMA interface block is to convert the data received from the ‘Authentication Events’ block into the MATLAB format compatible with FGI-GSRx in the form of tags and generate a corresponding graphical position authentication report.

The OSNMA initialization consists of retrieving and verifying the public key and TESLA root key. The TESLA root key is broadcasted regularly and verified through a digital signature that is made with OSNMA public key [23]. FGI-GSRx requires the user to offer a public key as an essential input and TESLA root key as an optional input in the configuration parameters as shown in Figure 4. The TESLA root key, chain cryptographic functions, TESLA chain key length, tag length, and other TESLA chain parameters are received in the DSM-KROOT [21]. The public key is authenticated by a Merkle tree root [21] preinstalled in the receiver [4]. The initialization process can be divided into three distinctive scenarios [21]:

• Cold start: In case the public key and TESLA root key are not available, the receiver shall first retrieve them directly from a web service, or possibly via SIS.
• Warm start: If the receiver has stored a previously verified public key, the receiver shall retrieve the DSM-KROOT, verify the public key, and verify the DSM-KROOT with the stored key.
• Hot start: If, in addition to a stored public key, the receiver also possesses previously verified TESLA key and chain parameters, it does not have to retrieve the DSM-KROOT. The receiver shall attempt to verify the received TESLA chain key with the stored key.

The processing of the authentication events to generate navigation data authentication starts in relation to the Time to First Authenticated Fix (TTFAF) taken by the receiver. TTFAF depends on the fulfillment of time synchronization requirements by the receiver and satellite visibility. [13,21]. FGI-GSRx offers both warm start and hot start, possibilities based on the user input and the data availability. The navigation layer of FGI-GSRx then generates the authenticated position solution based on the TTFAF and the choice of activated tags verification. It is important to mention that a position authentication is only performed on the navigation layer for the Galileo signal that is OSNMA verified and has $C/N_0$ greater than 30 dB-Hz. The OSNMA verification is carried out on the data for which a CRC checksum was successfully passed as per Galileo OSNMA receiver guidelines [21].

5. Experimental Setup

This section presents the experimental setup used to collect data in two different use cases: (i) live open sky signal and (ii) recording and replaying the Jammertest data. A brief insight into these scenarios is discussed below.

5.1. Live Open Sky Signal

A high-precision Septentrio’s PolaNt Choke Ring antenna was used to receive live GNSS signals on the L1/E1 frequency band. The signals were then processed with a stereo dual-band GNSS front end from Nottingham Scientific Limited (NSL) to generate raw IF data as input to FGI-GSRx.

Table 1. RF recording configuration of the NSL stereo dual-band GNSS front end.

Parameters	Frequency Bands (E1B)
Center frequency (MHz)	1569.03
Sampling rate (MHz)	26
Data type	Sampling
Sample bit width	8 bit
Bandwidth (MHz)	4.2

presents the configuration parameters and the complete experimental setup is shown in Figure 5 for both scenarios. In this work, only the Galileo E1B signal is processed, even though the GPS L1 signal is also present in the shared dataset. The reason for having only Galileo E1B signal is that Galileo is the only global constellation that offers OSNMA capability on the E1B signal.

5.2. Recording and Replaying Jammertest Data

GNSS observations serve as valuable tools for testing the receiver’s resilience in the spoofing or jamming event under open-sky conditions. In this scenario, a recorded signal from the Jammertest 2023 was replayed using a LabSat wideband 3 record and replay device. The raw IF samples were captured with the same NSL stereo front end as shown in Figure 5 with a similar configuration mentioned in Table 1.

6. Result Analysis

This section presents the results and analysis of the OSNMA-based authenticated position solution by FGI-GSRx. We will be presenting two scenarios captured by using the methods presented in Section 5. In both cases, the OSNMA verification is carried out in hot start mode. This option is utilized considering the relatively short length of GNSS raw IF datasets. For much longer datasets, it is also possible to receive and authenticate the TESLA root key to operate in OSNMA warm start mode.

6.1. Authenticated Position Under Clean Open Sky Scenario

The following scenario is taken by recording the clean open sky signals at the Otaniemi premises of FGI in Espoo, Finland. The true receiver position is 60.182°N, 24.828°E with an altitude of 47.248 m. For this study, the raw IF data are processed with FGI-GSRx only for the Galileo E1B signal. The data were recorded on 31-10-2023 between 12:23:25 UTC and 12:29:42 UTC for 6 Galileo E1B satellites (PRNs 4, 9, 21, 31, 34 and 36). Figure 6a presents the $C/N_0$ plot and Figure 6b shows the report generated by the ‘OSNMA Analysis’ block. After the authentication of the root key, FGI-OSNMA authenticates all the satellites by ADKD=0 authentication. SlowSelfAuthADKD=12 tags are also available from 12:23:42 to 12:25:12 UTC. Moreover, the ADKD=4 tag can be seen to verify the Galileo constellation timing information during the complete time interval.

OSNMA-based authenticated position plot by using only Galileo E1B signal is shown in Figure 7a. In this case, the navigation block of FGI-GSRx generates the position solution using the SelfAuthADKD=0 and CrossAuthADKD=0 tags. In the beginning, no authentic position solution can be generated due to 88 s TTFAF, after which the position solution is successfully authenticated by the receiver. For comparison, the position solution without OSNMA authentication is presented in Figure 7b and

Table 2. Clean open sky: summary of positioning performance.

	Availability (%)	${\mathit{ϵ}}_{3\mathit{D}}$	${\mathit{ϵ}}_{\mathit{V}}$	${\mathit{\sigma }}_{\mathit{V}}$	${\mathit{ϵ}}_{\mathit{H}}$	${\mathit{\sigma }}_{\mathit{H}}$	TTFAF
Position authentication	80.86	2.69	1.03	1.49	0.75	1.83	88 s
No position authentication	100	2.68	1.45	1.14	1.84	1.73	NA

discusses the authenticated and not-authenticated solution statistics. The “availability” here refers to the percentage of the total time after the first subframe decoding the authenticated position solution is available. In Table 2, symbols ${\epsilon }_{3D}$, ${\epsilon }_H$, and ${\epsilon }_V$ represent three-dimensional root mean square (3DRMS), horizontal RMS, and vertical RMS in meters, respectively, while ${\sigma }_H$ and ${\sigma }_V$ denote horizontal and vertical standard deviation in meters.

6.2. Authenticated Position in a Real-World Spoofing Scenario

The following scenario is taken from the time-synchronous simulated driving spoofing scenario from the Jammertest 2023. The receiver is at rest and the spoofer will initially generate no major changes in the navigation solution, maintaining a rather static position. After this initial period, the spoofer is intended to take away the receiver from its initial position. The spoofing attack is executed with a 25 dB Spoofing-to-Signal Ratio (SSR) over the authentic signal. The recording was made on 20-09-2023 between 14:37:02 UTC and 14:48:12 UTC and the spoofing signal was inserted at 14:40:03 UTC. This recorded scenario is replayed in the laboratory following the record and replay setup presented in Figure 5, and processed by FGI-GSRx for Galileo E1B signal only. The receiver acquires and tracks 7 Galileo satellites (PRNs 3, 5, 13, 15, 24, 25 and 31). Figure 8a,b show $C/N_0$ plots and OSNMA analysis for each satellite. For the data collected before 14:39:43 UTC, PRNs 15, 24, and 31 are not generating OSNMA data, thus resulting in the `AllZero’ tag. However, they are authenticated by using the ‘CrossAuthADKD=0’ tag. PRNs 3 and 25 are authenticated by ‘SelfAuthADKD=0’ tag, while PRNs 5 and 13 are authenticated by both ‘SelfAuthADKD=0’ and ‘CrossAuthADKD=0’ tags. A similar trend can also be seen for ‘SlowSelfAuthADKD=12’ and ‘SlowCrossAuthADKD=12’ tags for these satellites. The ‘ConstellAuthADKD=4’ tag also verifies the timing information of the constellation during this phase.

FGI-GSRx offers the flexibility of using multiple different strategies to compute the authenticated position solution. For the presented case, we consider the computed position solution as not authentic, if ADKD=0 (self/cross) is not authenticated or OSNMA is still in the initializing state due to TTFAF. The OSNMA-based authenticated position solution for the complete duration is shown in Figure 9a. After spoofing, the ADKD=0’s not-authenticated event was received at 14:40:12 UTC, thus introducing a 9 s delay to spoofing detection in this particular case. Due to this, after 14:39:43 UTC, failure to authenticate ADKD=0 is reported, and hence no position solution is generated afterward. For comparison, the position solution without OSNMA-based authentication is also shown in Figure 9b, which clearly shows the position deviation introduced due to spoofing the Galileo E1B signal.

Table 3. Jammertest 2023: summary of positioning performance.

	Availability (%)	${\mathit{ϵ}}_{3\mathit{D}}$	${\mathit{ϵ}}_{\mathit{V}}$	${\mathit{\sigma }}_{\mathit{V}}$	${\mathit{ϵ}}_{\mathit{H}}$	${\mathit{\sigma }}_{\mathit{H}}$	TTFAF
Position authentication	10	4.38	3.12	0.98	2.69	1.11	90 s
No position authentication	100	426.01	32.49	66.59	227.18	416.60	NA

presents a comparison of authenticated versus non-authenticated position solutions via FGI-GSRx. Authenticated positioning is only available for 10% of the total data duration after the first subframe synchronization. High deviation in the not-authenticated position solution indicates the change from the true reference due to spoofing.

7. Conclusions

This paper presents an end-to-end OSNMA-based position authentication solution by FGI-GSRx open-source GNSS software-defined receiver by FGI. FGI-GSRx computes the position authentication with the Galileo E1B satellites having $C/N_0$ greater than 30 dB-Hz by performing authentication via the FGI-OSNMA open-source Python software package. This research also investigates the availability of OSNMA-based authenticated position solutions for two real-world cases (clean open sky and spoofing). The results are also supported by the comparison of authenticated versus non-authenticated position solutions in terms of availability of the solution, deviation of 3DRMS, and mean and standard deviations for both scenarios. It was also shown that the FGI-GSRx stops offering authenticated position solutions at the time of spoofing. To conclude, we are also sharing the FGI-GSRx-v2.1.0 update as open-source and we believe that it would serve as a helpful tool for OSNMA-based position authentication research.