Keysight Blogs

DoIP: Remote Diagnosis Protocol for Smart Cars

Modern cars are becoming computers on wheels. They can use up to 70 or more Electronic Control Units (ECU) for performing various critical functions. These ECUs are embedded systems that maintain and oversee critical functions ranging from fuel injection, cabin room temperature to brakes and suspensions. These devices digest data from local sensors and perform calibrations to keep everything in order.

Fig. 1: ECUs in Modern Cars

In the automotive industry, “vehicle diagnostics” refers to an inspection of the vehicle to identify any faults and guarantee the smooth operation of all the mechanical, software, and hardware components. These components are usually the ECUs in modern cars.

Typically, a manual vehicle diagnosis is carried out by connecting test equipment to the car’s physical ports. These on-site vehicle diagnostic methods are not always a practical choice.

Moving forward, the Original Equipment Manufacturers (OEM) began to give some expensive cars the ability to get over-the-air diagnostics through the network connection. What began with a brand-specific method soon became a standard that we now know as Diagnostics over IP (DoIP).

Nowadays, most of the popular automobile brands such as BMW, Porsche and Ferrari have equipment that can leverage DoIP.

The Emergence of DoIP

DoIP is a standardized diagnostic transport protocol according to ISO 13400. The overall goal of the protocol is to encapsulate diagnostics messages of protocol standards like Unified Diagnostic Services (UDS) and route them to and from the ECU. The DoIP gateway or server can be a part of the ECU. A vehicle can have multiple DoIP entities and multiple testing devices and ECUs can route their traffic via a single DoIP entity. This feature comes in handy because IoT devices such as smart cars can have many ECUs on board.

DoIP is most often used in the automobile industry and has become an integral protocol within it since it enables a client to retrieve diagnostic information from their vehicle’s onboard computer system over the internet. This becomes especially crucial when the car is on the road or in a remote area.

DoIP has the potential to be applied in a variety of other industries as well. It may be used to troubleshoot industrial equipment, medical equipment, or even household devices. As the Internet-of-Things (IoT) phenomenon catches up, DoIP can become an important player in the sector.

Implementation

DoIP uses both User Datagram Protocol (UDP) and Transmission Control Protocol (TCP) for specific phases of the underlying layer. The initial announcement and identification messages are over UDP, after which the communication switches over to TCP.

DoIP works over the transport layer. It encapsulates a diagnostics protocol in the application layer. DoIP is recommended to use over (Transport Layer Security) TLS, but it is not mandatory as per latest specifications.

Communication Sequence

The DoIP gateway nodes act as an interface to the actual Electronic Control Units (ECU) of the Internet-of-Things (IoT) devices.

Fig. 2: Communication Sequence

1. At first, the testing device (or the client) broadcasts a Vehicle Identification Request which is received by the DoIP gateway.
2. The DoIP gateway then sends out a Vehicle Announcement Response. It can have multiple pieces of information such as the Vehicle Identification Number (VIN), Entity ID (EID) and the logical address of itself.
3. After the information exchange over UDP is done, the TCP communication commences as the Routing Activation Request is sent by the testing device. This is parsed by the DoIP gateway and if the DoIP header is valid and the received logical address matches the configured logical address of the testing device, then the routing of data between the tester and the ECU is activated.
4. With the acknowledge of the activation of routing, the logical address of the DoIP is also communicated to the tester via the Routing Activation Response.
5. After the commotion of acknowledgement and information exchanges, the actual communication of diagnostics information takes place as each of the entities involved have the information regarding the others. The gateway routes the requests to the ECU and gets the responses back for the tester.
6. To ensure the tester that the diagnostic messages are being received by the ECU, it sends the acknowledgements back to the tester after each request.

Message Types

1. Vehicle Identification and Announcement Phase

The Vehicle Identification Request message sent by the tester may or may not contain the Entity ID (EID) and Group ID (GID) of the DoIP gateway. If it does, the gateway will compare the received value with the configured value first and then respond.

Here’s what it looks like in Wireshark. The packet does not contain any identification information.

Fig. 3.a: Vehicle Identification Request in Wireshark

