Data Security Challenges In Automotive

Automakers are scrambling to prevent security breaches and data hacks in new vehicles while simultaneously adding new and increasingly autonomous features into vehicles that can open the door to new vulnerabilities.

These two goals are often at odds. As with security in any complex system, nothing is ever completely secure. But even getting a handle on this multilayered issue is a challenge. Vehicle architectures today, and those being developed for future vehicles, are increasingly complex and often beyond the control of any single company. They involve both hardware and software components, with data generated and processed at multiple levels and in multiple places — within a vehicle, between different vehicles, and externally in connected infrastructure. Some of that data is critical to the functionality of the vehicle and tightly controlled, but even less-critical data can provide a potential attack vector.

“If you have a fully autonomous and connected vehicle, and somebody can hack into the car and take control, then all of a sudden it becomes almost a weapon,” said Robert Schweiger, director of automotive solutions at Cadence. “That’s why OEMs and the whole automotive industry are super sensitive about this topic. If there is no security, all the fancy ADAS technologies will not see consumer acceptance. Security is paramount and super important.”

Those concerns are being echoed across the chip industry. “We have many challenges with vehicles today because there is an increasing amount of advanced driver assistance systems that require a lot of electronic control units,” noted Thierry Kouthon, technical product manager at Rambus. “All the functions of the car that in the old days were mechanical or hydraulic are now computerized. Otherwise, you cannot control the car by computer. But this also provides attack surfaces for hackers. Infotainment systems are a great entry point for attacks due to a number of wireless connections to the vehicle. At the same time, there is the electrification of vehicles, which multiplies the number of electronic control units in those vehicles. There are fewer moving parts, but more electronic parts, which represents an increased attack surface. Finally, autonomous vehicles by nature don’t use driver interaction, and therefore need even more advanced electronic systems.”

Fig. 1: Potential security risks in vehicles. Source: Rambus

Data security in any electronic system is difficult. But within a vehicle, that data needs to be moved, stored, processed and updated.

“When we look at cybersecurity and all the aspects that revolve around cybersecurity — data in transit, data that’s moving from point A to point B, data at rest that’s being stored in the vehicle or outside of the vehicle but is in one form or another associated with the vehicle — what’s the risk to store it?” asked Chris Clark, senior manager in Synopsys’ automotive group. “What’s the risk to transmit it? What’s the risk of even using this data, and should it be used? That’s the gold standard today for how organizations look at that.”

The automotive industry has made some progress in securing data over the past five years, but it still has a long way to go.

“We’re learning how to really talk about cybersecurity — maybe not in a meaningful way, but we’re starting to use the same terms,” Clark said. “We’re looking at what one industry does compared to another, and whether we can utilize some of what they have learned to really make progress around security to protect an organization and to protect the consumer. But unless there’s regulation, the cybersecurity activities and processes are there to protect an organization, not necessarily the individual.”

This is complicated by the fact that in vehicles there is a growing overlap between security and privacy. The more that data is protected, and the more autonomous features in a vehicle, the more it potentially infringes on privacy.

“Does my car manufacturer or whomever is providing a service know what I’m doing? Given what has happened with social media, people are going to be trying to monetize that data,” said Jason Oberg, CTO of Tortuga Logic. “In the case of car insurance, this is already happening. But you can imagine getting certain ads based on where you’re driving. Maybe you go to McDonald’s all the time, and they can detect you’re doing that, so you start getting Instagram and Facebook and Google ads saying, ‘Here’s this new sale at McDonald’s.’ Or if you’re at the airport and they know you like to travel, they may give you targeted ads about travel. That is probably inevitable.”

This is potentially much more serious than a simple annoyance. “If a ‘zero day‘ vulnerability is found in all the cars manufactured with the same authentication keys, or something is actually baked into the parts of the car and someone figures it out, then they can go spy on their neighbor’s car or their neighbor’s driving behavior, or any car of that model,” said Oberg. “If it’s a social media platform, there’s not a physical device. You log into a system, and there’s infrastructure to protect that. But if it’s a physical device, that attack vector is now open. Having physical access, finding hardware vulnerabilities, these kinds of things are now viable attack vectors to get that information.”

For hackers, there is good reason to tap into that data stream. It can open the door to IP theft for the technology used in those vehicles. At the same time, the personal data being stolen is increasingly valuable, and more of it will be added into vehicles over time.

