How to Prioritize Self-Driving Vehicle Security
Authors: Chris Valasek & Charlie Miller
Hello, Internet. It’s C&C — the guys that remotely hacked a 2014 Jeep Cherokee.
During our employment at Cruise (1.5 years already!), we’ve worked hard on our goal of building the most secure vehicles ever created. Often, we’re asked about the bugs, exploits, and attack research that gets published about the software and hardware that make up a self-driving vehicle. You’ll see statistics about automobiles having millions of lines of code, combined with the fact that self-driving vehicles won’t even have steering wheels or brake pedals, and begin to wonder how we prioritize our security projects.
The short answer is: we come up with a Realistic Threat Model.
We start with our expertise in remotely attacking and obtaining physical control of vehicle systems (along with reading of other groups efforts). Then, we come up with protection strategies for the Cruise Autonomous Vehicle (AV) that strategically utilize our resources to make actual attacks that we care about more difficult.
In this post, we will go over one such example involving our vehicle connectivity.
Considering different attacks
Many times, people send us articles describing GPS spoofing or LIDAR spoofing and ask what we are doing to secure Cruise against these attacks. Many articles state that AVs are at a high risk of attack, claiming that it is relatively easy to stop — or even crash — AVs using these techniques.
People tend to be shocked when we tell them that those types of attacks are not currently our focus. While they are on our long-term radar (AV pun intended) since attacks improve over time, most attacks of this nature do not affect our vehicles due to the way they work and the hardware that we use. To learn why our AVs are unaffected by these attacks, check out our Black Hat whitepaper on securing autonomous vehicles.
So how do we decide to focus our efforts on other projects? We look at the vehicle holistically and determine:
- Which types of attacks have the biggest impact/scale
- How difficult these attacks are to carry out
- How each attack might affect the physical control of our AVs
Using this approach, our primary focus has been on remote attacks that can potentially result in physical control of a vehicle. More specifically, we focus our efforts on attacks that can be carried out remotely from a long distance since these can be scaled up against an entire fleet.
We focus significantly more effort on preventing this type of attack than, say, an attack requiring a malicious physical device to be directly wired into a vehicle. That’s not to say we only focus on remote attacks; rather, we tactically choose how we deploy our finite resources to most efficiently protect our vehicles.
Before we go through our protection technologies, let’s explain a bit more about our vehicle.
Communications between Cruise AVs and the outside world
Each Cruise AV has a telecommunications electronic control unit (ECU) responsible for talking to our internal infrastructure. This ECU can also communicate with the AVs main computer module, which serves as the “brain” of our self-driving vehicle.
To a security practitioner, this may sound terrifying, but we enforce a multitude of security controls to reduce the chances that a compromise can result in persistence or physical control of the AV.
On a network level, we utilize technologies such as private APNs and IPSec tunnels. However, we architect our AVs such that even if an attacker could see our traffic, the vehicle will be safe.
Playing defense
First, we ensure that our vehicles only create outbound connections, meaning Cruise AVs initiate all connections to the outside world instead of responding to inbound connections. We also remove potentially attackable technologies such as Bluetooth and Wi-Fi from the vehicle.
By reducing the amount of attackable code, we make the vehicle more secure and eliminate concerns about the inherent problems of code dealing with potentially malicious inbound data. In the event that technologies such as Bluetooth and Wi-Fi are later needed, we would architect a separate network and device for those use cases.
Our telecommunications device is also resilient against successful attacks by leveraging a secure boot (and update) mechanism and a read-only file system. We have made careers out of hacking the unhackable, so we know that we cannot solely count on a device — especially one that has connectivity — to never get owned. However, in the event of a compromise, we want to ensure that attacker persistence is extremely difficult to achieve (and that we can detect such a compromise has occurred, but that is for another blog…)
But what about the connectivity between the telecommunications unit and the AV brain?!
Good question. Generally speaking, our main AV computer will treat ECUs as untrusted, providing only the minimal amount of access needed. When it comes to our telecommunications device, the main AV computer does not allow inbound communication from the telecommunications device.
All connections between these two devices are initiated by the main computer device. This makes it more difficult for lateral movement to occur from the telecommunications device to the important modules that control the vehicle.
Self-driving vehicle security is not one-size-fits-all
Securing a self-driving vehicle from the outside world isn’t as simple as setting up a firewall. Instead, we take a layered approach to ensure two things:
- Remotely attacking our vehicle over cellular is absurdly difficult
- In the event of a compromise, affecting the physical aspects of our AV are equally as challenging
Any one of these defenses would have prevented the Jeep hack we demonstrated, and in the vehicle we’re securing, we layer a number of these defenses such that any successful attack would have to circumvent all of these layers of defense.
In our next blog, we’ll talk more about what we do inside the vehicle to increase our security posture and mitigate attacks.
If you’re interested in joining our Security team in the meantime, check our open roles — you’ll find us under the “Engineering — Product & Infrastructure” department.
