Search Results for: automotive security

Ann Steffora Mutschler of Semiconductor Engineering recently wrote an article that takes an in-depth look at automotive security challenges. As Mutschler notes, automakers are “scrambling” to prevent security breaches and data hacks in new vehicles. Concurrently, they are adding new and increasingly autonomous features into vehicles that open the door to new vulnerabilities.

“As with any complex system, nothing is ever completely secure. But even getting a handle on this multilayered issue is a challenge,” she explains. “Vehicle architectures today, and those being developed for future vehicles, are increasingly complex and often beyond the control of any single company.”

This is because vehicle architectures typically involve both hardware and software components, with data generated and processed at multiple levels and locations, such as within a vehicle, between vehicles (V2V), and externally via connected infrastructure.

“Some of that data is critical to the functionality of the vehicle and tightly controlled, but even less-critical data can provide a potential attack vector,” she adds.

Thierry Kouthon, technical product manager at Rambus, concurs.

“We have many challenges with vehicles today because there is an increasing amount of advanced driver assistance systems (ADAS) that require a lot of electronic control units,” Kouthon tells Semiconductor Engineering. “All the functions of the car that in the old days were mechanical or hydraulic are now computerized. Otherwise, you cannot control the car by computer. But this also provides [an attractive] attack surfaces for hackers.”

As Kouthon highlights, infotainment systems are a prime entry point for attacks due to a number of wireless connections to the vehicle. There is also the electrification of vehicles, which multiplies the number of electronic control units (ECUs). And although there are fewer moving parts, there are more electronic components that create a wider attack surface. This is especially true for autonomous vehicles which require even more advanced electronic systems.

Vehicle-to-everything (V2X) adds yet another potential attack vector, as cars and trucks will eventually communicate with traffic lights, other vehicles, and even pedestrian devices. In addition, V2X-enabled cars will communicate with non-V2X-enabled cars—or earlier iterations of the evolving technology.

“[This] means you want to make sure the communication protocols work together. Everything is wireless, and there are two main standards—5G/cellular network-based and DSRC, which is based upon direct radio frequencies between cars,” says Kouthon. “All those are almost interchangeable, and maybe both will work. [However], since you don’t have any physical connection and you are communicating wirelessly with your environment, you [must] make sure that all those messages are authentic.”

According to Kouthon, drivers need to be sure data relayed from traffic lights and stop signs is legitimate—and not spoofed by hostile hackers trying to cause an accident.

“[This] becomes an authentication problem,” Kouthon elaborates. “Authentication means that all the messages are signed with a signature, so the car can verify this message originates from a genuine source, and that it’s not a fake traffic light or rail crossing infrastructure. It needs to be a genuine one that is actually run by the city.”

In addition to potential security issues posed by city infrastructure, vehicle-to-vehicle (V2V) communication is expected to be another complex challenge, making it especially important for manufacturers to agree on a clearly defined set of protocols. This will enable vehicles to seamlessly—and securely—identify and authenticate each other.

“[The issue] of certificate distribution is an old problem that has been very well studied in the context of websites on the internet. [It is] usually pretty complex [because] certificate chains can be very long,” Kouthon explains. “In the case of the car, the challenge is to make sure that the verification sessions are very quick [so a vehicle can] verify up to upwards of 2,000 messages per second.”

Verification, says Kouthon, has implications for automotive infrastructure because it must be rapidly executed.

“[This] also impacts the certificate format, their nature, and it means you cannot design these exactly like websites were designed, where they could authenticate each other,” he adds. “With a website, it’s assumed that the user can wait a couple of seconds, whereas in the car, decisions [must] be made in microseconds.”

As Kouthon emphasizes, anchoring security in hardware is foundational to safeguarding all automotive electronic systems. This can be done by embedding a hardware root of trust in the ICs used in automotive ECUs.

“Rambus offers ISO-26262 ASIL-B and ASIL-D ready hardware root of trust cores tailored for automotive applications. These root of trust cores (RT-640 and RT-645 respectively) protect against a wide range of failures such as permanent, transient and latent faults, and hardware and software attacks with state-of-the-art anti-tamper security techniques,” he concludes.

Thierry Kouthon, a technical product manager at Rambus, recently wrote an article for Semiconductor Engineering that takes a closer look at the critical importance of securing automotive electronics. As Kouthon notes, modern cars can have up to 100 Electronic Control Units (ECUs) depending on their class, make, and model – with the number of ECUs rising even higher in electric vehicles.

