Auto security pros wrangle many attack surfaces in modern cars

The modern vehicle is often equated to a “server on wheels,” but from a security point of view, it’s just as much an Internet of Things (IoT) device that can exploited by threat actors to gain access to other connected systems.

But like a server or a data center, the connected car is full of potential access points, including networking, memory and storage devices that represent an attack surface. And while every primetime crime show in recent years has done an episode about a car being hijacked to murder the driver as part of some nefarious plot, there’s other more mundane ways a modern vehicle can be used to cause mayhem. In the automotive world, security shares the road with functional safety.

Aside from connectivity, what makes automotive security more challenging today is the inherent complexity of the modern vehicle – the systems of connected cars and their electronics are some of the most complex. This complexity is compounded by massive restructuring of vehicle systems architectures, electrification, and autonomy – recent research by IDTechEx forecasts that semiconductors for automated driving will grow at a 10-year CAGR of 29%.

Automotive security has many layers

Securing vehicles goes back further than you might think – long before cars had connectivity or autonomy and electrification were even considerations. SBD Automotive was founded in the 1990s as a technical consultancy – SBD stands for “secure by design,” said Alex Oyler, the company’s director for North America in an interview with Fierce Electronics. “Our heritage is in physical security.” The company has gone from looking at how better to secure cars against theft to addressing cybersecurity and connectivity, he said, and automotive security today has as many layers as an onion.

A cybersecurity team tasked with protecting a vehicle wants to know about the threats to the system, and how the system can be abused that may result in a safety concern or breach of personal data, Oyler said, such as access to content or services or theft of the vehicle itself. Boundaries and thresholds must also be set for individual systems. “If I'm embedding a car with connectivity, that increases my risk by a certain factor because it provides a remote attack path for attackers to access the vehicle from the convenience of their home,” he said.

An electronic control unit (ECU) responsible for connectivity must be secured to the best degree possible at hardware and software level to protect the input and output to that device, Oyler said. But that device is part of a larger, consolidated computing platform in the car. “That becomes a whole different ballgame because it's doing a lot of things at once. There's more software, there are more layers, there's more entry points for attackers and potential things that could be exploited.” Those entry points can be software or hardware, he said, and be a part of many different systems, including those responsible for autonomous driving, electric vehicle motor management or battery management, all of which have their own controllers and components.

At the digital cockpit and Advanced Driver-Assistance System (ADAS) level, cybersecurity must account for data processing that’s connected to the cloud as well as accessing all the systems and services within the car. Oyler said the internal boundaries of the digital cockpit must be especially strict even as third-party developer applications, such as a music streaming, are allowed to run on that system. “That has to be entirely sandboxed from the rest of the system.”

Cybersecurity standards hit the road

Oyler said in the last seven years or so, automotive OEMs have got their act together on cybersecurity, and there’s organizations and standards that have been established to enforce the security development life cycle across an OEM's product portfolio. Most notable is the UN R155 cybersecurity management system requirement, which outlines cybersecurity processes, controls and operations that are necessary to prove that the car was developed as securely as possible, he said.

According to Nina Turner, director of technology supply chain intelligence at research firm IDC, hardware and software standards such as UN R155 as well as the ISO 26262 road vehicle functional safety standard, which defines automotive safety integrity levels, and the ISO21434 cybersecurity standard, among others, are critical as the vehicle becomes increasingly software defined.

In a recent joint webinar with Rambus, she outlined how automobile architecture is evolving to accommodate additional technology and how complexity is driving the need for security within the vehicle as the use of semiconductors increases within the vehicle. “Today's current growth drivers are advanced driver assistance electrification, and the driver and passenger experience.” She said ADAS technologies are becoming more standard, and governments are including these features as requirements to achieve certain levels of safety ratings.

Between ADAS advances and increasing levels of autonomy, there’s an increased need for different cameras and sensors working together, Turner said, and this “sensor fusion” is driving software complexity – hence the creation of the software-defined vehicle. She noted that the Ford F-150 has more lines of code than Facebook, Windows 10, the Linux kernel, and many other systems. “We forecast that the average vehicle in the future could have more than 200 to 300 million lines of code while a level 5 autonomous vehicle could require up to 1 billion lines of code.”

Connected, networked and software-defined vehicles face more vulnerabilities
(IDC)

