Automotive Security in a CAN

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.

Principles of Automotive Security

Despite uncertainties and changing market dynamics, some automotive security principles are starting come into clear focus:

• Automotive security begins with the semiconductor processor. These processors need to be personalized using private keys injected by secure equipment and processes. Certicom’s Asset Management System is an example of equipment used to accomplish this task.

• The next step is to ensure that the operating system is secure. An example is the microkernel-based architecture of the BlackBerry QNX SDP 7.0 OS. It separates critical OS components into their own protected memory partitions, provides temporal separation for threads, uses an encrypted file system, offers multi-policy driven security features, and provides network security to reduce the attack surface.

• Different levels of safety criticality must be managed. An example of that is the BlackBerry QNX true Type 1 hypervisor, which allows isolation between virtual functional modules, providing another layer of security and safety—it can isolate safety-critical from non-safety-critical functions.

• ECUs and modules will have certificates installed, which can be used to authenticate other modules, or other cars and infrastructure (i.e., V2X). These certificates must be issued and managed using a secure managed PKI system, such as offered by Certicom.

• Software must be readily updatable at dealers and repair shops, via secure over-the-air software update systems such as offered by BlackBerry IoT.

• Aftermarket suppliers must be able to sell and update the software on secure devices.

• Communication between ECUs must be authenticated and messages need to be signed to avoid rogue messages which can create havoc.

• Access to sensitive electronics of the car via different access ports needs to be protected against unauthenticated access.

• OEMs must be able to authorize or not authorize specific electronic devices at manufacturing time and after the car is in use (for example to enforce warrantee policies).

• Software needs to be scanned and validated for being secure. This requires very special tools, also provided by BlackBerry.

Who’s in the Lead Now?

2. Results from Electronic Design’s Embedded Revolution survey on IoT security from a couple of years ago.

Interestingly, the recent results from Electronic Design’s “Embedded Revolution” survey for IoT security (Fig. 2) match very closely with 2015 surveys focused on automotive embedded security, which was before the Miller-Valasek Jeep hack. Things have changed drastically since then.

Primary research recently conducted with automotive OEMS, Tier Ones, and Tier Twos shows that the security is “Very Important” to well over 95% of the respondents. This new statistic indeed matches the evidence of large-scale investments being made into automotive security gateways, hardened ECU (hardware security modules, or HSMs) and domain controllers, secure manufacturing, secure operating systems, secure firmware over-the-air (FOTA) updates, security health monitoring, and secure processors (Fig. 3). The automotive industry quickly went from being just like any another embedded application when it came to security to being the clear frontrunner with a profound sense of urgency.

3. Many precautions and technologies need to be interwoven into system development because security is a multifaceted and multilayered proposition.

Security Starts in the Supply Chain 

As noted above, security mechanisms such as keys and certificates must be injected into ECUs in the factory and in the field. To do this, a secure manufacturing system must have global reach, be manageable on a distributed basis, be updatable by various entities, and remain secure for years. To maintain the maximum amount of flexibility, personalization and updating should be moved as close as possible to the very point in production, which is a critical objective of the global manufacturing blueprint (Fig. 4).

4. Shown is one sample of a global secure manufacturing blueprint.

Multi-Level Security

With cars, security must happen on multiple levels.  Multi-level cybersecurity will not be an option, but will be commercially mandatory and mandated by the government (Fig. 5). The signs are already there.

5. Multi-level cybersecurity will no longer be an option. Rather, it will be commercially mandatory and mandated by the government. (Source: NXP)

Multi-layered automotive security will likely include a mix of the following items (Source: NXP, Argus, Roland Berger, IHS, Strategy Analytics, ST Micro, Infineon, Bosch, Elektrobit, Microchip, Renesas, Harman, Deloitte, PwC, McKinsey & Co., Intel, IO Active, Automotive OEMs, BlackBerry QNX, Certicom, others):

• Isolating in-vehicle electronics from external interfaces by means of firewalls.
• Applying strict access control to only allow known/trusted entities (partial) access to in-vehicle systems.
• Clustering in-vehicle networks with similar criticality into domains to better isolate safety-critical systems from others.
• Protecting in-vehicle networks with cryptographic authentication, data integrity, and maybe perhaps later encryption.
• Using intrusion detection/prevention systems (IPS/IDS) to detect and counter attacks.
• Protecting ECU operation via secure boot, secure update, and others.
• Upgrading ECUs to include secure processors.
• Secure gateways, transceivers, and switches to protect networks.
• Protecting cryptographic keys using hardware-based key storage (e.g., secure crypto elements and/or HSMs).
• Using high-speed secure crypto elements to authenticate V2X signals.
• Movement toward PKI-based security using a hardware root of trust and active certificate management.

