The automotive security market is at a clear inflection point—safety issues are forcing the industry to move from effectively no security to robust security implementations almost instantaneously. Many powerful market drivers and fast changing dynamics are putting security into the driver seat, especially when the driver isn’t a human.

When any embedded system, especially a vehicle, becomes connected, the first thought should be “how secure is it?” For connected vehicles, until recently, security has been an afterthought at best. That fortunately is changing, which is important because vehicles are becoming largely defined by software as they evolve toward connected autonomous drive.

As entrepreneur and software engineer Marc Andreessen famously said, “Software is eating the world.” If that is true, the next course will be served on wheels. It should be clear to any observer by now that software is already becoming the basis of automotive competition for automakers. Statistics show that software will become the main driver of an automaker’s profitability.

Autonomous driving, connectivity, and other initiatives are making automotive software highly complex with more lines of code than a sophisticated fly-by-wire jet fighter. Connectivity and large code size make vehicles more vulnerable to hacking, raising safety issues. In fact, the industry was given some high profile wakeup calls over the last few years.

Hacks of automotive buses and electronic control units (ECUs), most notably by Dr. Charlie Miller and Chris Valasek of the Jeep, undeniably illustrate that robust cryptographic security is needed, and quickly. That’s due to the simple calculus in the increasingly software-based connected vehicle (and smart highway infrastructure)—without robust cryptographic security, there cannot be safety (Fig. 1). Security will become the table stakes for any new automotive design, right down to the specific processors. Security must become endemic to automotive systems and subsystems just like DNA is to an organism.



1. This chart depicts software size, representing millions lines of code required for each application.

Insecurity Means Liability

The market for automotive security is driven by the fact that current control systems in cars (such as ECUs operating over control-area-network, or CAN, buses) are insecure, which exposes automakers to enormous potential liability. Such liability can only be addressed with technology that’s more advanced than that of the attackers. Because of the high-profile hacks, the deep pockets of carmakers, and the “win the lottery” nature of such litigation, the race to secure vehicles has started. However, car-makers are in catch up mode.

It may not be long before the commercials for asbestos poisoning are replaced with actions for injuries stemming from insecure vehicle systems. If you think about it, in a human-driven car, the human is responsible. In a car driven by software systems, though, it’s very likely that the maker of the car will be held responsible.

Automotive safety and security risks have already attracted the attention of legislators in Washington D.C., and if the history of legislating the automotive industry is any clue, there’s much more to come. Because public safety is at stake with automotive hacking, specific cryptographic security will increasingly be mandated by legislation. However, the specifics aren’t clear.

The most salient examples of legislative interest in automotive security is the Markey Car Security Report and the SPY Car Act. With Washington getting into the act, clearly there will be increasing urgency to design, analyze, test, respond, and standardize automotive security. However, before technical solutions can be standardized and/or legislated, it’s critical to understand what is meant by “automotive security.”

The Mobile Compute-Platform

The connected autonomous car will morph into a sophisticated networked compute-platform, integrated with fused sensors and actuators, and be increasingly controlled by artificial intelligence. This is becoming clear by now.

Vehicles are already a hybrid mechanical-electrical control system with a wide range of ECUs sending and receiving signals over evolving signaling buses to act in a coordinated, organic way. ECUs are controlled by increasingly sophisticated and complex software. But, for connected, networked cars to be safe, the software and hardware must be extremely secure, meaning they must have multi-layered robust cryptographic security mechanisms built right in.

Cryptographic security means that mathematical algorithms, methods, protocols, cryptographic keys, and certificates like those used to secure banking systems, smart cards, mobile infrastructure, and secure websites must be designed into vehicles (and into their manufacturing systems). These methodologies will be used to protect sensors, actuators, ECUs, communications buses, ECU access points, and gateways to the outside world.

Today, signaling buses and ECUs aren’t very secure and a hacker can inject malicious messages to make a car potentially unsafe. One might even say that without security, the notion of a connected autonomous car can’t be safely realized. No safety means no connected autonomous car industry.

If autonomous cars are the next big thing, then a truly robust automotive security architecture for ECUs, gateways, domain/area controllers, and their manufacturing systems is the thing that makes the next big thing possible. Therefore, it’s not an overstatement to say that robust cryptographic security is the sine qua non of the automotive future.

ECUs are at the heart of the automotive security challenge because they and the buses that connect them need to be secured. There’s no way to tell if the signals or messages sent are from an authentic sender, or if they have been corrupted (i.e., have lost data integrity). That must change quickly, and every carmaker, ECU producer, and automotive semiconductor supplier knows it and is working on it. However, there are no standards and these approaches often tend to be fragmented.

ECUs are little computers that run a wide range of systems, including the powertrain; things inside the car like seats, mirrors, windows; multimedia systems; braking systems; safety systems (e.g., airbags); emerging assisted driving mechanisms; and sensor/actuator platforms, among others. Because ECUs control remote systems, they need to be connected to those things (obviously), and that’s done over various types of buses such as CAN, LIN, FlexRay, MOST, and others. Eventually, as more data is gathered and processed by cars, higher bandwidth networks like to those now used by PCs (e.g., Ethernet) will be widely employed. This shift has started.

As for security, as the number of computing nodes in a car network grows, the ways in which these nodes can be attacked increases exponentially (some experts say to the 4th exponent of the number of nodes).

Automotive cryptographic standards and architectures for secure ECUs and other processors aren’t standardized. OEMs, Tier Ones, and Tier Two semiconductor suppliers haven’t agreed on a common standard for securing and updating vehicles and factories, but are looking to each other for a holistic solution that none currently can offer. Past standardization activities such as the European Union’s EVITA and the Hersteller Institute of Software’s Secure Hardware Extension (SHE) are still in their infancy despite nearly a decade of work by important parties in the automotive ecosystem.

What this means is the clay is wet when it comes to automotive security, and many proposals are being made by startups, established computer security companies, networking companies, management consultants, IP providers, mobile communications companies, OEMs, Tier Ones, Tier Twos, and others.

Given the cat-and-mouse nature of digital security, and the accelerating advances in connected autonomous vehicle technologies, there will always be a certain amount of cryptographic evolution and flux, making the task to define and standardize architectures challenging. The ability to adapt to the unknown must be built into any security solution. That point can’t be emphasized enough.