Testing a Receiver's Galileo OSNMA Capability Using Skydel
Technical & Application Notes
The new generation of satellite-enabled applications relies on resilient and accurate GNSSGlobal navigation satellite system (GNSS): A general term describing any satellite constellation that provides positioning, navigation, and timing (PNT) services on a global or regional basis. See also signals as a key element for many critical projects to ensure highly accurate positioning, navigation, and timing (PNTPosition, Navigation, and Timing: PNT and map data combine to create the GPS service.) data.
Safran offers GNSS test and simulation solutions designed to ensure your system’s performance, resilience, and accuracy for complex GNSS applications.
The Challenges of Jamming and Spoofing Attacks
GNSS technology is the primary global technology for PNT, and it is critical that it continues to evolve and become more secure and resilient.
Jamming is simply the ability to overpower the GNSS signals transmitted from satellites
since they have travelled long distances. Spoofing is a more sophisticated attack where fake
GNSS signals are transmitted to fool a receiver into misrepresenting its location and timing.
Jamming and spoofing attacks are becoming increasingly common on GNSS systems and technologies.
What is GALILEO OSNMA?
Open Service Navigation Message Authentication (OSNMA) is an authentication service emerging for GNSS technology – specifically in the Galileo satellite constellation. OSNMA allows GNSS receivers to verify the authenticity of received data to protect against spoofing attacks that can result in service disruptions, denial incidents, and more severe consequences. OSNMA will be a free service for Galileo Open Service users but does require a compatible receiver to decode and authenticate.
The European Union Agency for the Space Program (EUSPA) launched the test phase. In November 2020, Galileo satellites began transmitting authentication data. This data is currently being transmitted for public observation and evaluation. Full operational capability (FOCFull Operational Capability refers to military acquisition missions that have been completed the development phase. This phase comes after an initial operational capability phase.) is targeted for availability in 2023.
OSNMA Architecture
OSNMA is a data authentication function. This means that the receiver can authenticate broadcast navigation messages and ensure they have not been modified. OSNMA data is encrypted and unpredictable, so a spoofer cannot replicate it.
Figure 1: E1-B I/NAV Nominal Page structure before/after added OSNMA data. (Source: OSNMA ICD / GALILEO OS ICD)
OSNMA data is broadcast on the E1-B signal component and inserted in the previously “Reserved 1” fields of the E1 I/NAV message. So, OSNMA does not modify the I/NAV message structure but simply adds data into a new field. A receiver that does not support OSNMA can still use an E1 signal with the same performance.
Figure 2: OSNMA processing logic.
OSNMA uses the Time-Efficient Stream Loss-Tolerant Authentication (TESLA) protocol to optimize authentication performance in terms of computation and communication. Authentication data reception is delayed, and data can all be retrieved in one I/NAV subframe (30 seconds).
The OSNMA receiver needs to be synchronized with the GALILEO System Time to ensure the security of the TESLA protocol. Also, navigation data and tags need to be received before the TESLA chain key. The OSNMA receiver guidelines V1.1 sets the time synchronization requirement to 30 s.
The data authentication process can be summarized as follows:
- Navigation data, including OSNMA data (Public Key, TESLA root/chain key and tag), is broadcasted. Navigation messages, Message Authentication Code (MAC), or Tag are received before the TESLA chain key.
- TESLA root key is authenticated using a Public Key broadcasted with some delay.
- Authenticated TESLA root key authenticates TESLA chain key.
- A local tag is computed using Navigation data and the TESLA chain key. The local tag is compared to the received one. Navigation data is authenticated if it matches.
OSNMA Test Vectors
In October 2022, EUSPA published a set of test vectors to allows users to test their receivers on all OS-NMA configurations. These test vectors are independent, and they can test nominal modes and each cryptographic process. They do not reflect OSNMA service performance, but they assess the capability of a commercial receivers to fully support OS-NMA.
You can find more details about test vectors in the OSNMA receiver guidelines.
A list of 13 test vectors has been published and is summarized below:
| Test Vector | Date (GST) | Duration (Hours) |
|---|---|---|
| Configuration A | 13/12/2022 09:00:01 | 1 |
| Configuration B | 17/01/2021 08″00:01 | 1 |
| Configuration C | 28/02/2021 08:00:01 | 1 |
| Configuration D | 20/02/2022 08:00:01 | 1 |
| End of Chain Step 1 | 12/01/2021 10:00:01 | 2 |
| End of Chain Step 2 | 13/01/2021 10:00:01 | 2 |
| New Public Key Step 1 | 25/01/2021 08:00:01 | 2 |
| New Public Key Step 2 | 11/12/2020 08:00:01 | 3 |
| New Public Key Step 3 | 12/12/2020 08:00:01 | 2 |
| Public Key Revocation Step 1 | 15/12/2020 08:00:01 | 2 |
| Public Key Revocation Step 2 | 15/12/2020 10:00:01 | 2 |
| Public Key Revocation Step 3 | 16/12/2020 08:00:01 | 2 |
| OS-NMA Alert Message | 23/02/2021 09:00:31 | 1 |
New OSNMA Test Vectors (updated April 2024)
Following the new version of GALILEO OSNMA Receiver Guidelines (v1.3) published on January 2024 , a new test vector dataset has been released by the EUSPA.
These test vectors allow users to test their receiver compatibility with the ICD version 1.1. In addition to nominal operating conditions, cryptographic operations such as Public Key, TESLA chain, Merkle Tree management processes can also be tested.
SAFRAN provides – at no charge – a new collection of scenarios to play this test vector using the Skydel simulation engine.
| Test Vector | Date (GST) | Duration (Hours) |
|---|---|---|
| Configuration 1 | 16/08/2023 05:00:01 | 1 |
| Configuration 2 | 27/07/2022 00:00:01 | 1 |
| End of Chain Step 1 | 06/10/2023 16:45:01 | 1 |
| End of Chain Step 2 | 06/10/2023 18:30:01 | 1 |
| Chain Revocation Step 1 | 06/10/2023 21:45:01 | 1 |
| Chain Revocation Step 2 | 06/10/2023 23:30:01 | 1 |
| Chain Revocation Step 3 | 07/10/2023 00:30:01 | 1 |
| New Public Key Step 1 | 07/10/2023 02:45:01 | 1 |
| New Public Key Step 2 | 07/10/2023 03:45:01 | 1 |
| New Public Key Step 3 | 07/10/2023 04:45:01 | 1 |
| Public Key Revocation Step 1 | 07/10/2023 07:45:01 | 1 |
| Public Key Revocation Step 2 | 07/10/2023 09:30:01 | 1 |
| Public Key Revocation Step 3 | 07/10/2023 10:30:01 | 1 |
| Merkle Tree Renewal Step 1 | 07/10/2023 12:45:01 | 1 |
| Merkle Tree Renewal Step 2 | 07/10/2023 13:45:01 | 1 |
| Merkle Tree Renewal Step 3 | 07/10/2023 14:45:01 | 1 |
| OSNMA Alert Message Step 1 | 07/10/2023 18:45:01 | 1 |
| OSNMA Alert Message Step 2 | 07/10/2023 19:45:01 | 1 |
Test vectors are provided in a CSV format file and named accordingly with the start time of the transmission. They contain a hexadecimal I/NAV data stream for a set of satellites.
Figure 3: I/NAV Message Structure in the Nominal Mode (Source: OSNMA ICD).
According to the GALILEO ICD, an I/NAV message page is transmitted every 2 seconds (1s for even/1s for odd), and 15 pages form a subframe. Each page is 240-bit sized—more details on the OSNMA ICD.
Public Keys and Merkle Tree Roots corresponding to test vectors are also available. You can introduce them manually in your receiver in case the Public Key Renewal is unavailable (simulated scenario) or to speed up the initialization step.
Test Vector Implementation in Skydel
The test phase of the Skydel solution for OSNMA testing is a list of scenarios (SDX format) corresponding to each test vector. Safran has generated OSNMA scenarios by modifying I/NAV messages using the message modifications menu available for each constellation. All the navigation data from the Test Vectors replaces the Skydel computed ones.
Figure 4: Skydel Message modification menu
We have used this feature to implement all the I/NAV messages contained in the test vector. After importing one of the Test Vectors scenarios, you can double-click each modification to see the description of the 240-bits modifications Skydel is managing.
Figure 5: I/NAV message modification to include Test Vector data (configuration A).
Each message modification corresponds to one I/NAV page (even and odd parts). A new page is transmitted every 2 seconds and consists of 4*60 bits modifications.
All the Skydel scenarios have been generated using the remote API. A single script has been used to read the CSV test vector file and send the message modifications to the Skydel instance.
To ensure consistency between the navigation message and the simulated satellite location, a RINEX file of the test vector date and time is imported in each scenario.
Testing a GNSS Receiver
In this part, we will demonstrate how we use the OSNMA scenarios, and provide an example of how they can be modified to perform spoofing testing.
Figure 6: List of available OSNMA scenarios.
You can find all the files in this Skydel OSNMA GitHub repository. In each file, there is a Skydel scenario corresponding to the test vector, RINEX file, raw test vector (XML file), Merkle tree root (XML file), and the public key in two formats: hexadecimal (XML file), Base64 (PEM file).
Depending on your receiver, you may need to introduce manually public key/Merkle tree root to make your receiver work successfully with OSNMA data. Please refer to your receiver documentation in order to properly configure it for a simulated environment.
For the simulation, connect an OSNMA-compatible receiver to a Skydel-based GNSS simulator.
Figure 7: Hardware configuration (using a GSG-8 simulator).
Example: Septentrio Mosaic-X5
In this example, a Septentrio Mosaic-X5 receiver with firmware version 4.12 is used to see how it manages OSNMA data using one of the test vectors.
Firstly, we enable the OSNMA “loose” mode of the receiver so that the PVT is computed for satellites in “unknown” or “authenticated” status – only “failed authentication” satellites are rejected.
The authentication status is reported in the GALAuthStatus SBF block. Please refer to the Mosaic-X5 firmware reference guide.
For this example, we use the configuration D test vector scenario in Skydel.
Figure 8: Opening configuration D test vector scenario in Skydel
- The scenario begins at the test vector starting time, indicated in the name of the raw test vector data.
- The output signal is GALILEO E1.
- The simulated position is static and located in Grasse, France.
- I/NAV messages from the configuration D test vector are implemented.
All the Skydel OSNMA scenarios are modifiable; only I/NAV message modifications and starting time parameters must remain unchanged to run the test vector correctly. If using advanced jamming or spoofing engines, you could modify the scenarios and add a spoofer or jammer.
Figure 9: RxControl and Message Inspector View Menu
- Start the simulation and open the RxControl software to view the OSNMA status. The receiver is in a cold start situation.
Figure 10: RxControl and Message Inspector View Menu
- After two minutes of simulation, we can see the initialization process starting. The receiver retrieves and verifies the public and TESLA root keys at this step.
Figure 11: RxControl and Message Inspector View Menu
- After three minutes, the receiver switches to authentication mode. The TESLA chain key is verified, and the tag is authenticated. We can see on RxControl that authenticated satellites are marked with a green square. Seeing this result, we can assess the receiver’s capability to support OSNMA in the test vector configuration.
Using this same OSNMA scenario, you can add a spoofing transmitter to test OSNMA’s anti-spoofing capabilities. Keep in mind that test vectors do not represent OSNMA service phase performance. You are able to observe the effect of OSNMA against a simple spoofing attack by running the same scenario with and without OSNMA data.
- Firstly, set up a working spoofing scenario: the simulated location is fixed, and the spoofer is broadcasting a circle trajectory; if the receiver location is moving, this means it is being spoofed.
- Secondly, run the scenario by enabling the receiver’s OSNMA mode and compare the deviation results.
All scenario files are available in the Skydel GitHub repository. To perform this scenario, both the SKY-ADVJAM and SKY-ADVSP options must be activated.
Figure 12: Adding spoofer.
3. Set up the spoofer next to the simulated location in the Settings/Spoofers/Spoofer 1/Trajectory menu. The reference power must be chosen according to your receiver in the General tab.
4. Tune your reference power value by running the non-OSNMA scenario. For this example, we have chosen -35dBm as the reference power.
Note: Refer to the advanced spoofing application note to get more details about how to set up a spoofer in Skydel.
Figure 13: Setting the spoofer trajectory.
5. Run the scenario to see how the receiver-computed location is moving:
-
- First, the OSNMA mode is disabled, and allows the receiver fix its position; after 4 minutes, enable the spoofer broadcasting.
- After 10 minutes, deactivate the spoofer and activate the receiver’s OSNMA ‘loose’ mode.
- Then, wait 5 minutes to let the OSNMA-ready receiver authenticate satellites, then reactivate the spoofer.
Figure 14: Spoofing results with and without OSNMA enabled on the receiver
On the left of the above image, the deviation tab shows the difference between the simulated and the receiver positions. On the right, we see the broadcasted trajectory of the spoofer and beneath it, the PVT time plot of RxControl. We can see that the PVT is cut for a short time when spoofed (red bar).
- With only a GALILEO E1 signal, the receiver provides a 5m absolute accuracy from the simulated location. When the spoofer is enabled, the receiver starts to move and doubles its deviation values.
- OS-NMA doesn’t avoid the receiver motion but limits the spoofing impact on the position.
This simple simulation assesses the anti-spoofing capability of OSNMA and shows how Skydel can be configured to perform your own OSNMA test case.
Conclusion
Using the OSNMA test vector scenarios allows users to test if receivers support OSNMA with different configurations and scenarios. It does not reflect the OSNMA service performance of your GNSS receiver, but it enables you to broadcast OSNMA data to any receiver. These OSNMA scenarios are also editable, so you can use all Skydel features to customize your simulation case.
