“Are you supposed to be here right now?” by Scott Webb on Unsplash“Are you supposed to be here right now?” by Scott Webb

Short Topic Introduction:

Nowadays, there are many ways to have the data of your vehicle read out and to turn your car into a smart car with the help of so-called dongles. This brings along a number of problems and potential risks. The associated challenges cover a wide range of areas, including, of course, aspects of IT security. It goes without saying that in-vehicular components and networks need to be secured and protected. The now de facto interface between vehicle ECUs and third parties is OBD-II. It is thus an important task to control and check exactly what data is sent at the interface or fed into the respective vehicle system.


For a considerable period of time, the desire of many people has been striving to interconnect as many things as possible and accumulate a lot of useful data in order to draw logical conclusions. In the meantime this has also made its way into a large number of passenger cars. For example by the use of the OBD-II interface, which exists since 1988. On-Board-Diagnosis (OBD) is a vehicle diagnostic system, which makes important control units and their data accessible (e.g. the current speed, rpm). In 1996 the USA made it mandatory for every new car that is sold to have this interface. According to Regulation (EC) No. 715/2007, all new passenger car registrations in the EU since 2001 for gasoline engines and since 2004 also for diesel engines must be equipped with an OBD interface. This means that nowadays a huge amount of cars are equipped with this On-Board-Diagnosis system. Even if a car does not have an OBD-II interface, there are ways to make it a smart car in some way. There are dedicated mobile phone applications that use acceleration sensors, the gyroscope and the GPS module to analyze driving data and save the trip digitally.

Generally we can categorize the possibilities of retrieving the data of a car and the associated driving behavior into three main categories:

  1. Standalone dongle (Fully integrated OBD-II smart car dongle)
  2. Consolidated dongle (Partly integrated OBD-II dongle with separate bluetooth application)
  3. Nonexistent dongle (No physical OBD-II dongle, but a separate application that uses the mobile phone to track driving behaviour)

What is the underlying problem?

As mentioned above, the on-board diagnostic interface allows to interact with a variety of ECUs (Electronic Control Unit) and to obtain valuable data for an overall insight into the current state of a vehicle. Even without this interface and the use of a specific mobile application (category C) for the purpose of collecting such data, a huge amount of data on driving behavior can be collected. Category C is currently being used primarily by insurance companies. But also companies from the business sector offer a wide range of services that can be used to track the car. Especially telecommunications service providers such as Vodafone [1], Telekom [2] or Telefonica [3] offer OBD-II connectors in combination with a SIM card and a corresponding tariff. This means that providers of these services get insights into an enormous amount of highly private data of the drivers’ everyday life. Among other things, this includes driving style, routes and accurate driving times. Manufacturers and insurance companies as well as service providers from the business sector are already using the information provided as a basis for monetarizing the individual journeys of users. An example would be the reduction of car insurance if you have a particularly restrained and safe driving style. This monetarization can also work in the opposite direction. This means that drivers who drive very aggressively, for example, are punished with higher rates.

But what happens if the methods and metrics used to determine these characteristics are incorrect or can be influenced? Furthermore, malicious dongles or apps could possibly cause damage to the vehicle, influence or even impair the driver. Since there is no such thing as encryption or authentication the CAN bus [4] on, these threats are very real and by far not hard to implement. Besides malicious injections on the CAN-Bus level, there can be done much more with OBD-II. The OBD-II protocol provides status information and Diagnostic Trouble Codes (DTCs) for a multitude of ECUs as mentioned above (e.g. Powertrain (Engine and Transmission), Emission Control Systems, Vehicle Identification Number (VIN), Ignition counter…). In addition, the criteria according to which the evaluation is carried out must be asked. Is only the speed investigated or are more complex behaviors being studied (such as the use of turn signals before turning into a new road). Are the comparisons really fair and balanced? Could they possibly be unified and a generally applicable standard for evaluating established? Overall there has not much research been made in this area. Wen et al. [5] has provided a comprehensive vulnerability analysis of 77 OBD-II dongles. He proposed an automated tool called DongleScope to perform an analysis and to test the dongles. They also identified and defined 5 different types of possible vulnerabilities. In the paper published by Yadav et al. [6] the authors give an overview of various security vulnerabilities and points of entry for malicious entities in vehicular systems. There were also three papers published ([7], [8] and [9]) which show how to monitor automobiles, predict condition of the internal hardware, detect driving behaviors and discover different anomalies. It’s definitely clear that it is not easy to answer all the questions stated above. This is due to the diversity of offered devices by the large number of providers and methodologies as well as the intended usage. We also think that it is necessary to inform the intended audience more about the way how their driving is rated along with what information is processed and in the end stored on the servers of the service provider. This should help vehicle owners to know better how and, above all, which data their vehicle collects and is also passed on to certain third-party services. On the other hand, it is important to make it clear what the devices that are plugged into the cars actually do.


All these problems posed above are currently being worked on in my Master’s thesis. I will probably write a detailed blog post after finishing this thesis, as well as publish my own thesis.


[1] Vodafone. V-Auto: So einfach wird Dein Auto zum Connected Car
(visited on 10/22/2020)

[2] Telekom. CarConnect: Lösung für vernetztes Fahren
https://www.telekom.de/smarte-produkte/iot?wt_mc=alias_301_smarte-produkte/ iot/carconnect
(visited on 10/22/2020)

[3] Telefonica. o2 Car Connection von Telefonica
(visited on 10/22/2020)

[4] B. Groza and Pal-Stefan Murvay. “Security solutions for the CAN bus , bringing authentication to in-vehicle networks”. In: 2018.

[5] Haohuang Wen, Qi Alfred Chen, and Zhiqiang Lin. “Plug-N-Pwned: Comprehensive Vulnerability Analysis of OBD-II Dongles as A New Over-the-Air Attack Surface in Automotive IoT”. In: 29th USENIX Security Symposium (USENIX Security 20). USENIX Association, Aug. 2020, pp. 949–965. ISBN: 978-1-939133-17-5.

[6] Aastha Yadav et al. “Security, Vulnerability and Protection of Vehicular On-board Diagnostics”. In: International Journal of Security and Its Applications 10 (Apr. 2016), pp. 405–422. DOI: 10.14257/ijsia.2016.10.4.36.

[7] A. El Basiouni El Masri, H. Artail, and H. Akkary. “Toward self-policing: Detecting drunk driving behaviors through sampling CAN bus data”. In: 2017 International Conference on Electrical and Computing Technologies and Applications (ICECTA). 2017, pp. 1–5.

[8] B. Nirmali et al. “Vehicular data acquisition and analytics system for real-time driver behavior monitoring and anomaly detection”. In: 2017 IEEE International Conference on Industrial and Information Systems (ICIIS). 2017, pp. 1–6.

[9] A. Srinivasan. “IoT Cloud Based Real Time Automobile Monitoring System”. In: 2018 3rd IEEE International Conference on Intelligent Transportation Engineering. 2018, pp. 231–235.