“It’s very conceivable that your car would have an Apple Pay type infrastructure, or something that would store information locally in the automobile,” Oberg said. “Or maybe it’s some biometrics data, and that’s stored locally on the hardware in that vehicle. Now there’s a viable attack vector potentially to exploit that type of data. And as we get more distributed IoT devices and more stuff being collected about people’s personal behaviors, then the device itself now becomes a viable attack vector. We’re going to see more of that happening with direct consumer impact from these types of issues. There are not a lot of cars collecting personal information yet, but there will be. It’s like anything in security. As people start adding more autonomy, collecting a little bit more info about people’s driving behaviors or whatever they may be doing in their car, that is going to have some exploits. Then they’re going to get fixed. It’s an iterative process. The interesting thing about a car is that, depending on the severity of the attack, you may not be able to issue a software patch. It may be more ingrained in the behavior of the car, so you potentially might not be able to fix that. Over time, hopefully we get more security around how the car collects data and how it’s protecting it, but there’s going to be a learning process, for sure.”

More attack vectors
Vehicle-to-everything (V2X) — where the vehicle communicates with the traffic lights, other vehicles, even pedestrians, and the network in general — adds yet another potential attack vector While this is more of a forward-looking issue, it needs to be considered now. Compounding this, with V2X-enabled cars will need to communicate with non-V2X-enabled cars, or older versions of that technology, due to the long lifetimes of vehicles.

“What that means is that you want to make sure the communication protocols used work together,” Kouthon said. “Everything is wireless, and there are two main standards — 5G/cellular network-based and DSRC, which is based upon direct radio frequencies between cars. All those are almost interchangeable, and maybe both will work. The real issue is that, since you don’t have any physical connection and you are communicating wirelessly with your environment, you have to make sure that all those messages are authentic. You need to know that if the traffic light is telling you that it’s turning green, it is actually the traffic light and not a hacker trying to cause an accident because you’re not paying attention. That becomes an authentication problem. Authentication means that all the messages are signed with a signature, so the car can verify this message originates from a genuine source, and that it’s not a fake traffic light or rail crossing infrastructure. It needs to be a genuine one that is actually run by the city.”

Things get even more complicated when messages are received from other cars, because now all the manufacturers have to agree on a set of protocols so each car can recognize the others. Work is underway to make that happen, so that when a BMW or Chrysler communicates with a Volkswagen, the Volkswagen can make sure it’s a real BMW or Chrysler.

“That becomes a problem of certificate distribution,” Kouthon said. “It’s an old problem that has been very well studied in the context of websites on the internet, and usually it’s pretty complex. Certificate chains can be very long. In the case of the car, the challenge is to make sure that the verification sessions are very quick. For instance, you want the car to be able to verify up to upwards of 2,000 messages per second. That has implications on the infrastructure because it cannot take too long to verify each message. That also impacts the certificate format, their nature, and it means you cannot design these exactly like websites were designed, where they could authenticate each other. With a website, it’s assumed that the user can wait a couple of seconds, whereas in the car, decisions have to be made in microseconds.”

Over the past year alone, IP providers across the automotive industry have released secure versions of their processors. Schweiger said lockstep processor versions of certain processors have been rolled out to address safety aspects, such as ASIL D.

“We need to provide IP to address security, which is usually within a root of trust system, so the vehicle can first boot in a very secure and isolated way, and can authenticate all other systems to ensure the software is not corrupted or manipulated,” he said. “When you open up the car to the outside world, with vehicle-to-vehicle communications, vehicle-to-infrastructure communications, over-the-air updates, along with WiFi, Ethernet, 5G, and so on, it enlarges the surface of attack of a car. That’s why measures must be put in place to prevent people from hacking into the car.”

The network on chip (NoC) within automotive SoCs can play a role here, as well. “On the NoC within the SoC, think of it as being like the network within your company,” said Kurt Shuler, vice president of marketing at Arteris IP. “Within your company, you’re looking at the network traffic, and there is a firewall that’s usually at the edges of the network. You put it someplace strategically within the network to watch the traffic. In an SoC, you do the same thing. Where are the trunk lines within the SoC? Where are the places where you’d want to see the data and inspect it? You’re not necessarily doing deep packet inspection and looking at all the contents of the packets within the network on chip. But because the firewalls are programmable, you can say, ‘In this type of use case, with this type of communication, from this IP initiator, maybe at the CPU cluster, the data is valid to go to this memory or this peripheral, and that’s a valid communication.’ You also can use it to test the system by saying, ‘Only allow that through if there’s invalid communications in that use case.’ Then you can fire information up to the system to indicate something bad is going on. This is useful since hackers will intentionally create that traffic to try to see what kind of security you have. Therefore, you also can tell the system to let the data through, and not act on it, in order to tag the data and the commands that you think are bad. And if somebody is fuzzing the system — putting a whole bunch of garbage in — you can catch them.”

