Protecting a Cyber-Physical Remote Diagnostic Communication System Against Cyberattacks

Figure 1: Screenshot of a generic diagnostic tester. (Softing Automotive Electronics)

The increasing complexity of microcontroller-based E/E (electrical/electronic) systems that control heavy-duty trucks, buses and non-road mobile machines and their powertrain components (diesel engines, emission control systems and transmissions) comes with increased self-diagnosis functions and diagnosability via external test equipment.

Table 1: Examples of standardized diagnostic communication protocols. (Softing Automotive Electronics)

Technicians in the development, production and service depend on diagnostic test equipment that is connected to the E/E system of the vehicle/machine and performs diagnostic communication. Examples of use cases of diagnostic communication include diagnostic data acquisition, (guided) fault finding and flash reprogramming.

The physical connection between diagnostic test equipment and a vehicle/machine is provided by a diagnostic connector that comes with pins for K-Line, CAN and Ethernet. In addition, today´s vehicles are equipped with several wireless access points, such as telematic control units (TCUs), global positioning systems (GPS), Bluetooth or wireless LAN (Wi-Fi).

The wireless and remote connection between a diagnostic tester and a fleet of vehicles can be considered a technical masterpiece, but only if new challenges such as closing security gaps are mastered. This article analyzes the components of the cyber-physical system (CPS) for remote diagnostic communication and provides measures to improve the resilience against cyberattacks.

A cybersecurity panel taking place on September 11 at the SAE COMVEC 2019 event in Indianapolis also will cover this topic and other cyber-related concerns. The session will be moderated by Larry Hilkene, chief product cybersecurity engineer at Cummins Inc., and include the author from Softing Automotive Electronics.

Automated functions require real-time detection, fast repair

Like any other function, the diagnostic functions of a vehicle or machine must be specified, planned, designed, developed, tested and released. External test equipment, in this context referred to as diagnostic tester, helps the technician to do his or her job right—for example, to develop the correct setting of Diagnostic Trouble Codes (DTCs), to program control units in the production line or to find a fault in the aftersales service. Figure 1 shows the screenshot of a diagnostic tester as an example.

Note: In colloquial language it is often said that the diagnostic communication takes place between the tester and the vehicle/machine. That is not actually correct. For reasons of accuracy, we presume that the diagnostic communication at a specific point in time takes place between the tester and exactly one control unit (ECU). SAE J1939 goes one step further and defines Controller Applications (CAs) that consist of control unit firmware, for example for diagnostic purposes.

In simple terms, there is a TST-to-ECU and an ECU-to-TST connection. The communication protocol between the tester and the ECU is referred to as the diagnostic communication protocol. Examples of common and standardized diagnostic communication protocols are listed in Table 1.

Diagnostic communication protocols are mapped to the Open Systems Interconnection Basic Reference Model (OSI model) and organized in OSI model layers. On the OSI model application layer, the tester sends a diagnostic service request to the ECU and the ECU answers with a positive or a negative response.

Table 2: OSI model physical and data link layer protocols. (Softing Automotive Electronics)

Each diagnostic communication protocol also comes with an OSI model physical and data link layer such as CAN, Ethernet or Wi-Fi. Table 2 lists a selection of the currently used OSI model physical and data link layer protocols for diagnostic communication.

Figure 2: Wired and wireless access points to the E/E system of the vehicle/machine. (Softing Automotive Electronics)

Figure 2 shows a simplified in-vehicle network with access points as they are listed in Table 2.

Especially with the increase of automated functions, reliable self-diagnosis functions must be implemented. The detection of malfunctions in real time and methods/procedures for the fastest possible correction or repair must already be considered in the planning phase of safety-relevant automatic functions. Remote diagnostic communication is part of the game, and in order to fix malfunctions caused by software bugs, the update of control unit firmware by OTA (over-the air) flash programming is required.

Figure 3 and Table 3 show a simplified cyber-physical system for remote diagnostic communication.

Increasing resilience against cyberattacks

For diagnostic communication, the tester is connected to the control unit (actually to its CA) and sends a diagnostic service request to it. If supported, the control unit will send a positive response and process the requested action—for example, start internal (test) routines, send diagnostic data, or prepare for/process flash reprogramming.

Figure 3 (shown) and Table 3: Components of the cyber-physical system for remote diagnostic communication. (Softing Automotive Electronics)
Figure 3 and Table 3 (shown): Components of the cyber-physical system for remote diagnostic communication. (Softing Automotive Electronics)

Each component of the CPS as it is described in Figure 3 / Table 3 can be attacked by a malicious hacker. Especially the wired and wireless data links pose a security risk.

To improve the resilience of remote diagnostic communication between external test equipment and a vehicle/machine against cyberattacks, it is imperative to understand and analyze the functionality and vulnerability of each communication system component, including the wired and wireless communication channels.

Numerous papers, studies and guidelines, even standards, such as SAE J3138, SAE J3005 and SAE J3061, have been published since the automotive industry became aware of the cybersecurity issue a couple of years ago. Since then, cybersecurity has been a moving target.

Due to the limited resources provided by the E/E system and due to real-time requirements of many processes within a vehicle, it is not possible to implement the full set of available measures known from the IT industry. It is reasonable that each CPS component supplier installs its own cybersecurity line of defense to protect itself from being blamed for a successful attack, but the resilience of the entire CPS can be rated and improved only if the vehicle manufacturer specifies, validates and verifies the entire system and the associated processes.

There is no such thing as 100% security. Thus, the improvement of the resilience against attacks is a must, whereby cybersecurity measures are effective enough if the effort of hacking them is unrewarding.

A very powerful measure to increase the resilience is the implementation of cryptography. Both the communication between control units (in-vehicle communication) and the diagnostic communication can be encrypted.

Another measure is the implementation of UDS (ISO 14229) as a diagnostic communication protocol. UDS comes with several security measures, meaning diagnostic services such as Diagnostic Session Control (0x10), Security Access (0x27), Authentication (0x28), Secured Data Transmission (0x84), and Tester Present (0x3E).

Table 4: Examples of measures to increase the resilience against cyberattacks. (Softing Automotive Electronics)

Table 4 summarizes effective measures to increase the resilience of the diagnostic communication against cyberattacks.

Intrusion detection by OBD

The UNECE 1998 Global Agreement was finalized under the leadership of the European Community, Japan, and the United States. The agreement establishes a process through which countries from all regions of the world can jointly develop UN Global Technical Regulations (UN GTR), for example regarding safety or environmental protection. GTR No 5 = Technical Requirements for On-Board Diagnostic Systems for Road Vehicles “prescribes the requirements for on-board diagnostic (OBD) systems to detect, and, if applicable, record and/or communicate failures of specific vehicle and engine systems that affect the environmental or safety performance of these systems.”

Security threats can severely harm the functional safety and finally cause damage to the vehicle/machine or worse, to life and health of people. If a cyberattack affects the safety, it should be detected by the OBD system. The OBD system shall have the capability of detecting malfunctions that affect emissions, functional safety and security.

Reasonable measures must be taken to prevent unwanted intrusion and/or manipulation, detect malfunctions that affect safety, create a fail-safe situation in case of a detected cyberattack, and fight any unauthorized intrusion and manipulation.

Peter Subke, Director Business Development, Softing Automotive Electronics GmbH, wrote this article for Truck & Off-Highway Engineering. He is the author of an SAE “deep dive” book on diagnostic communication (www.sae.org/publications/books/content/r-474/ ) and will participate in the Cybersecurity session at SAE COMVEC 2019 in September.