There was a time when the only real security concern for vehicle owners was that someone would pop their lock and either steal the stereo, or hotwire the engine and drive off. However, as we add increasing connectivity and the electronic controls that will eventually lead to full automation, the risks become exponentially greater. Cyber security is a very real concern that all automakers and suppliers deal with daily.
There was never much cause for concern around cyber security until the late 1990s; even then, it was closer to 2010 before most people really started paying attention. In the early days, most electronic control units (ECUs) in vehicles weren’t even reprogrammable. The algorithms that ran on those relatively primitive microcontrollers, which powered systems like antilock brakes, were actually encoded right on the silicon dies.
In some cases, a chip could be replaced with modified calibrations for the engine management or transmission. Even when reprogrammable flash memory became available, someone would need physical access to the vehicle and a proprietary diagnostic tool to make changes. At that point, you were more likely to break—or ‘brick’—the ECU than accomplish a malicious hack.
Fast forward to 2020, and the majority of new vehicles have an embedded LTE data modem, Wi-Fi and Bluetooth, and many reprogrammable safety critical ECUs. Within the next few years, nearly all new vehicles will be connected in some way with 5G and vehicle-to-everything (V2X) joining the communication suite. At the same time, more sophisticated, partially automated systems are becoming commonplace.
As we deploy highly automated vehicles (AVs) that can operate without any human intervention, connectivity becomes essential. After all, how can you tell a car to go park itself, or return from the parking garage, or summon a robotaxi if you can’t communicate with it? AVs will also need to download map updates, traffic and road conditions, enable teleassist capability, and more in real time.
Why hack a car?
Who is likely to attempt a hack on a car, and why? There are those who will attack a system just to see if they can do it, and what they can accomplish. Similarly, the vandal may simply be out to cause some seemingly minor trouble, like disabling a friend’s car. The more troubling cases could involve active attempts to steal data or otherwise commit financial crimes, and those involving state actors.
The first confirmed hacks shared with the public came out in 2015, and both were executed by security researchers. A team from the University of Washington managed to get into GM’s OnStar telematics system and show how they could manipulate steering, braking, the engine, and other systems remotely. GM was notified of the vulnerability and corrected it before it was made public. A similar attack was famously executed by Charlie Miller and Chris Valasek on a Jeep Cherokee using vulnerabilities in the Chrysler Uconnect system and wireless provider Sprint. That incident led to the recall of more than one million vehicles to have their telematics systems updated.
The new verification tools used to continuously test flaws in the software could be exploited to inject malicious instructions. Access to code repositories must be controlled and changes must be documented, maintaining a chain of trust
Imagine a scenario in the not too distant future where thousands of AVs roam around a large city, and millions exist worldwide. Each is continuously connected to the others, as well as data centres. What if those vehicles suddenly came to a stop, and a message appeared on infotainment screens demanding payment of one million bitcoins to release the cars? There would be instant gridlock across countless cities.
This is an example of a ransomware attack, which in truth is probably the least of the industry’s worries. What if someone found a way to infiltrate a data centre and send a command to the entire fleet to accelerate as quickly as possible? Or to tell every AV to turn left immediately? The potential casualties in cities around the world could be enormous. This is an unacceptable outcome of the move to take human drivers out of the loop.
What’s the solution?
The first step to a solution is admitting there’s a problem. When the first demonstrations of security vulnerabilities in vehicles occurred around 2009 and 2010, automakers publicly denied a problem existed. By 2015, that had changed. GM appointed its first chief product cyber security officer, Jeff Massimilla, and began creating a team entirely focused on security within its product development organisation.
Several automakers including Tesla, FCA and GM established responsible disclosure or bug bounty programmes, while others had less formalised processes. Responsible disclosure programmes have proven essential in many industries, such as technology, financial services, and aviation. These programmes provide security researchers like Miller and Valasek a pathway to report any vulnerabilities they discover to the manufacturer before they are disclosed publicly. This gives the manufacturer an opportunity to correct the problem, hopefully before bad actors can exploit it. Increasingly, security researchers that have demonstrated an ability to find vulnerabilities receive job offers from the very companies whose products they infiltrate. Miller and Valasek are now responsible for security engineering at Cruise, the GM subsidiary developing its automated driving system.
Like many other industries, the auto industry formed an information sharing and analysis centre (Auto-ISAC). ISACs provide member companies with an organisation where they can share information about security threats and best practices in a noncompetitive environment. In the auto industry, the challenge with cyber security is the long value chain where potential attacks can happen or vulnerabilities can be implemented. Any given vehicle programme has thousands of engineers working on it, with an ever-increasing number of them focused on software and electronics development.
It’s not just the developers and the vehicles that need to be secured: the network infrastructure that manages AVs must be too. Control centres will most likely be the primary attack surface for bad actors
One of the changes within the industry is the implementation of new development, review, and test processes. Rather than approaching security as an afterthought, it must be designed from the ground up for software and hardware. The new verification tools used to continuously test flaws in the software could be exploited to inject malicious instructions. Access to code repositories must be controlled and changes must be documented, maintaining a chain of trust. That documentation is important for engineers working on the software and for regulatory purposes. In Europe, software is included in the type approval process before vehicles can be sold, as well as for after-sales service. Once a vehicle has received its type approval, any software changes that affect regulated systems must go through an amended type approval process.
Notably, this has affected Tesla, which pushes out regular and frequent updates to its customers for many features including its Autopilot driver assistance system. Some features distributed to Tesla owners in North America are not available in Europe because Tesla has not submitted them for amended approval. New development tools are becoming available to automate this process of documenting what has changed.
Systems are needed in vehicles to maintain security. With most ECUs now being reprogrammable, it’s crucial to establish that only verified updates are ever applied. A number of suppliers now offer systems for encrypting and digitally signing software update packages. In the vehicle, the digital signatures must be verified before the updates are applied. Another solution is to continuously check the software against known encryption hashes to make sure it hasn’t been tampered with.
Monitoring systems embedded in the vehicle can continuously monitor all of the message traffic across the vehicle network, looking for anomalies that might indicate either an attack or even just an error. When these anomalous messages are detected they can be blocked, the system can go into a fail-safe mode, and the driver or control centre alerted.
AVs will feature levels of redundancy and diversity in the actuation, electronic, and software systems never used in automotive industry before. With no human driver in place to take over if something fails, backup compute platforms are required. AVs will likely be using backups with distinct hardware architecture and software algorithms that execute similar functionality. This can be used as a verification that the primary compute is functioning properly and also to get the vehicle to a safe, minimum-risk condition if a serious problem is detected.
Ultimately, every honest security expert will admit that it is impossible to absolutely guarantee that any complex system is completely secure. Anyone that says otherwise is lying or deluded. That means that AVs must also be designed to be resilient to attacks
It’s not just the developers and the vehicles that need to be secured: the network infrastructure that manages AVs must be too. Control centres will most likely be the primary attack surface for bad actors. Many networks have been breached over the past decade, from banks and manufacturing to retail and movie studios. If attackers found a vulnerability in a remote operation system or a dispatch platform or map updates, it could spread to the entire fleet.
Best practices need to be implemented at every level of the chain when deploying AVs. This includes designing data and control centres for security from the ground up.
Ultimately, every honest security expert will admit that it is impossible to absolutely guarantee that any complex system is completely secure. Anyone that says otherwise is lying or deluded. That means that AVs must also be designed to be resilient to attacks. Systems need to be put in place to mitigate the risks if anything goes wrong, because sooner or later it will. Redundant and diverse systems are an important piece of the puzzle. So is constant monitoring and rapid response when issues are detected.
If the industry fails on any of these many fronts, from development to validation to dispatch to updates, it will quickly hamper any enthusiasm that the public and regulators have for AVs. However flawed humans are as drivers, malicious actors rarely take control of them remotely. A hack of a social network, department store, or even a bank is annoying and can be costly, but it’s rarely deadly. The same cannot be said of AVs.
As AVs are deployed in the coming years, everyone involved must hope for the best and plan for the worst.
Sam Abuelsamid is Principal Research Analyst, Guidehouse Insights. He leads the group’s E-Mobility Research Service, with a focus on transportation electrification, automated driving and mobility services.