Grappling With Auto Security

It’s a changed world under the hood of automobiles today, as vehicles become increasingly connected to infrastructure and each other. But that connectedness also is creating new security risks.

Growing complexity is one piece of the problem. There are upwards of 80 electronic control units (ECUs) and more than 100 million lines of code in an average vehicle. On top of that, there are more vehicles communicating. The number of cars on the road containing at least some level of interconnectivity will reach 100 million by 2025, according to Gartner.

But even with all of that sophistication, automobiles still operate with a series of non-secure controller area network (CAN) buses that are vulnerable to common software flaws, particularly when that vehicle is also connected to the cloud.

“It’s going to be one of those multi-faceted things,” observed , Cadence Fellow and CTO of the IP Group. “With security you have to think about it systematically, addressing the different kinds of threats that might be faced, and therefore what whole layered system of protection is going to be needed.”

The problem increases with the number of connected features and the overall number of possible interactions. “There are fairly complex interlocking sets of pieces that do things like isolate and secure software from general application software running in the system, and which can do suitable encryption of various pieces of content, including being able to sign the code and verify that the code is coming from the right place. Then, if you have a fairly comprehensive and complex system, you know that the first time you developed it, it’s not right. It’s guaranteed to be wrong. So you’re going to have to do a lot of work in order to verify that you have met the goals of leaving no holes in the system. Being able to systematically and provably cover the design to a high degree of confidence is an essential part. It’s like any software, only more so. All software is completely broken until you’ve hammered on it, and then once you get done hammering on it, it’s only slightly broken,” Rowen said.

Given all of the unique features of the automotive segment, it may make sense to have a more specific or vertically focused automotive software testing environment. Rowen said there are some unique operating systems such as AUTOSAR, unique automotive requirements, and a suitably high level of paranoia about automotive security issues to warrant that kind of domain-specific test. At this point, however, none exists. Some generic software tests using formal technology currently are filling that need. But adding this into the regulatory regime would go a long way because in automotive it’s not just about the test—it’s also about proving that it has been adequately tested.

In fact, the ISO 26262 automotive standard requires component providers to classify where their product is used in automotive products and defines the types of testing required.

“Products need to show how tolerant they are to the presence of faults,” said , CEO of Imperas. “This means somehow the supplier needs to demonstrate that their product will keep working when there are faults. These faults can be problems to do with the inputs, problems to do with fixed faults, and problems to do with transient faults such as single event upset.”

Davidmann noted that transient faults are becoming more of a concern due to small geometries of chips and large caches. “The challenge is how to demonstrate/show/certify that a product does keep working. One way for suppliers to do this is to simulate their design with the software running with injection of faults, and for them to demonstrate that the design detected/recovered/ignored the faults. Virtual platforms using instruction-accurate models can be used for this, and there is research beginning to show very promising results.”

How much connectivity?
There is much discussion these days about how much connectivity is required, as well.

“We all know that cars are going to need cameras and radar (light detection and ranging), or both, and there’s going to need to be some communication with infrastructure,” said Robert Bates, chief safety officer for the Embedded Systems Division of Mentor Automotive. “It may be that it makes sense to also have the cars communicating position to one another, especially for things like convoying, which is going to be a big deal with trucks. But how much is necessary? You read some of the stuff, and it’s like there’s all of this positioning information being transformed by networks that are being created and destroyed on the fly. And yes, a GPU has a lot of processing power, but is the car really going to have that much sensor and processing power to be able to deal with all of that information in millisecond range?”

Bates compared the automobile to a collection of IoT devices. “That’s clearly going to happen, and there is going to be some communication between the cars and each other, as well as between the cars and infrastructure, not just the car and the cloud. You’ve got things like SOTA (Software Over-The-Air) and FOTA (Firmware Over-The-Air) updates, which can be done in a more controlled fashion, and then you’re going to have some amount of ad hoc networking happening. I question how much is really going to be necessary.”

