Whilst Global Navigation Satellite Systems (GNSS) spoofing has often been regarded as an exotic, unrealistic GNSS attack scenario, recent events have shown that spoofing needs to be considered as much, if not more, of a threat as interference. The increasing use of GPS signals across different IT enterprise systems also means CIOs should be aware of the issues and how to respond.
Recently in the Black Sea, there have been numerous reports of GPS anomalies affecting ships in the area. The reports suggested that there might have been some sort of signal jamming, or even spoofing going on – and the US Maritime Administration have now issued an advisory notice containing details on the reported disruption:
Reference: U.S. Maritime Alert Message Reference Number 2017-005A.
Issue: During the week of 19 June 2017, a vessel transiting the northeast portion of the Black Sea reported multiple instances of GPS interference. More than 20 other vessels in the same area reported the same interference, which included an incorrect signal.
The interesting part about this advisory notice is the reference to an “incorrect signal.” Whilst no technical details are given, this shows that whatever has been going on in the Black Sea, it was not a straightforward jamming or interference event.
We know that GPS jamming or interference can degrade the performance of GPS receivers to the point where it is possible that misleading information can be output. In 2010, the STAVOG project’s trial in the UK’s North Sea found that receivers affected by GPS interference could report false positional data without generating any warnings to the user.
The existence of an “incorrect signal” implies that highly inaccurate or false navigation data has been received, implying that either the GPS transmissions have been delayed and re-broadcast (this is often called “meaconing”) or a fake GPS-like signal has been generated.
In October 2016, reports started to surface from Russia that GPS users in the vicinity of the Kremlin found that their devices showed them to be located almost 20 miles away at Vnukovo airport. Shortly after, there were reports that GPS users near the centre of St Petersburg suddenly found their devices were indicating a location close to Pulkovo airport. These types of incident reports suggest more than straightforward jamming or interference was responsible for the kind of disruption being experienced.
It is now possible to build a capable GNSS spoofer based on a standard software defined radio (SDR) for less than $500. All the software code is readily available on the internet and can be downloaded to programme an SDR to become a GNSS transmitter, so it can’t be totally ruled out that some of the reported incidents in Russian cities could have been caused by a hacker experimenting with the transmission or re-broadcast of GPS signals. There have, after all, been recent talks at DEFCON on the subject of GPS spoofing, and it is a topic that is attracting a much higher degree of interest these days.
The re-transmission of GNSS signals or broadcast of replica or “fake” GNSS signals over the air often causes receivers or systems to become “confused” and start behaving unexpectedly, even if the are not spoofed. Sometimes the affected receiver will not recover when the source of the replica signals is removed – necessitating a hard reset of the affected receiver or system. This is why developing and testing spoofing detection and mitigation in GNSS receivers should now become a much higher priority for the industry.
GPS signals are now used in a wide range of industry sectors, including transportation and logistics, insurance, finance, telecommunications and even utilities, and this makes it essential to address the growth of interference and spoofing.
An important first step is to understand if and how IT systems use the GNSS signals. GPS was originally conceived to provide positioning and navigation data, but the very accurate timing of the signals means they are now used to synchronize networks, and timestamp financial transactions – to name just two of the many applications.
It is also important to make use of information outside your organization and industry. The reports of disruption in the Black Sea have resulted in a Maritime Alert message being issued by MARAD. This helps to warn GNSS users in the area that they need to keep a close eye on the data being output by their receivers and the navigation system. Whilst the MARAD is clearly not directly relevant to non-maritime GNSS users, the information it contains shows that there is the potential for GNSS disruption in areas adjacent to the Black Sea. Such disruption could affect other industries.
These incidents demonstrate very effectively that openness in reporting GNSS vulnerabilities in the commercial sector will benefit everybody from users to system integrators, and developers to manufacturers.
A third and important step is to assess how your infrastructure will respond to either GNSS interference or a deliberate spoofing attack.
Just as the performance of other IT equipment should be checked to ensure it provides the functionality or security required, GNSS receivers should be assessed to understand how they are likely to behave when subject to the re-broadcasting or faking of GPS signals.
It is relatively easy to measure the performance of other equipment, whether it’s a firewall or a Wi-Fi network, but testing GPS receivers can be extremely difficult to conduct in the real world. The military often conducts such tests on remote test ranges to ensure that civilian users could not be affected, but for commercial users, it can be extremely problematic to obtain the permissions and sponsorship to carry out testing on a military range.
However, it is now possible to conduct detailed simulations of jamming and spoofing effects, which allows the effects to be evaluated without needing to generate an over-the-air signal. For example, Spirent Communications has created a range of GNSS threat scenarios that can be used to test how a receiver would respond and used to provide insight into likely risks caused by GPS interference, spoofing, atmospheric scintillation, segment errors and exceptional events.