One of the primary obstacles confronting OEMs today is the realm of automotive cybersecurity. This challenge has intensified due to the significant rise in integrated hardware and software within vehicles over the past few decades. Modern vehicles may contain upwards of 100 electronic control units (ECUs). This proliferation, combined with a rise in communication methods, has substantially amplified the array of vulnerabilities that cybercriminals can target.

The growing demand for automotive cybersecurity prompted the International Organisation of Standardization (ISO) and the Society of Automotive Engineers (SAE) to develop the ISO 21434 standard, titled ‘Road vehicles – Cybersecurity Engineering,’ released in 2021.

In this blog, we will delve deeper into the significant security risks associated with ECUs and the strategies that can be employed to mitigate these threats in the subsequent sections. Additionally, we will examine various security concepts that can be utilized to thwart such dangers, focusing specifically on their implementation. However, an exploration of cybersecurity processes will not be included in this discussion.

Below are some of the key methods through which hackers can take advantage of ECUs:

Compromising In-vehicle communication – Modern vehicles utilize various interfaces for communication, including CAN, K-Line, and Ethernet. These networks are vulnerable to exploitation by hackers who employ different intrusion techniques. One such method is sniffing, where data is intercepted and logged from a network. Another method involves spoofing, where an attacker impersonates a legitimate node in the network. These attacks can be categorized into two types: masquerade attacks, which involve corrupting the network by inserting misleading data, and replay attacks, where the impersonating node retransmits previously sent data from another node.

Gaining unauthorized access to vehicles – All modern vehicles are equipped with On-Board Diagnostics (OBD) systems and OBD ports that can communicate with Electronic Control Units (ECUs) over a CAN network to retrieve diagnostic information and performance data. Hackers can exploit these ports to inject malicious code and data into the network.

Tampering with ECU firmware and rogue updates – Attackers have the capability to alter ECU memory and modify the security keys used for software authentication. This allows them to reflash the ECU with their own custom firmware, leading to potential manipulation of the ECU’s state and unintended actions. Furthermore, they can introduce malware to gain control over the firmware.

To safeguard against these threats, implementing certain cryptographic algorithms is crucial for encrypting data transmitted across vehicle networks, securing access to vehicle diagnostics, and authenticating software updates. There are two primary methods to implement these cryptographic algorithms: traditional software-based approaches and those that utilize additional hardware components. The following sections will explore how both implementations can be carried out within an AUTOSAR ECU.

AUTOSAR provides a Crypto Stack that facilitates the conventional software-based implementation. This Crypto Stack offers standardized access to various cryptographic services, including hash computation, asymmetric signature verification, and symmetric data encryption.

The stack is structured into three layers: the service layer, the hardware abstraction layer, and the driver layer. The service layer, which is the highest layer, serves as the interface between the application and the lower layers of the stack. Its responsibilities include scheduling and queuing incoming cryptographic service requests based on their priority before relaying them to the lower layers for processing.

The hardware abstraction layer takes the crypto service requests from the service layer and directs them to the appropriate cryptographic operations within the driver layer. At the bottom of the stack, the crypto driver contains the actual implementations of cryptographic methods and facilitates key configuration and storage. In a traditional setup, the driver layer acts as a cryptographic software library, providing various services such as hashing and pseudo-random number generation.

Imagine a scenario where an application component within a vehicle needs to send a secure message to another software component. In this case, the application component would send the message to the service layer. The service layer would then organize the service request into the proper queue. Let’s say the message needs to be encrypted prior to reaching the next application component. The service layer would append the necessary information to the message and forward it to the hardware abstraction layer. The hardware abstraction layer would determine the appropriate driver needed to perform the required cryptographic operation, which in this case is encryption. Once the message is encrypted using the suitable encryption algorithm, it gets returned to the hardware abstraction layer, which subsequently passes it back to the service layer, and then sends it to the targeted application component.

The implementation of cryptographic algorithms can effectively utilize a mix of both hardware and software solutions. Examples of hardware components that can support the AUTOSAR Crypto stack in providing cryptographic services include the Hardware Security Module (HSM) and Secure Hardware Extensions (SHE).

A key benefit of employing a hardware solution like HSM over a solely software-based approach is the provision of a dedicated secure environment for security applications. This environment offers core functionality, secure memory, and hardware accelerators. The designated secure space has multiple advantages:

Various third-party vendors such as Vector, ETAS, and Elektrobit offer modular and adaptable stacks for hardware components like HSM. This modularity simplifies the integration of the stack within the AUTOSAR framework. HSM can deliver numerous security functions, including the storage of security assets and supporting cryptographic algorithms. Let’s explore in depth how a hardware component like HSM can collaborate with the AUTOSAR Crypto Stack to execute cryptographic services.

The firmware of HSM is composed of specific modules alongside standardized AUTOSAR modules. These Crypto modules in the HSM firmware align with the AUTOSAR Crypto Stack and consist of a service layer, hardware abstraction layer, and driver layer. The core of the HSM communicates with the Host core, which operates the application components and the AUTOSAR Crypto Stack, through an inter-processor communication interface (IPC).

Let us revisit the earlier scenario where a software component within a vehicle needs to transmit a secure message to another software entity.

On the Host side, similar to the conventional setup, the application component forwards the message to the Crypto stack. The functions of the Crypto stack are consistent with those described in the earlier traditional software-based implementation. However, a key distinction lies in the specifications regarding the cryptographic algorithms to be utilized, the keys designated for encryption, and related aspects, which are determined by HSM settings. This information is delivered to the Host through a specific HSM configuration file. Consequently, the configurations within the Host Crypto stack are aligned with this data. Moreover, details regarding IPC settings, such as version and channel count, are also transmitted to the Host via the configuration file. In this setup, the Crypto driver layer functions purely as an interface to the HSM, facilitating the IPC communication.

On the HSM side, the request for a crypto service (specifically, encryption in this context) received from the IPC channel is directed to the Crypto hardware abstraction layer. This layer forwards the request to the crypto driver, which executes the encryption cryptographic algorithm. Buffers in global RAM are allocated for the driver to accommodate all input and output data for the requested crypto operation. The access rights to this RAM section can be configured based on security requirements. Upon completion of the crypto operation, the host modules receive notifications through an interrupt or polling mechanism. The results of the cryptographic algorithm are relayed back to the Host Crypto driver via IPC and then passed on to the upper layers.

Modern vehicles’ ECUs come with various vulnerabilities that can be exploited by hackers, potentially endangering both drivers and pedestrians. Increased standardization in ECU components and software development efforts by organizations such as AUTOSAR has bolstered the defenses against such threats, yet there remains much work to be done to fully safeguard them against hacking attempts. It is imperative for vehicle manufacturers to prioritize cybersecurity and integrate it into the fundamental aspects of safety infrastructure.

At Ignitarium, cybersecurity remains a top priority for us. Our expertise encompasses various aspects such as bringing up security platforms, integrating security stacks, ensuring secure boot processes, and facilitating secure diagnostics.

Stay tuned for the upcoming article in this blog series, where we will delve deeper into the application of the Crypto software stack.

Welcome to DediRock, your trusted partner in high-performance hosting solutions. At DediRock, we specialize in providing dedicated servers, VPS hosting, and cloud services tailored to meet the unique needs of businesses and individuals alike. Our mission is to deliver reliable, scalable, and secure hosting solutions that empower our clients to achieve their digital goals. With a commitment to exceptional customer support, cutting-edge technology, and robust infrastructure, DediRock stands out as a leader in the hosting industry. Join us and experience the difference that dedicated service and unwavering reliability can make for your online presence. Launch our website.