Inside GNSSEditor’s Note: Logan Scott, a GPS signal expert and a consultant specializing in radio frequency signal processing and waveform design for communications, navigation, and other systems, wrote this report following an incident at the ION GNSS+ 2017 conference in which spoofing by a GNSS signal generator affected numerous smartphones.
Date of Occurrence: September 28, 2017
Location: Portland Convention Center, Exhibition Hall, ION GNSS+2017 Conference
Narrative Description: Starting around 10 am, numerous smartphones began exhibiting abnormal behavior. Some phones showed no effect while others were profoundly impacted to the point where texting, email, etc., would not work. All phones did retain the ability to operate in voice modes. That afternoon, finally recognizing that a spoofing event was in progress, I borrowed a Chronos model CTL3520 directional jamming detector from the NavtechGPS booth (Booth 318), and used it to find and identify the spoofing source within a couple of minutes; it was a GNSS simulator. The simulator had six coaxial output ports, one of which was attached to a “device under test”. The remaining five ports were not properly terminated but had plastic caps over them allowing energy leakage sufficient for phones to lock onto the false signal set for a two booth block radius. The signal generator was set to produce signals for January 12, 2014, with a location set to a location in Europe.
In subsequent interviews I learned that both Android and Apple iPhones were affected but a select phone type (S2) was much more adversely affected since they were alone in buying into the 2014 date. Affected users had carriers that included all the majors: Verizon, AT+T, and T-Mobile, and, cellular coverage was available in the exhibition hall. WiFi coverage was also available with good strength.
Affected phones of several types bought into the incorrect position but I did not receive any reports of them yielding to incorrect time. Nonetheless, recovery was slow. In the screenshot above, my phone was still showing incorrect position in Europe 1.5 hours after exposure. This was discovered after a train ride to downtown Portland when I needed walking directions. Exposure to real signals corrected the problem after about 4 minutes. The long acquisition time was possibly due to faulty almanac and position obtained from the leaky GNSS signal generator. Similar position (but not time) problems were described by several other model phone users.
Affected phones (S2) from one manufacturer experienced much greater impact. Their phones bought into the incorrect time of January 12, 2014 as well. This led to numerous security failures possibly related to invalidated security certificates. Attempts to access email led to “server error” and “invalid attachment” errors. Text message errors and ancient text messages began to appear. Power cycling and hard resets performed in the exhibition hall did not cure the problem. One individual contacted his carrier (T-Mobile) and they sent a time update command to his phone which apparently rejected the command. He went to a service center where after two hours of struggle, they wiped his phone and reinstalled firmware to get to a “factory fresh” state. Another individual was able to manually update time on his S2 phone but only with a bit of ingenuity. Specifically, there was no year entry on the “set date” screen so he rolled time, day by day, all the way through 2014, 2015, 2016 and most of 2017 and then entered the correct time. His phone then recovered. Yet another affected S2 user having an older version of the operating system lost access to his Gmail account and was unable to recover while in the exhibit hall but was able to recover by going outside to clear sky and rebooting the phone.
That said, there are vulnerabilities in basestation authentication that need consideration in developing comprehensive trust models. In this particular case, too much trust was afforded GNSS signals and not enough to the cellular basestation time but this is by no means a universal truth. If instead, this had been an IMSI-catcher scenario, type S2 phones might have been better situated to detect the presence an IMSI-catcher and prevent a trackable response or a man in the middle attack. Trust models are not just a question of black and white.
Copyright © 2017 Gibbons Media & Research LLC, all rights reserved.