Playing Catch Up

CAN bus insecurity coupled with high-profile hacks has put carmakers into a position where they’re playing catch up. With cars being connected and with the growing code base, vulnerabilities are growing. This creates what’s referred to as an expanding attack surface. Simply put, cars are hackable in an increasing variety of ways (Fig. 6).

6. There are multiple ways to hack a car.

Exposure to attacks is now well-known; thus, the industry must quickly find ways to cryptographically secure existing low-bandwidth buses such as CAN and the ECUs that connect over those buses. Higher-bandwidth buses like Ethernet are coming to automotive platforms to address the need for faster and higher volumes of information. These systems will have stronger security mechanisms, but they’re not coming in time to obviate the need to retrofit the existing CAN bus for robust security. That’s a core issue, and it presents almost overwhelming challenges when it comes to resource, cost, implementation, and management (especially of security keys).

So, Where Are We?

The automotive security industry, as noted, is in its infancy. There are no clear technological winners yet regarding the type of security that will be adopted for cars and smart infrastructure. Shared RSA keys, RSA-based PKI, ECC-based PKI, and mixed systems are all in various states of exploration and implementation with OEMs, Tier Ones, and Tier Twos. Different types of key storage and updating are being used and contemplated, including automotive trusted platform modules (TPMs), HSMs, and other methods.

The evolution of security techniques is happening on a purely pragmatic basis because standards don’t exist and may not for a while. The industry is taking a crawl-walk-run approach, which means that some type of quick-to-implement security solution, perhaps using shared symmetric keys, appears to be an emerging first step (crawl).  That may be followed by a more robust approach using public key infrastructure (walk). Subsequently, an even more secure approach using higher bandwidth buses like Ethernet and more sophisticated domain/area controllers and gateways equipped with PKI-based solutions may be adopted (run). 

PKI is highly likely to be a part of any long-term solution. That’s because PKI is more secure and manageable at finer resolution (i.e., a key for each ECU) than shared key approaches. 

Security is required not only on the control buses and ECUs, but also on vehicle-to-vehicle and vehicle-to-infrastructure (collectively V2X), as well as on manufacturing and updating systems. Different schemes will be implemented for V2X and internal vehicle security due to differing needs. V2X is already adopting PKI.

Final Thoughts

A critical dynamic worth paying attention to in the automotive industry today is a shift in terms of who will control software development, including security. OEMs recognize that they must be in control of automotive software development because security and safety are interlinked and must be built into the foundation of the design into every layer.

Many refer to the dynamic of connected, autonomous, software-driven cars as Silicon Valley invading Detroit (at least in American parlance).  “Detroit” is responding by becoming more software savvy, which means hiring, acquiring, and partnering on software, from operating systems, to artificial intelligence, to cryptography, and over-the-air software updating.

Just as automakers are taking more responsibility for software development, silicon makers are taking more responsibility for system definition. They’re adopting more risk to get ahead of the curve and provide the silicon and increasingly the software that runs on the silicon. They can’t do it alone, so they’re partnering with software companies skilled in the art of automotive security and safety.

Due to the long semiconductor design cycles, especially for multicore processor-based products, and the long automotive design cycles, semiconductor companies must anticipate market needs more than ever, and well before standards are set and requirements codified. Multicore processors with complex graphical processor units (GPUs) are expensive to design. Despite the increasing levels of risk, there is a silicon land grab underway, and the spoils will likely go to the most innovative and daring companies.

Due to the need to provide security under time pressure from the threat of liability and regulation, semiconductor companies making automotive processors simply have no choice but to propose advanced security solutions, with the risk that some of these may never get adopted or standardized.

Evidence of the semiconductor companies’ technical and market leadership include automotive hardware security devices of various flavors such as HSMs, secure processors, and automotive TPMs. One thing common to these devices is that silicon makers have figured out that the key to cryptographic security is keeping the secret key secret. Therefore, these products are increasingly storing the secret key in secure hardware. Think of that as a secure key vault.

Of course, the other side of the silicon equation is software. Silicon and software should work together intimately and securely if vehicles are going to be safe.  Software needs secure hardware, which must be made and updated on secure equipment.  Knowing this, it’s already possible to decrypt the software-defined automotive future: Silicon, software, safety, and security must become seamless.