The low-cost, lightweight platform can be easily configured for a variety of applications and test scenarios. This article focuses on its use for GNSS authentication.
CILLIAN O’DRISCOLL, Independent Consultant
GIANLUCA CAPARRA, European Space Agency
The need to protect GNSS based Position, Velocity and Time (PVT) against malicious attack has been the subject of much research in recent years. At the system side, Galileo is in the process of implementing both Navigation Message Authentication (NMA) and Spreading Code Encryption (SCE) in the current generation of satellites [1, 2, 3], and GPS is investigating options for introducing similar protections on L1C [4].
NMA provides authentication of the navigation message, ensuring it cannot be arbitrarily modified by a malicious actor, but also tying the broadcast data to a particular instant in time. This forces the attacker to observe and repeat the true data and provides the participating user with a lower bound on the current time.
SCE is a mechanism to protect the navigation signals by modulating them with encrypted sequences, either in whole [5] or in part [4]. These encrypted sequences can be re-created only by a user with the appropriate cryptographic key. These keys are either maintained in authorized user receivers in secure tamper-proof modules [5], or kept private permanently, in which case the sequences themselves are broadcast publicly at some delay after the initial broadcast [4].
In essence, both schemes operate by adding elements of unpredictability to the broadcast signals, generating them in a way so the system operator can be demonstrated as the originator of these unpredictable elements. For NMA, the unpredictable elements are data bits included in the broadcast message, while for SCE the unpredictable elements are the chips of the spreading codes themselves.
We have developed a low-cost embedded platform, Nautilus, for testing GNSS authentication signal processing strategies in real world environments in real time. Nautilus is designed to be a low-cost, lightweight platform that can be easily configured for a variety of different applications and test scenarios. In this work we demonstrate its use in the context of GNSS authentication.
We give an overview of the Nautilus platform, describe test configurations developed, and present initial results of live sky testing and calibration, showing the platform’s suitability for use in real time and post-mission testing of GNSS authentication. All the test campaigns are conducted using only publicly available information, for example the Galileo Open Service Navigation Message Authentication (OSNMA) testing specification [1], the Galileo E6 public Interface Control Document (ICD) [6] and the Chimera draft specification [7].
System Overview
The Nautilus testbed is based on the LimeNET Micro development board from Lime Microsystems [8]. This board is designed to be a low cost (about $350) platform for deploying narrow band wireless networks. It incorporates the following components:
• An LMS7002M RF transceiver chip, which performs down conversion to baseband and I/Q sampling at rates of up to 160 MHz
• A Raspberry Pi Compute Module 3+, which contains a quad core ARM Cortex A53 CPU operating at 1:2 GHz with 1 GB of RAM
• An Intel Altera MAX 10 Field Programmable Gate Array (FPGA), which acts as a gateway between the LMS7002M and the Raspberry Pi
• A u-blox MAX M8Q GNSS receiver, capable of tracking three systems at once from among GPS, Galileo, BeiDou and Glonass
The LimeNET micro is shown in Figure 1, with a biro included for scale. The platform is approximately the size of a modern smartphone and is easily portable.
The u-blox receiver generates a Pulse Per Second (PPS) timing signal that is input to the FPGA and used to tune the on-board oscillator—in effect operating as a low-cost GPS disciplined oscillator. This means the samples collected through the LMS7002M are collected with a clock drift measured in Parts Per Billion (ppb) relative to GPS system time, albeit with relatively poor short-term stability.
The LMS7002M is a high performance 2×2 Multi Input Multi Output (MIMO) chip, with a frequency range covering 30 MHz to 3.8 GHz, and a 12-bit Analog-to-Digital Converter (ADC) capable of operating at up to 160 Msps. The LimeNET Micro board is not able to take full advantage of this chipset. It is limited to Single Input Single Output (SISO) operation and a maximum sampling rate of about 10 to 12 Msps. The raw samples are packetized in the FPGA and then streamed to the Raspberry Pi over an integrated Universal Serial Bus (USB) interface.
Hardware Modifications to the LimeNET Micro
A number of minor modifications and additions were made to the LimeNet Micro to increase its usefulness for GNSS applications. The first step was to synchronize the data collection with GNSS time from the u-blox receiver. The pre-existing hardware achieved a very close syntonization (i.e. matching in frequency) but for authentication we also need close alignment in time.
To this end, the FPGA firmware was updated so that, once enabled, data collection is triggered on the next rising edge of the PPS. The LimeNET Micro is fully open-source hardware, so the FPGA source files are all available online [9]. The modified gateware for Nautilus can be found in [10]. With this modification, data collections can be triggered to occur only at 1 second boundaries, but this is not seen as a major limitation.
To know precisely the time at which the data collections are triggered, it is necessary to have an accurate time reference on the Raspberry Pi, which acts as the overall controller for the Nautilus platform. For that to be achieved, the Network Time Protocol (NTP) software is used in conjunction with the raw NMEA messages logged from the u-blox receiver. To ensure the NTP time is as closely aligned to the GNSS system time as possible, the FPGA firmware was updated again to route the u-blox PPS signal to one of the Raspberry Pi General Purpose Input/Output (GPIO) pins. The NTP software is then able to use the PPS signal to achieve time synchronization with the u-blox that is accurate at the microsecond level. Again, this modification is available at [10].
The final modification to the LimeNET Micro boards was the addition of two non-fixed resistors to open up a previously unused USB connection between the Raspberry Pi and the u-blox receiver. This is a particularly important addition in that it enables two-way communication with the GNSS receiver, without modifying the configuration on its serial port, which logs the NMEA message used by the FPGA as part of the clock taming circuitry.
With this modification, it became possible to enable Galileo processing on the u-blox receiver (which was disabled by default), and to log raw navigation messages for all tracked satellites. This last feature was essential to enable real-time processing of Galileo OSNMA data. We had hoped to also log raw observables (pseudorange, Doppler and C=N0) but unfortunately the u-blox receiver model does not support this feature. A work-around has been developed, using a combination of decoded ephemeris, raw PVT information and raw Doppler and code-phase measurements.
In addition to the above modifications to the LimeNET micro hardware, Nautilus also includes two additional peripherals:
1. A Bosch BMO055 9-DOF Inertial Measurement Unit (IMU), connected via serial port
2. A WiFi/3G/4G LTE USB dongle
Software Components
The Nautilus functionality is provided through a number of inter-connected software components, including both commercial off the shelf (COTS) and custom elements.
COTS:
• Network Time Security (NTS) over NTP, for authenticated time transfer [11]
• Roughtime, also for authenticated time transfer [12]
Custom:
• libosnma, an implementation of the OSNMA based on the user ICD for the testing phase, which is available online [1]
• Narwhal, a snapshot authentication tool
• Kronos, authenticated time synchronization using NTS over NTP and Roughtime
• Integration software implemented in Python including IMU, clock modelling (error modelling), clock bound modelling, and u-blox interface software
The software components are pluggable, so for example, the u-blox integration tool, libosnma and Kronos tools all integrate to provide OSNMA functionality in real-time, including assurance that the time synchronization requirement is met. Similarly, the Narwhal snapshot tool integrates with NTP and the u-blox software to generate time-stamped snapshots including PVT, ephemeris and observation data extracted from the u-blox. This is very useful for post-processing. The raw snapshot data can be processed to determine if the expected signals are present, or if spoofing signals are present nearby, for example.
Configuration Options
Given the hardware and software components, Nautilus can provide the following system level services (although not necessarily all at once):
• Real-time testing of Galileo OSNMA, including the authenticated time synchronization requirement via the Kronos software
• Delayed release of encrypted sequences for spreading code authentication. For example:
– Taking snapshots of Galileo E6-C, which will be encrypted as part of the upcoming Commercial Authentication Service (CAS) [3]. These snapshots can be post-processed to determine the presence of the encrypted chips that are (potentially) released after some delay.
– Taking snapshots of GPS L1-C, which may contain secure marker sequences as part of the proposed Chimera scheme [7].
• Dynamic error model mismatch detection, using the clock model and IMU.
• Angle of arrival spoofing detection, using a different antenna for the LMS7002M than used for the u-blox receiver.
• Clock bound modeling, based on authenticated two-way time transfer.
• Anti-spoofing testbed. Using the timestamped snapshots, it is relatively straightforward to emulate a variety of different spoofing attacks in post-processing.
Figure 2 shows a system level view of the hardware and software components.
Sample Results
Nautilus has been used as an R&D tool for GNSS authentication over the last two years. Here we show some sample processing results obtained with the platform.
Early OSNMA Testing
In November 2020, the Galileo program began an internal OSNMA test campaign, in which valid OSNMA data was broadcast through the Galileo E1 OS signal. The details of the signal configuration, and indeed the most up to date signal specification, were not public at the time, and we did not have access to these elements for this work. Nevertheless, Nautilus was deployed to process the live OSNMA signals in real time using NTS for secure time transfer for establishing the loose time synchronization bound required for OSNMA processing.
Figure 3 shows a snapshot from the Nautilus OSNMA log, captured as a screenshot in real-time from a remote terminal connection to the device in late November 2020.
Snapshot Calibration and Testing
The main reason for choosing the LimeNET Micro as a basis to build Nautilus on was the synchronization of the sampling clock with GNSS time. In theory, this should allow the collection of snapshots of data with a precisely known time of reception. This, in turn, makes the tool incredibly useful in evaluating signal level authentication features, such as Galileo CAS on E6 and GPS Chimera on the L1C signal. Figure 4 shows the correlation functions over all Galileo satellites in view for two snapshots: one for the Galileo E1 band and one for the Galileo E6 band.
The snapshots were triggered by the rising edge of the PPS from the u-blox receiver, and the nominal pseudorange and Doppler were computed based on the u-blox observables. The figures show the correlations evaluated with a 1 metre resolution over a range sufficient to cover ±1.5 chips around the nominal peak. In this case, the nominal calibrated offset between the start of the recording and the PPS has been subtracted.
For the purposes of calibration, a large number of such snapshots were recorded and the offset of the peak from the nominal was computed. Figure 5a shows some results for the statistics of these observed offset for data collections at 10 Msps. Here we see an average bias of approximately 20 m, with a variation of ± 30 m. This variation can be explained by the fact that the PPS “slips” with respect to the sampling clock, and at 10 Msps, each sample corresponds to approximately 30 m. This can be seen in Figure 5b where the saw-tooth nature of the delay is apparent, as is its commonality across all satellites in each snapshot.
Note this bias includes all the divergence effects between the nominal pseudorange as measured by the u-blox and observed in the snapshot, including differential group delays and the impact of the ionosphere when considering E6 (because the u-blox measurements are based on E1/L1 only). The consistency of this bias shows Nautilus can be used for signal authentication testing.
Signal Level Authentication
To validate this claim, a simple test was constructed to verify a signal authentication scheme in which it is assumed the E6C samples have been encrypted. The scheme is described in detail in [13], but in essence depends on computing both the correlation function, as shown in the previous section, and the “attack agnostic decision statistic,” denoted ν.
Figure 6 shows the distribution of this decision statistic as measured from E6C signals using snapshot processing with 100 ms snapshots at 12.5 Msps. The figure shows both the observed and theoretical distributions of the decision statistic, which are seen to match very closely. Again, this indicates Nautilus is an appropriate tool for assessing these kinds of techniques. Note also the E6C signal was not encrypted in this case, but the principle is of course the same.
Assured PNT
The final stage is to integrate the OSNMA-authenticated navigation messages with snapshot observations that pass the authentication check to obtain “assured” PNT solutions. Again, the resulting solution is not in fact assured at all as it is based on processing the E6C signal while it is not encrypted, but this demonstrates the feasibility of the approach.
Figure 7 shows the results for a data set collected on April 6, 2021. The data set is divided into two parts. During the first half Nautilus was configured to collect snapshots on E6, while during the second half E1 snapshots were collected. Figure 7a shows the difference in both North and East directions between the u-blox position and that computed from authenticated observations and ephemerides. Note here we assume the snapshots that pass the authentication test are authentic, even if the chips are not encrypted. This is simply as a proof of concept.
Similarly, Figure 7b shows a time history of the vertical and clock differences. Here we can again clearly see the impact of the sliding of the PPS with respect to the 10 Msps sampling clock as the time error varies between -30 and +30 m. Interestingly, there is also an approximate 10 m bias in the vertical, which is likely from the coupling between clock and vertical errors, but warrants further investigation.
Conclusion
In this work, we introduce the Nautilus GNSS authentication testbed. Its utility as a tool for the analysis of NMA and SCE has been demonstrated both in static and dynamic conditions. It is a low-cost, highly portable, highly configurable platform that is intended to be used for authentication, but can easily be configured for other uses like signal quality monitoring or recording snapshots of interesting GNSS signal events such as jamming or ionospheric scintillation.
The tight time and frequency synchronization between the collected snapshots and GNSS time make this simple board a unique and incredibly useful tool for GNSS signal authentication research and development.
Unfortunately, due to the global supply chain issues resulting from the COVID-19 pandemic, the manufacturers of the LimeNET Micro have made the decision to discontinue development of this very useful board. However, the entire board is open-source hardware, with full details available from [8] should anyone wish to manufacture the board for themselves.
Acknowledgments
This work was supported by the European Space Agency under Contract No. 4000120583/17/NL/CRS/hh.
References
(1) European Commission, “Galileo open service navigation message authentication (OSNMA) user ICD for the test phase,” Issue 1.0, 2021. [Online]. Available: https://www.gsc-europa.eu/electronic-library/programme-reference-documents
(2) T. Cozzens, “Tests begin of Galileo’s OSNMA signal authentication service,” GPS World Magazine, 2021.
(3) I. Fernandez-Hernandez, G. Vecchione, and F. Diaz-Pulido, “Galileo authentication: A programme and policy perspective,” in 69th International Astronautical Congress, 2018.
(4) J. M. Anderson, K. L. Carroll, N. P. DeVilbiss, J. T. Gillis, J. C. Hinks, B.W. O’Hanlon, J. J. Rushanan, L. Scott, and R. A. Yazdi, “Chips-message robust authentication (chimera) for GPS civilian signals,” in Proceedings of the 30th International Technical Meeting of The Satellite Division of the Institute of Navigation (ION GNSS+ 2017), 2017, pp. 2388–2416.
(5) O. Pozzobon, L. Canzian, M. Danieletto, and A. Dalla Chiara, “Anti-spoofing and open GNSS signal authentication with signal authentication sequences,” in 2010 5th ESA Workshop on Satellite Navigation Technologies and European Workshop on GNSS Signals and Signal Processing (NAVITEC). IEEE, 2010, pp. 1–6.
(6) European Commission, “Galileo E6-B/C codes technical note,” 2019. [Online]. Available: https://www.gsc-europa.eu/electronic-library/programme-reference-documents
(7) Air Force Research Laboratory, “IS-AGT-100 Chips Message Robust Authentication (Chimera) Enhancement for the L1C Signal: Space Segment / User Segment Interface,” 2019.
(8) “LimeNET micro product page.” [Online]. Available: https://www.crowdsupply.com/lime-micro/limenet-micro
(9) “LimeNET micro gateware source.” [Online]. Available: https://github.com/myriadrf/LimeNET-Micro GW
(10) “CODC fork of limenet micro gateware source.” [Online]. Available: https://github.com/odrisci/LimeNET-Micro GW
(11) D. Franke, D. Sibold, K. Teichel, M. Dansarie, and R. Sundblad, “Network time security for the network time protocol,” Working Draft, IETF Secretariat, Internet-Draft draft-ietf-ntp-using-nts-for-ntp-20, Jul. 2019. [Online]. Available: http://www.ietf.org/internet-drafts/draft-ietf-ntp-using-nts-for-ntp-20.txt
(12) A. Malhotra, A. Langley, and W. Ladd, “Roughtime,” Working Draft, IETF Secretariat, Internet- Draft draft-roughtimeaanchal-03, Jul. 2019, http://www.ietf.org/internet-drafts/draft-roughtime-aanchal-03.txt.
(13) C. O’Driscoll, T. Scuccato, A. DallaChiara, T. Pany, M. Arizabaleta Diez, M. S. Hameed, “The attack agnostic defence: a spoofing detection metric for secure spreading sequences,” in Proceedings of Navitec 2022.
Authors
Cillian O’Driscoll received his M.Eng.Sc. and Ph.D. from the Department of Electrical and Electronic Engineering, University College Cork, Ireland. He was a senior research engineer with the Position, Location and Navigation (PLAN) group at the Department of Geomatics Engineering in the University of Calgary from 2007 to 2010. He was with the European Commission from 2011 to 2013, first as a researcher at the JRC, and later as a policy officer with the European GNSS Programmes Directorate in Brussels. From January 2014 to June 2017, Dr. O’Driscoll was a research fellow at University College Cork. He is currently an independent consultant. His research interests are in all areas of GNSS signal processing.
Gianluca Caparra received a Ph.D. in information engineering from the Università Degli Studi di Padova, Italy. He is currently a radio-navigation system engineer with the European Space Agency. His research interests include positioning, navigation and timing assurance, cybersecurity, signal processing, and machine learning, mainly in the context of global navigation satellite systems.
