Disrupting GPS - new attack vector

[masloki]

http://arstechnica.com/security/2012/12/how-to-bring-down-mission-critical-gps-networks-with-2500/

Researchers took the usual approach of crafting a spoof GPS signal, but then added a payload that can act like a virus. One neat trick was to add in a divide by zero error forcing a reboot loop. Because many receivers accept input over GPS and internet, they also were able to cause numerous receivers to transmit bad data along the line. As a bonus, demonstrated clock drift on power plant control systems. Whee.

I am in favor of ADS-B, but perhaps we shouldn't be in such a hurry to turn off the VORs.

 

[iflyblog.com]

That's too scary! You're right, maybe we have all our eggs in one basket on this GPS deal.

But I love it so much! I don't want to go back to shooting NDB approaches...

 

[Sac Arrow]

When life gives you eggs in one basket, make an omelette!

 

[N801BH]

......
I am in favor of ADS-B, but perhaps we shouldn't be in such a hurry to turn off the VORs.

And the LORAN C system too...

 

[LDJones]

On a very remotely related topic...power-saving GPS...from same site above...


"Currently, most standalone GPS receivers get Ephemeris information (their current orbital position) and almanac data (the current course information for all the GPS satellites) from the satellites themselves as part of their broadcast. Because of the slow data rate of the transmission—in some cases, as low as 50 bits per second—it can take 30 seconds for a standalone GPS receiver to get the complete information required from each satellite used in establishing a fix, which requires at least three satellites (and optimally, five). In the process, GPS receivers expend a lot of power doing the signal processing needed to lock onto satellites' weak signals and adjust for the Doppler shift of those signals as satellites zoom past in their orbits.

Most smartphone GPS systems and Internet-connected GPS receivers use Assisted GPS (A-GPS) to speed up the process. A-GPS uses the smartphone's network connection to obtain Ephemeris and almanac data over the air and guide which satellites to watch for. Smartphone navigation apps also draw on other location data, including cell tower triangulation and a database of Wi-Fi access point MAC addresses (such as those maintained by Google Maps and Skyhook), to speed up getting a precise fix. Processing all of that data to get a fix can be a big drain on battery life.

But a new approach to handling GPS data takes a big bite out of that power consumption—by offloading all the computation to a server in the cloud, where the computational cost is lower and power is plentiful. In a paper published by Microsoft Research in November, researchers reported that a prototype "cloud offloaded GPS" sensor they developed, called CLEO, pushed raw GPS signal information to a remote server for processing. The result: CLEO was able to generate high-precision location information while reducing the amount of power consumed by the sensor by three orders of magnitude. "In other words," the researchers wrote, "with a pair of AA batteries, CLEO can theoretically sustain continuous GPS sensing (at 1s/sample granularity) for 1.5 years."

 

[denverpilot]

I'm always amazed that any device with a GPS that also has Net access doesn't simply query a public NTP Stratum I server for an exact timestamp, if cold-startup is required, to populate the ephemeris data "close enough" from a table, and circumvent all the drama.

Sometimes engineers only look in their own toolboxes for answers, I swear. Public NTP, even with jitter and latency inherent in the Net, is still plenty good enough to kick start a GPS receiver.

Much of A-GPS is exactly this, it's just using the Network clock source embedded in the cellular protocol. The other information it gets is time zone offset from UTC which isn't available with NTP.

So you'd have to do some threaded checking (try all timezones and see what is sane) to see what's "right" or ask the user. I think the threaded check would be faster than waiting for the slow satellite data, but could be backed by it.

Certainly a GPS engineer could figure out how to effectively wedge the time data into a typical startup algorithm better than I, and it's a tiny bandwidth exchange.

 

[fgcason]

When life gives you eggs in one basket, make an omelette!

That's all nice and cute..until YOU are the omlette.

I'm waiting for the day that GPS is the only navigation equipment available...and someone decides a terrorist attack is in progress (even if it's just a 150 with a flat tire) or some wacko jams the system and shuts down the entire GPS network in the interest of national security..leaving 1000+ airliners in widespread LIFR conditions with no way to find an airport for 27 hours.

People can poo poo VOR's and NDB's as obsolete junk all they want but if someone dynamites one, you just click the frequency knobs and move on to the next nearest one on the map.