 My name is Victor Murray. I'm from Southwest Research Institute. I'm here to tell you today about some of our work with legal GNSS spoofing and its effects on autonomous vehicles. Sound up? Alright. Global navigation satellite systems. Alright, these are constellations of satellites that orbit the planet, broadcast out signals. Your receiver is able to receive those signals and from those signals calculate where it's at on a three-dimensional grid It's used for all kinds of things. Our navigation systems, it's used for Uber and Lyft. It's also used for things like stocks. It's, it's, uh, stamps the time that the exact time that the stock went was traded. It's also used, um, for power lines. Synchrophasers use GNSS to set the frequency of power on a power line. So one of the issues with GNSS is that all public versions lack integrity mechanisms. This includes GPS, Galileo, Baidu, GLONASS. In addition to lacking integrity mechanisms, it's also broadcast with low power. So the actual transmitted power is going to vary depending on a lot of things. Your altitude, the atmosphere, those kinds of things. But for GPS, the typical received power is between minus 120 dBm and minus 130 dBm. So my software-defined radio can broadcast at plus 15 dBm, at least 135 dBm higher than the signal is typically received from the satellites. Additionally, these signals are susceptible to interference. The signals from satellites can bounce off of buildings. They can bounce off of mountains. It can cause errors in your localization estimate. Tunnels and overpasses can block certain satellites and again introduce an error. Similar thing with weather. So how could systems respond to GNSS spoofing? There's been a lot of work on this published, and I'm going to highlight a couple of the key cases that I like. Dr. Todd Humphries is from the University of Texas, right up the road from me. I'm from San Antonio. He's done a whole lot of work getting around GNSS spoofing these videos from YouTube. He flies the drone up, the drone sits in the air. They then spoof the GNSS. Once they get it locked onto the GNSS, the spoof signal, they run the altitude through the roof. And as a result, the drone comes back down. Pretty interesting. Team Unicorn presented here at DEFCON, their low-cost GPS simulator. So with a $400 SDR and with a laptop, they're able to spoof GNSS. They did a lot of interesting things also. One of the cool things they did was exploitation of geofencing. So you don't want these drones in their pre-programmed with areas that they're not supposed to fly, such as military bases. What Team Unicorn did was broadcast the GNSS signal of those military bases and cause them to drown themselves when they're out in an area where they're supposed to be allowed to fly. Another good case study is the Iran hack. They claim to have downed an RQ-170 drone by spoofing its GNSS. I have no inside information, just stuff that I've read publicly. But based on what I've read, it sounds suspect. So there's a whole lot of things that they claim one. They typically would use military-band GNSS, which is encrypted. They're not able to spoof that. If they were, that'd be a huge deal. So they say they jammed that. And then they spoofed the public versions of GNSS. Okay, that makes sense. Then they spoofed the location of the military base, who had to know where the military base was at. Again, okay. Makes sense. Then the plane automatically started its landing sequence and landed right near them. In my experience, which I'm going to tell you about next, I think a similar effect could have happened, even if they had just jammed the signals, which is a very low fidelity attack, much easier to do than spoofing. Not to mention, to get a GNSS receiver to lock on to a spoof signal while it's in flight is very difficult. You notice the drone that Dr. Humphrey spoofed was sitting still when they spoofed its GNSS remotely. So what can happen if systems aren't tested for GNSS issues? I was hired at my company in 2002 to work on drones. In 2006, these two pictures are from an article that was published. I'm the guy on the left. At that time, I was a project manager, and it was my job, part of my job to oversee field support. And as part of the field support, I would look at issues when they popped up. Issues ranged from things like our software flashed up a warning. We made the flight control system and the ground control station, so we made the brains that controlled the drone. So if a warning popped up on the operator's screen, or if the drone lost its attitude, estimation, and deployed a shoot, there's a small shoot on board, or we would look at why, what happened. Or if it lost GNSS, or if it lost GNSS for an extended time. These issues were caused by a couple of things. The first most common was mechanical issues. This is a wire came loose, or an antenna came loose, or a motor went out, those kinds of things. The second most common issue was from sensors. And the most common sensor that had an issue was GNSS. The types of issues I saw when looking at flight data were the planes flying along, and all of a sudden it jumps 200 meters to the right. Or the altitude jumps 50 meters up. So we've also done a lot of other work with sensor security. And that combined with this experience made us think, how can we help build a system that's more resilient to these kinds of events? And they happen, but they take a lot of testing time for you to see one or two of them. So we went and applied for internal research funding. All of the research results that you're going to see that I'm going to present were 100% funded by our company. Alright, so I'm going to tell you about our spoofing system. It has hardware and software components. And I'll tell you about our autonomous vehicle fleet, and specifically the vehicle that was tested. We did a whole lot of testing as a part of this effort, but I'm going to highlight three specific cases because they were the most interesting results. Physician translation, velocity manipulation, and halting the GNSS signal. Then I'll give you our recommendations and some key takeaways. So Southwest Research has an entire department that focuses on research and development for automated vehicles. All the vehicles on the screen are owned by Southwest Research and have all been outfitted with our own autonomy kit. The Lincoln MKZ in the upper right, outfitted with our own autonomy kit, was configured to drive by GNSS waypoints for the purpose of these tests. All the attacks that I'm going to show were performed remotely and in real time. The first word in the title of my presentation is legal. Legal GNSS spoofing. I haven't talked about that. So to be legal, how did we comply? Let me start with what's illegal. Spoofing, not just GNSS spoofing all RF signals is illegal for the Communications Act of 1934. And there's a few things that are allowed. The first is you can get special permission from the SEC. You can do that either via an experimental license or they can give you a waiver under their rules. All of the testing that we did did not use either of those methods. We did not require special permission. The next two we did do. First is you're allowed to rebroadcast inside of a fully enclosed Faraday cage. Second, you're allowed to broadcast in the ISM band. This is 900 megahertz 2.4 5.8 as long as the broadcast power is below one watt. This is the hardware outline. We started by putting our own RTK GNSS receiver on top of the receiver under test. This way we know the position of the receiver at all times. That signal sent there that receiver sends nemes sentences to the computer, the computer can manipulate them or pass them through that manipulation or lack thereof is controlled remotely either via Wi-Fi or cellular. The modified or unmodified signal is then sent from the computer to the software to find radio and it generates the analog GNSS signal and sends it to the receiver under test. There's a couple of ways that we did this. The first was inside the full enclosed Faraday cage. This is a cast aluminum box. We put the broadcast antenna and the receiving antenna inside of that box. We put some RF absorbing material to dampen the sound. And then the other way that we did it was connecting directly in giant with the receiver. All of the testing results that you're going to see use this approach for testing. And we demonstrated the frequency translation as well for the GNSS. Really interesting. So for frequency translation, we put two boxes in between the software to find radio and the GPS receiver under test. We mixed the signal and this focused on GPS L1 band has a carrier frequency of 1.575 gigahertz. We mix it with a 660 megahertz signal, filter, amplify it and move it to the 915 and broadcast it over there the 915. So this is the exact same signal. It's just shifted over to the 900 megahertz. On vehicle, we put a put our box on top of the receiver, receive that 900 megahertz signal and we do the opposite. Filter it the other way, amplify it and broadcast it to the unit under test. The cool thing about this is it lets us take a lot of the heavier weight equipment off of the vehicle. The software to find radio and the computer to be exact. The problem with it when we took it out to the field to test it was it only worked up to about 200 meters. Which if you're driving a car or if we're flying a drone, it's just not a lot of area. We needed a bigger area. And the Wi-Fi and cellular are much easier to expand the networks. I mean Wi-Fi in particular, we'd be on the other side of the state and implement these attacks. And so that's what we did. Alright, this is the controlling software. In the upper left is our software, it's Python scripts. The user is able to click anywhere inside those concentric circles and instantly insert an offset into the signal. That offset can be scaled, it can be 1 meter, 10 meters, 100,000 meters doesn't matter. The buttons at the bottom implement attack scripts. These allow us to speed up the vehicle, slow it down, adjust the timing, adjust the altitude, things like that. The software on the right is commercial off the shelf software. It's Skydell SDX. And that software is used to take the lot long altitude and translate it to the signal that goes to the SDR. Alright, and then the fun part, actual attacks. Okay, so the first is offset attack. For this we were able to move the location of the vehicle up to 10 meters at a time. For this first attack, we move the GNSS to the right 4 meters. And the vehicle responds instantly by moving left and driving off the road. We then remove the offset and the vehicle comes right back. Now understand if you plot the GNSS that's received by the vehicle, it's straight down the road, except when we insert our offsets and remove them. So it's driving straight, it blips over, it corrects itself, but by correcting itself it's driving off the road. But it's GNSS is now perfectly aligned with the road again. So if we tried to move it more than 10 meters at a time, the receiver could not keep locked onto it. And if the receiver loses a fix for more than about a second, it can't navigate the car. It needs constant feedback on its position. And it'll kick out to the driver and ask the driver to take over. And at that point we might as well just be jamming it. It's a lower fidelity attack. Alright, in addition to moving the car left and right, we also could move it forwards or backwards and make the car turn early or turn late. Alright, next we dorked with the velocity. For this demo, the car comes up, it makes a right hand turn and then comes to a stop. For the attack, as the car is coming up, right before it makes the right hand turn, we increase the velocity in the signal. So the signal it's received thinks that the car is driving past where the camera's at. So the car turns like it's supposed to and then it doesn't see a response, it turns harder, turns harder, turns harder, ends up driving off the road. So had we modified it earlier, we could have slowed it down or sped it up and could have made it turn earlier, turn late. It would have had a similar turning motion, turn and then you turn and run off the road. But we could have made it do it before the turn or after the turn. So if we do these attacks when the car's driving straight, it has no immediate effect. And the reason is, is because the speed of the vehicle is governed by the wheel speed, not by the GNSS velocity. The GNSS velocity is a little noisy and it makes a lot more sense to use the wheel speed for that. All right, next is bringing the vehicle to a halt. For this demo, the car drives through the intersection and right past the camera, keeps on going. And this time as the car's coming up, we halt the GNSS signal. You see the car swerve right and then swerve left really hard. So what actually happens there is when we run it to zero, we do that over a period of about two seconds. During that transition, that two second transition, the car drives straight, there's no noticeable effect. But as soon as that signal comes to a stop, the vehicle loses its mind and starts swerving left and right. The control system becomes unstable. We did a whole lot of other tests and one of those tests was delaying the timing. So we just passed through the GNSS signal like normal, but we delayed it a couple of seconds and that had similar results. The control system became unstable. All right, these are our recommendations to enhance safety critical systems. Now when I'm talking about safety critical systems, I don't mean your navigation system on your car. There's no reason. If I smooth through your navigation system, what happens? It's annoying. You might be late or you might not get to where you want to go, but you don't get hurt and your car doesn't get hurt. These recommendations are for systems that use GNSS to make a safety critical decision that could cause damage to a person or a thing. First recommendation is to use multiple constellations. This is the easiest to do. Most receivers already do this, especially the high end ones. The downside to it is it's also the easiest to overcome. I can spoof multiple constellations, as can any other researcher who works in GNSS. Second is you cannot rely solely on GNSS. You can't. It can be spoofed. It's going to be spoofed. It's not if, but when. Third is to monitor the GNSS signal. You can characterize a lot of the things that come from the signal. You have position, velocity, acceleration, the signal noise ratio. You have power levels. All of these things can be characterized. If you see your signal noise ratio jump from 35 up to 55, that's a good indication that you are being spoofed. Specific to autonomous vehicles, there are other localization systems out there. There are ones that are based on vision. There's ones that are based on LiDAR and there's ones that are based on both. Those other localization systems should be compared to GNSS. And if they diverge at some point, the system should be able to respond to that. And finally, we have to test the systems to make sure they respond appropriately to these errors. If the car's driving down the road and its signal jumps to the right or to the left, the car should be able to handle that safely. And the only way to verify that is to go out and test it. Longer term, we need to add integrity mechanisms to public versions of GNSS. This could be digital signatures, public-private key encryption, or some other form of encryption. As demonstrated, we were able to legally spoof GNSS in a field environment. We demonstrated at both of the fully enclosed Faraday cage and over ISM broadcast. So we did lots of cool things to the AV. We were able to move it left, move it right. We could make it turn early or turn late. Or we could cause the control system to become unstable. But that's it. There's significant limitations. When we started this research, we were hoping to be able to make the car think that it's driving down the freeway while it's parked in a parking lot. And it's just not the case. And that's because the car uses other sensors, not GNSS by itself. So GNSS is a great sensor and it should be a part of these critical systems. But as I said on the last side, specific to autonomous vehicles, it's got to be compared to other localization estimates. And I had a lot of help on this work. Dr. Abbott and I co-created the idea for this research. Ben Abbott did, wrote most of the software and performed most of the testing in the field. Jimmy Lee was our RF expert. He designed the enclosed Faraday cage. And he did a lot of other stuff too. This presentation covers a piece of what we looked at. One of the ideas we had was to have a hat that you're able to put on top of a GNSS receiver and spoof it. To do that, that's obviously not fully enclosed. It would require an experimental license. And to get that requires gathering a lot of data. And Jimmy focused on that. And that's my presentation. Thank you guys so much for coming out.