Improving security in automotive processors

Over the last few years, vehicle architecture has undergone rapid transformations due to the introduction of advanced features for improving safety, performance, and driving comfort. At the same time, the number of on-board electronic devices, controlled by dedicated electronic control units (ECUs), has escalated. At the center of these systems are automotive processors with functional safety and security features, dozens of sensors, and artificial-intelligence algorithms.

The evolution of the E/E architecture has inevitably entailed the need to address and manage the security of vehicles, which are increasingly exposed to potential attacks by hackers or criminals. Wireless firmware updates (OTAs), connection to the 5G network, and communication between vehicles are significantly increasing data traffic, leaving the door open to potential attacks or interception of valuable information by hackers or attackers.

Next-gen cars: innovations and risks

The panorama of innovations introduced in the automotive industry is vast, including advanced driver-assistance systems (ADAS), such as collision avoidance, adaptive cruise control, lane-departure warning, parking assist, and driver-fatigue detection; vehicle-to-vehicle (V2V) and vehicle-to-everything (V2X) (Figure 1); autonomous driving, software-defined vehicles, automotive Ethernet, and domain controller units.

Figure 1: Connected cars can exchange data in real time. (Source: Shutterstock)

In most cases, these systems are governed by electronic devices with multicore processors, a high number of sensors, and AI algorithms; as such, they require a high degree of security. Manufacturers of highly integrated electronic components must therefore integrate appropriate measures to ensure security, high quality, and reliability throughout the product’s operational life.

It is important to observe how in automotive systems the concepts of security and functional safety are directly connected to each other. The objective of functional safety is to ensure that each vehicle’s capability is carried out effectively for the entire expected life of the component or system, without compromising the safety of the user. Regulated by specific standards, primarily ISO 26262, functional safety is directly connected to security, as the same system that implements the functional requirements must be protected and resist possible attacks.

In the electronic design of the vehicle, the security and safety aspects must go hand in hand. In the absence of a robust security architecture, penetration points can be created that can impair system operation. Robustness, both at the hardware and software levels, is an essential requirement for security. A malfunction or degradation of even a single part of the system must not in any way jeopardize its vulnerability.

Security is paramount

The security of an electronic device must concern both systematic faults and random faults. A strict intellectual property, system-on-chip (SoC), or microcontroller (MCU) development approach helps to prevent systematic errors. To reduce random errors, the system might be designed with redundancy and ongoing inspections should be performed during the product’s lifetime.

Designers are searching for a clear way to integrate security and safety into their automotive processors due to the rising security risks mixed with new standards and market needs. However, due to the complexity of new designs, adding discrete functional safety and security features might not produce the best results. Processors for secure and safety-critical automotive applications must have built-in functional safety features as well as a defense against malicious attacks. A new generation of safe and secure cars will be possible by considering both functionalities throughout the design phase and during the processor selection process.

The V-Model development process, whose graphical representation is shown in Figure 2, summarizes the design phases of a hardware or software system and, as such, is applicable to the previously mentioned security concept. The process of developing a secure system can be considered complete when both hardware and software components meet the requirements defined in the system specifications.

Figure 2: V-Model graphical representation (Source: Shutterstock)

Reference standards

The standards for automotive processors provide designers with guidelines to mitigate threats to the vehicle’s electronics. Although the list of applicable standards is quite rich, a selection of the most significant in terms of hardware is highlighted below.

SAE J3101

The Society of Automotive Engineers (SAE) and the International Organization for Standardization (ISO) established the SAE J3101 standard a few years ago to meet the unique hardware security requirements for ground vehicles. The standard specifies a detailed set of requirements for automotive hardware security, including hardware security life cycle, key protection, key management, algorithms, entropy and randomness, a secure execution environment, and interface control.

Additionally, it connects the criteria to real-world scenarios like authenticated boot, authenticated updates, secure messaging, secure storage, and secure diagnostics. It should be noted that this standard does not define a particular hardware design or solution for implementing the requirements. Rather, it provides a methodical means of determining whether a given solution is properly addressing the vehicle’s safety requirements.

Secure Hardware Extension

Secure Hardware Extension (SHE) is a standard created by a consortium of several car makers, including Audi, BMW, Daimler, Porsche, and Volkswagen. It provides a specification for an on-chip extension to an automotive MCU. It aims at providing secure storage and processing environments for cryptographic keys.

The automotive MCU’s cryptographic keys are the primary target of this system, together with the authenticity of the MCU’s software environment and the provision of cryptographic services. SHE has found a lot of success in the automotive market because it requires a light hardware solution. It provides a widely used and straightforward application programming interface for implementing security protocols.

According to this standard, hardware-based security is a mandatory requirement. The management of the secure keys must be performed inside a dedicated and protected hardware module, which includes cryptographic acceleration, a pseudo random-number generator, volatile and nonvolatile memories, and control logic to sequence the cryptographic operations and control the keys.

