Most likely is the key term...I read your source link, and the link the article supplied as their source (which then referenced a comment on FoxNews) and there appears to be only speculation as to how it happened but no concrete evidence (besides the fact that it was mostly in-tact)
The military possesses control over encrypted GPS.
The military doesn't actually use it, though, for the most part - the keys are sensitive state secrets, and distributing them apparently requires the proverbial man chained to a suitcase level of paperwork.
The encrypted channels are sufficiently underused that drones whose very design is secret that we fly down the Iran-Afghanistan border aren't equipped with them, and so are vulnerable to Iran spoofing a landing-capture course.
Is this symmetric or asymmetric? Seems the keys would only be sensitive if it's the former, given that there (AFAIK) isn't much difference in accuracy between the encrypted and civilian signals anymore. Although, given the very old hardware in the GPS sattelites maybe asymmetric would require too much processing power.
I found an interesting slide deck that talks a bit about spoofing and key management. [0] Apparently there are different levels of classification for keys. (pg 23) But they must be derived keys, right? The satellites are only broadcasting one signal, not multiple signals each keyed to one receiver. I think there can only be one possible cipherstream (and thus one key) in the very low bandwidth signal.
"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..."
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.
Wow, awesome post! I like COTS but I also like soldering and being cheap. =)
I think my main confusion is how do I add the 4 channels together before I spit the signal out to the RF side? If they are all in phase, would it weird out the receiver because you're not going to see that in the real world? Would I have to have 4 output levels corresponding to how many channels are outputting a high level (1) during that chip/clock cycle? If them being in phase freaks out the receiver, maybe I could output the signal at 4.092 MHz and phase shift each channel by 1/4 chip/clock cycle? I was CompE so my RF/signal skills are almost zilch. =)
Good point about the cage, with the crazy low power of GPS signals, it is probably a lot easier to cause interference than with other signals.
They're not going to be in phase. Note that if phase relationship is important, at those frequencies cable length being identical is rather important. But its not relevant to this problem.
One big confusion in the electrical world is people use the same noun for audio "mixers" which are as linear as possible, and RF "mixers" which are as non-linear as possible. They do different things. linear mixers you could say superimpose signals without changing them. Much like pumping up the gain on a CD should not distort the sound on a mic at a "DJ" mixer. nonlinear mixers add and subtract signal frequencies from each other and what came in shouldn't come out at all. in fact a BPSK mod is a kind of balanced mixer, with peculiar TTL compatible (or 3.3v or whatever) levels of course.
You want a 4-port combiner. Most passives have a reciprocal path, a 4-port splitter usually makes a decent 4-port combiner. Think of the gadget that probably splits you cable TV signal in your house. They're electrically and mechanically simple. And relatively cheap. Also they are somewhat lossy. Good luck passively splitting a signal 4 ways with less than 6 dB of loss. And something is warming the resistors in there, so its going to be worse. Conversely yes you combine multiple signals there will be internal loss but the aggregate output will be higher. This is kind of the whole point of a class B or class AB amplifier... what if you took two perfectly good signals, 180 degrees out of phase, and (sorta) mixed them (using baluns), well you get very near twice the power out. Think of putting the whole works in a calorimeter... 4 zero dBm sources will heat it up just as fast combined or separate.
Aviation GPS "around 1.5 GHz" works pretty well despite being feet/inches away from a couple watt radar transponder around 1090 MHz or whatever it is exactly for ADS-B. Physically zorching it sounds unlikely. Distortion to the point of un demod ability is however possible. If you generate enough signal to overload it, attenuators are cheap. High power is expensive. If you're screwing around at "workbench range" you're not going to pay $XXX to generate multiple watts of power so you're not going to need multiple watt rated attenuators to reduce the sig level to something reasonable. Cost scales WAY beyond quadratically, like exponential at microwave freqs for a given tech type. Stuff working around a hundredth of a watt aka 10 dBm is going to be very cheap compared to stuff rated for old fashioned weather radars at kilowatts.
My suggestion is make what amounts to exactly one working satellite. Then make three more.
I don't think you can feed all four digital signals into the same BPSK mod by doing weird things with the clock rate, modulation does not work that way.
What you're building is vaguely reminiscent of a cable TV headend. Both in block diagram and actual wiring. Of course its been a long time since BPSK was cutting edge in CATV. If you think of BPSK as no amplitude modulation and either 180 or 0 degree phase modulation depending on 0 or 1 being input, well, a 256QAM signal is just 16 equally spaced levels of amplitude modulation and 16 equally spaced levels of phase modulation, sorta kinda a grown up cousin of the BPSK modulation in GPS signals. And 256QAM is sort of cutting edge for CATV. Anyway you could do worse than looking at a wiring diagram of a CATV headend WRT mods and digital sources and combiners and such.
Find your local ham radio VHF/UHF microwave club / community. Don't bother with the 160meter low band guys (well, not for this particular individual project, I mean) By the time you're done you'll know quite a bit about RF and might gain a new interesting hobby. Reading several "microwave handbook/project" ham radio books at the library would probably be as good a place to start as any. You could do worse than some chapters of the ARRL handbook to start.
Analog is fun. People will tell you the world is digital, but even their digital ckts are fundamentally analog. And if analog is fun, RF is just magic. A craft not a science at the higher levels.
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).
Obviously no one involved is talking, so it's pure conjecture. Iran had previously captured intact drones though, so it's possible they were able to pull out the keys. Or it's possible that the public GPS was used after a period of having the encrypted GPS jammed (that's the kind of behavior that will never be confirmed).
Finally, it could have just been BS that GPS was what went wrong. That's not a bad guess.
Why do you, non-cryptographer people, think that encrypted GPS is perfectly secure? Pretty much all crypto implementations have flaws (numerous SSL/TLS discovered and fixed over the years, Android package signing, Xbox game code signing, etc.)
GPS encryption was designed 20+ years ago. It is almost guaranteed it has (known and unknown) flaws.
It helps if the opposition is dumb enough to use a predictable route each day such that you've got a known plaintext attack. Then it amounts to playing yesterday's path, very loudly, today, and it'll fly in a straight line thinking its right on course.
Technically you need multiple recordings so you can switch between them to trick it to climb, descend, etc on command.
Also it helps if the opposition insists on not only flying the same exact "known plaintext" route over and over, but using a predictable precise number like 3000.000 meters on that route.
Yeah if they just used their paper charts, logged the position and compared GPS with the dead reckoning (or depth lines, radar shore returns,..) the attackers would have a much harder time... My sailing instructor always stressed that GPS is unreliable and especially when close to danger one should cross check what it says with other methods. Came in handy when my plotter failed.
There is more to it than that though. Aircraft often fly instrument approaches using GPS alone, getting to within 500 feet of the ground while still in clouds. If someone could make the aircraft think it was just a couple extra miles in the wrong direction it could be disastrous.
Counting airports doesn't give you an accurate picture, because just about any airport can have a GPS approach, since the whole point is that it doesn't require any ground equipment. That doesn't mean those approaches get much use, because people don't fly into those airports all that much, especially not on instrument approaches.
I fly out of an airport with a published GPS approach and no ILS, and people use the GPS approach on well under 1% of the total landings there. Any reasonably busy airport will have ILS.
True, they are less busy, but it does not mean GPS is not used for instrument approaches (as parent implied).
I fly airplane without IFR GPS (IFR student), but ATC is trying to assign us GPS approach all the time (when coming into airport with ILS). As far as I understand, GPS approaches are used, even if they are less critical in busier airports. Besides, sometimes ILS is not available in bigger airports as well.
Neither should matter. A visual landing at any airport is pretty much the same, and the basics don't change for different aircraft. There's nothing at all tricky about a visual approach into SFO.
You've got it backwards:
CAT I is 200ft Decision Height (btw, not Minimum Descent)
Cat II is 100ft
Cat III is 0ft (with differing horizontal visibilities for IIIa/IIIb/IIIc
>Limitations
Glide slope station for runway 09R at Hannover Airport in Germany
>Due to the complexity of ILS localizer and glide slope systems, there are some limitations. Localizer systems are sensitive to obstructions in the signal broadcast area like large buildings or hangars. Glide slope systems are also limited by the terrain in front of the glide slope antennas. If terrain is sloping or uneven, reflections can create an uneven glidepath causing unwanted needle deflections. Additionally, since the ILS signals are pointed in one direction by the positioning of the arrays, glide slope supports only straight-line approaches with a constant angle of descent. Installation of an ILS can be costly because of siting criteria and the complexity of the antenna system.
>ILS critical areas and ILS sensitive areas are established to avoid hazardous reflections that would affect the radiated signal. The location of these critical areas can prevent aircraft from using certain taxiways[3] leading to delays in takeoffs, increased hold times, and increased separation between aircraft.
You don't think that the ILS system could be vulnerable to an attack similar to this? The main point of the article is that we rely on tech that is insecure to give us our location and that can be influenced by an outside source. If that outside source is nefarious in nature then we can experience some real issues.
You can hijack it, but there are monitoring systems in place to detect if something is out of place. Also, ATC will usually notice flight path deviations quite quickly, at least on manned airports with radar coverage.
You can interpret that question a lot of different ways.
For example ultralights are pretty much "You're small and light enough not to cause much damage when you crash; don't do anything stupid". So yes, I am quite sure there are heavier-than-air flying machines carrying humans and a GPS unit as their sole navigational tool. As if you need advanced tools for what a ultralight can actually handle in practice, LOL.
On the other hand if you go to the E-CFR and look at FAA reg 91.205 if you want to climb above/thru FL240 you need a working DME or RNAV kinda implies any commercial operation must have VOR-type gear installed.
Note that the same playback hack that works really well on GPS works even better and easier on old fashioned VOR gear.
Merely being required to have operational gear doesn't mean a little angel is perched on each pilot's shoulder making sure they actually do have the gear, and they know how to use it, and they are actually using it.
Okay folks, "just do it manually" is not a solution. This is technology designed to make doing it manually obsolete. We're trying to design systems that can eventually run without human interaction, so saying a solution to this problem is to have a human just do it isn't viable and doesn't make sense and is fairly obvious, to boot.
The story here is that we thought we had designed a system which can do this without human interaction, and now/whenever it was discovered we're realizing we're not done yet. That this can be done by a person with a compass and a map is not a comment worth the text it's written with.
Thats a terrible system design, because all single points of failure eventually fail. Curl up and die is not a valid response to failure. The only valid solution always must end with "do it manually", that can never be removed. Doesn't matter if its a plane, ship, refinery/chem plant, or reactor control rod.
People who don't know much about GPS think the satellites are eternally autonomous but that is not the case. There are precisely two uplink control points on the planet which control them. Both in the USA as I recall.
Another interesting problem is lifetime mismatch. It would be foolish to create a system which depends on and could outlive the current GPS constellation.
Also being in the USA we tend to assume the fedgov is on our side and our side is everyone's side, but the rest of the world has found out the hard way many times over to never assume that is or will always be the case. So absolute best case is you should never deploy a worldwide system with a SPOF controlled by a foreign power.
"The story here is that we thought we had designed a system which can do this without human interaction"
No it was designed for humans (mostly US soldiers) to geolocate themselves, so they could help orient themselves on paper maps. This whole idea of pasting a navigation system, or even worse, an autonomous navigation system, on top is a good example of feature creep resulting in systemic failure.
You probably could design a redundant, tough, reliable, world wide (or at least, wide range) autonomous navigation system. It would not look anything like GPS. It would probably look a heck of a lot like a weird cross between the VOR system and authenticated LORAN. It would take a lot longer than a HN post to nail it down exactly, but I'm sure that whatever it optimized down to, it wouldn't resemble GPS very closely. In the grand tradition of all copier machines being called Xerox machines, I'm sure that whatever this successor system is called, the general unwashed masses will continue to call it a "GPS" to the immense confusion of people who actually know what they're talking about.
A planetary scale authenticated mostly decentralized web of trust mesh network of millions of stationary beacons and mobile inertial navigation systems with computational countermeasures to fight intentional bad actors? Probably providing global internet access via the mesh while you're at it, because it's there?
Just because something is complicated doesn't mean we can't automate it. That's the "curl up and die" solution that you yourself say is not an acceptable response to failure.
And GPS isn't what I was talking about, the automatic navigation system on the $80 million yacht was the system we designed which we thought could be run without human interaction.
And your paranoid delusion that the US can/would use its GPS satellites offensively is just that - paranoid delusion.
Click bait title(same as the article, for what its worth). $80mil yacht uses same GPS as a $80 sell phone, the 6 zeros dont change that.
To the actual issue, i wonder how practical this is? In that i mean what level of power output is required to override the correct signal and at what distance? Is this something that could be a real issue, impractical? What?
First, the fact that expensive machines can be brought down by cheap components is still interesting. Nobody will really care if your $80 cell phone can be spoofed.
Second, GPS receivers are not all the same. There are many different techniques you can use to make your receiver more resilient against spoofing, from cheap and easy things like adding Galileo and GLONASS support to crazy expensive things like adding backup star tracking and inertial navigation systems to cross-check the GPS results.
At the least, one would expect such an expensive ship to cross-check GPS results with internal dead reckoning to reject obviously bad GPS coordinates. That it didn't do this suggests that shipbuilders (or, at least, buyers) aren't aware of the spoofability of GPS. Articles like this make people aware of the problem and its solutions, solutions which simply don't apply to an $80 cell phone.
On the topic of not being aware of the "spoofability" of GPS, it is interesting to note that many of the older Inertial Navigation Systems (GPS + IMU) use GPS to check against the accelerometers and gyroscopes in the IMU. Effectively, they would throw out the results from the internal dead-reckoning system if it didn't agree with GPS, instead of the other way around!
I guess it has more to do with the fact that unless you have a great Kalmann filter design, your IMU will likely drift off course rather rapidly, whereas GPS spoofing wasn't as easy or as popular as it is today (and I would say it really isn't that popular outside of major areas today, as it stands). Either way, you're right, the GPS coordinates should definitely be checked against the internal dead-reckoning. However, then you have to ask yourself how you know the internal dead-reckoning is still on course. It's a tricky problem, and hopefully the solution doesn't just tend towards "add more sensors."
In such a system, what's the point of having the IMU at all? Is it just for the case when GPS becomes completely unavailable?
If I were designing such a system (and I'm sure I've overlooked about a million subtleties), I imagine I would make it so that the GPS corrects the IMU for small perturbations that lie roughly within the IMU's predicted error budget, and that the IMU causes the GPS to be ignored if the GPS coordinates suddenly diverge greatly.
In other words, the IMU is going to be saying something like, "our position is X, to within 5km". If the GPS disagrees with X by 1km or perhaps even 10km, correct the IMU's current state using the GPS. If the GPS disagrees with X by 100km, ignore the GPS until it gets its act together.
That's true. But I think a big reason this story is newsworthy is because the author connects it to what might be a much broader threat:
The scientists who conducted the experiment — done with permission of the yacht’s owners — say their ability to broadcast counterfeit GPS signals that triggered no alarms within the ship’s navigation system highlights a serious flaw in transportation networks on land and sea. Some 90 percent of the world’s freight moves by sea.
The difference between the boat and a cell phone is that the boat is automatically steering a course based on the GPS. It's also relevant that it's a boat because the open ocean provides 2-dimensional movement without obstacles.
Let's say a captain enters a course to stay 500nm offshore of a pirate-infested coast (btw, after Somalia, West Africa is now a pirate hotspot[1]). By interfering with the GPS, the ship could be turned imperceptibly towards shore, and after a day be within range of pirate boats. The GPS display on the electronic charts would still show the intended course, because the GPS thinks it's on the right track. And without any land for reference, the captain or crew might not notice. If GPS is the sole position-finder, the fake coordinates would also endanger the reliability of ship-to-ship collision detection such as AIS[2].
With a cell phone or any consumer device, the user has to constantly read the GPS output and then react to it based on the roads or other physical landmarks. You couldn't just "steer" a person to the wrong place by making the GPS believe it's in a different location. And then I can't think of any other "exploit" that you could do with the GPS on a phone.
As mentioned elsewhere in this thread, the solution to the boat navigation problem is to have alternate sources of position info (Loran, GLONASS, etc.). Alternatively, the error introduced by the fake GPS could also be detected by weather info. Any deviation from the dead-reckoning course (heading and speed) can only be accounted for by wind and current. I believe wind and current forecasts are fairly common for all areas of the globe now, so the calculated values could be compared to the expected values and raise an alarm if they are far off.
GPS signals are below the noise floor, so it wouldn't take much power to spoof them. You just have to get the gold codes correct (http://en.wikipedia.org/wiki/Gold_code).
So a $80 million yatch can't afford an $3000 high quality gyroscope?
Now you could buy amazing laser gyroscopes, for planes the Inertial navigation system error could be great, but for ships(that move more than 20X slower) is not.
Humans, like water, take the easiest route. Unless someone is particularly vigilant and routinely checks the gyroscope to verify the course the GPS is using you wouldn't notice the "hijack" till it was too late. Most people I know wouldn't be paranoid enough to verify their own course against a gyroscope, or any other means of determining coordinates.
True, it could be. If they went to the trouble to integrate the two and develop the solution. But that begs the question: why use GPS? Use the same map information with the non-GPS location calculations that could be automated. GPS is just too convenient...
GPS is convenient, but it has other advantages as well. It's almost always available, it's highly accurate, has a quick time-to-fix, etc.
Inertial navigation systems require finicky setup and drift over time. (Ask the passengers of KAL 007 about that one.) However, the setup can easily be automated using GPS inputs, and the drift can also be corrected that way. This way, you have two systems which help keep tabs on each other. The INS can't be spoofed, and so can tell you when your GPS goes out of whack. The GPS won't drift, and so can keep your INS up to date when it's not being spoofed. Cost aside, two systems are better than one.
Another interesting possibility would be to use a Star Tracker[1][2] for absolute fixes to sanity check GPS / recalibrate the INS periodically. And it has a long and storied naval tradition!
Seems like an experiment contrived to take a trip to the Mediterranean. I can see this being a good bachelors experiment, but if its grad student work, it seems pretty obvious that if you set up a fake GPS satellite, it will skew the coordinates on someones GPS device.
As mentioned in the paper, a simple solution if there is internet connectivity is to verify that the ephemeris is correct. This is how assisted GPS works in mobile phones and the like anyway (the ephemeris and almanac data are downloaded over the network to increase acquisition times).
Even with the mil spec transmissions (which by my understanding have un-broken encryption) you could theoretically somehow block 100% data to a receiver, and forward data with timings you want. So long as you are controlling all of the information you don't need to truly understand the cypher text, you are just interfering with the latency.
However this is based on what I can remember from 12 years ago, before I'd had any formal electronics/signals education so I might have some massive miss-conceptions.
I wonder how this compares with previous 'pseudolite' ideas? The University of New South Wales (et al.) were active here but I think the point was more an augemtation to provide better positioning at GPS-unfriendly latitudes or topographies.
These ran into all sorts of problems, largely to do with the proximity of the pseudolites to the receivers such as synchronisation and signal strength issues. Locatanets (http://locata.com/) are the in thing nowadays.
Do GPS signals not correlate themselves with a compass reading? I would think that comparing the change in coordinates to the external fact would prevent spoofing.
I discussed this with my friend yesterday and wondered about key management with the military GPS channels. Is there a single key that, if extracted* from just one military GPS receiver, could spoof all military signals? Or are there multiple keys, possibly with a revocation scheme? GPS is getting old, what was the state of the art key management back then?
* I'm sure the anti-tamper technology is pretty great.
I am seeing this more and more. I've seen the ability to have a phone take over an airplane, a laptop control a car, now a laptop taking over a ship... where are all the security guys at when this stuff is implemented?
>where are all the security guys at when this stuff is implemented?
It doesn't matter where they are, because where they're not is in management. During development, if attacks like this are even considered at all, its a very low probability incident, isolated to a very small number of targeted units and requires people doing things that can be dismissed by rhetorically asking "why would anyone ever do X?"
Computer security in general is abysmal. It's not for a lack of security guys trying. Good security costs time and money, but the return is practically invisible. The only reason the little bit we have exists at all is either that people have lost money, regulation, or an easy to spot practice has become trendy enough that people will chide others for not following them.
that's sad. I wonder if anyone has done a case study on companies that listen to their IT and implement as much as possible compared to the "let's just make it pass inspection" guys. I know in every cartoon I've seen, the first group wins, but in reality it may truly be worth it to skimp
They jammed communication signals and faked GPS data when automatic "go back to home base" landing procedure kicked in.
http://www.informationweek.com/security/attacks/iran-hacked-...