«1. Introduction and Motivation Modern vehicles have become complex information technology (IT) systems consisting of multiple interconnected ...»
OBD = Open Barn Door? Security Vulnerabilities and
Protections for Vehicular On-Board Diagnosis (OBD)
Stephanie Bayer, ESCRYPT GmbH Ramona Jung, ESCRYPT GmbH Marko Wolf, ESCRYPT GmbH
Leopoldstr. 244, 80807 München L. M. Allee 4, 44801 Bochum Leopoldstr. 244, 80807 München
firstname.lastname@example.org email@example.com firstname.lastname@example.org
The automotive On-Board Diagnostic (OBD) interface enables a standardized, efficient way to access information of the in-vehicle electronic system. However, the standardization of this interface also facilitates unauthorized access to critical services. Implemented simple OBD security mechanisms can be easily circumvented and publicly available tools allow even untrained persons the execution of virtually all diagnostic services, for example to manipulate the mileage or to activate component features without authorization. This paper provides an overview of OBD security vulnerabilities and proposes some effective and efficient security solutions that not only protect the system against unauthorized access by the integration of state-of-the-art cryptography, but also consider in-vehicle application constraints.
1. Introduction and Motivation Modern vehicles have become complex information technology (IT) systems consisting of multiple interconnected Electronic Control Units (ECUs) which are responsible for safe and correct functionality of the car. In order to provide comprehensive, easy-to-use self-diagnostic and reporting functionality for invehicle ECUs, a standardized On-Board Diagnostic (OBD) interface was developed in the 1990s and today OBD is deployed worldwide and legally mandatory in the US and Europe. On the one hand, OBD enables digital access to public data, for instance to emission control, error codes, and on the other hand, OBD enables access also to “hidden” manufacturer-specific ECU settings, for instance to theft protection or engine control.
Unfortunately, the widespread use of the OBD interface did not only ease maintenance but eases also unauthorized vehicle manipulations. Today, many tools are freely available on the market, which enable even beginners to tamper with the car. For example as shown in Fehler! Verweisquelle konnte nicht gefunden werden., the mileage of a vehicle can be changed in a few seconds without leaving any traces by using a diagnostic tester . Koscher et al.  describe how one can change in-vehicle parameters or circumvent the electronic locking system to affect even the driving behavior of the car. Even though the OBD standard foresees some basic mechanisms that enforce access control using four different security access levels, their practical realization is rather weak. Based on static, proprietary, or simply incorrect implemented algorithms, they often can be circumvented with cheap tools and only little publicly available knowledge .
The attractiveness for unauthorized access is even more increased due to the comprehensive and powerful functionality provided by “secret”, which means non-standard manufacturer individual diagnostic services. By knowing corresponding “secret” OBD parameter identifiers, it is not only possible to obtain detailed information from sensors and actuators not foreseen for disclosure, but also to modify critical ECU behavior, or even to reprogram the firmware or settings of some ECUs. Mileage alteration or unauthorized chip tuning are well-known practices which already exploit this vulnerability. Recent publications demonstrate some more advanced exploits by inserting manipulated parameters in order to “overtake” various safety-critical functionalities (e.g., steering, brakes) of a vehicle via OBD . Other potential attackers might read out competitor’s intellectual property (e.g., ECU firmware) or privacy invasive information (e.g., recent vehicle locations, eCall data set). Hence, there seems apparently a need for actions to protect the OBD interface against critical data security and privacy infringements.
First, we will provide some background on the OBD standard and the commonly used UDS protocol.
Then we will give an overview of some security vulnerabilities of the OBD interface. After that, we will present efficient and effective protection mechanisms that will re-establish the security of a vehicle such as a mandatory access control mechanism that enforces fine-grained access authorizations or mutual authentication of vehicle and tester based on strong cryptographic primitives.
Figure 1: With OBD and weak UDS protection, manipulation of total vehicle mileage became very easy, cheap and virtually untraceable (Pictures: ADAC/Simon Koy).
2. Background Information on OBD and UDS This section gives some introductory background details on OBD and UDS. If you are already familiar with these two automotive technologies, you can skip this section.
Automotive industry is using many different bus systems and diagnostic standards, among them the European On-Board-Diagnostic (EOBD) standard. Since 2004, EOBD is mandatory in Europe for all vehicles.
This standard defines the diagnostic connector (OBD) (Figure 2), manufactory-independent Diagnostic Trouble Codes (DTC), and the coverage of the on-board diagnostics. Diagnostic communication is used to connect the in-vehicular diagnostic service with external diagnostic tools, so-called “tester” devices.
Figure 2: OBD connector shape and pin out with red = battery (+12Vcc), dark-gray = ground, blue = SAE J1850 (PWM/VPW), green = ISO 15765-4 (CAN), yellow = ISO 9141-2/14230-4 and white = manufacturer-specific function (Picture: Xoneca, CC0).
The tester can either query the current state of the vehicle or read out the OBD log file. In this file all noticeable behavior of the vehicle is reported and logged. In general, this refers to a malfunction of an ECU caused by an application or service that is not being executed in the intended manner. Therefore, log files provide information about all in-vehicle incidents and can be used, for example, as evidence to an investigation in case of an accident.
One of the most used communication protocols over OBD is the Unified Diagnostic Services (UDS) protocol, which is implemented by many automotive manufacturers. The purpose of UDS is to get information from or set values in various ECUs inside a vehicle.
UDS is specified in ISO 14229-1  and describes different messages and data sequences that allow, for instance, to establish different level of access, to read out error memory, or to update software on an ECU. For all this, UDS is the mutual foundation and allows creating a set of different diagnostic services, which can be used manufacturer-independently. However, the UDS standard only describes the functional interfaces and communication flows, but does not specify how the diagnostic services should be implemented in detail. The realization of diagnostic services itself is left to the automotive manufacturers. The UDS protocol was originally designed to be used over the common in-vehicle Controller Area Network (CAN) bus. The CAN bus was developed in 1983 for efficient and fast automotive communication and is standardized in ISO 11898 . It broadcasts messages to all available receivers and restricts the message payload. However, today UDS is also used with other automotive communication protocols such as FlexRay . Although all car manufactures use UDS via the physical OBD interface and a wired connection from tester to the vehicle, many car manufacturers today also support remote diagnostic services via WiFi or mobile communication interfaces . This allows for instance to inspect a broken down car while the mechanic is driving to the stranded vehicle and thus speed up the repairing process rapidly.
Figure 3: Seed-Key Protocol used in UDS SecurityAccess Service.
For optional access control and basic authentication to enhanced diagnostic services, a “SecurityAccess” service is defined which is based on a “Seed-and-Key” protocol. The general communication flow according to this protocol is depicted in Fehler! Verweisquelle konnte nicht gefunden werden.. An authentication of a diagnostic tester to an ECU is performed as follows. After receiving a SecurityAccess service request, the ECU generates a value called the “seed”, and sends it to the tester. Using this seed, the tester then computes a corresponding value called the “key” and sends it back to the ECU. On the ECU’s side, a reference value for the key is computed. If and only if the received key and the reference value are equal, the tester is allowed to access enhanced diagnostic services on the ECU, for instance, for firmware updates.
3. Open Barn Door – OBD Security Threats and Vulnerabilities OBD was developed to have a manufacturer independent diagnosis interface which enables easy access to diagnostic data and convenient reporting functionality of the in-vehicular ECUs. However, security was not specified at that time and therefore OBD offers virtual no protection against misuse. Hence, the diagnostic interface is not only useful for authorized garages, but also enables unauthorized persons to access in-vehicular ECUs and diagnostic services. This can lead to various security attacks, as already demonstrated by various researchers (e.g.,   ).
Due to commonly available tools and information, automotive manufacturers are faced today with an increasing amount of ECU manipulations that might affect vehicle safety, legal applications (e.g., digital tachograph, exhaust gas treatment), or undermine aftermarket business models. Thus, not only ambitioned vehicle owner can misuse diagnostic services for illegal feature activation, ECU parameter manipulations, or mileage reset. Also criminal organizations aim to retrieve information about the intellectual property of OEMs and suppliers for creating counterfeit components or about driver sensitive data as, such as driving behavior.
This chapter presents some exemplary security threats and vulnerabilities of OBD and UDS that might cause critical damages to OEMs, suppliers, drivers, owners, and environment and society.
3.1. Direct Access to Unprotected In-Vehicle CAN Bus The OBD interface connects the outside world with the unprotected in-vehicular communication network, which was invented as closed internal system without allowing external access. The physical interface is usually placed at an easy accessible location in the vehicle, for example beneath the steering wheel. In addition, the standardization of the OBD interface offers the possibility to plug in common available connector devices, which can be used not only at vehicles of a dedicated manufacturer but for various models.
The attachment of an OBD connector enables direct access to the in-vehicle CAN bus system. CAN is a multi-cast protocol, which means that a message from any CAN node is always sent to all other nodes in the CAN network. This protocol property avoid costly message addressing and encryption overhead, but makes it also easy for an attacker to wiretap all messages, which are broadcasted inside the CAN network, by just plugging into the OBD interface. These wiretapped messages, however, can contain sensitive information such as the current vehicle speed. An attacker can also use the OBD connection to suppress or manipulate safety-critical messages . Furthermore, a potential attacker can easily inject any own messages over the interface into the CAN network. The messages will be broadcast to all available receivers inside the network without any chance to verify the authorization of the sender. This allows an attacker to send arbitrary commands to the ECUs inside the network .
3.2. Weak SecurityAccess Service Implementation Some diagnostic functions defined in the UDS standard (e.g., firmware update) are required to be only available for authorized users. To verify user authorization UDS provides a so-called Security Access protection mechanism based on the “Seed-and-Key” protocol as described in Section 0.
However, the UDS standard does not specify in detail how the SecurityAccess should be designed. They leave it open if cryptographic algorithms are used and give no recommendations which cryptographic algorithms should be used. However, the UDS standard recommends to calculate a new seed value for each access request since a reuse of the same seed, allows an attacker to circumvent the access functionality by replaying recorded data without knowing the underlying algorithm very easily. Unfortunately, this recommendation is not implemented every time, and either constant value seeds are used. Or the seed is picked from a small set of values, in this case the attacker also does not need any information of the underlying algorithm but has to eavesdrop a few valid access protocols before the attacker is able to reuse the gained knowledge. Another problem is that often the seeds and the key values are only 16 bit long  and therefore the access can be broken using Brute Force. An attacker with access to the vehicle can test all possible combinations of the seed and the key, the authors of  describe that they were able to carry out the attack in around 7.5 days.
Even if the seed is picked at random from a big set to avoid all former mentioned problems, the calculation of the key is often based on weak algorithms, which apply a linear function on the seed and therefore the key is predictable for an attacker who is in possession of the key generation algorithm. After the attacker has seen a few valid seed and key pairs, he is able to solve a linear system of equation to extract the secret value used to calculate the key. The discussion reveals that a basic implementation of the SecurityAccess service cannot provide a high security level. Hence, it is important to base the SecurityAccess on strong cryptographic algorithms.
3.3. Hijacking Authorized UDS Sessions As described in Section 0, some critical UDS diagnostic services (e.g., firmware update) can be restricted to authorized users only by applying the SecurityAccess protection mechanism. Even under the assumption of a perfectly secure SecurityAccess mechanism (cf. Section 3.2), a successfully authorized diagnostic session could be easily hijacked by an unauthorized third party having CAN access.