What is an ECU?

“An ECU is an embedded system in the car’s electronics,” Kouthon explained. “They are used to control all the vehicle’s functions, including engine, powertrain, transmission, brakes, suspension, dashboard, entertainment systems and more.”

According to Kouthon, the increasing popularity of self-driving vehicles has accelerated this trend, especially given the critical reliance on sensors and actuators to control and respond to external conditions.

“The reliability of these electronic components can be mission critical to the safety and reliability of the vehicle,” he elaborated.

 

---

Keep on reading.
Primer: Autonomous vehicles explained.

---

 

What is the most common automotive security standard?

“…industry standards [like] ISO 26262 have been developed to ensure the functional safety of automotive electrical and electronic systems.”

Essentially, the ISO 26262 standard defines a risk-based approach to dealing with (potential) hazardous operational situations occurring with the automobile’s electronic equipment. More specifically, the standard relies on Automotive Safety Integrity Levels (ASILs) to determine risk classes for various ECUs in the vehicle. For example, the engine control ECU belongs to a higher risk class than the ECU responsible for the taillights. Four integrity levels exist from A (the least demanding) to D (the strictest), leading to varying constraints and requirements for the ECUs.

From a practical standpoint, says Kouthon, designing ECUs to be ASIL-compliant requires the addition of verification hardware and safety mechanisms such as redundancy of critical components, error correction codes, Built-in Self-Tests (BIST), system watchdogs, and cyclic-redundancy checks.

“The ECUs also need to control an increasing number of sensors and actuators.

For example, an airbag ECU controls several airbags in a vehicle in addition to acceleration, angular rate, and pressure sensors to evaluate direction and intensity of impact,” he states. “These added mechanisms and components increase the complexity of the system and hardware verification process. They require a different verification flow than the one used for non-automotive hardware. The verification process must also support fault-injection to test for various fault handling scenarios.”

Is the verification of automotive ECUs and sensors a challenging process?

“[Yes], verification needs to cover real-time embedded mixed-signal domains and must be done at the system level, not only at the component level,” he continues. “[In addition, certain] verification scenarios require time to complete, which conflicts with the automotive industry’s stringent production calendars that demand first-time-right designs.”

Moreover, as there are four different ASIL levels, the verification scope must verify a device against both internal and external specifications (depending on its expected safety level). To be sure, all devices within a specified category must meet or exceed the ASIL established threshold. This approach provides a uniform, unbiased criteria for evaluating solutions that are essential components for the design of safety-critical systems.

As Kouthon emphasizes, automotive cybersecurity adds yet another set of constraints to verification because all safety-critical systems are security-critical systems. Indeed, a successful cyber-attack against a safety-critical system could potentially lead to human endangerment. However, the converse is not true, as security-critical systems, such as infotainment, are not necessarily safety critical.

“Automobiles are an attractive target for hackers,” he explains.

“They have been successfully breached in many highly publicized experiments, sometimes leading to a take-over of the vehicle from a remote location using its infotainment system as a gateway.”

Standards such as SAE J3061 and ISO/SAE 21434 focus on automotive cybersecurity to avoid such occurrences. In general, cybersecurity tends to focus on potential threats rather than hazards, and those threats are more challenging because they may be undiscovered.

“Security requires known behavior under all circumstances, so the verification scope must be increased to cover expected inputs and unexpected/unauthorized/illegal inputs,” Kouthon elaborates. “This dramatically increases the scale of the verification effort. The challenge is to include the additional input set and perform proper verification, and all this within the time constraints imposed by automotive production calendars.”

Keep on reading: SAE level of automation in cars simply explained (+Image)

What is the foundation of safeguarding any electronic system?

As Kouthon points out, the foundation of safeguarding any electronic system is security anchored in hardware. This can be achieved by embedding a hardware root of trust in the ICs used in automotive ECUs.

For example, Rambus offers ISO-26262 ASIL-B and ASIL-D ready hardware root of trust cores tailored for automotive applications. These root of trust cores (RT-640 and RT-645 respectively) protect against a wide range of failures including permanent, transient and latent faults, and hardware and software attacks with state-of-the-art anti-tamper security techniques.

“By partnering with Rambus, a company with over 20 years of renowned security experience, automotive designers can help ensure their safety critical SoCs are safeguarded against cyberattack,” he concludes.