View source for Projects:2019s1-166 Reliability and Trust in Global Navigation Systems

== Project Team ==

*Liam Shelby-James

*Stefan Norman

==Supervisors==

*Dr Matthew Sorell

*Dr Richard Matthews



__TOC__

==Introduction==

Global Navigation Satellite Systems (GNSS) are a ubiquitous & essential tool across many platforms and systems in the modern era. Many systems, and in fact, industries rely on these satellites for positional or timing data, and for this reason, GNSS requires protection & verification. Due to this reliance, it comes as no surprise that attacks on GNSS are of growing concern in cyber warfare. 
For example, in 2013, academics in the Mediterranean Sea took a yacht off course without being detected <ref name=Humpfries1>J. Bhatti, T. Humpfries, “Covert Control of Surface Vessels via Counterfeit Civil GPS Signals”, Journal of the Institute of Navigation, 2014</ref>.  In early 2019, also, Russian intelligence has interfered with NATO military training, and elsewhere throughout Russia, Crimea & Syria <ref name=C4ADS>Above Us Only Stars – C4ADS. [Online]. Available: https://www.c4reports.org/aboveusonlystars. [Accessed: 10-Apr-2019]</ref>.

Over-the-air attacks come in three main varieties: jamming, spoofing and software attacks.

'''Jamming''' refers to a brute force Denial of Service (DoS) attack where noise is generated and broadcast on GNSS frequencies, making it difficult for any receivers to separate and decode any data.

'''Spoofing''' is a more targeted attack whereby false signals are transmitted to imitate genuine GNSS signals and can result in erroneous positions being displayed. If the signals are tailored to a specific receiver’s location, this can then be slowly adjusted to bring ships & aircraft off course without any obvious indication to the operators <ref name=Humpfries1></ref>.

'''Software attacks''' are not attacks on GNSS directly, but rather the software implementations of GNSS receivers. For example, sending malformed requests, or exploiting known bugs in the software <ref name=Nighswander>T. Nighswander, B. Ledvina, J. Diamond, R. Brumley, and D. Brumley, “GPS software attacks,” Proceedings of the 2012 ACM conference on Computer and communications security - CCS 12, 2012.</ref>.

Using these attacks individually or in combination may allow an attacker to disable or alter the location returned by a GNSS receiver, which may be intended to disrupt or disorientate the victim.

==Objective==

Our objective is to formulate a framework that determines how trustworthy the current GNSS location data is and to create a simple user-friendly metric using this framework to display to a user. A secondary objective is to implement the metric in an Android app, utilising low-level GNSS data made available in recent chipsets <ref name=android-gnss>“Raw GNSS Measurements | Android Developers.” [Online]. Available: https://developer.android.com/guide/topics/sensors/gnss. [Accessed: 10-Apr-2019].</ref>.

==Related Work== 

The focus of our research is primarily the detection of GNSS spoofing. There are several studies investigating these methods of spoofing detection, which range in their effectiveness, depending on the complexity & kind of attack. However, it is not clear if existing receivers are advanced enough to detect sophisticated attacks, as many of these methods are mathematically intensive.
The most fundamental approach is to detect satellites that have suspiciously high-powered signals, which may eliminate the simplest of spoofing attacks from malicious parties that just want their targets to lock on to their signal <ref name=humpfries2>T. Humpfries, B. Ledvina, M. Psiaki, B. O’Hanlon, P. Kintner Jr, “Assessing the Spoofing Threat: Development of a Portable GPS Civilian Spoofer”, In Radionavigation laboratory conference proceedings, 2008.</ref>. This method will fool the most rudimentary receivers that simply prioritise the strongest signals from a single constellation (constellation here means each system of satellites run independently by different organisations, eg; GPS, GLONASS, Galileo, etc.).

