Cybersecurity for Automotive ECUs – An Introduction

Need for automotive cybersecurity

One of the biggest challenges faced by OEMs today is automotive cybersecurity with the amount of hardware and software integrated into vehicles increasing significantly over the last few decades. There can be as many as 100 ECUs embedded in modern vehicles. That, along with increase in communication options, has greatly increased the number of vulnerabilities that hackers can exploit. 

The need for automotive cybersecurity eventually led the International Organisation of Standardization (ISO) along with Society of Automotive Engineers (SAE) have come up with the ISO 21434 standard ‘Road vehicles – Cybersecurity Engineering’ in 2021.

In this blog, we will explore further the major security risks in an ECU and the measures that can be taken to prevent such threats in the following sections. We will also see in detail the different security concepts that can be used to prevent such threats strictly from an implementation point of view. However, we will not be discussing the cybersecurity processes in this blog.

What are the major threats for an ECU?

Listed below are a few of the major ways in which hackers can exploit ECUs:

Compromising In-vehicle communication – Communication in modern vehicles is handled by multiple interfaces like CAN, K-Line, Ethernet, etc. Hackers exploit such networks using various intrusion methods. For example, sniffing – which includes intercepting and logging data from a network. Another way in which hackers can exploit vehicle networks is by spoofing, i.e., by pretending to be another legitimate node in the network. These kinds of attacks can be of two types: masquerade attacks, where data is inserted that corrupt the network and replay attacks, where the “pretend” node replays data which was sent by another node in a previous iteration.

Gaining unauthorized access to vehicle – Modern vehicles all have on On-Board Diagnostics (OBD) and OBD ports that can communicate with the ECUs via CAN network and get diagnostic information regarding the faults in the vehicle and performance characteristics. Hackers can gain access to these ports and inject data & malicious code into the network.

Tampering ECU firmware & rogue updates – Attackers can modify ECU memory and change the security keys which are used for software authentication. They can reflash the ECU with their custom firmware and manipulate its state and perform unintended actions. They could also introduce malware and take control of the firmware.

Preventive Measures

For protecting against the above-mentioned threats, certain cryptographic algorithms need to be implemented to encrypt the data transmitted in vehicle networks, for securing access to vehicle diagnostics, authenticating the software flashed etc. There are basically two ways of implementing these cryptographic algorithms: traditional software-based implementation & implementation with usage of additional hardware components. We will see in the upcoming sections on how the two implementations can be done in an AUTOSAR ECU.

Traditional Implementation

AUTOSAR provides the Crypto Stack for facilitating the traditional software-based implementation. Crypto Stack offers standardized access to cryptographic services like computation of hashes, asymmetrical signature verification, symmetric encryption of data etc.

The stack is divided into 3 layers – service layer, hardware abstraction layer and driver layer. The topmost layer, i.e., the service layer acts as an interface between Application & the lower layers of the stack. It is responsible for scheduling and queueing the received crypto service requests based on their priority. It forwards the requests to the lower layers for further operations.

The abstraction layer receives the crypto service requests from the service layer and forwards them to appropriate cryptographic operation in the driver layer. The lower most layer i.e., the crypto driver holds the actual cryptographic implementations and supports key configuration, key storage, etc. In traditional implementation, the driver layer is a cryptographic software library which supports various services including hash services & pseudo random number generator.

Let us consider a scenario where an application component inside a car must send a message to another software component but this message must be secured. In this case, the application component will pass on the message to the service layer. This service layer distributes the service request to the appropriate queue. Let’s assume that the message must be encrypted before sending to the next application component. The service layer will add the required information along with the message and will send it to the hardware abstraction layer. The hardware abstraction layer will identify to which driver it should be passed so that the required cryptographic action (viz. encryption here) can be performed. In our example, the message is encrypted using the appropriate encryption algorithm. After encryption, the message is sent back to the hardware abstraction layer which in turn sends it to the service layer from which it is sent to the required application component. 

Hardware and Software Based Implementations

The cryptographic algorithms can be implemented with a combination of hardware and software as well. Hardware Security Module (HSM) and Secure Hardware Extensions (SHE) are examples of hardware components that can be used along with the AUTOSAR Crypto stack to facilitate cryptographic services.

The main advantage of using a hardware component like HSM compared to a purely software-based implementation is that it can provide a dedicated secure space for security applications like core, secure memory and hardware accelerators. The secure space can:

• Provide security services to the application
• Store keys and related security assets
• Manage keys and certificates 
• Execute cryptographic algorithms using hardware/software implementations

There are stacks provided by third party vendors like Vector, ETAS, Elektrobit etc., for hardware components like HSM which are designed in a more modular and flexible way. This makes it easier to integrate the stack with the AUTOSAR environment. HSM provides many security services like storage of security assets and cryptographic algorithms. Let us see in detail how a hardware component like HSM can be used along with AUTOSAR Crypto Stack to implement cryptographic services.

HSM firmware consists of specific modules as well as standardized AUTOSAR modules. HSM firmware consists of Crypto modules which correspond to the AUTOSAR Crypto Stack, with service layer, hardware abstraction layer and driver layer. The HSM core uses inter processor communication interface (IPC) for communicating with the Host core which runs the application components and the AUTOSAR Crypto Stack.

Now let us consider the previous scenario where an application component inside a car must send a secured message to another software component.

At the Host side, as with the traditional implementation, the application component will pass on the message to the Crypto stack. The functionality of the Crypto stack remains the same as explained in the previous traditional software-based implementation. The major difference is that the information on the cryptographic algorithms that can be performed, the keys that should be used for encryption etc., is defined by HSM settings and this information is passed to the Host with the help of a specific HSM configuration file. So, the configurations in Host Crypto stack will correspond to this information. Additionally, information on IPC settings like version and number of channels are also passed to the Host with the help of the configuration file. Also in this implementation, the Crypto driver layer just acts as an interface to HSM and provides the IPC communication.

At the HSM side, the crypto service request (viz. encryption here) received from the IPC channel is forwarded to the Crypto hardware abstraction layer. It dispatches the request to the crypto driver which performs the cryptographic algorithm for encryption. Buffers are allocated for the driver in global RAM to store all the input and output data for the requested crypto operation. The access rights for this RAM section are configurable based on the security needs. When the crypto operation is finished, the host modules are notified via interrupt/polling mechanism. The output of the cryptographic algorithm is read back by the Host Crypto driver layer via IPC and is forwarded to the higher layers.

Conclusion

ECUs in modern vehicles present a wide range of vulnerabilities that hackers can exploit, potentially resulting in harm to drivers and pedestrians. Growing standardization in ECU components and software development undertaken by groups like AUTOSAR has increased the level of protection against such threats, but still much remains to be done to completely secure them against hacking. It is high time that the vehicle manufacturers consider cybersecurity with priority and make it a critical part of the safety infrastructure.

Cybersecurity is a key focus area for Ignitarium; our capabilities include security platform bring up, security stack integration, secure boot, secure diagnostics etc.

Please look out for the next article in this blog series for understanding more about the usage of the Crypto software stack.

References

• https://www.electronicdesign.com/markets/automotive/article/21258959/electronic-design-taking-action-to-further-protect-automotive-ecus
• https://cdn.vector.com/cms/content/events/2019/vSES19/vSES19_07_Lohmann_Vector.pdf
• AUTOSAR Specification of Crypto Service Manager
• AUTOSAR Specification of Crypto Driver
• AUTOSAR_EXP_UtilizationOfCryptoServices
• AUTOSAR_SRS_CryptoStack.pdf