A complete reinvention of the automotive industry is currently underway. Autonomous driving, connected vehicles, and the electrification of the powertrain all represent a once-in-a-generation shift in the manufacturing process.
Traditional carmakers are repositioning themselves as technology companies, inserting upwards of three thousand chips in a new car today. These changes put tremendous pressure on delivering accurate and reliable data for proper operation. From the sophisticated imaging sensors of an autonomous driving system to the sensor continually monitoring power train system, modern cars rely on data being properly collected, processed, communicated, and stored.
The increasing complexity, regulation, and risk
An advanced driver assistance system (ADAS) makes decisions based on the real-time environmental data it collects from its sensors. As more cars become fully electric and require more sophisticated control systems, the number of lines of code (LOC) will rise from today’s 100 million to an estimated 300 million by 2030, according to McKinsey. As with driving data, this control code must also be protected from tampering, as it directly affects the occupants of any compromised vehicle. Additionally, the communications that flow between the hundreds of ECUs buried within a modern car, as well as to other vehicles (V2V), other external resources (V2X), and the power grid (V2G), will all need protection as well.
Various standards and regulations now guide the proper development of automotive cybersecurity and its focus on protecting consumer privacy, safety, and proper vehicle operations. They cover a wide range, from laws dealing with the general idea of information security to standards specifying how the software in a car can be securely updated. However, we can simplify our thinking by splitting them into the categories of information security, functional safety, internal/external communications, and software updates.
All major manufacturers aiming to sell in North America, Europe, and China must adhere to the information security policies and standards covered by China’s CSL, the EU’s GDPR, and ISO27001. The often-referenced ISO26262 standard deals with essential automotive functional safety, but is limited to safety-related systems. Thus, it is only tangentially related to cybersecurity, covering only how a security breach might affect those affected safety systems, rather than dealing with the topic of general automotive cybersecurity.
However, the framework of ISO26262 was used as a basis for the newer ISO21434 standard, which deals specifically with automotive cybersecurity. In particular, internal vehicle communications, such as between the ECUs inside a vehicle, are an essential part of automotive cybersecurity covered by ISO21434. Under this category of internal communications, we can also group the cybersecurity guidelines from the National Highway Traffic Safety Administration (NHTSA), as well as the regulation R155 put forth by the United Nations Economic Commission for Europe (UNECE) working party #29 (WP.29). SAE J3101 rounds out this category, covering the hardware mechanisms for accessing control and/or data of vehicles, which includes key fobs.
On the other end of the spectrum is the category of external vehicle communications, which covers messages and data between other vehicles, service providers, and offboard resources using the concept of the “extended vehicle.” The pertinent standards for this category include ISO20077 and ISO20078, which provide vehicle-to-grid (V2G) communications critical for the charging of electric vehicles. Finally, the fifth category relates to updating software and firmware. Here we see that since both ISO21434 and the NHTSA’s guidelines also cover software updates, they are also included in this category. In addition, both ISO24089 and the UNECE’s regulation R156 specifically deal with software update engineering, so they fit neatly into this category of software updates as well. We may note at this point that R156, along with R155, make up the WP. 29’s complete definition of their cybersecurity management system for automobiles.
Looking at the variety of categories that the standards and regulations relating to automotive cybersecurity may fit into, it’s clearly a complex issue requiring the adherence to multiple components and protocols simultaneously. That said, surveying the security solutions offered to date will still be beneficial, as seen here in Table 2. The listings here reflect different combinations of primitive cryptographic algorithms, a mix of supported security protocols, and various specialized hardware configurations. Three differing approaches to security are represented here: hardware separation, virtualization, and extensions implemented in hardware.
Security through hardware separation
These solutions offer a separate, secured section of hardware that is entrusted with a system’s sensitive data. The three examples from Table 2 that fall into this category are EVITA, TPM, and HSM. Like air-gapped computers left unconnected to a main network, these siloed-off security modules are not accessible by the rest of the CPU/SoC during normal operations. However, a critical difference between these three is that the e-safety vehicle intrusion protected applications (EVITA) and Trusted Platform Module (TPM) are two distinct and specific solutions, while hardware security module (HSM) is an umbrella term that can apply to any company’s proprietary and separate (from the main processor/CPU) security module.
Security through virtualization
More commonly known as a trusted execution environment (TEE), these virtually separated computing ecosystems are entrusted with a system’s sensitive data. By only allowing those processes deemed “secure” to access the TEE, system security is protected, while in reality, both “secure” and “non-secure” processes will be running on the same shared, underlying hardware platform.
Two of the most notable examples of this virtualization are Intel’s SGX and Arm’s TrustZone. The software guard extensions (SGX) from Intel are implemented through security extensions to the X86 instruction set, while TrustZone adds specialized hardware, such as the global TrustZone security controller (GTZC), to support Arm’s virtual separation between its TEE and rich execution environment (REE).
Hardware-implemented security extensions
The third and last category includes the security extensions that are added to an automotive microcontroller unit (MCU). To date, only the Secure Hardware Extension (SHE) solution from the Hersteller Initiative Software consortium resides in this category. More straightforward and lightweight when compared to EVITA, SHE is focused on protecting the cryptographic keys used by automotive MCUs.
Utilizing PUF Technology
Table 2 clearly shows an absence of standardization across the currently available hardware-implemented automotive security solutions. However, upon closer examination, some commonalities can be found, such as support for a symmetric cipher and a non-volatile memory (NVM). So while there currently is no “one-size-fits-all” automotive cybersecurity solution, we can still discern the essential components of a secure automotive solution. Central to this is a non-negotiable basis of trust that all security ecosystems are built on, the Root of Trust (RoT). Without such a core element, it is impossible to prove the security of any “trusted” system.
Building such an RoT on the naturally-occurring and intrinsic entropy of a Physically Unclonable Function (PUF) is a feasible and highly desirable solution, creating a Hardware Root of Trust (HRoT) that can underpin the entire security ecosystem of the vehicle. Furthermore, by using the common basis of a RoT, the deployment of solutions tailored to specific regulatory constraints can be simplified. Whether it be sensor data reporting, ECU communications, V2X, or another future auto system, protecting the various data and systems in a modern vehicle is paramount. And by stacking these cybersecurity protection measures upon the firm foundation of an HRoT, secure updates throughout the vehicle’s lifecycle are assured.
Our PUF-based Solutions
Since there is no one-size-fits-all solution for automotive security, PUFsecurity offers three different security IPs for the myriad of applications that make up a modern automobile system. For users that only require a secure location to store private data and keys, we have the Secure OTP IP with its anti-fuse cell array protected by anti-tampering designs backed by its built-in PUF. The next step up in protection is the hardware root of trust called PUFrt, which adds a PUF-based internal key provisioning system as well as a NIST SP800-90B compliant TRNG. Finally, there is PUFcc which includes a full cryptographic suite on top of PUFrt, featuring hardware-accelerated symmetric/asymmetric ciphers, public-key cryptography, secure hash, as well as both cipher- and hash-based message authentication code (MAC) generation. Because PUFsecurity’s solutions are based upon the hard macros (OTP and PUF) from eMemory, rest assured that they have been qualified under AEC-Q100 to have demonstrated proper functionality in high-stress automotive environments. Finally, all of PUFsecurity’s IPs support the functional safety reporting requirements as specified in the international ISO 26262 standard, which specifically deals with road vehicles.
Conclusion
Automotive cybersecurity is a complex subject, as evidenced by the number of regulations and the various types of solutions that have been surveyed in this article. However, the building blocks of a secure automotive system will inevitably look similar, even as vehicles evolve to incorporate autonomous driving, electrification, and increasing connectedness. The ever-increasing complexity of the modern automobile is a natural response to the liabilities involved. Therefore, automotive manufacturers and their suppliers must constantly be vigilant against a compromised system’s visceral, life-threatening risks, now and throughout a vehicle’s entire lifetime.