Automotive Security Shifts To The System Level

Cars are getting smarter, more complicated, and more vulnerable to cyberattacks. As the amount of semiconductor and software content continues to increase, so does the number of over-the-air updates and connections to edge-based servers and services, adding a variety of new vectors for attacks.

Properly securing vehicles requires engineers to first identify all the possible connection points. In the past, multiple ECUs were implemented as part of a vehicle’s security strategy, but carmakers increasingly are relying on a single, beefed-up ECU because it can improve performance and power efficiency. To make up for that loss of redundancy, carmakers are adding data encryption and strong security IP, and they are starting to require some level of security training for more types of engineers.

“Look at the applications where our products go,” observed Bill Stewart, vice president automotive Americas marketing at Infineon. “They go into steering systems, braking systems, the powertrain, whether it’s ICE or EV, and those are already mission critical systems. Even with a lot of the ADAS systems, you’re taking sensor data, you’re converting that into the direction the vehicle is going to travel, you’re converting that into braking or throttle messages. You need really high-quality levels of devices. You have to have security enabled into your devices, and security is always a moving target.”

Identify attack vectors
As any good sports team knows, the best way to plan out a defense is to have a good idea of what your opponent is planning on offense. While bad actors are constantly innovating, the best way to counter their efforts is to identify where a system is vulnerable.

In the strictest sense, there’s only one direct attack vector on a car, according to David Glasco, vice president for compute solutions group at Cadence — the WiFi through which all software updates are uploaded. And once a bad actor gets past that, they can find numerous ways to wreak havoc on a system.

“Once I have access to the car, I now have access to the silicon,” Glasco said. “Hackers can try to deduce keys by watching the electromagnetic emissions from silicon. If you’ve not seen a side-channel attack demo on an unprotected security, it’s pretty amazing how easy it is if you don’t have side channel protection. You have to make sure that not only do you have a root of trust, but that the root of trust has all the necessary side-channel defenses.”

Others agree. “[Threats can come via] anything that comes in from the outside, meaning outside of the compute system itself,” said David Fritz, vice president of Hybrid and Virtual Systems at Siemens Digital Industries Software. An example of an unconventional route of attack in a car is through the multitude of sensors, which a hacker can use to “push the bad data into the central compute,” he said. “But in today’s architectures, there is a safety island that all of those external inputs have to go through and get verified to be legitimate before they get passed on to the central compute.”

That safety island, which is mandated in ISO/SAE 21434, usually comes in the form of an ECU, which routes data, then detects and rejects unsecured entries. While historically a number of ECUs were deployed in an automotive design, the recent trend is to have one ECU with more compute implemented to run a hypervisor, which in turn runs several operating systems.

“You may have a secure operating system that handles mission-critical things, and then there’s another operating system on the same ECU that may stream videos to the kids in the back seat,” he said. “We call that mixed criticality. Some of it might be mission-critical, some not, but you need to put all that together. When you consolidate those, it does some great things. It lowers the weight, it lowers the power, so it extends the range of an EV. It lowers cost pretty dramatically. There are some strong benefits from that, but at the same time, now we have non-critical tasks operating in the same environment as critical tasks, so it’s really important that you ensure no data coming into that consolidated ECU is corrupted, or in some way carrying something that could be harmful to the critical tasks that have to do that.”

The ECU can be thought of as a fortified gateway, where encryption takes place, and one that requires some beefing up to prevent any potential faults, be they from human attackers or from other sources.

“We’re doing all kinds of error correction and encryption/decryption, public and private keys, all the normal security stuff, but none of it does you any good if there is a way within the hardware itself to go around that mechanism,” said Fritz. “To do that requires chips that are designed specifically to be fault tolerant, because you don’t want your security to stop working just because your battery is low, or something like that.”

The core of all security comes down to proper, strong cryptography. Cryptographic algorithms and software are subject to change, which only exacerbates the need for fool-proof hardware. While that’s particularly important in the ECU, data within the vehicle also can be encrypted as a fail-safe. Infineon, for example, uses a dedicated security processor that operates independently of other components on the same die, which can act as a layer of redundancy by encrypting data flow within the car itself.

“You have to secure the vehicle system from the outside world to the inside, and we’re encrypting the network traffic within the vehicles, as well,” said Stewart. “This happens mostly on our microcontrollers, which have hardware security modules built in. Obviously, that’s a lot of intensive processing. If you’re taking every Ethernet message and encrypting and decrypting, and you’ve got radar data and camera data, there’s a lot of data flowing through these vehicles. The biggest difference in an SDV is in the way you decouple hardware and software functions. You need to send more data back and forth. What this means for security is that you want to encrypt that data at the same time. This is where having efficient processors, which have isolated areas in them that can handle all of that data without interrupting the main processor, can be a benefit.”

The migration toward holistic security now includes roots of trust installed in ICs located throughout the car’s systems. “They’re used to establish secure networks within the vehicles,” said Mike Borza, a Synopsys scientist. “The security of the vehicle can then be established, and the identity of the vehicle can be established back to the manufacturer’s network, and that gives you a way to do authenticated, secured updates of the software, but it’s all rooted back to those hardware roots of trust in the chips. We’ll see that continue, even as we switch over to so-called SDVs.”

