As autonomous vehicles start appearing on our roads, so the importance of their cybersecurity grows. Self-driving cars and lorries are heavily dependent on communication links to operate safely and perform fundamental tasks. These links to the outside world enable vehicles to receive over-the-air (OTA) software updates, live traffic data, navigation and road sign information, and data from other vehicles. Unfortunately, this means exposing multiple surfaces to hackers for attack. Everything from the wireless vehicle-to-infrastructure (V2I) and vehicle-to-vehicle (V2V) links, to a straightforward USB drive containing firmware can be vulnerable to attack, and these vulnerabilities, if not mitigated, could compromise passengers’ and other road users’ safety.
Making autonomous vehicles safe
For those creating autonomous vehicles, the goal is to make the hardware and software attack surfaces as small as possible. This should form part of a comprehensive safety programme, following a standard such as ISO 26262.
A straightforward method of attack is to connect to the vehicle’s on-board debug (ODB) port, or to plug in a USB drive with malicious software on it. The consequences of this type of attack could be severe, as demonstrated when Uber researchers took control of a Jeep Cherokee’s brakes and steering, using the ODB port.
Real-time protection
To make things more challenging, autonomous vehicle cybersecurity defences need to be capable of dealing with threats in real time, recognizing malicious messages and stopping them from being distributed around the vehicle. This is a tough ask: the nature of threats will always change, meaning security systems need to be kept up to date. This generally requires periodic OTA updates, which themselves create openings for attack. Auto system developers therefore need to make sure their designs are fully protected.
V2V and V2I communication standard
V2V and V2I links typically operate over the dedicated short-range communication (DSRC) standard. In Europe, the frequencies used are 5470–5725MHz and 5855–5925MHz. In the USA, it’s between 5850 and 5925MHz, while in Japan, it’s 5770–5850MHz.
These V2I and V2V connections use encryption, but this in itself raises questions for system designers. For example, when and where do you decrypt a packet of data? One option is on board the vehicle, which means the vehicle can act on the data straight away. However, on-board decryption requires more processing power. An alternative is to send the data to a central server for decryption; this enables greater analysis to take place, but adds latency.
A third way could be to use a combination, with some data marked for instant on-board decryption and other data marked for forwarding to a server. This, however, creates another potential route of attack, because a hacker could send malicious data to a vehicle, marked for instant decryption, which then compromises some of the vehicle’s systems.
And alongside the encryption itself there needs to be a secure authentication layer, to ensure data is coming from trusted sources.
Integrated security products
Various companies are working on ways to secure autonomous vehicles. Infineon and Argus, for example, have been creating an integrated solution using Infineon’s AURIX multi-core microcontroller. The solution links Argus’s Intrusion Detection and Prevention System (IDPS) to a cloud-based platform, thereby creating a single secure gateway to the vehicle’s on-board network. The IDPS monitors for attacks using context-aware heuristic and learning algorithms. The cloud platform, meanwhile, gives car makers easy access to data about their vehicles’ cybersecurity health, as well as tools to analyse attacks and act accordingly. The flexibility of the IDPS means it works with a variety of operating systems, communication protocols and deployment options.
Another example is the collaboration between Mission Secure (MSI), the developer of cyber-defence software, and Perrone Robotics, which makes software for self-driving vehicles. This pilot put MSI’s Secure Sentinel platform through its paces.
Having identified some security weaknesses in cars with wireless technology, the firms set out to tackle these. The vulnerabilities included the fact that car makers couldn’t monitor hacking incidents that had already taken place; there were also insufficient processes to block attacks, and a risk of individuals’ privacy being compromised through the collection of data.
Those in the business of supplying components are also seeking to provide more integrated offerings. For example, Analog Devices (ADI) acquired Sypris Electronics’ Cyber Security Solutions (CSS) division, enabling it to incorporate cybersecurity into its portfolio of self-driving car products. This will sit at the heart of its Secure Technology Group (STG), which will be overseen by Sypris’ former president. STG’s remit will be to use secure software-based cryptography and secure hardware to deliver secure radio communications, while also providing cybersecurity software and services.
For anyone designing or developing any part of a self-driving vehicle, security needs to be front and centre in their minds. Compared to traditional cars, driverless models have much bigger potential attack surfaces, so without suitable cybersecurity, the vehicle won’t be safe. Those behind the autonomous vehicle revolution should think holistically: to create a truly safe environment, every aspect —from roadside assets communicating with a vehicle to the individual connections within vehicles’ controllers— must be taken into consideration.
Pedro joined Mouser in 2011 as a Technical Support Representative in the Barcelona branch. He supports the Customer Service team by searching for alternatives and solutions on customers’ applications. Pedro holds an Electronic Engineering degree from Polytechnic University of Catalonia and before joining Mouser gained work experience in other industries. He has experience in embedded solutions with regard to Dev Kits, such as Arduino, Microchip and Intel, and programming cell phone applications.