Vehicle Communications Network Is Due For Overhaul

The Controller Area Network (CAN), one of the main communications networks in an automobile, is headed for a security overhaul — if not a wholesale replacement.

Initially devised in the 1980s to allow electronic components in a vehicle to communicate directly without a central computer in between, the CAN bus has become a growing security risk as more functions are automated and integrated into a central logic system. It has been the subject of numerous high-profile security attacks, where hackers have been able to take control of a vehicle and actuate its brakes, and the threat is only increasing with rising levels of autonomy.

A modern CAN bus connects dozens of electronic control units (ECUs), each consisting of a microcontroller responsible for the operation of a specific vehicle function such as airbags, antilock braking, cruise control, or power windows. Interconnecting all of these functions enables a wide variety of convenience and safety features, such as the automatic enablement of the rear-view camera as soon as the driver shifts to reverse or the automatic braking of the vehicle when proximity sensors detect an obstacle. Nevertheless, the CAN bus was never designed with security in mind.

“CAN lacks some basic security features, such as message authentication and device attestation, and is prone to DOS (denial Of service), spoofing, and MITM (man-in-the-middle) attacks, to cite a few,” said Thierry Kouthon, technical product manager of Rambus Security. “Modern vehicles include 80 to 100 ECUs, and up to 200+ for high-end ones, which amplifies the problem. The recent hype for self-driving vehicles creates an urgency to remedy the issue as it grows the attack surface. Several alternatives to CAN exist, but they improve CAN in terms of reliability, bandwidth or price — not security.”

Those alternatives include Local Interconnected Network (LIN), Media Oriented System Transport (MOST), FlexRay, and Automotive Ethernet.

CAN comes from an era where security wasn’t considered necessary. “There was no reason to think that somebody was going to come along and try and hack your Jeep or your Tesla,” said Gajinder Panesar, CTO of UltraSoC. “Classic CAN attacks center around the fact that there’s no source information and there’s no integrity — as in there’s no signature of data going by. It is very easy to carry out protocol and denial of service attacks, which in the automotive industry can be catastrophic.”

Improving the security inside the vehicle requires addressing it from the ECU standpoint. “Since the vehicle networks interconnecting them cannot be solely relied upon, it is essential to make sure that the ECUs are hardened to provide secure processing and runtime code integrity, ECU attestation, message authentication, data confidentiality, tamper-proof identity and more,” Rambus’ Kouthon stressed. “Ensuring these security properties requires a strong foundation called a root of trust. A one-size fits all approach is not comprehensive, as ECUs can be roughly divided in three classes with very different price points: 1) sensors that are commoditized low-cost units, 2) internal functional ECUs, such as for engine control, that are relatively complex and have strong security requirements and, 3) high-performance ECUs that enable communication of the vehicle with the external world and require the highest level of security such as a head unit or a central gateway.”

Further, the CAN bus being 30 years old was never meant to be used in a system facing cybersecurity attacks. “There are plenty of reported vulnerabilities that leverage shortcoming of the CAN bus, the Jeep hack probably being the most famous,” said Sergio Marchese, technical marketing manager at OneSpin Solutions. “Some fundamental issues are that messages are visible to all the bus masters and peripherals and there are no provisions to ensure information confidentiality and authenticity. There can be mitigation countermeasures at the ECU level, for example, with IPs aiming at detecting and blocking suspicious bus traffic. Or they can use a hardware security module to encrypt and authenticate the messages that go on the bus.”

Mike Borza, principal security technologist at Synopsys, agreed. “CAN, on the whole, was designed far before anybody thought about the car as a connected appliance. The idea of hooking it up to the Internet was really not on anybody’s radar at the time — or at least not anybody who was designing cars and electronics to go in cars. It wasn’t quite pre-Internet, but it was pretty close. Certainly the idea, when people were connecting to the Internet with 1200 baud modems, and the idea of connecting your car to that was just not on anybody’s radar – except sci-fi writers. The idea that we could be here now was really not what people were thinking of. Also, the car always was assumed to be its own private thing, and even if you had radios coming into it, they weren’t really going to be connected to anything to do with driving the car. It was a way to get entertainment and not much else, maybe to let you make a phone call. But for many years that was sci-fi, as well.”

