Over the past 30 years, vehicle electrification has evolved from simple control logic to computer-based tasks such as powertrain control and signal processing for autonomous driving. Modern automotive systems often contain dozens of different computers, known as electronic control units (ECUs), including sensors and high-performance computing platforms. Since the production of a modern car often involves many suppliers and manufacturers, certain standards need to be established. In the 1990s, starting from OSEK/VDX, etc., the development of AUTOSAR standards was very slow. The standard was developed by the AUTOSAR Alliance to provide a common software architecture specification for all manufacturers and suppliers in the automotive industry.
AUTOSAR-based ECU threat models should include local and remote attackers, as well as attackers with different budgets, techniques, and motivations. Although AUTOSAR and the standards based on it (such as MISRA C) can provide higher security for more robust software, ECUs can still be attacked by hardware.
This paper not only introduces AUTOSAR in detail, but also discusses it in more detail in this context. Attackers can identify software vulnerabilities by examining the code (if source code is provided) or reverse engineering (if only binary software is provided). We use the freely available AUTOSAR software stack and describe several specific scenarios to better characterize the approach to introducing software vulnerabilities into AUTOSAR-based ECUs.
When software vulnerabilities are unknown, attackers may resort to other types of attacks. Several of these types are described here, ranging from simple PCB-level attacks such as debug interfaces to more advanced hardware attacks such as fault injection. These hardware attacks may eventually lead to loss of ECU control and/or failure of (secure) information extraction. Furthermore, there is also the potential for hardware attacks to lead to tampering of ECU firmware if proper code signing mechanisms (i.e. secure boot) are not implemented, which is generally not considered necessary for devices that store and execute code only from internal memory.
01 AUTOSAR
The automotive operating system has very different tasks and responsibilities from the classical computer system. The automotive operating system needs to process sensor information in real time and communicate with other ECUs using bus protocols extensively. According to the AUTOSAR specification, a three-layer abstraction approach is required to simplify software development, where specific microcontroller drivers, kernel, and communication protocol stacks need to be implemented in the base software layer (BSW). At the same time, through RTE, user applications can be developed parallel and independent to the basic hardware to access the functions and features of BSW. Figure 1 illustrates this layered approach.
Figure 1. AUTOSAR layered software architecture
There are two different versions of the AUTOSAR standard: AUTOSAR Traditional Platform and AUTOSAR Adaptive Platform. Since the AUTOSAR traditional platform is statically linked, it is usually used in the core ECU deep in the car, and has poor flexibility. In contrast, the AUTOSAR Adaptive Platform is dynamically linked and uses C++14 features, so it is often used in high-performance and highly connected ECUs with high flexibility. AUTOSAR series standards have been widely used in major automotive suppliers, and the main object of this research is AUTOSAR traditional platform.
02 Software attack
The automotive AUTOSAR standard builds on recognized secure coding standards such as MISRA C and CERT C, and is primarily used to produce safe and reliable software for ECUs. Therefore, it can be considered that the software based on AUTOSAR and completely in accordance with the above two coding standards should be safe and reliable. This section provides several scenarios for introducing software vulnerabilities into different AUTOSAR components, but it is worth noting that the examples in this article are only individual presentations.
A．MCAL vulnerability
The Microcontroller Abstraction Layer (MCAL) is usually bundled with the MCU, that is, the MCAL is often developed by the MCU manufacturer. Therefore, ensuring that the MCAL of the MCU fully complies with the AUTOSAR specification is a prerequisite for realizing MCU integration. All major MCU manufacturers are required to provide such AUTOSAR-compliant MCAL packages for their MCUs, otherwise they risk introducing software vulnerabilities. Therefore, developers of MCAL must ensure a secure implementation of MCAL. In addition, MCAL integrators can also conduct security code reviews to check whether MCAL is implemented safely according to AUTOSAR requirements.
Under normal circumstances, how the functions of MCAL are used in the upper layer of AUTOSAR software plays a decisive role. For example, in the case that there is an exploitable integer overflow vulnerability in the EEPROM driver, if the transmission of parameters of the EEPROM driver is restricted, the vulnerability may not be exploited. Nonetheless, we still believe that it is critical to ensure bug removal at all layers of the AUTOSAR software architecture. Especially considering that in the future the vulnerable driver may change during use, making this software vulnerability exploitable. In other words, MCAL should not blindly trust the data delivered by upper layers.
B．Communication Service Vulnerability
The introduction of new complex communication stacks, such as Ethernet, can have an impact on the automotive industry. This is because, compared with the traditional communication protocol stack (i.e. CAN), the new communication protocol stack needs to parse complex data structures, which makes the protocols built on the top layer (i.e. TCP/IP, UDS, etc.) more susceptible to software Vulnerability attack. An ECU based on a real-time operating system (RTOS) usually cannot use a communication protocol stack derived from general-purpose computing (such as Linux) because it cannot comply with the requirements of the RTOS. The communication protocol stack does qualify, but usually has not been properly tested. Recent research has shown that the TCP/IP stack of FreeRTOS is full of exploitable vulnerabilities. SAFERTOS also uses this vulnerable TCP/IP (this TCP/IP is an ISO 26262 ASIL-D pre-certified protocol stack). Therefore, appropriate checks are required for communication stacks, and integrators of these communication stacks need to ensure that relevant verification tests are performed.
03 Hardware attack
Hardware attacks require the attacker to be physically present on the target. In addition to using externally exposed interfaces, most hardware attacks require the attacker to open the device. Although several of the attacks described in this chapter require specialized tools, some are readily available. For well-funded attackers such as organized crime and state actors, access to other high-end tools is even better.
A．PCB level
Attacks at the printed circuit board (PCB) level include basic hardware attacks where an attacker opens an ECU to probe and/or modify its PCB to extract the contents of non-volatile memory, access debug interfaces, or log chip-to-chip communications. Depending on the design of the ECU, other attacks are also possible. If adequate measures are not taken to prevent these attacks, the ECU can be completely compromised. In cases where the ECU cannot be completely destroyed, higher-level attacks such as fault injection and side-channel analysis are performed using information obtained from PCB-level attacks.
1) Modify the content of external memory: An attacker can use a standard flash programmer to modify the content of external memory (eg eMMC). In other words, if an attacker is able to modify the code stored in external memory, he can execute arbitrary code on the ECU. Indirectly, the modification of the content can also be realized by modifying the data, resulting in software vulnerabilities. Since the security of code and data originating from external memory cannot be trusted, all code and data stored in external memory should be authenticated (i.e., implement secure boot) before being used.
2) Extracting the contents of external memory: An attacker can use a standard flash programmer to extract the contents of external memory (such as EEPROM). Security-sensitive data stored unprotected (that is, not encrypted) in external storage can be compromised by an attacker gaining physical access to the device. Therefore, it is necessary to encrypt security-sensitive data stored on external memory chips.
3) Debugging interface: All MCUs have a hardware debugging interface for accessing the MCU, so these debugging interfaces should be properly protected. The tools and knowledge to communicate with the hardware debug interface are within reach. However, if an attacker is able to communicate with the hardware debug interface, the security of the ECU can be completely compromised, so most original equipment manufacturers (OEMs) require protection measures for these debug interfaces to reduce such threats
4) Signal modification: Security-relevant data should not be stored in external memory, especially if the integrity of that data needs to be guaranteed. The try counter in UDS security access is a relatively error-prone case. The try counter should be implemented as-is according to the AUTOSAR standard, and after three incorrect authentication attempts are performed, a ten minute try delay will be triggered. If the try counter is stored in the external flash, an attacker can prevent the correct writing of the try counter by modifying the external flash signal on the PCB.
B. Fault Injection
In a fault injection attack, the expected behavior of a chip is altered under the shock of its environmental conditions. Specifically, the expected behavior of hardware and software suffers from glitches injected into their targets. Basic fault injection techniques affect the chip's clock and/or voltage supply, while more advanced fault injection techniques inject electromagnetic pulses and/or laser pulses into the chip's surface. There are already some well-accepted and affordable tools for dealing with these types of attacks.
The types of faults (i.e., fault models) caused by these glitch injections have been extensively studied in academia, with a common concern that instruction modification while performing glitch injections has become a strong attack primitive. Listing 1 shows an example of a broken ADD instruction on an ARM AArch32 system. By flipping just one bit in the instruction code, the result of the addition can be changed, completely affecting the intended behavior of the software. Therefore, a fault injection attacker can completely destroy the security model of the software on which most ECUs rely.
While traditional fault injection attacks aim to change the expected behavior of a chip when safety-critical decisions are made, more advanced attacks take control of the chip by executing arbitrary code. The case study in Chapter 5 demonstrates this advanced attack.
C．side channel analysis
A side channel analysis (SCA) attack is a passive attack that uses side channels to obtain information from a device, typically to extract keys from a device or to bypass authentication mechanisms. Common side-channels include timing, power consumption, and electromagnetic radiation, and side-channel attacks can occur in both software and hardware implementations. In the automotive industry, UDS security access checks and cryptographic operations (such as HSM) are the most typical attack targets.
This article introduces AUTOSAR and describes software and hardware attacks against AUTOSAR. The content of the next article will describe the case study of execution fault injection attack in detail, so stay tuned!