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.
At first, the testing device (or the client) broadcasts a Vehicle Identification Request which is received by the DoIP gateway.
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.
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.
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.
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.
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
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.
And its response:
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.
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.
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.
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.
1) 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.
2) 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.
3) 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.
The ECU processes the request and if everything looks to be serviceable, it responds in positive so the communication can continue.
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.
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 their 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.
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.
Learn more about Keysight’s portfolio of Network Security products.