That presents a problem today because it’s harder to retrofit security into a bus architecture than to design it in from the outset. “When things were connected to networks like CAN bus, the bandwidth was low, the protocols were proprietary, and they were kind of black magic,” Borza said. “As such, it was difficult to get information about what a CAN bus was, what it was doing, how it worked. That was thought to be as much security as anybody would ever need. It was about saying, ‘We’re not going to tell you how works and you’ll never figure it out.’ And that’s really not the case. People are very clever at figuring out what’s going on. They can watch the traffic and analyze a lot of it. That’s essentially how a lot of the details leaked out — plus the fact that it was very successful and widely deployed in vehicles. That meant there was also a lot of standards documentation floating around for it in the industry, which eventually leaked out. That’s why the protocol itself is not secure. It doesn’t make any pretense to be, but then it’s not even private anymore. It’s not a closed shop.”

Paul Kopp, senior manager of automotive solutions and platforms, Automotive & IoT Line of Business at Arm, pointed out, “Now that vehicles are becoming connected, and we move towards increasing levels of autonomy, ensuring appropriate security levels will become essential to protect both the privacy and safety of occupants, and that of other road users also. Although CAN, the current dominant bus architecture in automotive initially developed in the 1980s, was not originally designed with the security challenges we face today as a consideration, Arm partners and the wider ecosystem are deploying technology that can supplement the CAN bus with the level of security required for today’s vehicles. In parallel, the industry is also deploying newer, more secure and robust networking technologies into new models.”
 
It is possible to overlay a security layer on the existing CAN bus, and some companies have done just that. But it’s not as simple as building a firewall around the CAN bus, which has been tried unsuccessfully.

“As soon as you connect it, people always ask, ‘Why is the car radio connected to the CAN bus? Why can I control it from that panel, from the dashboard in my car? The answer is that a lot of the vehicle controls are integrated into that panel,” he said. “The same controls that are working with the radio also work with the CAN bus to turn up the heat or turn it down. If it’s one CAN bus — and there isn’t a single CAN bus in the car, it’s hierarchical — you get information about what your vehicle service state is. You can sometimes control things like the suspension settings. But that means there’s a pathway between that front panel in the car, the flatscreen in the car and the ECUs that actually control those things. And that’s what people have been exploiting — that and the fact that there’s now a lot more software running in cars, and it’s software that people know well, even the proprietary stuff. Added to that is the fact that we’ve now got at least 3G networks in new cars, which means there is significant bandwidth of Internet connectivity and it’s not very hard to find out how to target an individual car or even the services that connect to them. So maybe CAN bus is coming to the end of its life in vehicles, and that’s not necessarily a bad thing.”

Fig. 1: CAN Frame in base format with electrical levels. Green represents unique identifier, which establishes message priority; blue is remote transmission request; yellow is data length code; red is data field size. Source: Wikimedia, CC BY-SA 3.0

Starting securely
The CAN bus, or a replacement system, is essential for determining if potential problems exist when starting up a vehicle. It’s akin to an airplane running through system checks before departing from the gate.

“It’s one of the first subsystems that should be woken up as you bring up the power, come out of reset,” said Borza. “Now it needs to operate securely, as well. We’re still a little at the early edge of that curve. It’s lagging behind. Rigorous safety standards are now being enforced and deployed widely through the industry, which was not the case previously. There were what I would call mistaken assumptions about some of the safety perimeters, and where they exist versus other functions that were considered non-safety-critical. People are now starting to deal with those precisely because of things where there is a front panel that’s now using soft controls to operate parts of the vehicle ECU infrastructure. This certainly becomes an attack point for them. Using software that’s running somewhere else in that processor to go and attack those things is very feasible.”

Software is a key part of the safety package. “By extension, if you have secure software, you need to know that what is running there is what should be running there, that it’s not been modified and that it is doing the functions that it’s supposed to be doing to a high level of assurance. that’s critical to the continued safe operation of the vehicle. People are getting better and better at developing this kind of software, and they are starting to try to be more systematic about getting the defects out of it. Quality defects have a direct relationship to security, because it’s those quality defects that are often exploited when one attacks a system to break into it. If you create a buffer overflow that gives you access to something you want, it’s what you do. It should be impossible to create those kinds of things and better quality control tools and better design paradigms help to protect against that. In these complex software systems, it’s very, very difficult to design something that’s assured to be bug free,” he added.

Kurt Shuler, vice president of marketing at Arteris IP, likewise stressed the need for am architecture for security from the start. “Do as much as you can at the lowest possible level, because that’s where you can have the most control later. If you’re doing everything in software later, there are still ways around that. If you have things at the hardware level — and that’s where it comes to with the interconnects and the firewalls — if you have the physical mechanisms to stop traffic that shouldn’t be there during certain use cases and you can control that later when there’s new use cases, you’re covered. But it’s got to be built in an overall architecture, where the smallest parts are the SoC transistors. This equates to fire-walling, and either poisoning data that is suspect and letting it through or firing an interrupt up to the system that says, ‘Hey, I’m being hacked.’”