Even though this standard does not specify a specific hardware design, it provides requirements that can be met by many commercial MCUs, provided they are equipped with a SHE extension.

EVITA

In 2008, the European Commission financed a project called E-Safety Vehicle Intrusion Protected Application (EVITA), which provides an architectural framework to address the security needs of automobile ECUs. When establishing these criteria, EVITA considered a variety of use cases, assets, threats, and attack methodologies specific to automotive systems.

Hardware security modules (HSMs) were designed and implemented according to EVITA specifications for usage as trusted subsystems within ECU SoCs; these were based on the Trusted Platform Module (TPM) standard for secure cryptographic processors.

The suggested approach relies on hardware-security anchors and a software security layer that takes advantage of these modules. Applications installed on mobile devices, aftermarket replacement of parts, remote diagnosis, and intervehicle communication are all within the scope of the use cases. The project delivered a list of security criteria, including a secure execution environment for the ECUs, authenticity, integrity, freshness, confidentiality, controlled access, and availability of the data passed between the ECUs and shown to the driver.

EVITA’s solution is a standard for HSMs, which are available in three flavors to account for varying ECU processing power. For large ECUs like the head unit, the recommendation is to upgrade to the full EVITA version. ECUs like the engine control or central gateway should use the EVITA medium version. Brake actuators and airbag actuators are just two examples of ECUs that can benefit from the lightweight variant.

The EVITA specification emphasizes two key concepts: hardware-based security, and co-location of the HSM and the host system’s CPU on the same chip.

Hardware design solutions

The concept of the hardware security engine and HSM has been implemented by many chipmakers, while others have introduced their own architecture to provide the security feature at the hardware level. Some of these design solutions will be presented here.

Developed by STMicroelectronics, Telemaco3P (telematics and connectivity processors, including the STA1385 SoC and its variants) is the first family of automotive microprocessors to integrate a powerful, dedicated, isolated HSM. Securely verifying the authenticity of received messages and any external devices attempting to connect, the HSM acts as an independent security guard to prevent eavesdropping and to monitor data exchanges.

By running software-security algorithms, the HSM frees up the main high-performance CPU to handle more complex tasks, in addition to implementing state-of-the-art security techniques like symmetric and asymmetric cryptography. Featuring a single or dual ARM Cortex A7 plus an ARM Cortex M3 for managing an independent and isolated CAN subsystem, the Telemaco3P processor provides a security block with HSM, boot code authentication, and tamper detection (Figure 3).

Figure 3: STMicroelectronics’ Telemaco3P block diagram (Source: STMicroelectronics)

ARM provides different hardware solutions, based on a combination of HSM modules, proprietary TrustZone technology, and virtualization. For light HSM architectures (simple and secure communication between small ECUs and clusters of sensors and actuators), one solution (Figure 4) is based on an ARM Cortex-M processor with TrustZone technology, which enables secure services to run in isolation from the operating system (OS). With TrustZone, the processor can execute instructions in one of two security modes: normal world (where untrusted code executes) and the secure world (where secure services run). These processor modes have independent memory address spaces and different privileges.

Figure 4: Light HSM architecture (Source: ARM, “Architecting Secure Automotive Systems” whitepaper)

For medium and full HSM architectures, the solution proposed by ARM is based on virtualization, a way to achieve strong runtime isolation. Virtualization-based security architectures allow for the secure execution of multiple, fully featured runtime environments (virtual machines, or VMs) on a single computing platform, resulting in more effective use of all available physical resources.

A strong defense against unauthorized access to data, functions, or the execution or performance of other applications is provided by this feature, which ensures that subsystems, components, or even individual applications can communicate only through strictly controlled communication channels. Virtualization architectures use a compact, high-performance kernel to ensure a secure isolation layer. The practical application can be implemented in hardware, software, or a hybrid of the two.

A second example is shown in Figure 5. The ECU architecture consists of a virtualized hardware platform, with an ARMv8-R architecture CPU, which runs a hypervisor for securely scheduling and isolating VMs. The VM operates on the hypervisor’s implementation of the hardware interface. Each VM has its own OS and software environment, which includes an application that has been fully instantiated and configured. Each VM is typically set up to run a single automotive application (the firmware of a single-function ECU), with the runtime environment and OS included and tailored (minimized) to the needs of that specific application.

Figure 5: Hypervisor-based ECU design (Source: ARM, “Architecting Secure Automotive Systems” whitepaper)

Conclusion

Innovations introduced in infotainment systems, ADAS, wireless firmware upgrades, and in connected cars have dramatically increased the number of entry points that hackers can exploit to access the vehicle’s functions. Hence, security has become paramount in automotive applications.

At the regulatory level, standards have been introduced to provide chip manufacturers and automotive designers with specifications and guidelines for implementing security mechanisms inside vehicles. In the automotive industry, where the product has an average life of several years, it is essential that designers develop hardware systems capable of anticipating and preventing any form of potential attack.