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.
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.
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.
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.
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.
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...
"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.
Yeah that project is right at, or perhaps very slightly beyond, my abilities at this time. Which is what makes it such a good project!
My favorite part of this implementation is it shows the cutting edge of modern FPGA development style, where you have soft cores and smart peripherals and the boundary is extremely fluid and blurry between them. Is that in the softcore or "discrete" logic in the FPGA? Well it depends which version of the bitstream you load into the FPGA... In the future this is how all microcontroller and video card and motherboard and such development will be done... you want a different ratio of shaders to anti-aliasing tech, or a new "hardware" supported codec, well just upload a different bitstream... May as well get used to the future of hardware development now rather than waiting.
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. =)
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?
So.. if you can squirt out that C/A stream from your python code at 1.023 megabits/sec all you really are asking for is a COTS BPSK modulator (minicircuits ZFAS-2000?) and a COTS L1 signal around 1.5 GHz to drive the mod.
I have built N5AC microwave synth kits and I did not find it hard, but I've been doing this stuff since the 80s, so... I believe you can buy a COTS ApolLO-I board for your L1 signal. I donno if 1575.50 would be close enough. The smaller the .. forget the name but it boils down to the "tuning step" ... the worse the phase noise. So generating an exact 1575.42 will have MUCH ickier phase noise possibly impacting the PSK data itself. So is it better to have a noisy signal or be somewhat off frequency? I donno. COTS it'll probably have the VFO tuned to be "ideal" for ham radio guys around 1152 MHz but you'll want it a little higher, which it can do with a different smd 0204 sized inductor, but its going to take some soldering not just literally COTS.
There's more than one way to skin a cat and there's certainly a zillion ways to generate a stable-ish microwave signal. For that matter a BPSK mod is not exactly exotic material, but if there's a containerized COTS model for $65 its hard to find the motivation to hack up my own. Maybe you could trade time for money and build one out of 10 cents of junk parts, but it'll take time and gear to align and tune just right.
Note signal levels... You probably can't feed any ole LO directly into any ole modulator and expect the power levels to magically match up. And the levels the mod wants are probably not the levels of "whatever" your P/N code generator is outputing.
Do testing in a shielded cage to avoid an unfortunate appearance on the TV news.
Don't forget that you've just built a C/A generator but without a nav code (at like all of 50 bps, so slow even an arduino could do it...) all you're going to do is confuse the heck out of a RX.... I think... Which might be interesting to watch all in itself. The wikipedia article is hilarious because its kinda disinfo. As if you need to wander around asking weird questions like where to buy a "modulo 2 adder"... umm hint thats a pretty basic logic gate but if you can't figure that out, well... as if an actual devoted adversary would be slowed down by kinda intentionally weird terminology.
I think a harder problem that generating "a" more or less valid C/A stream and "a" more or less valid nav message, is generating them with actual reasonable real world data to simulate being over 15 km altitude or whatever, and them scale it up to do at least 4 of those signals at once.
Probably an interesting noob-level RX countermeasure would be you need at least 4 to get a fix, so lazy people are just going to generate 4, probably in idea geometry with weird unlikely visibility (like the four you hear are all over the sky but just bad luck you can't see another eight, yeah right) Another one would be watching signal strengths, which will vary "twinkle like stars" for real satellites but lazy synthesizers will not vary. Finally unless you go GPSDO (OH the IRONY) synth route, the homemade clocks the RX hears will probably be driftier than the real satellites.
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.
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.
Speaking of OMEGA, there's a Navy training film from 1969 on Youtube[1] which explains some of the theory and is helpful in understanding where GPS came from.
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?
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).
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.