More rigorous methods include measuring the incoming signals’ phase difference to determine the approximate direction of the signal source, as different satellites will be in different areas of the sky <ref name=double-difference>Y. Hu, S. Bian, B. Ji, J. Li, “GNSS Spoofing Detection Using Fraction Parts of Double-Difference Carrier Phases”, The Journal of Navigation, 2018</ref>. Some of these methods, such as cryptographic authentication, are computationally intense, as they utilise statistical hypothesis testing <ref name=humpfries2></ref><ref name=humpfries3>K. Wesson, M. Rothlisberger, T. Humpfries, “Practical Cryptographic Civil GPS Signal Authentication”, Journal of The Institute of Navigation Vol. 59, 2012</ref>. Some receivers will prioritise satellites which report being in different locations, as Geometric Dilution of Precision (GDOP) states that satellites in close proximity of each another will not provide as precise location data <ref name=gdop>“GPS Accuracy: HDOP, PDOP, GDOP, Multipath & the Atmosphere,” GIS Geography, 24-Feb-2018. [Online]. Available: https://gisgeography.com/gps-accuracy-hdop-pdop-gdop-multipath/. [Accessed: 10-Apr-2019].</ref>.

==Method==

Google has developed a GNSS Analysis suite targeted at application developers, which consists of an Android app (GNSS Logger) to capture raw GNSS data, and an analysis tool in compiled MATLAB code <ref name=android-gnss></ref>. This analysis tool provides a wide array of graphs and statistics that can be used to characterise and analyse the captured data, as seen below. This does not demonstrate all of the data collected by this tool however, as additional data such as Automatic Gain Control (AGC) is also recorded and can be useful for spoofing detection.

Screen capture from GNSS Analysis (Google.)

[[File:2019s1-166-gnssanalysis.png | 500px]]

The left column shows satellite data, from top to bottom; the strongest satellites from each constellation, each satellite’s signal strength over time, and the rough location of each satellite in the sky. The centre column shows clock & timing data, again from top to bottom; the distance from user to each satellite (called “pseudorange”), over time, how much the receiver's clock’s frequency must be changed to correct timing over time, and how much it has changed over time. Finally, the third column contains calculated data, including; variation in position, the magnitude of errors in pseudorange over time, and the number of errors in pseudorange over time.

We have used this GNSS Analysis suite as the basis for our data collection and analysis as it requires no translation to implement in an Android app and provides for easy integration into an SQL database for scalable analysis.

However, in order to test our program, a method to broadcast our own GNSS signals is required. Due to strict regulatory requirements and to avoid interfering with the public, these signals must be broadcast in an electrically shielded environment <ref name=acma>Australian Communications and Media Authority, “Devices prohibited by the ACMA,” 10-Feb-2019. [Online]. Available: https://www.acma.gov.au/Citizen/Spectrum/About-spectrum/What-is-spectrum-and-why-you-need-it/devices-prohibited-by-the-acma. [Accessed: 10-Apr-2019].</ref>. Shielding the testbed is a non-trivial problem, and we plan to solve this with a rudimentary grounded Faraday cage fabricated from sheet metal, and lined with copper mesh for conductivity.

Several Software Defined Radio (SDR) transmitters have been investigated, but many have a significant expense (from AU$300 to AU$2,000) which due to budgetary constraints would limit testing to a single transmitter <ref name=bladerf>“bladeRF 2.0 micro,” Nuand [Online]. Available: https://www.nuand.com/bladerf-2-0-micro/. [Accessed: 31-May-2019].</ref><ref name=hackrf>“HackRF One,” Great Scott Gadgets. [Online]. Available: https://greatscottgadgets.com/hackrf/one/. [Accessed: 10-Apr-2019].</ref>. After using a high-quality transmitter to provide a reference transmission, we are using several USB to VGA converters (approximately $10 each) which can be hacked with open-source software to become a crude transmitter <ref name=osmo-fl2k>“SDR (Software Defined Radio) » osmo-fl2k,” Steve Markgraf. [Online]. https://osmocom.org/projects/osmo-fl2k/wiki/Osmo-fl2k, accessed on: 10 Apr. 2019</ref>. This hack utilises higher harmonics of the 165 MHz VGA digital to analog converter, which can create undesirable interference. However, as this will be tested inside an isolated environment, this is not of concern.

In order to provide a realistic testing environment, real-world GNSS signals must be injected into our container in near real-time. There are several GNSS simulator tools capable of transmitting realistic signals for this purpose, as well as simple hardware repeaters to replicate signals received outside the containment, and at the time of writing, we are still investigating them <ref name=osqzss>Osqzss, “osqzss/gps-sdr-sim,” GitHub, 28-Oct-2018. [Online]. Available: https://github.com/osqzss/gps-sdr-sim. [Accessed: 10-Apr-2019].</ref>. 