And its response:

Fig. 3.b: Vehicle Identification Response in Wireshark

The same response can be sent to the IP of the testing device or broadcasted to the IP address of 255.255.255.255. All of this is over UDP.

2. Routing Activation Phase

After the identification process is done and both the testing device and the gateway are aware of each other, the routing activation exercise over TCP commences.

The request message contains the logical source address of the testing device.

Fig. 3.c: Routing Activation Request in Wireshark

The response by the gateway, in turn, records that value and compares with it configurations and sends back its own logical address if everything is in order.

Fig. 3.d: Routing Activation Response in Wireshark

3. Diagnostics Communication Phase

Diagnostics over IP (DoIP) can encapsulate many diagnostics protocol standards. Notable among them are Open Test Sequence Exchange (OTX), Unified Diagnostics Services (UDS) and Worldwide Harmonized On Board Diagnostics (WWH-OBD). In this blog, we will talk about how UDS leverages DoIP for communication.

3.a Tester Present Message

First, the tester lets its presence known by letting the ECU know that a tester is present in the network. By now it knows the logical address of the target ECU and hence can make a direct request to it.

Fig. 3.f: UDS Tester Present Request in Wireshark

3.b Acknowledgement

Then, the gateway lets the tester know if the message is successfully received by the ECU through an ACK message that it sends back.

Fig. 3.g: UDS Diagnostics ACK in Wireshark

3.c Data Transmission

The testing device often needs to upload or write files to the ECU. It is needed if the tester wants to install a service with the ECU to either run diagnostics check or send back periodic readings and measurements from within the ECU.

To make it happen, the tester first needs to announce a few things before the arrival of the data. It needs to mention within the Request Download message whether the incoming data is encrypted or compressed or not. If yes, it also needs to mention the type of encryption and compression. Apart from that, it also needs to mention the memory address at which it will write the contiguous blocks of data, and the total size of it.

Fig. 3.h: UDS Request Download in Wireshark

The ECU processes the request and if everything looks to be serviceable, it responds in positive so the communication can continue.

Fig. 3.i: UDS Request Download Reply in Wireshark

The ECU responds with the size of the memory it can process in one round of data transfer. In this case, the size of the incoming data is 57FC bytes (22524 bytes in decimal), but the ECU can only process a block of 800 bytes (2048 bytes in decimal) at once. Therefore, the whole file needs to be chopped in 11 blocks to send to the ECU smoothly.

After the negotiation, the blocks of data are appended to the Transfer Data message along with a counter for the block itself.

Fig. 3.j: UDS Transfer Data in Wireshark

Security Concerns

As per the latest update to the ISO standard, which was published in 2019, TLS is not mandatory for the communication. Without any encryption, the secrecy and authenticity of the messages are vulnerable and open to attacks from any bad-faith actor that has access to the network.

Even with TLS encryption for the TCP phase of the communication, the initial Vehicle Identification phase, which is over plain-text UDP, is vulnerable to many exploits. A malicious entity sitting within the network can easily pretend to be a DoIP gateway and hijack the communication as there is no way for the tester to verify if the entity sending the responses back is a DoIP gateway or not.

Furthermore, as mentioned earlier, the Routing Activation phase involves the gateway verifying the source address of the tester by comparing it with the pre-configured source address. If the provided logical source address is unknown, that information is sent back in the response to the tester. The attacker can use this feature to iterate and scan through several logical addresses until the correct one is accepted.

Security researchers have presented arguments to include TLS it in future versions of the standard to mitigate some of the vulnerabilities.

ATI Support in BreakingPoint Systems

As of the 2023–04 release of the ATI Strikepack subscription, Diagnostics over IP (DoIP) is supported as an application protocol that you can test your network with. With BreakingPoint Systems, you can mix DoIP traffic with thousands of other types of application traffic to test the resiliency of your network devices.

Fig. 4: DoIP with UDS in BreakingPoint Systems

For more details about Keysight BreakingPoint Systems and to test your network equipment against the most updated network traffic available on the Internet, visit the BreakingPoint landing page.