A new security level against GNSS spoofing

GNSS spoofing and jamming attacks are on the rise. In recent years, growing availability of inexpensive signal simulators has led to spoofing episodes, which in turn have resulted in disruptions of GPS and Galileo signals reported by high-precision GNSS equipment manufacturers.

GNSS signal falsification has become a significant concern for global market sectors that rely on precise navigation, such as critical infrastructure, aviation, and maritime transport. More specifically, this means fishing vessels misreporting their locations, alterations in timing for critical infrastructure, and interferences with tachographs, motor vehicles, and unmanned aerial vehicles (UAVs).

As a result, Galileo, Europe's Global Navigation Satellite System, has developed a safety function to strengthen resilience against spoofing attacks. The so-called OSNMA (Open Service Navigation Message Authentication) is a GNSS-embedded anti-spoofing feature that should become attractive for high-end and mass-market GNSS receivers.

While this feature represents progress in ensuring security and safe communication between satellites and GNSS receivers, there is potential to enhance its functionality. This improvement could extend beyond Galileo’s system transmission and encompass other constellations and multiple frequency bands, too. To address these limitations, it is essential to first identify them through field tests and then explore alternative solutions.

How does OSNMA operate against GNSS spoofing?

Galileo OSNMA was developed to prevent GNSS spoofing attacks by ensuring secure end-to-end transmissions between Galileo satellites and GNSS receivers. It’s currently in the final trial testing phase.

OSNMA functions as a security measure to protect the authenticity and integrity of navigation messages transmitted by the Galileo satellites, ultimately enhancing the reliability of GNSS positioning and timing information. It ensures the legitimacy of signals transmitted by GNSS satellites to GNSS receivers via a mechanism that prevents any tampering with the signals. The secure mechanism can be summarized as follows.

OSNMA in 7 steps

• Message generation. Satellite systems generate navigation messages containing critical information about satellite positions, satellite health, and precise time data. These messages are crucial for ensuring accurate positioning by user receivers.
• Key generation. Satellite system operators generate and distribute a secret cryptographic key known only to them,  which is used for generating a message authentication code (MAC).
• MAC calculation. With this secret cryptographic key, a MAC is calculated for each navigation message and generated by applying a cryptographic algorithm (for instance, HMAC or CMAC) to the message content. The MAC, therefore, serves as a unique signature for that specific message, which is based on the message content and the secret key.
• Inclusion of MAC in the message. The calculated MAC is attached to the navigation message.
• Message transmission. The satellite transmits this combined message, including the original navigation message and the MAC.
• Key verification. The user receiver can access the satellite system operators' secret key, which is made public with a certain delay. This key independently calculates a MAC for the received navigation message, relying on the same cryptographic algorithm.
• MAC comparison. The user receiver compares the calculated MAC with the MAC received in the message. If the two MACs match, the navigation message has not been tampered with during transmission. This means the message is authentic and can be trusted for accurate positioning information.

OSNMA’s limitations today and initial steps to solve them

Implementing OSNMA in mass-market receivers faces technical challenges and resource limitations. OSNMA currently only authenticates the I/NAV message from the Galileo constellation. However, trends require GNSS receivers to process signals from multiple constellations and signal bands for more accuracy and availability.

Adopting a pure OSNMA solution under these circumstances would be detrimental, inevitably leading designers to find methods for running parallel navigation solutions that would increase the processing power requirements.

The first step in addressing these challenges while maintaining navigation quality was to assess the performance of Galileo OSNMA. At u-blox, we recently conducted a series of tests in diverse environments, employing different u-blox OSNMA receivers.

The primary objectives of these tests included evaluating service performance, measuring availability in different real-world scenarios, and assessing the additional processing power required for authentication. For this aim, we created simulated scenarios to explore the impact of various OSNMA parameters on receiver performance under stress conditions.

The navigation accuracy and availability of the pure OSNMA solution have provided insights into the expected coverage based on the specific environment or application.

