草榴社区 Cloud
Cloud native EDA tools & pre-optimized hardware platforms
Request a Free Trial →
Remember when a pair of ethical hackers remotely took over a Jeep Cherokee as it was being driven on a highway near downtown St. Louis back in 2015? The back story is, those “hackers,” security researchers Charlie Miller and Chris Valasek, approached vehicle manufacturers several years before their high-profile feat, warning of the risks that security vulnerabilities posed for cars. However, manufacturers at the time didn’t consider cars to be targets for cyberattacks.
With the amount of hardware and software content enabling greater automation, vehicles actually have many potential points of security vulnerability—much like many of our other smart, connected IoT devices. Let’s take a look at key automotive areas that should be protected, why it’s important to keep security in mind starting early in the design cycle, and how you can protect the full car from bumper to bumper.
ECUs: Irresistible to Hackers
We can start our discussion with electronic control units (ECUs), the embedded systems in automotive electronics that control the electrical systems or subsystems in vehicles. It’s not uncommon for modern vehicles to have upwards of 100 ECUs running functions as varied as fuel injection, temperature control, braking, and object detection. Traditionally, ECUs were designed without the requirement that they validate the entities with which they communicate; instead, they simply accepted commands from and shared information with any entity on the same wiring bus. Vehicle networks were not considered to be communications networks in the sense of, say, the internet. However, this misconception has created the biggest vulnerability.
Going back to the . First, they exploited a vulnerability in the software on a radio processor via the cellular network, then moved on to the infotainment system, and, finally, targeted the ECUs to affect braking and steering. That was enough to get the automotive industry to start paying more attention to cybersecurity.
Today, it’s common for ECUs to be designed with gateways, so that only those devices that ought to be talking to each other are doing so. This presents a much better approach than having a wide-open network in the vehicle.
How Infotainment Systems Can Be Exploited
In addition to ECUs, cars can include other vulnerabilities that can allow a bad actor to hopscotch from one device inside the vehicle to another. Consider the infotainment system, which is connected to cellular networks for activities such as:
- Firmware updates to cars from vehicle manufacturers
- Location-based roadside assistance and remote vehicle diagnostic services
- Increasingly in the future, vehicle-to-vehicle and vehicle-to-everything functions
The thing is, infotainment systems also tend to be connected to various critical vehicle systems to provide drivers with operational data, such as engine performance information, as well as to controls, ranging from climate control and navigation systems to those that tie in to driving functions. Infotainment systems also increasingly have some level of integration with the dashboard—with modern dashboards becoming a component of the infotainment display. Given all the connections that exist in this vehicle subsystem and the powerful, full-featured software on them that performs these functions, it is probable that someone will exploit a vulnerability to hack into them.
Safeguarding In-Vehicle Networks
To prevent such attacks, it’s important to apply physical or logical access controls on what type of information gets exchanged between more and less privileged subsystems of the network. To ensure that the communications is authentic, it is also critical for in-vehicle networks to tap into the security experience gained over the past 30 years in the networking world by combining strong cryptography with strong identification and authentication. All these measures should be planned early in the design cycle to provide a robust security foundation for the system. Doing so early is less labor intensive, less costly, and more effectively scrutinized for residual risk than incorporating security measures piecemeal to address problems that emerge later.
The increasing popularity of Ethernet for in-vehicle networks is a positive development. Ethernet comes with some cost savings and some powerful networking paradigms that support the speeds needed for applications like advanced driver assistance systems (ADAS) and autonomous driving, as well as increasing applications of infotainment systems. Part of the Ethernet standard provides for devices identifying themselves and proving their identify before they are allowed to join the network and perform any critical functions.
NHTSA Automotive Cybersecurity Best Practices
The National Highway Traffic Safety Administration (NHTSA) suggests a multilayered automotive cybersecurity approach, with a better representation of the in-vehicle system as a network of connected subsystems that may each be vulnerable to cyberattack. In its updated released this month, NHSTA provides various recommendations regarding fundamental vehicle cybersecurity protections. Many of these would seem to be common-sense practices for development of critical systems, but these practices have been (and even continue to be) surprisingly absent from many. Among the suggestions for a more cyber-aware posture:
- Limit developer/debugging access in production devices. An ECU could potentially be accessed via an open debugging port or through a serial console, and often this access is at a privileged level of operation. If developer-level access is needed in production devices, then debugging and test interfaces should be appropriately protected to require authorization of privileged users.
- Protect cryptographic keys and other secrets. Any cryptographic keys or passwords that can provide an unauthorized, elevated level of access to vehicle computing platforms should be protected from disclosure. Any key from a single vehicle’s computing platform shouldn’t provide access to multiple vehicles. This implies that a careful key management strategy based on unique keys and other secrets in each vehicle, and even subsystem, is needed.
- Control vehicle maintenance diagnostic access. As much as possible, limit diagnostic features to a specific mode of vehicle operation to accomplish the intended purpose of the associated feature. Design such features to eliminate or minimize potentially dangerous ramifications should they be misused or abused.
- Control access to firmware. Employ good security coding practices and use tools that support security outcomes in their development processes.
- Limit ability to modify firmware, including critical data. Limiting the ability to modify firmware makes it more challenging for bad actors to install malware on vehicles.
- Control internal vehicle communications. Where possible, avoid sending safety signals as messages on common data buses. If such safety information must be passed across a communication bus, the information should reside on communication buses that are segmented from any vehicle ECUs with external network interfaces. For critical safety messages, apply a message authentication scheme to limit the possibility of message spoofing.
The NHTSA cybersecurity best practices report provides a good starting point to fortify automotive applications. However, it is neither a recipe book, nor is it comprehensive. NHTSA also recommends that the industry follow the National Institute of Standards and Technology’s (NIST’s) , which advises on developing layered cybersecurity protections for vehicles based around five principal functions: identify, protect, detect, respond, and recover. In addition, standards such as ISO SAE 21434 Cybersecurity of Road Vehicles, which in some ways parallels the ISO 26262 functional safety standard, also provide important direction.
Helping You Secure Your Automotive SoC Designs
Vehicle manufacturers have differing levels of in-house cybersecurity expertise. Some still opt to add a layer of security to their automotive designs near the end of the design process; however, waiting until a design is almost completed can leave points of vulnerability unaddressed and open to attack. Designing security in from the foundation can avoid creating vulnerable systems (see the figure below for a depiction of the layers of security needed to protect an automotive SoC). Moreover, it’s also important to ensure that the security will last as long as vehicles are on the road (11 years, on average).
Layers of security needed to protect an automotive SoC.
With our long history of supporting automotive SoC designs, 草榴社区 can help you develop the strategy and architecture to implement a higher level of security in your designs. In addition to our technical expertise, our relevant solutions in this area include:
- ASIL B-compliant DesignWare? tRoot? Hardware Secure Module for Automotive, which integrates a root-of-trust security solution with hardware safety mechanisms to protect against malicious attacks and random and systematic faults
- ASIL D-compliant ARC? SEM130FS Safety and Security Processor IP, which adds hardware redundancy to the side-channel attack protected processor to mitigate random hardware faults and avoid system failures
- Software integrity solutions designed to help build software security and reliability into the modern connected car
With the this year, the fact that most of them will be things that are not inherently secure is unsettling. Connected cars are part of this mix of things that should be made more resilient and hardened against attacks. While functional safety has become a familiar focus area for the industry, it’s time for cybersecurity to be part of the early planning for automotive silicon and systems, too. After all, you can’t have a safe car if it is not also secure.