A lot of that is captured in the interconnect, which can work like the firewall in a computer. “There may be millions of people a day hacking away at your firewall and trying to break into your computer, but usually nothing gets through,” Shuler said. “It’s the same kind of thing here. Instead of millions, because it’s a closed system, it might be a few, but that’s why you have those firewalls. But this must be set up as part of an overall security strategy.”

Some of the learnings from Arm’s TrustZone are very relevant in this case. “The automotive players can learn something from what consumer electronics and mobile phone guys have had to do from a security standpoint to be able to, for example, run Netflix,” he noted. “You have to go through a certification process, because for digital rights management everybody who licenses their content to Netflix has to have assurances from Netflix that if you run it on this phone that somebody can’t rip it off and put it up on BitTorrent. They’ve had to go through a lot of stuff to make sure that those things are designed properly and are harder to hack. That knowledge from consumer electronics is valuable, even though the effects of a security breach are different. One is you lose money because somebody stole your movie. The other is something bad happens to the car. The effects are different, but the technical safeguards are similar in that you have within the hardware and software certificates to sign things to make sure that it’s the right software you have uploaded and nobody’s hacked that or the firmware.”

A good security architecture will make it clear when things are not supposed to be transmitted. And as security evolves in this space, more of those kinds of responses will need be handled automatically.

“If you look in functional safety, there’s ISO 26262, which defined a formulaic way for developing functional safety in electrical systems in automotive,” said Brendan Morris, technical marketing engineer, Integrated Electrical Systems Division at Mentor, a Siemens Business. “There are similar standards been developed for cybersecurity that take a similar philosophical approach to establishing best practices and establishing the things that need to be considered in a risk assessment, as well as the process steps an OEM should go through and considerations for the development of software and systems. There already were standards issued by the SAE that took a similar view. The ISO standard steps a little bit more into the formal process steps you need to take, but doesn’t lay down exactly what you need to do. It has the freedom of movement for the OEM to interpret into their production development process. We are starting to see more of that more formal process woven in, with the OEMs now having the expertise so they can be confident in working through what they need to do, which functionalities on the vehicle really need to be very heavily protected, and which ones they just need to stop when things are happening.”

Fixing the problem
At the end of the day, the biggest security issue with CAN is that it has no intrinsic support in the protocol for authentication. A receiver doesn’t know where a message really came from.

“Anyone hijacking an ECU or gaining direct access to the wiring can spoof messages and get ECUs to do almost anything,” said Ken Tindell, CTO of Canis Automotive Labs. “Until now the focus has been on cryptographic solutions for authentication combined with security gateways to try to keep hackers away from CAN in the first place. But this brings a whole bunch of secondary problems, such as secure key distribution, and a new set of weaknesses, such as vulnerabilities in gateway software. What’s really needed is to directly address the security of CAN at the protocol level by using hardware, and side-step the problems of software vulnerabilities.”

NXP has done this with its secure CAN transceiver that contains an allow/deny list for CAN IDs, and Canis Automotive Labs has designed hardware to inject details of the real source into out-of-band space in CAN frames so that spoofed frames can be directly detected and stopped.

A different approach is to eliminate the need for different ECUs in the car to communicate to implement higher-level functions. “A recent report from McKinsey identifies a key trend in vehicle electronics where few DCUs (domain control units) replace many ECUs,” said OneSpin’s Marchese. “That means going from many independent, specialized components (ECUs) with their own software connected through the CAN bus, to a more centralized architecture where software potentially could be sourced in a completely different way.”

Conclusion
Despite all of these new ideas, there are a lot of vehicles on the road today that are not secure.

The wiring harness and electronics are all fixed, said Tindall. “The two biggest security holes in cars are the infotainment system and the OBD-II connector, and it was very common for the OBD-II connector to be directly wired to the main vehicle CAN bus. Today we even have insurance companies pushing customers to install their OBD dongles, and in theory some kind of security gateway could be retrofitted to limit what can be done over the connector. But I don’t think drivers would be motivated enough to install it. This is really just a case study in the security problem of the IoT. There aren’t incentives for anyone to make a secure product. Although CAN is an old protocol designed long before we connected cars to the Internet, it’s possible to strengthen its defenses and keep using it for quite a while.”

At the same time, there is a growing recognition that security and safety are increasingly tied together.

“That’s a major shift,” said Borza. “It’s taken a long time for the industry to come to this point, but they’re finally dealing with moving toward a much better approach to automotive safety and the security implications of connecting vehicles. That’s essential if we’re going to move into the next phases, where we head toward semi-autonomous and autonomous vehicle operation. That’s the only way we’re going to get to anything that’s resembling a safe environment for all of us.”