This article is part of the How to Overcome Autonomous-Vehicle Networking Challenges series and in the Automotive topic of our Library: Article Series.
What you’ll learn:
- Environmental and safety requirements for vehicle hardware.
- Threat vectors for autonomous vehicles.
- Industry standards for vehicle security.
The last two articles addressed how sensor fusion is advancing the capabilities of autonomous vehicles (AVs), and how the electrification of vehicles has drastically changed how they’re designed and manufactured. But we haven’t yet touched on one very important aspect of this conversation—automotive safety and security.
The electronics, hardware, and semiconductors used to power modern vehicles and push them into the realm of L4/L5 autonomous and ADAS capabilities are incredibly complex. But unlike a telecom or data-center use case, vehicles have much harsher environments and much stricter safety requirements.
Whether it’s a network controller or an integrated circuit for a sensor, the reliability and security of automotive electronics are held to some of the highest standards to ensure high quality and safety throughout the operational life of the vehicle. Any point of failure, whether security vulnerability or part degradation, could put property and lives at risk.
Before diving into the topic of security, let’s first establish the environmental challenges for automotive systems that make this all so complicated.
Performing Reliably on the Road
When compared to typical commercial silicon designs, semiconductors for automotive use cases have much more stringent operational requirements. These chips face environmental challenges like extreme temperatures, moisture exposure, power stability and limitations, EMF radiation, and physical abuse due to vehicle vibrations.
It’s no surprise, then, that reliability and robustness are absolutely vital in automotive silicon designs, including implementing fail-safe and/or fail-operational conditions. This creates a distinct trial for designers who need to develop silicon that will operate as intended with high performance, under the assumption that failures in silicon are a possible—if not a guaranteed—eventuality.
To address this, all chips, systems, and hardware designed to be deployed in vehicles must meet the automotive safety integrity level (ASIL) requirements of the automotive OEMs. The ASIL, based on a use case and hazard analysis of each specific vehicle make and model, allows for an acceptable level of certainty that the vehicle electronics will perform as needed in various scenarios and conditions. Such standards are paramount in establishing trust with consumers.
Bringing Security into the Picture
Naturally, as our world becomes increasingly digital and connected, more devices and tools we use every day become vulnerable to cyber attackers. Such cyber threats and attacks continue to increase on a yearly basis, and the automotive industry is not immune.
The introduction of key features like remote updating and vehicle-to-everything communications in AVs and electric vehicles have created a growing attack surface for malicious actors to exploit. But automotive security is a different beast from many traditional commercial or industrial applications because as with hardware reliability, vehicle security also is a safety problem. A sub-par automotive safety architecture can lead to vehicle malfunction, putting consumers lives at risk.
As is usually the case with cybersecurity, this isn’t a simple problem to solve. Multiple dimensions and complexities need to be considered. For example, just a few threat vectors for a vehicle include:
- External networks: Cellular networks for telematics and Wi-Fi for entertainment are often a first attack vector. The vehicle connection to the telematic network could be hijacked and exploited, and personal devices that rely on vehicular Wi-Fi can be successfully attacked if the Wi-Fi link isn’t secure. Hackers have gained fame in the past by successfully controlling a vehicle’s steering and braking from a remote location.
- Internal vehicular networks: The lack of confidentiality in most automotive networks enables attackers to reverse-engineer ECU messages and understand the impact and function of each message. This allows them to spoof messages between ECUs and impersonate other internal devices.
- Vehicle internal ports: Diagnostic ports like OBD or OBD-II often aren’t secured and can be used for genuine or malicious software updates, including implementing unauthorized configurations through the diagnostic port protocol.
- External devices: Wireless key fob interactions with the car are usually relatively simple, utilizing a repeatable sequence of messages that can easily be copied. This leads attackers to design phone applications that replicate this process, allowing them to open and close the vehicle at will.
Engineers quickly realized that they would need to use cryptography to address the security challenges. They will require automotive hardware security modules (HSMs) to run cryptographic functions that will help combat the problem. Several initiatives have been launched in the industry to provide a formal framework and approach to vehicle security and detailed requirements for automotive HSMs
Industry Standards Help Address the Problem
One key example is the European research project e-safety vehicle intrusion protected applications (EVITA), which designed, verified, and prototyped the foundation for secure automotive on-board networks through hardware-security anchors and a software security layer. EVITA addresses various communications use cases, including vehicle-to-vehicle, vehicle-to-infrastructure, nomadic devices, aftermarket parts, and remote diagnostics.
Another popular initiative is Security Hardware Extensions (SHE), developed by the Hersteller Initiative Software (HIS) consortium founded by several automotive manufacturers in 2004 (i.e., Audi, BMW, Daimler, Porsche and Volkswagen). SHE focuses on providing secure storage and a secure processing environment for keys, based on an on-chip extension to provide hardware-based security.
There is also ISO/SAE J3101 and Automotive Open System Architecture (AUTOSAR), which each address broader security guidelines and requirements. ISO/SAE J3101 offers OEMs a systematic methodology to evaluate the quality of automotive security solutions. It appraises the hardware security lifecycle, key protection, key management, algorithms, entropy and randomness, secure execution environment, and interface control—even providing specific assessments for authenticated boot, authenticated updates, secure messaging, secure storage, or secure diagnostics use cases.
On the other hand, AUTOSAR is a framework that helps manage the complicated security requirements of the hundreds of interconnected ECUs in a vehicle. It enables a better understanding of how ECUs interact within the car.
Designing for Safety and Security
One key challenge for automotive is that safety and security are very closely intertwined. Any threats to the security of the vehicle hardware and software are immediate safety threats to consumers. On the other hand, security subsystems must be built in such a way that they’re resilient to faults to ensure their proper functioning.
For any semiconductor or integrated-circuit manufacturer wishing to serve the automotive market, the starting point is to fully understand the safety requirements and identify exactly what would violate them. This may tie to an overarching safety goal at the vehicular level based on a hazard and risk analysis, or more granularly be defined at the semiconductor level as a Technical Safety Requirement.
To explain it simply, hardware and software developers need to focus on addressing systematic failures and random failures. The former addresses the design and implementation level of the component. The latter requires updating the vehicular component with safety mechanisms that will mitigate the impact of random failures.
Experienced developers for this market will implement numerous safety mechanisms in the hardware design to identify and control failures to stay within the safety requirements. These can either be software, hardware, or a mixture of both.
To properly detect/mitigate threats while protecting the safety features of the vehicle hardware, a robust security architecture must be built into the technology. A proper security implementation inherently improves the safety and reliability of the part, making it more attractive to automotive OEMs.
This has led to a rise in embedded hardware security models utilized for automotive electronics, which offers a more complete safety and security package for silicon suppliers. Other examples include MACsec protocol engines (to secure Ethernet communications), chip identity authentication solutions, as well as secure key provisioning and management services. Companies need an adequate cybersecurity culture as laid out the standard ISO/SAE 21434, with the purpose of introducing security requirements and processes as early as possible in the product design and development process.
It’s ultimately impossible for automotive electronics and parts to be safe without also being secure. As security threats continue to rise over the coming years, robust automotive security will only become more vital and important for coming generations of vehicles. Especially as automotive SoCs continue to rise in complexity, it can be challenging for even veteran automotive hardware suppliers to address the safety and security aspects independently.
Nonetheless, it’s absolutely vital that engineers design systems for autonomous vehicles that are safe and secure to ensure vehicles meet consumers’ needs.
Read more articles in the How to Overcome Autonomous-Vehicle Networking Challenges series and in the Automotive topic of our Library: Article Series.