Automotive cybersecurity has gained notoriety in the past few years, starting with the widely publicized Jeep Cherokee hack in 2015 by security researchers Charlie Miller and Chris Valasek, and the reports of Felix Domke. Many researchers refer to the intuitive connection between IT and automotive cybersecurity. They are both networks of connected devices. Why not simply “borrow” solutions from the IT world? We have witnessed many companies based on this premise, with very few successfully penetrating the automotive industry or making any real impact. Automotive cybersecurity differs from its IT counterpart in many ways:
Various Interconnected Systems
A single vehicle contains many component types: Simple logic circuits, automotive sensors, complex onboard computers, proprietary chipsets, embedded operating systems, Linux-based systems, JVMs, AT-Based Modems, classic and adaptive AUTOSAR ECU partitions, HSMs, hypervisors and technologies from the past 20 years. It’s hard enough combining Mac and Windows in an IT system, but getting these components to communicate over CAN or Ethernet?
OEM versus Tier 1 vs. Tier 2
Most IT systems revolve around a single processor with a bit of OEM tweaking. Add a standard operating system, and the OEMs become integration companies. In the automotive world, Tier-1 electronic control unit (ECU) suppliers develop most of the functionality, including drivers, memory management, communication protocols, some cryptography, power management, etc. The processor manufacturers (Tier 2s) have less impact on the final product, increasing system complexity and diversity. Since most vehicle OEMs focus on mechanics, electronic design decisions are made by Tier 1s.
The OEMs create functional requirements, add some general recommendations and throw in all the automotive regulations. The advantage is that the Tier 1 has almost complete responsibility for the component – none of that “It’s the other guy’s fault.” The main disadvantage is the lost “bird’s-eye view” of the system. No Tier 1 sees the entire vehicle, and OEMs don’t have a clear grasp of the ECU insides. This makes the vehicle a sum of independent parts, instead of a unified design. That’s a big security problem.
(In)Tolerance to additional hardware
You know that pitch you see in conferences about the “Magic Box,” the cutting-edge component to fix all your cybersecurity problems?
Adding this “Magic Box” to a vehicle platform means additional weight, energy consumption, cables, quality control, integration cycles, training for garage mechanics, meetings, documents, regulations, manpower and more money than you would expect. And that’s before you reach the wall of engineers claiming they don’t need a “Magic Box.”
This is one of the reasons many automotive cybersecurity companies create partnerships with Tier 1s: they already have a box in the car.
Tolerance to mistakes
This is a big one. Let’s say you create an intrusion-detection system in the car that decides the incoming “brake” signal is spoofed. What now? What if you’re wrong and the car goes over a cliff? What if you’re right and an attacker stops the car in a crowded road? Who is responsible either way? An OEM may decide it would be simpler not to have an intrusion-detection system to begin with.
Upgradeability
It’s not that difficult to perform an over-the-air update of almost every vehicle component. However, when you find a vulnerability in a certain ECU, the supplier needs to analyze and integrate the fix in the component. And then testing, lots of testing. Now the OEM needs to test it in all possible permutations of the vehicle architecture. And of course, there’s that one test where the component and/or vehicle brick themselves. The OEM can’t update millions of cars and have a few brick overnight, right? That translates into vulnerable cars running around waiting for their next garage appointment. There are solutions for this: sandboxes, safe modes, redundancies, etc. But you always will have that executive sitting in his chair, afraid to press that button
Time to Market
The average time from vehicle concept to wheels on the ground is four years. Most major decisions regarding architecture, operating systems and security concepts take place four years before the car is released. The suppliers try to maintain up-to-date software up to the start of production, but they would not voluntarily replace an entire Linux Kernel in mid-development.
That means four years of new vulnerabilities, security methods, bug fixes and communication schemes are not considered. It gets worse. If any new component fails testing or jeopardizes start of production, the OEM will prefer to use a legacy ECU, rather than the new one.
How long does it take you to switch to a new personal computer? Five years? A new smartphone, two years? The typical vehicle now is on the road for 15 years or more, meaning some very old code driving through the streets. And as everything gets connected and cars talk to cars, to smart cities, to backend servers, to smartphones, etc., you will have these vulnerable antiques acting as the weakest link in the chain.
Standardization
There is AUTOSAR, the global automotive development partnership for open and standardized software architecture for ECUs, both classic and adaptive. And there are committees, governments, ISO, SAE and many others trying to make automotive standards and enforce them. We are on such committees. However, with such complexity and so many permutations of a single vehicle platform, with suppliers from all over the planet, it’s hard to get everyone to agree on anything.These are just some of the differences between the Automotive and IT cybersecurity fields. So where does that leave us? How can we make sure the future of automotive mobility is secure? By working with the OEMs and Tier 1s, and not by creating magic boxes.
Tamir Bechor is a clinical associate professor in Claremont Graduate University’s Center for Information Systems and Technology and is a cofounder of automotive cybersecurity company Cymotive Technologies. Erez Gazit is Global Head of Engineering Services at Cymotive.
