Ensuring the authenticity of satellite navigation messages is crucial. During the latest OSNMA live tests, Rokubun’s OSNMA client SDK proved its reliability, outperforming other commercial solutions that produced erratic or incorrect results in standard operational processes required by any OSNMA client in order to work properly.
As it is known, Galileo OSNMA service relies on the TESLA (Timed Efficient Stream Loss-tolerant Authentication) protocol, which is based on sequentially disclosing (transmitting) cryptographic keys in reverse order of generation. The finite nature of the chain that generates these TESLA keys necessitates periodic renewal, and in cases of compromise, immediate revocation and renewal needs to be performed. An OSNMA implementation in the user navigation device has therefore to be robust to those renewal and revocation events in order not to mislead the navigation solution with inaccurate authentication information.
More recently, specifically from June 4 to June 6, 2024, the Galileo OSNMA service underwent Orbital Live Test Notification (OLTN) 2024009 that involved both a TESLA chain renewal and a revocation process. The SPEAR OSNMA SDK, which is Rokubun’s implementation of the OSNMA client, was monitored during these tests using Rokubun’s Continuous OSNMA Monitor Stations (COSMOS). This infrastructure provided real-time Key Performance Indicators (KPIs), which were benchmarked against other commercial solutions.
During the OLTN2024009 test, first a chain renewal, and later a chain revocation exercises were performed, the first having no impact on the number of authenticated satellites, and the second resulting in a planned OSNMA outage from 14:00 to 16:00 UTC (SoW 309618 to 316818) on the 5th of June.
The TESLA chain renewal process was planned to start on 2024/06/04 at 08:00 UTC (SoW 201618), and last for 24 hours. During this period OSNMA would remain operational without any disruptions.
We can see how the SPEAR OSNMA SDK does capture the start of the TESLA chain renewal process, and no abnormalities are observed on the authentication plot.
In addition, while conducting the test exercise, we noticed that in other commercial solutions, there were satellites incorrectly flagged as spoofed. Further evaluation revealed that this was not related to the test exercise (chain renewal/revocation). Instead, this was related to the inclusion of 2 Galileo SVs in the OSNMA constellation (GSAT201 and GSAT202, on June 3rd 2024), following the OLTN2024010 notification event.
On June 5th, the TESLA chain renewal was expected to take place at 08:00 UTC (SoW 288018) as reported by GSC OLTN2024009 , followed by the revocation process between 14:00 to 16:00 UTC (SoW 309618 to 316818).
We can see how the SPEAR OSNMA SDK does capture both exercises, resulting in no disruption whatsoever on the renewal exercise, and successfully performing the revocation exercise.
However, for the commercial solution the chain renewal exercise (that should have no effect on the number of authenticated SVs) caused incorrect flagging of numerous satellites: these affected satellites were incorrectly flagged as spoofed. The problem persisted during the TESLA revocation exercise and a reboot of the receiver was needed. The reboot however did not fix the issue with GSAT201 and GSAT202, and the receiver still shows an OSNMA spoofed flag for these satellites.
In view of these results, the SPEAR OSNMA SDK has proved to outperform commercially available solutions, successfully performing the chain renewal and revocation exercises at the expected epochs and also handling the inclusion of GSAT201 and GSAT202 without incorrectly flagging these satellites as spoofed.
