[unoti]

The article is interesting. Take a look at it.

"By putting noise [jamming] on the communications, you force the bird into autopilot... Notably, it's also much easier than trying to crack the encrypted remote-control communications channel. With the drone relying solely on GPS to determine its latitude, longitude, altitude, and velocity, the Iranians then broadcast carefully spoofed GPS coordinates..."

[tlrobinson]

Parent comment says the military uses encrypted GPS, which should protect against this type of attack.

[michaelt]

What do you suppose a drone does if the command channel and the encrypted GPS signal are both unavailable/jammed but the unencrypted GPS signal is available?

In any case, you don't have to be able to decrypt a GPS signal to be able to replay it - you fly a plane 200m above the drone, record whatever's coming over the air from the satellites and you know precisely what would be at the drone's antenna if it were 200m higher. Rebroadcast that at the drone's antenna et Voilà, the drone thinks it's 200m higher than it is.

[alphaBetaGamma]

What your suggesting is going to be tricky to implement. First you can only add delay, not subtract delay, so your specific example will not work: you can not "rebroadcast at the drone's antenna" before the original signal reach the drone.

To overcome this, could record all the gps signals, and rebroadcast them with carefully timed delays. But than gps time as determined by the drone will be different from what a clock in the drone gives, so it could be detected. If you are quick enough it might work, but it's non trivial.

And if the drone uses carrier-phase gps measurements you have a whole bunch of other problems.

Not saying it can't be done, but it's not easy.

[michaelt]

There are commercial products for less than $100 that do this for the L1 C/A signal - such as [1].

You can rebroadcast at substantially higher power than the signal coming directly from the satellite, so the direct signal gets drowned out. After all, the satellite has to broadcast to cover half the world, while you only have to cover a few square meters.

Now, I'll grant the receiver may see a change in signal strength, some cycle slips, and an increase in clock skew. But you get those in normal GPS operation anyway. If you're going to detect GPS attacks and self-destruct your drone you'll want a very low false-positive rate, and I'm not sure that's feasible.

[1] http://www.diplomat.co.uk/products/hardware-products/active-...

[eksith]

That would only work if it had a really silly default similar in a way to "automatically connect to available Wi-Fi network" even when it's unsecured. It's possible the manufacturer may have overlooked something like that, but if it is in a military capacity, I doubt they would have left a gaping hole like that. Electronic countermeasures have been in use for several decades now so jamming/hijacking etc... would have been considerations in the design and they may have introduced hardening against those.

[VLM]

A traditional problem programmers have is thinking the lower "EE" levels are more complicated than they really are. Such as assuming a mid 2010s era level of complication for a two way communication stream in something designed in the 80s for unidirectional listening.

The way GPS works is pretty much like LORAN (well, maybe more like OMEGA) but with embedded metadata. So you've got 40 satellites who know exactly where they are and exactly what time it is and exactly what frequency is the center of their spread spectrum spread, and they're more than glad to tell you all about it. All 40 of them. Maybe you can see a dozen of them at a time?

Anyway you sync up to the SS signal and that gives you a local offset for your clock and your local oscillator and you know the exact orbital position pertaining to that delta-t (aka distance) and delta-f (aka doppler velocity). Now average together a zillion satellites and solve a least squares puzzle for the most likely location for you. Which also feeds out an internal error correction signal for your internal osc and real time clock.

All the .mil signal does is squirt out a slightly more accurate encrypted signal so you need the same key all the satellites use and the key changes rather often.

[makomk]

Traditionally, I believe receivers had to lock onto the civilian GPS signal before even trying to lock the encrypted military GPS.

Besides, encryption doesn't stop you from receiving the existing signal and repeating it with a well-tuned delay, which is all you really need to do to fake GPS...

[VLM]

"I believe receivers had to lock onto the civilian GPS signal before even trying to lock the encrypted military GPS."

That's the old fashioned P(Y) code that they dumped because it sucked and went to the M code that doesn't need P(C) first.

P(Y) code sucked because aside from needing to sync to P(C) first, they fed in the encryption stream at a varying, yet slow enough rate that you essentially got dozens of "known plaintext" packets reporting the same position using the same code. So if you could sync up to the W feed rate, even if you couldn't figure out what it said, you could get a better position after gathering enough data. Then again, for something like a cruise missile while in flight, taking 15 minutes while stationary isn't really all that useful.

The whole design of GPS is an interesting window into tradeoffs between accuracy and time as seen in the 70s. Given enough time you can always average something stationary to ridiculous precision. However the whole thing was designed so strategic weapons in motion couldn't average enough measurements in time to be useful at a strategic weapon level unless you had the .mil keys...

The wikipedia article is kinda interesting.

I currently/used to do stuff in the ham radio microwave bands kinda bracketing the GPS signal, one of those "infinite spare time" projects to program a FPGA to decode my own GPS. Why? Because I can. Right up there with making my own ADS-B receiver which is actually a lot easier on the digital side and about the same level of difficulty on the RF side, more or less.

[shabble]

Have you seen the "Homemade GPS Receiver" project?[1]

I imagine it'd be a whole lot easier if you already have gear to receive and sample the RF side, but still an interesting challenge.

Don't forget to implement CoCom restrictions :)

[1] http://www.holmea.demon.co.uk/GPS/Main.htm

[jevinskie]

I wanted to make a GPS simulator for testing my high altitude balloon's receiver to make sure it works over 15km altitude, or whatever the limit usually is. I think I gave up when I couldn't figure out how I would build the RF side. I think I got the CA PRNG code working. =)

https://github.com/jevinskie/jevps/blob/master/ca.py

Edit: I think I remember the issue. I started out thinking I just had to create a signal at 1.023 MHz, easy to do with an FPGA right? But then I realized that I would need to generate a much higher frequency signal so I could phase shift the different satellite's CA codes before adding them together. Am I correct in my thinking?

[stanfordkid]

Well that would only work if they are using the most simplistic encryption on the planet (i.e an XOR cipher or something like that). In general replaying the same data through an encryption algorithm should not result in the same encrypted result being generated. Thus if you were to replay the existing signal it should decrypt to nonsense.

[VLM]

You've sort of described kind of how some auth systems work around MITM by having a bidirectional conversation with salt while sharing a the same clock and talking about timestamps during their bidirectional conversations. That doesn't work very well in a broadcast environment where your only source of timestamps is the MITM and technology exists such that the MITM sounds just as good, but louder, than the genuine other guy.

You'd be surprised how many people think GPS is a bidirectional protocol like DME/TACAN or an aircraft radar transponder. Its actually a heck of a lot more like the old fashioned TRANSIT sats or VOR or LORAN or OMEGA, with a thin smear of spread spectrum on top to reduce the impact of simplistic jamming and it sends more metadata on top of the nav data than pretty much anything ever invented.

[jevinskie]

The parent isn't talking about MITMing the signal to modify it, just to delay/buffer it. No need to decrypt/encrypt. If you could delay the signals from different satellites by different amounts, would that not also change the position?

[jevinskie]

I would hope the engineers designing the drone would NOT fall back to the unencrypted channels precisely because of spoofing attacks. I would think they would rather have the drone use inertial guidance to get it to a friendly area where its secrets would be safer. It may not be able to land without GPS but it would have prevented it from falling into "enemy" hands. Perhaps even activate a self destruct mechanism(s).