The firewalls with the NoC also can be used to enforce functional safety. “If you’re going from a less safe part of the chip — let’s say it’s an ASIL B or A, or maybe it’s QM — and data and commands from that side of the chip are going over to an ASIL D side, you want to be able to test that to make sure that the data either gets wrapped in ECC, or whatever method is required for the safer side of the chip. Firewalls help with that. That firewall functionality is used as a failsafe to ensure the data that comes from a less safe part of the chip is properly protected before it goes into the safer side of the chip,” Shuler explained.

Simulation and test
Planning ahead in design and manufacturing can help identify hardware vulnerabilities that allow data to be compromised, as well.

“There’s software hacking, but there’s also hardware hacking — side channel attacks,” said Marc Swinnen, product marketing director for the semiconductor business unit at Ansys. “You can extract the encrypted code from a chip by simply analyzing it, probing it electromagnetically, probing its power noise signature. With a software hack, you can always fix it by updating software, but if your hardware is vulnerable to this sort of hacking, there’s nothing you can do about it. You have to build a new chip because it’s too late to do anything. You really need to simulate that before it gets to that point, and simulate the scenario that if someone were to put an EM probe a few millimeters above my chip, what signal would it receive? Which of my wires would be emitting the most, and how good is my shielding working? Also, what is my power noise signature? All these things can be stipulated. It’s possible to get metrics for how many cycles of simulation are needed to extract the encryption.”

Some of this also can be identified in the test process, which involves multiple insertion points throughout the design-through-manufacturing flow. That can incorporate everything from the usual pass-fail in-system test data, to memory and logic repair data, as well as data collected from in-circuit monitoring.

“All of this data can be collected from the device into a cloud database solution, where it becomes extremely powerful,” said Lee Harrison, automotive IC test solutions manager at Siemens EDA. “Having collected data from a large cross section of systems in the field, the data is analyzed and subjected to AI based algorithms to then provide feedback to the physical system to adjust and fine tune its performance. Here, the application of the digital twin can be used as part of the analysis and refinement process.”

Fig. 2: Simulating and testing for data vulnerabilities. Source: Siemens EDA

Off-chip data can be collected and then shipped securely to the cloud for analysis using unique identities and authentication. This is especially important when over-the-air updates are involved, and those are subject to rigorous regulations in many countries, said Harrison.

Conclusion
While these capabilities and improvements provide some encouragement, data security will continue to be problematic for years to come in all electronic systems. But in applications such as automotive, breaches are not just an inconvenience. They can be dangerous.

“When we hear about the activities that are happening, we automatically feel more comfortable and say, ‘Oh, okay, things are happening,’” said Synopsys’ Clark. “But when we talk about moving data securely from point A to point B, or not accepting the device that shouldn’t be on that network, it encompasses both technology and process. How does an organization take cybersecurity practices seriously, and how do they define and measure against their overall cybersecurity program so they see they’re improving? That may not have anything to do with how I move data, but it has everything to do with whether an organization takes cybersecurity seriously. And that process enables the engineers, the system designers, the infrastructure designers to say, ‘Not only are we developing this really great technology, but we have to take a real look at cybersecurity. What does cybersecurity mean in this context? That’s where we start to see real improvement. Organizations have to become mature enough from a cybersecurity testing perspective to acknowledge that and develop their cybersecurity testing processes to get to that point in a meaningful way.”

Tortuga’s Oberg agreed. “It’s all about having a process. Security is always a journey. You can never be secure, so the best thing you can do is be proactive. Think about what you’re trying to protect, what the adversaries are capable of. You can’t predict everything. You have to accept that. I like the approach of always being as open as you can. Don’t try to hold back. Of course, you shouldn’t disclose any of your intellectual property. But you also need to be transparent about your process to your customers. If something happens, they need to know what your process is. And then, you need to be very clear about what you’ve done yourself, and what you haven’t done. It’s all about, ‘This is my threat model. These are the assumptions I made. This stuff we have not considered.’”