Anti-spoofing Techniques for GNSS Receivers
(Project in association with GNSS-SDR)
Global Navigation Satellite System (GNSS) is a primary source of precise positioning, navigation and timing information for a wide-variety of applications like navigation, autonomous vehicles, power-grids, communications, asset tracking and even financial systems. Importance of satellite navigation is ever increasing in safety and security-critical applications. GNSS is capable of providing a robust position, velocity and timing (PVT) solution. However, the lack of authentication in civilian navigation systems, leaves them vulnerable to signal spoofing attacks. In a signal spoofing attack, the attacker transmits specially crafted signals that can force the receiver to calculate a false PVT solution. These specially crafted signals imitate legitimate satellite signals and are powerful enough to overshadow legitimate satellite signals. In past years researchers have demonstrated the susceptibility of these systems to spoofing attacks. Most notable <1> where they were able to modify the course of a ship and <2> where the researchers were able to take over a UAV mid-flight. There are also reports of Global Positioning System (GPS) spoofing in the wild. Eg. <references>. Widespread availability of inexpensive COTS software-defined radios and open source software, GPS spoofing is possible with $100 worth of hardware.
In recent years researchers have proposed various mechanisms to counter GNSS spoofing attacks. The simple nature of GNSS makes it fundamentally challenging to develop security mechanisms that can provide PVT solution authenticity and integrity. The proposed countermeasures are cryptographic solutions, physical layer solutions or logical layer solutions. Each countermeasure solution is capable of providing anti-spoofing capabilities against a specific set of attacks. This GSOC project aims at implementing well-known physical and logical layer solutions in GNSS-SDR, an open-source software-defined receiver that provides signal processing software for multiple satellite navigation systems.
Find the repository here all the files mentioned in this document consider this repository as the base directory
This project focuses on three categories of anti-spoofing techniques to detect GNSS spoofing attacks.
This technique incorporates multiple networked GNSS receivers. Spoofing detection techniques that involve multiple receivers require the development of additional infrastructure which is not available in GNSS-SDR. Hence, these techniques are deemed optional and the decision to implement these will be taken based on the implementation of other techniques.
This type of checks involves checks based on the signal’s physical characteristics like the power level and cross-ambiguity function matrix obtained in the acquisition process.
The power level check observes the prompt correlator output obtained from the tracking loops. This function checks for sudden changes to the prompt correlator value of the tracked signal. This correlator value corresponds to the baseband amplitude of the received signal. In a non-adversarial scenario (no spoofing) this value will not show sudden changes as the TX power of the satellites is constant. However, when an attacker executes an overshadow attack where the attacker’s signals are strong enough to overshadow the legitimate signals, the signal’s amplitude will show rapid changes.
CNo is the ratio of the carrier power and the noise power density expressed in dB-Hz. This value determines whether the receiver can lock on the carrier and demodulate the signal to obtain transmitted data. Each receiver has a minimum CNo value set to determine the quality of the received signal. In case of satellite navigation CNo value is calculated for each visible satellite. In this check, the function compares the CNo values of all the signals received from all the satellites.CNo values of each individual satellite varies as a function of the relative range between the satellite and the receiver. However, if the signals have a common RF source, the C/No values are uniform. This is often the case in case of naive overshadow attacks. The most common way of generating spoofing signals is to use a GPS simulator with an RF frontend. A common RF frontend results in uniform CNo values. A comparison of CNo value can be used to detect such an overshadow attack.
The cross-ambiguity function (CAF) is the magnitude of the correlation between the received signal and the local replica of a specific satellite signal. Acquisition is a process of determining whether signal from a particular satellite is present in the received signal. In this process the receiver performs a circular cross-correlation operation in frequency and time domain. If this operation results in a correlation value (a peak) above a certain threshold, the signal is considered to be acquired. In a non-adversarial scenario, this process results in only a single peak that crosses the threshold value. However, in case of a spoofing attack, there are multiple peaks that cross the threshold value as the attacker transmits signals that imitate legitimate satellite signals. These peaks are defined as auxiliary peaks and tracking such peaks can lead to spoofing detection. In the original work It is defined as Auxiliary Peak Tracking. It is now re-implemented in GNSS-SDR as part of this project.
Logical layer checks consist of model-based checks to determine outliers. These functions check the consistency of receiver observables and calculated PVT solutions with configurable threshold values.
In this type of check, the position consistency is verified by three techniques. Each technique is used in different scenarios.
The receiver is configured to raise an alarm in case any of these checks fail.
This model checks and examines the receiver clock drift and the calculated UTC time for normal behavior. The observables block in GNSS-SDR calculates clock offset and clock drift. In GNSS timing attacks, the attacker constructs the signals such that they drift significantly over time to force the receiver to calculate false timing information. The receiver is programmed to examine the variance of the drift and calculate clock offset error to verify the consistency of clock information. The function also compares the calculated UTC time with an external source to check if the timing solution is consistent i.e., if the timing solution is in the past, present or the future.
All the spoofing detection methods are defined in
Methods are implemented in
The configuration object that store all the spoofing detection parameters are defined as
class defined at:
Majority of the methods are called from the PVT block with exception of amplitude check and TOW check are called from the tracking block and the telemetry block respectively. Spoofing detector configuration parameters are set in the respective block’s adapter alongwith parameters of that particular block.
The spoofing detection report can be obtained from the telecommand interface. For more details check out the GNSS-SDR documentation. Command to obtain the report is “spoofer_status”.
This method calls the get_spoofer_status() method defined in the PVT interface and implemented in the PVT block. This method requires a reference to a spoofer status struct.
This struct stores the results of individual tests performed by the receiver.
Figure 1: Spoofing detection report obtained from telecommand interface
This check is implemented independent of GNSS-SDR. All the functions are placed in
It connects to multiple instances of GNSS-SDR and receives PVT information. It treats multiple receivers as a single constellation and compares its geometry with a predetermined set of coordinates. It performs three types of checks
In case a spoofer unaware of such a setup tries to spoof, it will end up spoofing all the receivers to a single location and as a result all receivers will report the same location.
In this technique the reference coordinates are propagated using the velocity vectors received from the receivers. It uses the propagate_coords() function to propagate the coordinates. It is followed by a proximity check where the propagated coordinates’ proximity to received coordinates is calculated by calculating the distance between the coordinates using the Haversine formula It uses the function get_distance() to calculate the distance. If the distance crosses a set threshold, spoofing is detected.
Here, the perimeter and the area of the polygon formed by the received coordinates and the reference coordinates are compared. The tests allow an error of 1% by default. This can be configured as required.
This check compares the value of prompt correlator with a set threshold. This check is implemented at:
It is enabled by setting SecureGNSS.enable_amp_check=true
This function averages absolute prompt_I value and compares it with an adaptive average and it checks for sudden changes in the average which can occur only in case of a spoofing attack. C/No can also be used to detect such an attack, however, if the attacker is powerful enough to bury the legitimate signals under the noise floor, the C/No values will not be affected as it is a ratio of the carrier power and noise. Thus this test relies on the prompt_I value obtained from the tracking loops.
Figure 1: Prompt I correlator value showing jump in presence of a overshadow attack on PRN 16 (TRACE 4)
This check calculates the standard deviation of C/No values of all the tracked satellites. The check_cno() method accepts a vector of C/No values obtained from the gnss_synchro object. This method is called from the PVT block.
This check is enabled by the SecureGNSS.enable_apt flag in the configuration file. Each satellite is assigned multiple channels, this value can be configured through the SecureGNSS.channels_per_sv parameter in the configuration file. Each channel tracks a different peak as seen in the acquisition plot or the CAF matrix. Eg., if the receiver is configured to run 7 channels, if apt is enabled, gnss_flowgraph will initiate 7 x # of channels_per_sv. The first 7 channels will be primary channels and the rest will be auxiliary channels. Each channel object has a primary channel flag. If the primary channel flag is false there is a value which indicates the primary channel number. Similar changes are made to the gnss_synchro object so that other blocks from the flowgraph can identify primary and auxiliary channels. Similarly each channel is assigned a value that indicates which peak to track. /src/core/receiver/gnss_flowgraph.cc:2702
Once channels are initiated, the acquisition block is responsible for allocating peaks to individual channels. If the enable_apt flag is true, the acquisition block will execute acquire_aux_peak() method.
This method sorts the CAF matrix and assigns a peak based on the peak_to_track value of the channel. For details on this process refer to <code place>. By default the highest peak is assigned to the primary channel. A peak is assigned to an auxiliary channel only if the difference in code phase delays is above a predetermined value that can be configured by setting SecureGNSS.peak_separation=500. This value is in nanoseconds.
The tracking, telemetry and observables block don’t play a role in APT. However, the debug cout statements are suppressed if the channel is not a primary channel.
The final peak separation is calculated in the PVT block at <code place> using the tracking sample counter. The resolution of peak separation depends on the sampling rate. The spoofing flag is set accordingly. If spoofing is not detected, a stop_tracking message is sent to the control thread to reset the auxiliary channel and re-acquire auxiliary peaks. This is done to be able to detect seamless takeover attacks.
By default the PVT block will use the primary peaks to calculate the PVT solution. However, the receiver can be forced to use the auxiliary peaks to calculate the PVT solution. This can be done through the SecureGNSS.use_aux_peak parameter in the configuration file. Moreover, the user can switch between peaks at run time through the telecommand interface. switch_peaks() method is added to the PVT interface to enable the user to switch between auxiliary and primary peaks at runtime.
Figure: (a) Shows presence of a single peak in a non-adversarial setting while (b) shows presence of auxiliary peaks in adversarial setting
All the position consistency check methods are called from the PVT block at <code place>. PVT block calls check_PVT_consistency() which executes rest of the consistency methods
Maximum position jump param. This check compares the distance between consecutive position solutions and compares it with a set of propagated coordinates. This check relies on the last known good location (lkg) value. Every time a position solution passes the check, this value is updated. Future values are then compared with this lkg value.
Velocity estimates are used to propagate (t - 1)th coordinates. The propagated coordinates’ proximity to the (t)th coordinates is calculated. If the proximity check fails, (t)t estimate is considered to be inconsistent.
This method compares the calculated solution with a set of abnormal or infeasible values. These values can be set through the configuration file.
Figure: Comparison of X,Y and Z measurements in non-adversarial and adversarial settings. Spoofing can be observed at 50-60 s mark where the receiver jumps position (TRACE 1)
This method is implemented as implemented in the PNT-Integrity library The method estimates the expected clock offset based on the previously received clock information by calculating the variance of previous clock values. The spoofing flag is raised if the error value crosses a threshold.
Figure: A plot showing projected clock offset error over times (TRACE 4)
Just like position jumps, this check detects jumps in the received TOW value. It compares 2 consecutive values TOW values with respective tracking sample counters. Any TOW manipulation attacks can be detected in such a way. This check also maintains a lkg value. Since this check is performed on each satellite, this check is performed in the telemetry block.
This check compares UTC time obtained from the host and the time calculated through GNSS. It notifies if the calculated time is in the past or future.
These checks are evaluated independently using a variety of GPS spoofing traces generated using open source GPS simulators and TEXBAT (a publicly available repository of GPS spoofing traces) For more information regarding TEXBAT checkout the documentation
*All the traces will be made available on request
This trace contains a naive GPS spoofing attack where there is no spoofing signal for the first 80 seconds after which the overpowered spoofing signal starts. The spoofing signal results in a position jump of 250 m.
Similar to trace 1 but instead of position jump this trace contains TOW jump of 10 minutes
This trace simulates an ongoing seamless takeover attack where the attacker has managed to execute a seamless takeover attack and has deviated the receiver 500 m away from the original location.
Refer to TEXBAT documentation for information.
Refer to TEXBAT documentation for information.
Refer to TEXBAT documentation for information.
Refer to TEXBAT documentation for information.
 Multi-path transmissions are an exception
 Aanjhan Ranganathan, Hildur Ólafsdóttir, and Srdjan Capkun. 2016. SPREE: a spoofing resistant GPS receiver. In Proceedings of the 22nd Annual International Conference on Mobile Computing and Networking (MobiCom '16). Association for Computing Machinery, New York, NY, USA, 348–360. DOI:https://doi.org/10.1145/2973750.2973753