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 also extend beyond Galileo’s system transmission and encompass other constellations and multiple frequency bands.
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. The system is 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 summarised in the following seven 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’s 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’s 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 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, a series of tests in diverse environments were recently conducted, 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, simulated scenarios to explore the impact of various OSNMA parameters on receiver performance under stress conditions were created.
Conclusion
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. Therefore, the goal is to find a solution that offers OSNMA robustness in multi-constellation use, while minimising the resource and processing requirements of multi-band receivers.
From 2023 onwards, u-blox GNSS products will have access to the OSNMA function.
For more information contact RF Design, +27 21 555 8400, [email protected], www.rfdesign.co.za
| Tel: | +27 21 555 8400 |
| Fax: | 086 653 2139 |
| Email: | [email protected] |
| www: | www.rfdesign.co.za |
| Articles: | More information and articles about RF Design |
© Technews Publishing (Pty) Ltd | All Rights Reserved
printer friendly version