When developing autonomous vehicles (AVs), cybersecurity is a fundamental issue that must be addressed from the outset. We need to protect vehicles from criminals both in an immediate, physical sense and protect the code and software that they run on.
We need to protect AVs against a wide range of threats, which vary in scope and technical sophistication. There is a variety of potential attack vectors for AVs, with harmful consequences if criminals are able to either sabotage a journey or access the data that an AV produces, for example. That is why AVs and the systems they rely on and interact with must be guarded with effective defences which are in-built into the system architecture from day one.
To properly protect AVs, first we need to understand the threats. Some of the main challenges that should be taken into consideration include the potential for an individual or group to:
- Gain access to the AV’s code through physically hacking the car, and therefore inputting/rewriting the code to suit their own purpose
- Tamper with sensor input or one component in the vehicle which then misinforms another and alters the car’s behaviour
- Gain access to the software before it is loaded onto the vehicle with the aim of modifying the code. If this happened in advance of an over-the-air (OTA) update and not detected, the malicious code would be pushed to many AVs
- Launch a ‘one to many’ attack where one car is compromised, then used to gain access to other cars
- Obtain GPS reports and live location data from the vehicle
- Hack into server data and use this for information on the vehicles and/or its users
- Breach the internal networks of AV companies in order to use them to gain access to vehicles or associated systems
Companies developing AVs are aware of these risks, and we have been working hard to address them from day one to ensure that any and all potential threats are mitigated. Key to this aim is ensuring that cybersecurity is inbuilt, that it is addressed right from the beginning of the development process.
For instance, we had to develop a secure cryptographic verification model which verifies our software at each stage of its development through to deployment. This means that we can ensure that the code hasn’t been changed after it has been finalised.
In terms of physical cybersecurity, the AV systems we fit to our vehicles use tamper resistant hardware security modules (HSM). Within the HSM, there will be a key which is used to verify the software on the vehicle. Each time the vehicle is started it will run an verification process to ensure that the code and systems are unedited and operating as designed. Attempting to gain physical access to the hardware will damage the chip beyond the point of usability.
Of course, there are also legitimate reasons for certain people to want access to an AV or its control systems. For instance, emergency services might want to shut down a vehicle which had been commandeered by an unauthorised party. Enabling such a system would be potentially problematic, in the same way that any back door is open to misuse. Just as protection should be in place for preventing unlawful access to AVs and its technology, any system put in place to enable law enforcement to take control of vehicles would need to be subject to hugely rigorous checks and balances — measures which could even offset the usefulness of such a system in the first place.
At this stage, cybersecurity is not being given due prominence in the industry. Automakers and software developers have, historically, been too focused on trying to solve the problem of autonomy, rather than keeping cybersecurity front of mind. Five’s view is that you need to engineer cybersecurity as something which is central to the product from day one, because security will affect the entire development of your AV and the associated technology and systems.
The situation around security in the AV industry is not unusual throughout the technology space; where security is something that gets pushed back when delivering a particular product as it can often be seen as a barrier to innovation. Security engineers have a specific set of skills, but they must also be able to work with the software engineers so that cybersecurity and development go hand in hand from day one, and work together rather than against each other.
Security engineers should be fully embedded into the development team from the outset of projects. To ensure the holistic security we need to protect AVs, we must ensure that knowledge is not siloed and a common goal is in sight for everyone. Only then will we create a safe and secure future for AVs.
