I spent time in January improving my understanding of Global Navigation Satellite System (GNSS) technology and working on lab techniques to test GNSS dependency during security assessments. GNSS is a broader term referring to all satellite positioning systems such as GPS, GLONASS, BeiDou, and Galileo. Our daily experience with positioning systems is usually the “blue dot” on Google Maps. This experience isn’t just GNSS. There are actually a set of technologies which contribute to processing raw GNSS observations into a position estimate. Indoor positioning is even more complicated.

GNSS as an IoT Threat Vector

What we have seen in IoT devices is that even in applications that aren’t positioning focused GNSS technology is “sneaking” into designs. Many cellular modems for IoT applications also include GNSS receivers and all that is required to enable GNSS is an antenna. In applications that are positioning-dependent GNSS receivers are incorporating network services to improve position acquisition time (SUPL) or improve accuracy (CORS, NTRIP).

GNSS hacking and jamming is not new. What we have seen, however, is that developers tend to think that GNSS is too exotic an attack vector for them to be concerned about. The mindset that the military needs to be concerned about GPS manipulation but not commercial applications is probably incorrect.

Many systems are designed or become dependent upon GNSS for time synchronization. The finance industry has had to devote considerable effort to synchronize clocks across high-frequency trading platforms and also maintain evidence of time synchronization (eg. FSMLabs blog post “Introduction to Clock Sync in Finance and Beyond”). What is notable about finance applications is that being able to prove that clocks were synchronized seems to be as important as the synchronization itself.

Precision positioning systems such as RTK use networked GNSS receivers in known locations as reference stations to improve the accuracy and precision of position estimates. Research published in 2012 (GPS Software Attacks, Nighswander et. al.) demonstrated how “…a 45 second GPS message can (remotely) disable over 30% of the Continually Operating Reference Station (CORS) network, which is used for safety and life-critical applications.” This GPS-delivered, in one case, permanently disabled a GPS reference station.

Nighswander et. al. also demonstrated attacks against simple system timekeeping: “…we can cause UNIX epoch rollover in a few minutes, and year 100,000 (the first 6-digit year) rollover in about 2 days. These attacks are carried out via RF, showing the attacks can remotely exploit latent bugs that depend upon time and date…”. Not many systems are likely to have tested failure paths for timekeeping failures such as these.

These attacks were demonstrated using a $2,500 custom built “phase coherent signal synthesizer” which the reader might rightfully consider to be a little exotic. The security minded reader is also remembering that quote (vaguely attributable to the NSA in reference to cryptographic matters) that “Attacks always get better; they never get worse.”

Software-only GNSS Testing

The costs and technical sophistication required to experiment with GNSS technology has also decreased significantly. Software defined radio receivers and synthetic GNSS satellite signal generators has made experimentation with these technologies a software project. Part of my January research was pulling together a software-only GPS “lab” using these projects. I was able to generate synthetic GPS satellite signals:

The generated signal is shown below in this spectrogram:

The auto-correlation chart at the bottom shows a the GPS coarse/acquisition code. This is a repeating signal with a duration of 1ms. The chart shows the synthetic GPS signal correlating with a time-shifted version of itself every millisecond.

Lastly the synthetic signal is processed by a software-only GPS receiver and the time-of-day and position extracted:

Reconsider GNSS as a Threat Vector

GNSS attacks may not be just a “nation-state” level threat given the rapid accessibility of software-defined radio tools and software. IoT devices that process GNSS signals will have some level of dependency on GNSS derived position and time estimates. GNSS signals also bear low bitrate data payloads that deliver satellite ephemeris and other messages. One difficulty of testing GNSS-dependent software is that the difficulty of generating malicious input for the purposes of robustness testing has likely limited the awareness of GNSS signal processing software vulnerabilities.

We may all know, and discount, GNSS-hijacking attacks but have developers thoughtfully considered all of the GNSS dependencies that exist in their system? We propose that it is time to reconsider GNSS as a threat vector in IoT threat models.