All of this adds new security risks, as well.

“Updating is a solved problem for the most part,” said Bates. “Apple has figured it out. Google has figured it out. A lot of IT infrastructure companies have figured it out. That technology is all available and well documented. Yes, the car has some legacy problems, and it has some infrastructure problems. The legacy problems are things like devices that might already be trying to communicate with the outside world that are just sitting on an unprotected CAN bus. We’ve all seen examples of that—going through a tire air pressure sensor or something like that to take control of the car through the CAN bus. There are some problems there that will need to be solved. Certainly CAN messaging is going to have to be encrypted, probably with more advanced encryption techniques—especially if you are going to allow interfaces for diagnostics, which no one is going to remove. But in terms of the individual things in the car, communicating with the outside world, that’s going to have to be much more controlled just from a basic security standpoint.”

That includes a security unit responsible for all of the over-the-air communication, which is where the security engine will run, he said. “It might be part of the head unit/cluster infotainment system or it might be separate. It’s a question of processing power, cost, how many Tier 1s you are using to develop these things, and whether the OEM decides the security function is so vital to their interest they take it on themselves. And that’s not clear at this point.”

Securing the car with hardware
As with most complex devices, hardware and software both need to be secured. But cars are a special class of security problem. They share all of the behaviors and risks of other complex hardware. Cars will communicate with traffic lights, phones, antennas, and other cars. But unlike many other devices, they’re also large and potentially dangerous to occupants, as well as others outside the vehicle.

“If we start today with software downloads, it is very important that authentication is built into the chips inside the car so they only download from authorized servers or services—and they are able to check that the downloaded code is indeed authentic code,” said Pim Tuyls, CEO of Intrinsic-ID. “That should be a very good secure boot process so you don’t download malware, or don’t download changed code. Then looking a bit further down the road, where cars are going to communicate with the infrastructure, the key thing is authentication. This is a very important point because most people, when they think about security, they think about encryption. The first thing you need to do is authenticate it because if you don’t have authentication, encryption doesn’t make much sense necessarily.”

Knowing where the information is coming from is one piece of the puzzle. But there’s also a possibility that someone has hacked a car in front of yours.

“Assume the information you get is from a car in front of you that says it is driving at a speed of 50 miles per hour while it is actually braking,” said Tuyls. “The important thing here is that due to all of these electronic systems, a hacker could do that on a large scale. Again, this comes down to having authentication built into the chips, and the ability to verify the authentication code in a very fast way. In terms of authentication, the codes are well known, but there are many chips in a car, and you need to be able to build in lightweight authentication methods into those chips.”

One of the more promising approaches for this kind of problem is to use physically unclonable functions, which use properties of the silicon itself to recognize the chip and to create device-unique identifiers and device keys. The authentication can be set up from there.

Not there yet
There is another wrinkle in the automotive security picture, as well. While chipmakers and automotive companies wrestle with the best security approaches, they are working with an architecture that is still in flux. At this point, no one knows what the electronic topology is going to look like and how much processing power will be needed, Mentor’s Bates said.

“Is the processing power really there between, say, a bulky multiprocessor part along with a GPU? Is that still enough processing power to do all of that? And then does it make sense from a security and safety verification process to put all of that in one box? Or do you have to put in redundancy? And if you have to put in redundancy, does it make sense to have two different copies of the same box? Or does it make more sense to have the separation that you basically have today, where the non-critical functions are running on one part and the safety/security functions running on another? There are many ways to solve this problem in theory, and there probably won’t be one solution,” he said.

Related Stories
The Race To Secure The Car
Connectivity and complexity are raising concerns about safety and reliability.
Autonomous Vehicle Disruptions Ahead
When self-driving cars actually reach the market is still not clear, but the automotive ecosystem is preparing for huge changes.
Enabling Self-Driving Cars
What’s missing from the engineering ecosystem.