==Preliminary Results==

We have identified several key concerns to be analysed from the raw GNSS satellite data in Table 1 below. The table contains descriptions of spoofing detection methods, and what data sets they must be analysed against to detect suspicious results. 

“Absolute” here means that a satellite’s data is compared to a numerical constant, or set of constants, and not other satellites. The column “Self” refers to whether each satellite’s data is compared to its own historical data, as collected on the device. The “System” column indicates the satellite’s data is analysed with respect to other satellites in the same constellation. Finally, “All”, applies to data that will be compared to all satellites in range.

{| class="wikitable"
|-
! Title and Description of Method
! Absolute
! Relative to Self
! Relative to System
! Relative to All
|-
| '''Satellite ID exists:''' checking to see that every SVID that is received is an actual, in-operation satellite
| [[File:13px-Green_check.png]]
| [[File:13px-Dark_Red_x.png]]
| [[File:13px-Dark_Red_x.png]]
| [[File:13px-Dark_Red_x.png]]
|-
| '''Satellite is in the expected location:''' if the satellite with the given SVID should be reachable in this part of the world
| [[File:13px-Green_check.png]]
| [[File:13px-Dark_Red_x.png]]
| [[File:13px-Dark_Red_x.png]]
| [[File:13px-Dark_Red_x.png]]
|-
| '''Duplicate signals from the same SVID:''' if a single SVID appears more than once from different sources, at least one of these is unauthentic
| [[File:13px-Dark_Red_x.png]]
| [[File:13px-Dark_Red_x.png]]
| [[File:13px-Green_check.png]]
| [[File:13px-Dark_Red_x.png]]
|-
| '''Unexpected distance jump:''' when spoofing occurs, there may be a single, sharp position jump that is obvious
| [[File:13px-Dark_Red_x.png]]
| [[File:13px-Green_check.png]]
| [[File:13px-Green_check.png]]
| [[File:13px-Green_check.png]]
|-
| '''Time variance/jitter:''' if the timestamp given is delayed, this can indicate a man-in-the-middle attack . Also, if the clock bias is noticeably large, this may indicate the spoofing device is not as reliable as the atomic clocks used by satellites
| [[File:13px-Dark_Red_x.png]]
| [[File:13px-Green_check.png]]
| [[File:13px-Green_check.png]]
| [[File:13px-Green_check.png]]
|-
| '''Time of arrival:''' if multiple signals are consistently received instantaneously, they are likely from a single spoofer device
| [[File:13px-Dark_Red_x.png]]
| [[File:13px-Dark_Red_x.png]]
| [[File:13px-Green_check.png]]
| [[File:13px-Green_check.png]]
|-
| '''Power of signal:''' if a certain set of satellites’ signals are well above others, or if signal strength was slowly increased over time
| [[File:13px-Green_check.png]]
| [[File:13px-Green_check.png]]
| [[File:13px-Green_check.png]]
| [[File:13px-Green_check.png]]
|}

If there are any malicious signs detected during data analysis, flags will be raised ranging in level with respect to the severity of the observed interference. Based on the number of flags and their impact, the application will utilise our framework to place a value on the level of interference, which will manifest in a certain colour grade, as per the table below. These are the key results of our research, and we expect this kind of algorithms will be most useful for transport companies, but also eventually more widely by the public as well as defence as a rough estimate on the type of interference in the area.

{| class="wikitable"
|-
| Purple
| <span style="color:purple">&#x2B24;&#xfe0e;</span>
| Encrypted (typically defence)
|-
| Blue
| <span style="color:blue">&#x2B24;&#xfe0e;</span>
| Authenticated (e.g. GALILEO 2019+)
|-
| Green
| <span style="color:green">&#x2B24;&#xfe0e;</span>
| No suspicious activity detected
|-
| Yellow
| <span style="color:yellow">&#x2B24;&#xfe0e;</span>
| Suspicious activity 
|-
| Red
| <span style="color:red">&#x2B24;&#xfe0e;</span>
| Inconsistent; signal unverifiable, may be heavy interference
|-
| Black
| &#x2B24;&#xfe0e;
| Device compromised; the device is using a false signal
|-
| White
| &#x25EF;&#xfe0e;
| No/insufficient signal detected (environmental or malicious)
|}


= References =
{{Reflist}}