Assessing GNSS spoofing in various environments

u-blox evaluated the reliability of OSNMA across multiple environments, ranging from open and unobstructed spaces to challenging urban scenarios. Two tests took place during the summer of 2023 in Zurich and Chicago. In the former city, we tested the function on a mix of suburban, highway, and urban environments, whereas in the latter, the focus was on deep urban environments.

u-blox engineers considered 1) the availability of OSNMA data to authenticate data and 2) the accessibility to (at least) four satellite vehicles (SVs) with OSNMA-authenticated data during navigation.

Zurich. The journey on highways and in the city of Zurich lasted for about 1.5 hours. During this time, access to OSNMA authentication was considerable.

Measuring this accessibility is possible by comparing the calculated MAC of the GNSS receiver with the MAC included in the message. Based on this comparison, the receiver can verify whether the message has been tampered with during transmission and whether the source is reliable.

Conducting the same test on highways and within the city did not yield a noticeable difference in results. The following graph illustrates the number of authenticated MACs over time during the Zurich test.

Four Galileo satellites with authenticated data were consistently accessible at least 98% of the time. The most challenging areas, whether on highways or within the city, were tunnel entry and exit points, with limited satellite visibility, resulting in the unavailability of authenticated data.

Chicago. The u-blox team carried out the same test on the other side of the Atlantic.

In this case, we approached downtown Chicago, transitioning from a less dense urban area to a denser one over approximately the same time. Once again, we plotted the number of authenticated MACs over time.

As the graph illustrates, at the start of our journey, the temporal plot of authenticated MACs is higher compared to the middle and end of it. These results align with the transition from a less dense urban environment to a denser one.

Upon entering downtown, with skyscrapers lining both sides of the streets, the environment presented more significant challenges than Zurich’s.

Indeed, we obtained results in line with our predictions. In this highly challenging environment, access to more than four Galileo satellites with verified data accounted for only 83% of the time.

Limitations have a twofold origin: the constrained access to exclusively Galileo satellites for authenticated data and the fact that in such scenarios, satellite signals may be obstructed by buildings, regardless of their authentication status.

With these two tests, u-blox confirmed a reduction in the number of MAC authentications relative to the scenario. The more challenging the environment, with more buildings, tunnels, and bridges, the less access to four Galileo satellites is possible at the same time.

Yet, with cross-authentication, and since it is only necessary to authenticate the same navigation data once, access to authenticated data and position information is also available in the most adverse conditions.

Further steps

After characterizing the OSNMA capabilities and their impact on navigation, the next step is to explore strategies to overcome OSNMA's inherent limitations.

The OSNMA protocol currently focuses on authenticating Galileo I/NAV data, thereby restricting the navigation solution to Galileo signals with authenticated data.The result is an undesirable trade-off that affects the security, accuracy, and availability of numerous products.

Designers may consider implementing a parallel navigation filter for data authentication, enabling users to compare this solution with the multi-constellation approach used for navigation. Nevertheless, some products may require additional resources to run parallel filters for high-precision corrections or sensor fusion.

In other words, the goal is to find a solution that offers OSNMA robustness in multi-constellation while minimizing the resource and processing requirements of multi-band receivers.

Other aspects u-blox has explored include the following:
•    Assessing the possibility of verifying elements of authenticated and unauthenticated payload data components.
•    Examining the feasibility of using authenticated I/NAV data (or confirming the F/NAV signal based on I/NAV) for dual-frequency receivers utilizing the ionosphere-free combination of E1 and E5a signals.
•    Cross-authenticating GPS coordinated universal time (UTC) using Galileo’s authenticated offset to GPS and UTC.

The several strategies u-blox has adopted should provide insights into the next steps for enhancing the Galileo OSNMA feature. Stay tuned for novel results in this regard.
In the meantime, bear in mind that from this year (2023) onwards, u-blox products will have access to the OSNMA function.