Testing a Receiver's Galileo OS-NMA Capability Using Skydel

Technical & Application Notes

Skydel OS-NMA GitHub Repository


The new generation of satellite-enabled applications relies on resilient and accurate GNSS signals as a key element for many critical projects to ensure highly accurate positioning, navigation, and timing (PNT) 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.


Open Service Navigation Message Authentication (OS-NMA) is an authentication service emerging for GNSS technology – specifically in the Galileo satellite constellation. OS-NMA 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. OS-NMA 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 (FOC) is targeted for availability in 2023.

OS-NMA Architecture

OS-NMA is a data authentication function. This means that the receiver can authenticate broadcast navigation messages and ensure they have not been modified. OS-NMA 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: OS-NMA ICD / GALILEO OS ICD)

OS-NMA data is broadcast on the E1-B signal component and inserted in the previously “Reserved 1” fields of the E1 I/NAV message. So, OS-NMA does not modify the I/NAV message structure but simply adds data into a new field. A receiver that does not support OS-NMA can still use an E1 signal with the same performance.

Figure 2: OSNMA processing logic.

OS-NMA 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 OS-NMA 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 OS-NMA 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.

OS-NMA 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 OS-NMA 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 OS-NMA 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

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 OS-NMA testing is a list of scenarios (SDX format) corresponding to each test vector. Safran has generated OS-NMA 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 OS-NMA scenarios, and provide an example of how they can be modified to perform spoofing testing.

Figure 6: List of available OS-NMA scenarios.

You can find all the files in this Skydel OS-NMA 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 OS-NMA data. Please refer to your receiver documentation in order to properly configure it for a simulated environment.

For the simulation, connect an OS-NMA-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 OS-NMA data using one of the test vectors.

Firstly, we enable the OS-NMA “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 OS-NMA 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

  1. Start the simulation and open the RxControl software to view the OS-NMA status. The receiver is in a cold start situation.

    Figure 10: RxControl and Message Inspector View Menu

  2. 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

  3. 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 OS-NMA in the test vector configuration.

Using this same OS-NMA scenario, you can add a spoofing transmitter to test OS-NMA’s anti-spoofing capabilities. Keep in mind that test vectors do not represent OS-NMA service phase performance. You are able to observe the effect of OS-NMA against a simple spoofing attack by running the same scenario with and without OS-NMA data.

  1. 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.
  2. Secondly, run the scenario by enabling the receiver’s OS-NMA 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 OS-NMA 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 OS-NMA ‘loose’ mode.
    • Then, wait 5 minutes to let the OS-NMA-ready receiver authenticate satellites, then reactivate the spoofer.

Figure 14: Spoofing results with and without OS-NMA 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 OS-NMA and shows how Skydel can be configured to perform your own OS-NMA test case.

Future evolutions

The Skydel simulation engine will provide complete flexibility within the scenario configuration (time, navigation, message, etc.) and the OS-NMA authentication parameters (keys, encryption algorithms, message sequences, etc.). It will help advanced users (e.g., receiver manufacturers) who test receivers in a wide range of edge and corner cases.

Available later in 2023, this phase will include the following elements in Skydel:

  • A new Skydel release to support OS-NMA User ICD.
  • Authentication of the Galileo E1 OS Navigation Message.
  • Support for the Timed Efficient Stream Loss-tolerant Authentication (TESLA) protocol.
  • Useful crypto material for running user-programmable simulation test scenarios.
  • This feature will be ready for future software updates by the following phases
    recommended by EUPSA.


Using the OS-NMA test vector scenarios allows users to test if receivers support OS-NMA with different configurations and scenarios. It does not reflect the OS-NMA service performance of your GNSS receiver, but it enables you to broadcast OS-NMA data to any receiver. These OS-NMA scenarios are also editable, so you can use all Skydel features to customize your simulation case.


Skydel OS-NMA GitHub Repository Reference documents – GSC Electronic Library Official Documentation Description and Access to OSNMA Products Advanced Spoofing Application Note