IP a critical component in SDV security
Some safety-critical issues can be solved on the software side, but that can lead to more vulnerabilities than hardware-based solutions. Rob Fisher, senior director of product management at Imagination Technologies, said creating virtual environments within the GPU can lead to more satisfactory outcomes, an approach Imagination first used in mobile phones, and which it now applies to automotive.

“What we do in the GPU is allow non-safety critical things to operate alongside safety critical ones with freedom from interference,” said Fisher. “Essentially, we’re creating multiple environments within the GPU that cannot communicate with each other, so you have isolation, and we do this specifically for safety reasons. But part of this strategy for creating a secure environment on the SoC is partitioning these environments and having permission levels so that privileged applications can access different parts of the architecture, whereas third-party applications that might be running don’t have that same level of access.”

In an automotive context, implementing this sort of IP can allow SoCs to perform a range of tasks by splitting up these tasks via execution cycles. That could be an infotainment task, for example, or one connected to ADAS. Both tasks will be distributed across physically separated hardware registers. While this contributes to functional safety in an obvious way, Fisher that it also can have a positive effect on a vehicle’s cybersecurity.

“Having multiple environments is very similar to having different privilege levels within the CPU structure, which allows you to assign a very low privilege, for example, to a third-party app,” he said. “In my car, I might download a new application that finds parking garages, but I don’t know who’s written it. I don’t know whether that person has done things in a sensible, safe manner. Or, it could be an application that’s going to try and hack my car. I want to run it in a very, very containerized section in my SoC, so I assign it a very low privilege level, and that privilege level wouldn’t allow it to access the GPU, for example, or it wouldn’t allow it access to the vehicle buses, the sensor buses, and things like that.”

Security expertise a must for SDV designers
From powerful ECUs, to layers of redundancy, to secure IP, implementing these security features comes at a cost, albeit a necessary one. While there are typically conversations around security implementation that include weighing the effects on PPA, Cadence’s Glasco said that in the context of SDVs, security takes precedence over any other consideration.

“Security is just like safety,” he said. “Security is the ultimate. It is the top priority. If someone can break into the car, they can just drive you into a wall. So you have to be secure. You have to have really good security architects. And you have to really think through the threat vectors. The problem is you have people who are actively spending all their day trying to find a new attack vector.”

Adiel Bahrouch, director of business development, automotive industry, at Rambus, contends that at least some level of expertise in security is a must for any designer looking to dip their toes into the automotive realm.

“We are dealing with a very complex system, and complexity is the enemy of safety and security,” Bahrouch said. “We are dealing with a vehicle that is 24/7 connected to the outside world. We are dealing with a vehicle that is collecting a lot of data from sensors for ADAS, for autonomous driving. A lot of data is processed, so safety and security are becoming key. Adding safety and security capabilities into the design might lead to certain system choices and system architecture choices.”

Glasco echoed that call. While an attacker attempting to remotely access a vehicle will almost definitely have to get through the ECU, layers of redundancies are still needed.

“You have to think about it as one large system,” he said. “You have to think about it as a system that actors will be able to gain access to. It’s way more than just a secure boot. You have to think about all the attack vectors, especially now with internet-connected cars, WiFi-connected cars, over-the-air updates. There are even more attack vectors.”

Those redundancies can come in the form of hardware security modules (HSM), which can be found throughout the automotive system. This may seem like overkill, given that all the incoming data ultimately is passing through the ECU, but it’s a necessary one.

“Security is a system-level decision,” Infineon’s Stewart said. “You can’t say, ‘This piece is secure, but then everything else around it isn’t secure.’ You have one HSM in the zone controller, you have one in the braking module, you have one in the steering module, because all this network traffic must be secure.”

A focus on reinforced security is particularly important due to the lifespans of cars, which can stretch for well more than a decade. Synopsys’ Borza noted that what’s implemented at the time of manufacture must be flexible enough to execute updates that might only be uploaded in the distant future.

“There needs to be a plan to keep updating over at least the first 10 years of lifetime of that vehicle,” he said. “We have to make sure that we close security problems as they happen, as they’re discovered, and as the threats emerge. It’s that interplay of the root of trust in the hardware with the software to authenticate all of the downloads that you’ll get, all of the communications between the vehicle, the endpoints within the vehicle, and the vehicle to the network itself.”

Conclusion
Cybersecurity is mission-critical to SDVs, and it requires a view of the vehicle as a system rather than as a collection of isolated components. While in the past security was implemented through a number of ECUs through a car, the trend has veered toward a single, powerful ECU at the car’s largest weak point, supplemented with different redundancies and new updates throughout the lifetime of a vehicle.

The challenge for automakers is understanding how these systems of systems will behave both individually and together, and that may require security training as a pre-requisite for any facet of automotive design. Vehicles will only become more complicated in the future, and security increasingly is being looked at as everyone’s responsibility.

Related Reading
How Software-Defined Vehicles Change Auto Chip Design
SDVs are booming, but designing hardware that can run software updates a decade in the future is a huge challenge.
Chip Security Now Depends On Widening Supply Chain
How tighter HW-SW integration and increasing government involvement are changing the security landscape for chips and systems.
ISO 26262’s Importance Widens Beyond Automotive
The international standard has been proven effective in automotive functional safety and has begun to spread to other markets.