Not only is today’s vehicle full of code, it’s also full of ECUs that require an extremely complex network of cables to enable the ECUs to communicate with one another, Turner said. Although today’s domain controller architecture reduces the number of ECUs and consolidates similar functions into a single compute module, the tradeoff is that more powerful processors and software are necessary to enable all the functions. ECU consolidation doesn’t significantly reduce the cabling in the vehicle either, she said.

All the data flow, meanwhile, is pushing up memory and storage requirements, and that includes over-the-air (OTA) updates, which must be reliable and secure. Turner said safety and security are important consideration for automakers, but there are challenges in the implementation as they must balance them against speed and agility. Staying with a decentralized architecture creates technical debt, which can slow development and lead to security vulnerabilities.

Consolidation, complexity and connectivity determine attack surfaces

With all its connectivity, Turner said, the digitized, networked vehicle is a vulnerable system with automotive security incidents on the rise. Key attack vectors in 2022 included telematics and application servers, remote keyless entry systems, individual ECUs, and connectivity--whether cellular, Wi-FI or Bluetooth.

Bart Stevens, senior director of product management for security IP at Rambus, said doing threat assessment for the modern vehicle starts by identifying the various vulnerable systems and their attack surfaces. “Vehicles used to be designed as a closed system with fewer attack surfaces.” Fortunately, he said, various industry standards have evolved over time to help security architects select and implement proven methods in a uniform way.

Stevens said a hardware root of trust plays an important role in automotive security. By storing the keys used for cryptographic functions and enabling a secure boot process, a root of trust in hardware makes it immune from malware attacks. A hardware root of trust can either be a stand-alone security module or implemented as a security module within a processor or system on chip (SoC). A silicon-based hardware root of trust can be either fixed function and programmable, while a fixed function root of trust is a state machine, typically compact and designed to perform a specific set of functions such as data encryption, certificate validation and key management. These compact, state machine-based root of trust solutions are particularly well suited for IoT devices.

A hardware root of trust provides a secure location to store and manage security assets like keys and certificates
(Rambus)

In an interview with Fierce Electronics, Jim Yastic, director of technical marketing at Macronix, said automotive security is having to evolve along with the vehicle thanks to autonomy and electrification, which has led to increased electronics content in the car while opening opportunities for semiconductor and networking companies to reimagine their architectures and offer new products. By leveraging technologies that exist in other markets and redesigning them so fewer parts are required, he said, they’re creating a domain architecture that acts as “sensor fusion,” which aggregates a great deal of data traffic.

(The recent IDTechEx research report also noted not only will autonomous vehicles increase the number of sensors in vehicles, but that autonomy is driving up the need for higher-performing sensors, including lidar, with more expensive and more advanced semiconductor technologies.)

Regardless of the analogy you apply to modern vehicles – they’re a smartphone, server, or data center on wheels – automotive OEMs are being mandated to secure data when it’s in transit or at rest through the adoption of standards. “The market is simply reacting to that,” Yastic said. “These central computers require the storage of a lot of keys and credentials.” As a memory maker with a long history in automotive, Macronix must comply with new standards that require it to do authentication on the fly, which makes its architecture more complex even as it becomes safer, he said, while not slowing down boot up so the car starts right away.

The threat to automotive security isn’t just that data might get breached or that nefarious parties might get control of the vehicle and compromise safety, but the intellectual property within the vehicle that enables autonomy and other advanced features is valuable and must guarded against theft, Yastic said. Autonomous vehicles rely a great deal on machine learning models, for example, and they need to be protected from corporate espionage. “The model that they have is the thing they're trying to protect,” he said. “If someone stole the model, they can learn a lot from it.”

As automotive architectures become more complex as they consolidate, there’s fewer attack surfaces (and the benefit of lower power consumption). Yastic said consolidation of compute platforms also makes OTA updates easier, while also providing potentials paths to compromise the vehicle, making the car itself an access point to other systems for threat actors so they can access other servers, he said.

In a smart city, the connected vehicle is another IoT device, which has led to the emergence of the “internet of vehicles,” Yastic said. The car is no longer the target of the attack, but the mechanisms it uses to enable convenient functions such infotainment, software updates and even automatic toll payments are also a means to gain access to other systems via the vehicle. “Interconnectivity is a great thing but an excellent way to enter into a system if it's not properly protected," he said.