![A graphical representation of the pinouts of some data protocols on the 16-pin DLC [21].](https://www.researchgate.net/profile/Mahmoud-Ammar-3/publication/341902721/figure/fig2/AS:1161742394638336@1653992379132/A-graphical-representation-of-the-pinouts-of-some-data-protocols-on-the-16-pin-DLC-21_Q320.jpg)
Content uploaded by Mahmoud Ammar
Author content
All content in this area was uploaded by Mahmoud Ammar on May 31, 2022
Content may be subject to copyright.
83
ARTICLE INFO
Article ID: 11-02-02-0009
© 2020 SAE International
doi:10.4271/11-02-02-0009
History
Received: 16 Jun 2020
Accepted: 16 Jun 2020
e-Available: 18 Aug 2020
Keywords
Automotive security, OBD-II,
Authentication
Citation
Ammar, M., Janjua, H.,
Thangarajan, A., Crispo, B.
et al., “Securing the
On-Board Diagnostics Port
(OBD-II) in Vehicles,” SAE
Int. J. Transp. Cyber. &
Privacy 2(2):83-106, 2019,
doi:10.4271/11-02-02-0009.
ISSN: 2572-1046
e-ISSN: 2572-1054
Securing the On-Board Diagnostics
Port (OBD-II) in Vehicles
Mahmoud Ammar,1 Hassaan Janjua,1 Ashok Samraj Thangarajan,1 Bruno Crispo,1,2 and Danny Hughes1
1KU Leuven, Belgium
2Trento University, Italy
Abstract
Modern vehicles integrate Internet of Things (IoT) components to bring value-added services to
both drivers and passengers. These components communicate with the external world through
dierent types of interfaces including the on-board diagnostics (OBD-II) port, a mandatory interface
in all vehicles in the UnitedStates and Europe. While this transformation has driven significant
advancements in eciency and safety, it has also opened a door to a wide variety of cyberattacks,
as the architectures of vehicles were never designed with external connectivity in mind, and accord-
ingly, security has never been pivotal in the design. As standardized, the OBD-II port allows not only
direct access to the internal network of the vehicle but also installing software on the Electronic
Control Units (ECUs). While this privilege, historically, is achieved through physical access on the
underlying port using a dedicated tool, remote access is recently supported in many modern vehicles,
i.e., self-driving ones, and via OBD-II dongles, making the OBD-II port the most significant automo-
tive interface that has to besecured.
Motivated by various recent attacks and vulnerability analyses of OBD-II, this paper tackles the
problem of lack of security in OBD-II by proposing a novel end-to-end role-based access control
(RBAC) mechanism that would prevent unauthorized access to any of the vehicle functionality
through existing vulnerable OBD-II ports. The proposed solution is AUTOSAR compliant and archi-
tecture independent, and does not require modifying any hardware inside the vehicle. Accordingly,
it applies to the millions of current on-road vehicles. Furthermore, while physical attacks are not
avoidable, they are not scalable, considering our approach, and only aect the attacked vehicle.
Weprovide a proof of concept implementation and evaluation of the proposed solution, showing
its robustness and eciency.
This article is part of a Special Issue on esca r USA 2020.
Downloaded from SAE International by SAE International [Sales Team], Monday, September 21, 2020
84 Ammar et al. / SAE Int. J. Transp. Cyber. & Privacy / Volume 2, Issue 2, 2019
Introduction
Modern vehicles are no longer mere mechanical devices, they are controlled by
dozens of heterogeneous electronic components comprising millions of lines
of code that execute per vasively with rich connectivity coordinated via internal
vehicular networks. e basic unit of computation in vehicles is the Electronic Control
Unit (ECU) [1]. ECUs are interconnected via serial buses and communicate using a de
facto standard protocol called the Controller Area Network (CAN) [2] (along with other
protocols) to control everything, including infotainment, steering, acceleration, brakes,
and other safety-critical systems. Furthermore, this interconnectivity is extended to
encompass vehicle-to-everything, such as vehicle-to-vehicle, vehicle-to-infrastructure,
and vehicle to Internet communications via an embedded modem or Bluetooth-paired
cell phone [3].
While the automotive industry has a long-standing experience in vehicle safety,
security issues of connected systems in vehicles and their potential impact on vehicle
safety are not yet properly taken into account for the vast majority of modern platforms
[4]. Some studies point out the potential attack vectors of connected vehicles [4, 5, 6, 7,
8, 9], which can beclassied into remote (e.g., via WiFi, Bluetooth-paired dev ices, keyless
entry systems, cellular radio) or local attacks (e.g., through physical access to the OBD
or USB ports). For example, researchers have shown that an attacker connected to a
vehicle’s internal network can circumvent all computer control systems, including safety-
critical ones such as brakes and airbags [5]. Furthermore, full control of a jeep of model
Cherokee 2014 has been demonstrated through a remote attack that can belaunched
from any distance, resulting in the recalling of over 1.4 million vehicles [10].
Problem statement. Despite the clear security risks that could threaten people’s
lives, securing the broad range of potential attack surfaces in vehicles poses fundamental
design challenges.
1. First, despite the initiatives to include security in the development process of
vehicles, there is still a lack of a common standard allowing a complete integration
of safety and security in the vehicle development life cycle [4].
2. Second, several key components of vehicles are still developed with proprietary
technologies, which make it more dicult to develop security solutions that can
beapplied to a large market due to the lack of standardization.
3. ird, as security issues arise from the integration of connected components in
vehicles, there is no chance to enforce perfect isolation between the dierent
connected subsystems, which means that vulnerabilities from any actor, including
aermarket components, may allow compromising and tampering with the entire
vehicular network [7].
Diagnostic and maintenance systems are external systems interfaced with the vehicle
through a dedicated and standard interface, called the automotive On-Board Diagnostics
(OBD-II) port. e OBD-II port has been mandated on new vehicles in the UnitedStates
and Europe since the 1990s. It enables diagnostics equipment to bephysically connected
to the intra-vehicle network in order to quickly analyze problems and perform diagnos-
tics of the vehicle. e OBD-II interface provides full access to the CAN bus, allowing
direct manipulation of CAN trac in the vehicle and thus tampering with safety-critical
functions, since, by design, neither OBD-II nor CAN oer any protection [11].
Apart from the severe consequences of attacking the vehicle through physical access
to the OBD-II port, exposing the vehicle to the same level of potential risks is possible
with remote access. Leveraging on smartphones, aermarket telematics plugin devices,
known as OBD-II dongles, have wireless connectivity such as WiFi and Bluetooth [12].
Any user can access these devices remotely using an app on his/her smartphone. A very
recent study has shown that a vast majority of existing OBD-II dongles are vulnerable
and expose the vehicle to various remote attacks with implications on privacy and safety
[13]. Furthermore, many modern vehicles, including all self-driving ones, support bui lt-in
remote connectivity for the OBD-II without any form of protection [4]. is makes the
Downloaded from SAE International by SAE International [Sales Team], Monday, September 21, 2020
Ammar et al. / SAE Int. J. Transp. Cyber. & Privacy / Volume 2, Issue 2, 2019 85
OBD-II port the most critical entry point for the various attack vectors as both physical
and remote attacks are possible through it, motivating the need for better protection
and separation between the connected devices through the OBD-II port and the intra-
vehicle network, i.e., CAN bus.
Contributions. To tackle this problem, wepropose a generic and novel authentica-
tion and authorization service that would t in any vehicle, requiring no changes to its
architecture or hardware. To avoid scalable physical attacks that aim at bypassing the
security rewall by leaking secret keys from the vehicle ECUs, our proposal requires
storing no secrets inside the vehicle. Weutilize the Internet-connected trusted servers
of Original Equipment Manufacturers (OEMs) to handle secret keys, thus participating
in the authentication process as a second verier that would prove the genuineness of
the connected user (mobile app) to the communicating ECU inside the vehicle (the
original verier).
Contributions of this paper are twofold:
•We precisely identify the key elements in terms of security and system requirements
that are important in the design of any access control model to eliminate the root
causes of the attack vector through the OBD-II. Wethen overcome the security
limitation of lacking access control by designing a nd developing an end-to-end secure
and efficient role-based access control (RBAC) model based on public-key
cryptography, with regard to the AUTOSAR specications on secure on-board
communications [14] and the good practices and recommendations mentioned in
the ENISA1 report [4]. e proposed solution is architecture independent and can
beintegrated into the design of new cars as pure soware, requiring no change to
any hardware component. Furthermore, it can beeasily retrotted to existing cars
through updating soware or as an external dongle.
•We provide an open-source proof of concept implementation and evaluation of our
solution on dierent CAN-enabled ECUs to show its practicality and eciency even
on resource-constrained ones [15].
Paper outline. e remainder of this paper is organized as follows. Section 2 briey
presents preliminary information about vehicles. All essential aspects of OBD-II are
surveyed in Section 3. In Section 4, wedescribe in detail our proposal to secure the
OBD-II port. Implementation details and evaluations are reported in Section 5. Sect ion6
concludes the paper.
AutomotiveBackground
is section briey describes the vehicle architecture and one of the main communica-
tion protocols that is used over the OBD-II port.
2.1. Modern Vehicle Architecture
e vehicle architecture has been evolving over the years as vehicles are becoming more
and more complex systems that are heavily connected. A vehicle is therefore made up
of several subnetworks interconnected through a gateway. Each subnetwork consists of
multiple ECUs that communicate with each other using dierent communication buses
(i.e., CAN, LIN, FlexRay) [16]. Furthermore, a modern vehicle can connect directly to
the Internet and may interact with external utilities (i.e., smartphones, electric charging
stations) using various communication protocols (WiFi, Bluetooth, etc.). Figure 1 shows
a high-level architecture of today’s vehicle. e architecture distinguishes between
dierent domains, interconnected by a centra l gateway. e gateway collects and transfers
data from and between various ECUs using one of the vehicle data buses (mostly CAN).
1 ENISA: European Union Agency for Network and Information Security.
Downloaded from SAE International by SAE International [Sales Team], Monday, September 21, 2020
86 Ammar et al. / SAE Int. J. Transp. Cyber. & Privacy / Volume 2, Issue 2, 2019
© SAE International
e domains correspond to dierent (and maybe independent)
features of the vehicle.
2.2. CAN
e CAN bus [2] is a broadcast communication medium that
has been originally developed by Bosch in 1983 and standard-
ized by the International Organization for Standardization
(ISO) in the 1990s as ISO 11898 (CAN2.0) [17]. It is the most
widely used protocol in the OBD-II port (see Section 3). e
CAN has severa l built-in features that make it robust and fault-
tolerant. Speeds of up to 1 Mbps are supported in this data bus.
It also features a n arbitration met hod that automatically priori-
tizes messages and resolves packet collisions. A typical CAN
network consists of a series of nodes (ECUs) connected by a
two-wire bus, addressing two physical CAN standards: high-
speed CAN (up to 1 Mbps) and low-speed (fault-tolerant) CAN
(up to 125 Kbps). ECUs can communicate using either CAN.
Each ECU has a CAN controller and transceiver. e CAN
controller is responsible for reading and writing messages from
and to the CAN bus, while the CAN transceiver acts as an
arbitrator between the bus and the controller, thereby trans-
lating between dierent signal levels. Both CAN controller and
transceiver represent the physical and data link layers in the
OSI model, as specied in ISO 11898-1 [17].
CAN Packet Structure. CAN messages have a standard format consisting of a
message ID, a data length eld, a data frame, and other control bits. Message IDs should
beunique as CAN is a message-based protocol following the publish-subscribe pattern.
us, there is no ECU ID, meaning that any ECU can transmit using several message
IDs. For example, an ECU can report motor speed, position, and acceleration on three
dierent message IDs. e message ID is used in the arbitration process to determine
which message has priority when two or more ECUs attempt to transmit simultaneously.
e lowest message ID has the highest priority.
ere are two standardized CAN message formats: the standard frame (CAN2.0A)
(see Fig ure 2) and the extended frame (CAN2.0B) (see Figure 3). At the application layer,
the standard frame format consists of an 11-bit message ID, followed by up to 8 bytes of
data payload. e extended format features a 29-bit message ID instead of 11-bit. In
particular, the extended format is backward compatible, which allows both formats to
beused on any CAN. Following any of the CAN frame formats, there are four dierent
types of frames that can beused on the CAN bus [2]: (i) Data frames, (ii) Remote frames,
(iii) Error frames, and (iv) Overload frames. Diagnostics information, sometimes called
diagnostics frames that are exchanged over the OBD-II port, are carried over the Data
frames [11].
Message Arbitr ation. CAN is an asynchronous Carrier-Sense Multiple Access with
Collision Resolution (CSMA/CR) serial data protocol. When two ECUs attempt to
transmit at the same time, an arbitration process determines which one ta kes preference.
FIGURE 1 A high-level architecture of a modern
vehicle [4].
Reprin ted from Ref. [4]. © Europe an Union Agency
for Netw ork and Informat ion Security ( ENISA), 2016
FIGURE 2 A standard CAN base frame format (CAN2.0A).
Downloaded from SAE International by SAE International [Sales Team], Monday, September 21, 2020
Ammar et al. / SAE Int. J. Transp. Cyber. & Privacy / Volume 2, Issue 2, 2019 87
In other words, collision is resolved through a bit-wise arbitration, based on a prepro-
grammed priority of each message in the identier eld. e CAN physical layer considers
“0” as a dominant bit and “1” as a recessive one. So any bit with zero value has the highest
priority. To solve bus arbitration, CAN transceivers are required to continue listening
on the bus while sending the message ID at the beginning of the data frame. us, the
ECU that transmits a message containing a higher priority ID (lower ID) always wins
bus access and accordingly keeps transmitting. All other ECUs detect that one of their
recessive bits has been overwritten by a dominant bit of another ECU, resulting in the
stopping of its message transmission. Likewise, message acknowledgment can simply
beimplemented by overwriting the ACK bit in real time.
OBD-II
OBD-II are measurements and checks built into a vehicle’s engine and systems, which
record any abnormal behavior or malfunction in any of the system components. In the
remainder of this section, wedescribe the standards of OBD-II, its architecture, and
related security concerns.
3.1. OBD-II: Standards
e OBD-II specications are standardized through a joint work by the Society of
Automotive Engineers (SAE) and ISO. With those standards, the vehicle manufacturers
had new guidelines to follow when developing their implementation for OBD-II in
the engine control management systems (ECMs). e standards dene both the elec-
trical interface signaling protocols and messages format, primarily Diagnostic Trouble
Codes (DTCs). Also, they specify the location of the OBD-II connector, style, and
its pinout.
SAE standards versus ISO standards. SAE developed and published many of the
original OBD-II standards. As the vehicle industry is a global and international industry,
and a majority of the world follows the ISO, the original SAE specications have been
rolled into ISO specications. Figure 4 shows the conversion from the SAE standards
to the ISO 15031 standard, which species the OBD-II connector and conguration
parameters. For example, SAE J1930 has been incorporated into ISO 15031-2, while SAE
J2012 has been incorporated into ISO 15031-6.
DTCs. Prior to OBD-II, each OEM was free to determine which systems were
diagnosed and its own DTCs. is resulted in a lot of confusion and diculty in diag-
nosing specic information reported from the OBD system because there were no stan-
dards on fault reporting. With the advent of OBD-II, DTCs were standardized according
to SAE J2012 (see Figure 4). is specication dened the DTC as having ve digits. e
DTC digits specically give information about where the fault is generated, what type
of fault it is, and the specic fault itself. For example, a standard DTC for a general engine
misre is P0301; P refers to Powertrain, 0 indicates that it is a standard SAE code, 3
denotes that it is related to ignition or misre, and 01 indicates a misre on cylinder
number 1 [18].
FIGURE 3 A standard CAN extended frame format (CAN2.0B).
© SAE International
Downloaded from SAE International by SAE International [Sales Team], Monday, September 21, 2020
88 Ammar et al. / SAE Int. J. Transp. Cyber. & Privacy / Volume 2, Issue 2, 2019
3.2. OBD-II: Architecture
e OBD-II architecture is represented by the data interface (Section 3.2(1)) where
dongles or testers could beconnected to, in order to verify the status of ECUs, and the
communication protocols that run over this interface (Section 3.2(2)).
1) Data Link Connector: e OBD-II data interface, formally called the Data Link
Connector (DLC), is the main conduit used to query DTCs from a vehicle’s on-board
system or, in some cases, program some ECUs. e OBD-II device, i.e., a dongle, physi-
cally interfaces with or connects to DLC to access the on-board system. e DLC is a
16-pin D-style female connector (see Figure 1) specied by the SAE J1962 standard [19].
is particular standard dictates the physical location of the connector inside the auto-
mobile, the shape and size of the connector, and the electrical pinouts in the connector.
2) Data Protocols: ere are multiple data protocols or formats in which the data
stream is presented through the DLC. Various standards are specied to ensure a unied
diagnostic service. ese standards include SAE J1850 VPW, SAE J1850 PWM, ISO
14230 KWP2000, ISO 14229, and ISO 15765-2 CAN (ISO-TP) [9, 20]. Such data protocols
are not compatible with each other. us, it is up to the connected device to adapt to the
dierences in pin congurations, data transfer rates, and signal voltage levels. A graphical
representation is shown in Figure 5.
SAE Standards
J1930 J1962 J1978 J1979 J2012 J2186
Determines
abbreviation
s, definitions
and
acronyms
Defines
physical and
electrical
standardsfor
interface
connector
Definesthe
standards for
scantool
interfaces
Definesthe
diagnostic
testmodes
Definesthe
diagnostic
trouble
codes(DTC)
Definesthe
data link
security and
seed keys
234567
ISO 15031-
FIGURE 4 Multiple OBD-II-related SAE standards are incorporated into a single
ISO standard.
© SAE International
CAN
High
CAN
Low
Signal
Ground
Chassis
Ground
+12VC
PWM+
PWM-
LS-CAN
Low
KWP K-
Line
KWP L-
Line
MS-CAN
High
LS-CAN
High
FIGURE 5 A graphical representation of the pinouts of some data protocols on the
16-pin DLC [21].
Adapted f rom Ref. [21]
Downloaded from SAE International by SAE International [Sales Team], Monday, September 21, 2020
Ammar et al. / SAE Int. J. Transp. Cyber. & Privacy / Volume 2, Issue 2, 2019 89
3.3. OBD-II: Security Concerns
e various potentia l attack vectors on vehicles (with real examples) have been intensively
discussed in many articles [4, 5, 6, 7, 9]. In this section, we focus only on the
OBD-II-related attacks.
e OBD-II port provides direct access to the vehicle’s CAN bus(es), thus providing
an attack vector for compromising the entire automotive system and threatening safety
and privacy as attackers will beable to extract the intellectual property (IP) of OEMs
and steal driver private data [6]. Abstractly speaking, counterfeiting and IP the are two
major issues with the underlying soware in modern vehicles.
ISO 15031-7 (SAE J2186) [22] is meant to identify a security access service for
protecting the vehicle from unauthorized access through the DLC. is service entails
identifying a simple challenge-response protocol, called the seed-key protocol, in which
the DLC challenges the connected device with a seed in order to generate the correct
response for authentication, taking into account that both parties share in advance a
secret key and a cryptographically secure function. Apart from being outdated and not
evolving to cope with new and sophisticated attacks, the standard is ver y loose and vague
and does not identify information on what the function and keys should be, the length
of keys, the security of storage area, the type of random number generator used to
generate the seed, etc. Moreover, the seed-key protocol itself is not standardized. Due
to the lack of a rigorous standard and implementation specications, studies have shown
that vehicles either lack any protection mechanism on the OBD-II port or implement
various types of seed-key protocols that keep them vulnerable to cyberattacks, since the
seed-key protocol itself is weak and vulnerable to replay and brute-force attacks [21, 23].
A group of researchers was able to gain control over many vehicle ECUs and upload a
malicious rmware into the ECM via the OBD-II [5, 6]. Furthermore, there have been
reports illustrating that attackers with specialist OBD reprogramming devices were able
to steal vehicles without the need for original keys [24, 25].
Remote attacks. Since 2004, all new vehicles in the UnitedStates had to support
the SAE J2534 standard, a Windows API that provides a programmatic interface to
communicate with a vehicle’s internal buses. us, the standard OBD-II port allows
third parties to develop soware embedded into external devices (dongles) that interacts
with the vehicle. Such dongles have become attractive targets for cyberattacks. is is
exemplied by the remote attack (over the Internet) that is performed by Argus Cyber
Security on a third-party device sold by Zubie [26], thus being able to circumvent all
computer systems inside the vehicle. Furthermore, researchers have discovered two
classes of vulnerabilities of another SAE J2534-enabled device, allowing them remotely
injecting and installing malicious soware over the CAN bus on some ECUs [6]. Other
vulnerabilities in aermarket WiFi-enabled OBD-II dongles are reported in [12, 27],
which caused unauthorized access to the intra-vehicle network and tampering with
various ECUs. Finally, a recent work uncovered ve general vulnerabilities on wireless
OBD-II dongles that lead to remote attacks [13]. It has shown that all OBD-II dongles
on Amazon have at least one of these vulnerabilities. Accordingly, the researchers were
able to construct four classes of concrete remote attacks including leaking sensitive and
private data, stealing the car, and performing denial-of-service (DoS) attacks.
To this end, the primary cause of the OBD-II vulnerability is the lack of secure and
smart implementation for authentication and authorization that can deny commodity
OBD-II dongles/testers from exploiting either physical or remote access to the intra-
vehicle network of the vehicle. Although SAE has mentioned general guidelines to secure
the OBD-II port [28], a practical and secure solution has yet to beoered to protect the
intra-vehicle network from unauthorized access via this port. Weaddress this problem
in the next section2.
2 e release of AUTOSAR 4.4 specications for the classic platform [29] proposes to add a new
authentication service for the OBD-II that would replace the outdated related security standards.
Although this proposal is in its early stage as there is no concrete protocol or implementation,
weprovide a detailed comparison of our protocol with it in Section V-B4.
Downloaded from SAE International by SAE International [Sales Team], Monday, September 21, 2020
90 Ammar et al. / SAE Int. J. Transp. Cyber. & Privacy / Volume 2, Issue 2, 2019
SecuringtheOBD-IIPort
Over v iew. In this section, wepresent our approach to secure communications with the
intra-vehicle network via the OBD-II port. Weimplement a challenge-response protocol
to authenticate any connected device to the OBD-II DLC by the central gateway3 to
which the OBD-II is connected on the other side (see Figure 1). e key idea of our
proposal is that weutilize the trusted OEM back-end servers to share the burden of the
authentication process with the corresponding gateway or ECU in the sense that all
long-term secret keys are stored there, thus preventing scalable physical attacks. Our
protocol depends on lightweight asymmetric cry ptographic primitives along with a hash
function to provide the appropriate security level needed for each user/device. As a one-
size-ts-all access control model is not appropriate in this domain, weleverage an RBAC
model, in which multiple authorization levels are identied and where each level consti-
tutes a role (e.g., OEM, repairmen, insurance companies). e permissions of each role
are the CAN commands (messages) that are allowed to beexecuted on the receiving
controller. e various roles are not allowed any control over what permissions they are
granted, only the administrator (the OEM in our case) has the right to grant permissions
as necessary.
In the following, weoutline our attacker model and precisely formulate the require-
ments for practical and trustworthy security protocol for the OBD-II. Wethen describe
in detail our approach and analyze its security.
4.1. Attacker Model
e goal of the attacker is to send craed CAN messages via the OBD-II port to tamper
with safety-critical functions, steal sensitive data, spread malware on some ECUs, or
retrieve the condential soware installed on some ECUs. erefore, weprotect against
two types of attackers. e rst one is represented by any user (device) connected to the
OBD-II port, either physically or remotely, intending to send harmful or nonauthorized
CAN messages. More specically, this attacker tries to overpass the authentication
process to get some privilege by forging responses. e second attacker is a third party
who is granted full control over the external network (between the OBD-II port and
end-user/OEM back-end server). is adversary can eavesdrop on, modify, or synthesize
any message between any two entities by performing some attacks, i.e., replay attack,
Man-In-e-Middle (MITM) attack. e main goal of this attacker is to take advantage
of exchanged messages by being able to use them later to bypass the authentication
procedure and get an unauthorized privilege level once connected to the OBD-II.
We extend the capabilities of either attacker by assuming that he/she can perform
noninvasive physical attacks (e.g., side-channel attacks) and interface with the vehicle
from other attack surfaces (either remotely or physically), with a purpose of observing
and recording all CAN trac (that have been broadcasted on the CAN bus that connects
the OBD-II DLC and the gateway) and manipulating the corresponding soware and
data installed on the guard gateway, i.e., public keys, the permissions table.
We rule out all invasive physical attacks (e.g., replacing the guard gateway ECU with
a default insecure one) as protection against these types of attack requires techniques
that are outside the scope of this paper. However, the design of our protocol prevents
the scalability of such attacks. Also, weconsider DoS attacks as out of scope. Weassume
that the OEM is a trusted party. Finally, once implemented, weassume that the imple-
mentation of either part of our proposal is bugfree, and the cryptographic primitives
used are secure and adhere to the standard specications.
3 Authentication is possible by either the receiving gateway or edge ECUs. We continue further
describing our protocol using the term gateway and then explain how it would be in the case of lacking
a ga te way.
Downloaded from SAE International by SAE International [Sales Team], Monday, September 21, 2020
Ammar et al. / SAE Int. J. Transp. Cyber. & Privacy / Volume 2, Issue 2, 2019 91
4.2. Requirements
e design and implementation of an RBAC model in the automotive domain pose
fundamental design challenges.
1. First, the access of users should bedetermined by a privilege associated with their
roles, where such roles are identied by a trusted party in a way to protect various
data and functionality in the vehicle.
2. Second, the design of any RBAC model should consider the already deployed
architectures, i.e., current on-road vehicles, and aermarket telematics. us,
supporting the seamless integration in such architectures with minimal overhead.
3. ird, the authorization measu res should bedetermined accurately for every involved
party, while regularly conducting compliance and checking vulnerabilities is a must
in order to ensure defenses against evolving security threats.
4. Fourth, the proposed RBAC model should beexible in a way being well designed
to adapt to dynamic changes as necessary. is includes regular updates and
revocation of roles, privileges, and security checks. Last, scalability should
betaken into account, since millions of vehicles are already manufactured by
each OEM.
To overcome the aforementioned challenges, wedesign our RBAC model considering
the standard National Institute of Standards and Technology (NIST) at RBAC model
[30], which provides a valuable level of abstractions to promote security on a large scale.
In our model, the basic role concept is establishing permissions based on the functional
roles for each user of the vehicle (from the OEM point of view) and then appropriately
assigns users a role or set of roles. e access decision is based on the roles, where each
role represents the set of privileges or permissions that are allowed to beexecuted by the
holder of this role. Accordingly, wecarefully illustrate the requirements that should
bemet in order to have a practical security protocol for the OBD-II. Wedistinguish
between two levels of requirements: security and system. e former concerns a awless
design of the security technique needed, whereas the latter is about the practicality,
feasibility, and portability of the proposed approach.
4.2.1. Security Requirements
•SE1: Authentication e guard gateway should authenticate each role with its
corresponding public key. For example, an OBD-II device dedicated to a repair shop
should not beauthenticated as a device used by an OEM, as each one of them has a
dierent privilege level.
•SE2: Authoriz ation If a role is authenticated, only the commands within the granted
privilege level can beexecuted.
•SE3: Secure storage Wherever secret keys are stored, they must bekept condential
in a secure area and protected from being leaked anyway.
•SE4: Replay attack resistance An attacker who monitored and recorded authenticated
CAN messages sent by one of the roles (e.g., the OEM) should not beable to replay
these messages again under any circumstances.
•SE5: Integrity e integrity of the cryptographic primitives along with other data
stored in the memory of the guard gateway should bemaintained. Other untrusted
code modules in the same ECU or other participating ones should beprevented from
tampering with these data.
•SE6: No single point of failure Physical attacks on modules implementing the security
protocol should not bescalable. Only the hacked vehicle should beaected.
4.2.2. System Requirements
•SY1: Performance Despite the fact that interfacing with the OBD-II to diagnose
information is not restricted to real-time communications as normal internal
Downloaded from SAE International by SAE International [Sales Team], Monday, September 21, 2020
92 Ammar et al. / SAE Int. J. Transp. Cyber. & Privacy / Volume 2, Issue 2, 2019
vehicular communications, the proposed secu rity technique should not add substa ntial
overhead that would irritate users (e.g., repairmen) while doing their jobs, to reduce
possibilities of physical tampering with the security module.
•SY2: Compliance e security protocol should bein line with the AUTOSAR
specications [14] in terms of not requiring changes to any of the standards employed.
Furthermore, existing o-the-shelf diagnostics tools that do not support the security
layer should beable to interact smoothly with the guard gateway using a baseline
security level (by being granted a basic privilege level).
•SY3: Compatibility Adding an extra security layer to the OBD-II should demand
minimal costs in terms of portability, computation and runtime overhead, and
maintenance. Hence, the solution should involve minimal or no hardware
modications such that it can beeasily retrotted in existing vehicles.
4.3. Our Proposal
Vehicles provide one or more gateways to interact with the external entities. Such gateways
represent the entry and exit points to any exchanged CAN message via the OBD-II. In
our proposal, the security at the OBD-II port is enforced through two steps. First, any
OBD-II-connected device should beauthenticated by the gateway with respect to (w.r.t.)
the role claimed. Each role is associated with a key pair, where the private key is stored
at an Internet-connected ser ver owned by the corresponding OEM. us, this step requires
Internet connectivity4 for the user of the OBD-II-connected device in order to beable to
provide the gateway with some data that helps in authenticating the claimed role. Second,
once a role is authenticated, a session secret key is established between the gateway and
the OBD-II-connected device. is key is associated with the authenticated role for the
entire session lifetime. us, it is used to check the authorization level for each exchanged
CAN message by computing its message authentication code (MAC) on both sides. If the
MAC is veried at the gateway, it means that t he corresponding role has sent this message.
Accordingly, the gateway looks up in a look-up table stored in its memory, called the
permissions table, to see whether t hat role is authorized to do so. is adds another feature
that authenticates and veries the integrity of all exchanged CAN messages. Figure 6
provides a high-level description of our approach.
4 In areas where Internet connectivity is not always available, we propose to have specia l OBD-II devices
that would r un the entire procedure in the oine mode. us, these devices will hold some secret keys.
Accordingly, it should beprotected by strong and tamper-proof hardware modules.
FIGURE 6 A working scenario of secure OBD-II system.
© SAE International
Downloaded from SAE International by SAE International [Sales Team], Monday, September 21, 2020
Ammar et al. / SAE Int. J. Transp. Cyber. & Privacy / Volume 2, Issue 2, 2019 93
In the following, wedescribe the various parts of our
security mechanism in more detail.
RB AC mod el. As mentioned, weassume that the OEMs
are the only trusted parties. is assumption is reasonable
as each OEM is mainly concerned with preserving its intel-
lectual properties and privacy of its users. us, each OEM
is responsible for regulating and establishing policies that
control the way how OBD-II devices and soware applica-
tions can interact with the intra-vehicle network without
exploiting any of the vehicle functionality. We, therefore,
identify a set of roles that represent the building blocks of
our RBAC model. Please note that the denition of these
roles is made for demonstrative purposes, as more or fewer
roles can beconsidered depending on the corresponding
OEM. e roles are
•OEM: e OEM refers to the manufacturer of the vehicle.
Accordingly, the OEM is the only trusted party and
should have no restrictions to send and execute any CAN
command over the OBD-II. Also the OEM can act as an administrator to add or
revoke any role as required.
•Repair shop: e OBD-II is originally designed and standardized to allow repairmen
to diagnose and x the vehicle malfunctions. is access should berestricted in a
way that other in-vehicle functionality cannot betampered with (e.g., a repairman
should not beable to change the mileage of the vehicle to aect on its value).
•Insurance company: Sometimes insurance companies need restricted access to the
vehicle ECM to implement services such as Usage-Based Insurance.
•Vehicle owner: With respect to the right-to-repair law [31], third parties, i.e., the
owner, should begranted a level similar to Repair shops. However, they are not allowed
to perform some forbidden operations such as editing the mileage in order to increase
the car value.
•Police: Police agents should have some access rights to handle cases such as stolen
vehicles or tampering with the odometer values.
As such, a permissions table is specied (see Figure 7), which represents the output
of designing a ne-grained access control model (from the OEM point of view). For
example, in Figure 7, a repairman would beallowed to display the speed of the vehicle
(IDH: 02, IDL: 01), but prevented from alternating the odometer value (IDH: 04, IDL:
02). e permissions table is stored in an immutable memory area (read only) at the
guard gateway in order to protect its genuineness. Only the OEM (administrator) can
update its records, leveraging the administrator credentials.
Role authentication procedure. Our approach entails assigning each role a unique
ID and a key pair. e IDs and the public keys are stored along with the permissions table
in the read-only memor y (ROM) area at the gateway. e private keys are stored at a cloud
server owned by the OEM. At this server, it is the responsibility of the OEM to maintain
the secrets condential, validate credentia ls, anonymize data, etc. OBD-II device ma kers
will have their products (diagnostics tools, dongles, etc.) certied to work with the OEM’s
vehicles by implementing only the same cryptographic functions and CAN standards
used at the gateway side. All noncertied OBD-II devices will begranted a basic privilege
level, allowing only for harmless CAN packets (Default column in Figure 7).
Having a certied OBD-II device5 connected to the OBD-II port, the authentication
procedure begins by sending an initialization CAN packet containing the ID of the role
5 Please note that what we mean by an OBD-II device is either a sophisticated diagnostic tool that can
be connected directly to the Internet or a smar tphone, represented by its companion app, along with
the paired OBD-II dongle, as shown in Figure 6.
FIGURE 7 An example of a permissions table. “1” means that
the permission is granted for that role. ID = IDH (3 bits) + IDL
(8 bits). CAN message IDs are 11-bit long, where IDH represents
the three most significant bits, and IDL is all the remaining bits.
Each role is associated with a unique public key stored in the
same immutable memory area.
© SAE International
Downloaded from SAE International by SAE International [Sales Team], Monday, September 21, 2020
94 Ammar et al. / SAE Int. J. Transp. Cyber. & Privacy / Volume 2, Issue 2, 2019
(roleN) to the guard gateway6, as shown in Figu re 8. As a response, the gateway generates
a short-term key pair [i.e., KPGen(.)] and sends the public key to the OBD-II device,
which fur ther propagates it to the OEM Certication Authority (CA) (the OEM back-end
server). e OEM CA signs the hash value of the received key using the corresponding
role private key and sends this signature (Sig) back to the OBD-II device, which further
propagates it to the gateway. Both the gateway and the OEM CA are in a position now
to generate a shared secret key using the credentials they have (each one has a public
and private key of a dierent key pair) using a predened cryptographic primitive (e.g.,
Elliptic-curve Die-Hellman [ECDH]). Having the gateway veried the signature using
the corresponding role public key [Verify(.)], it generates a secret session key [KG en(.)],
computes the MAC value of the role ID using it and then transmits this value to the
OBD-II device, which forwards it to the OEM CA. On the other side, the OEM CA
generates the same session key in order to verify the MAC value. Having this value
veried means that the guard gateway has successfully authenticated the OBD-II device
w.r.t. the associated role. us, the OEM CA transmits the secret session key to the
OBD-II device over a previously established secure communication channel. See Fig ure 8.
Role authorization procedure. Having an OBD-II device authenticated by the
guard gateway w.r.t. a custom role does not mean that it is authorized to execute any
CAN command. Wetake advantage of MACs to verify the authenticity and integrity of
any CAN message as well as the authorization level of the role, as described in Figure 9.
First, the OBD-II device computes the MAC of CAN message using the shared session
secret key. en, both the CAN message and its MAC are accommodated in ISO-TP
format [34], the most commonly used protocol in OBD-II, where the payload length
goes up to 4095 bytes. e entire ISO-TP frame is sent to the guard gateway in compli-
ance with the standard CAN2.0A format. For further details about the transmission
mechanism t hat is shown in Fig ure 9, werefer to Appendi x A. If the MAC of the extracted
CAN packet is veried [VerifyMAC(.)], the gateway looks up in the permissions table
whether the associated role has the privilege to execute this CAN command or not
[CheckPermission(.)]. If so, it broadcasts the extracted legacy CAN packet to the target
6 Please note that users with certied OBD-II devices will have to rst authenticate to the back-end
server of the OEM through any of their Internet-connected dev ices using some credentials (e.g., a
username and password). e authentication procedure results in establishing a secure channel
between both par ties and getting the suitable role ID on the OBD-II-connected device. So the users get
role IDs assigned to them compulsively depending on their credentials. We consider the
implementation of this part of the protocol as out of scope since it is not the main objective of this
paper. Suitable aut hentication mechanisms have been already proposed and applied in commercial
products [32, 33].
FIGURE 8 OBD-II device authentication and key agreement.
© SAE International
Downloaded from SAE International by SAE International [Sales Team], Monday, September 21, 2020
Ammar et al. / SAE Int. J. Transp. Cyber. & Privacy / Volume 2, Issue 2, 2019 95
subnetwork. As soon as a reply is received by the gateway, it forwards it toward the
OBD-II port adopting the right format.
4.4. Discussions
Architecture independency. Some vehicle architectures do not consider providing a
gateway as shown in Figure 1. In principle, our security protocol can beeasily imple-
mented without a gateway. If so, each connected ECU to the CAN bus has to implement
the gateway part in the authentication procedure that is visualized in Figure 8 and only
maintains a permissions table that constitutes roles regarding its functionality. is
means that the records of the permissions table will bedistributed over the participating
ECUs. In a nutshell, our protocol can besimply implemented on the edge ECUs in
vehicles that lack gateways in their architecture.
Compatibility. Backward compatibility is supported easily in our protocol. For
example, if one of the involved parties does not adhere to the ISO-TP standard, multiple
legacy CAN frames can beused. In this case, the original CAN message is sent out rst
and then its associated MAC is embedded in the payload of multiple consecutive CAN
messages with an ID correlated to the original CAN message ID. To avoid overhead and
complexity, the MAC can betruncated to t in one CAN frame (64 bits), as suggested
by AUTOSAR [14].
Please note also that our protocol is implemented on top of ISO-TP, where addresses
for source and destination are added to specify the sender and receiver. is simplies
the task of the gateway when forwarding the received CAN message if it is successfully
authenticated. Likewise, in the case of lacking a gateway, this simplies the task of the
edge ECU, where only the corresponding one (the one that has its ID mentioned in the
destination eld) will handle the security-related procedures.
Memory protection. To maintain the security of the proposed protocol, all related
cryptographic primitives and data (e.g., the permissions table and public keys) should
beprotected from being tampered with by an attacker who has the ability to access the
rmware of the gateway. Since none of the stored data at the gateway is condential,
virtual ROM is sucient to address this requirement. All ECUs in today’s vehicles have
the capability to turn part of the memory into virtual ROM aer installing the data or
FIGURE 9 CAN message authentication/role authorization.
© SAE International
Downloaded from SAE International by SAE International [Sales Team], Monday, September 21, 2020
96 Ammar et al. / SAE Int. J. Transp. Cyber. & Privacy / Volume 2, Issue 2, 2019
code needed. With the administrator credentials, the OEM can reserve the right to
remotely write on this part when updates are required. Weconsider a virtual ROM, not
a real one, in order to preserve the feature of deploying updates remotely, without
requiring physical access to the vehicle. Isolating part of the memory and enforcing
some access control in modern ECUs do not require any external hardware or soware
as they have some built-in security primitives (e.g., memory protection units [MPU],
memory management units) [35, 36]. However, as wediscuss in Section 5, weprovide a
proof of concept implementation on highly resource-constrained ECUs to demonstrate
eciency. ese ECUs lack basic memory protection modules. erefore, weemploy an
open-source formally veried pure-so ware trusted computing architecture for resource-
constrained ECUs [37] (that is further customized to legacy automotive ECUs [38]),
which brings us two important benets: (i) memory protection by means that all OBD-II-
related functions and data are isolated in a virtual ROM and (ii) a secure remote update
mechanism that lets the administrator revoke or add roles and rights to the permissions
table when needed (likewise, updating public keys).
Advantage of requiring Internet connectivity. Dynamic updates on vehicles, i.e.,
adding/revoking roles, can occur automatically by utilizing the online authentication
step in the rst part of the protocol, where Internet connectivity is a must. is can
bedone by storing a version control number (VCN) along with public keys and permis-
sions table in the protected memory of the gateway. us the gateway can send the VCN
along with the generated short-term public key in the rst step of the authentication
procedure. e OEM server checks whether the corresponding vehicle holds the latest
updated VCN. If so, the authentication procedure continues as visualized in Figure 8.
Otherwise, it enforces the needed updates rst, updates the VCN, and then proceeds
with the authentication part. Such a technique is highly scalable and secure since any
vehicle will bealways up to date whenever someone tries accessing the OBD-II services.
For simplicity, weskip visualizing this part of the protocol. However, wedescribe it in
detail in Appendix B.
In areas where Internet connectivity is not always available and thus special hard-
ware-protected OBD-II devices are used to run the full protocol in the oine mode, the
OEM can always propose a temporary license of the soware inside such devices, where
they have to beconnected to the Internet, for example, at least once a month. Accordingly,
they can beupdated and enforce updates over any vehicle they are connected to later
on. Please note that Internet connectivity is required on a device, i.e., smartphone, that
is held by the user and not on the vehicle itself.
Adaptabilit y. Our solution is architecture independent. us, it can beintegrated
into new vehicles easily. Existing vehicles can adapt this solution whenever they have to
go through the regular control-technique check process. Integrating this solution inside
any vehicle is as easy as remote soware updates.
On the other hand, the design of our solution can besimply implemented inside
an external specic dongle rather than being implemented as a soware protocol
inside vehicles. is dongle should beattached to the OBD-II port in order to secure it.
is solution is valid for areas where existing on the road vehicles do not go through
control-technique check processes, i.e., in some third-world countries, while their drivers
or owners are still interested in securing the OBD-II port.
4.5. Security Analysis
We analyze the security of our protocol by describing how the desired security require-
ments (Section 4.2.1) are satised w.r.t. our attacker model (Section 4.1).
It is obvious that the security of our protocol depends on the OEM, the most inter-
ested party in security, to protect the IP as well as safety-critical components. All long-
term secrets are saved in an OEM-owned secure cloud server, that is, weassume secure,
tamper-proof storage capacity a nd code execution on this server (SE3). OBD-II- connected
devices are authenticated to the gateway via the OEM server through a challenge-
response protocol (SE1). e authentication procedure results in a shared session secret
key between the gateway and the OBD-II device. e use of session keys avoid replay
Downloaded from SAE International by SAE International [Sales Team], Monday, September 21, 2020
Ammar et al. / SAE Int. J. Transp. Cyber. & Privacy / Volume 2, Issue 2, 2019 97
attacks (SE4), as their lifetime is limited to a short-term session (a few minutes).
Leveraging the resulted session key, our solution allows us to verify message authenticity
and role authorization level using MACs (SE1, SE2). Memory protection is guaranteed
by the memory protection technique employed (or the underlying hardware) (SE5). To
address the nal security requirement, weemploy asymmetric cry ptography where only
public keys are stored in the gateway and nothing stored at user devices (SE6).
We distinguish between three dierent cases for an adversary, adv, where these
cases cover all possibilities according to our attacker model. First, adv will try to
bypass the authentication procedure by claiming another role ID, in order to send
CAN packets belonging to a dierent privilege level. Our approach depends on a two-
verier (the gateway and the OEM CA) authentication procedure hosted in trustworthy
components (guaranteed ROM at the gateway side and immune high-end server at
the OEM side). us, adv has to convince the OEM to send a valid signature and then
the secret session key of the role ID chosen. is is considered infeasible as adv has
to beauthenticated rst by the OEM server in order to establish a secure communica-
tion channel and get assigned the role ID compulsively, depending on some factors
(e.g., corresponding credentials, device used) (as mentioned, this part of the protocol
is considered out of scope).
Second, adv will try to control the network outside the vehicle in order to record
packets and apply some attacks. By eavesdropping on exchanged messages, adv would
gain nothing as no secret data is exchanged (except for a session secret key over a prees-
tablished secure communication channel). Accordingly, a passive MITM attack is useless
in this case, whereas an active MITM attack can bedetected directly, since integrity is
veried during the entire lifetime of the authentication process by both the gateway and
OEM server, resulting in dropping the altered packet and ending the process. Replay
attacks are mitigated by the use of short-term session keys. Even it is infeasible for an
adv who recorded some authenticated CAN packets and then tried physically to unplug
the attached OBD-II device and plug his/her device in order to replay the recorded
messages, beneting from the underlying open session. e gateway prevents this since,
by design, as soon as an OBD-II device is plugged or unplugged, the gateway get notied
by a signal and accordingly ends the ongoing session. Applying side-channel attacks is
useless as no secrets stored at either the gateway or the OBD-II device. Furthermore,
our protocol is immune to remotely exploitable soware side-channels that aim to extract
the session secret key (before being deleted), as the time required will bemuch longer
than the lifetime of the ongoing session [39].
ird, adv will try to exploit remotely another potential attack vector on the vehicle
to alter some data or code on the gateway. Our protocol is secure against arbitrary code
execution and data manipulation since the memory of the gateway is tamper-proof (due
to the memory isolation technique employed or underlying hardware). Moreover, if adv
manages to get access over the CAN bus, he/she will not beable to manipulate or jam
the CAN trac between the OBD-II and the gateway unless sending a higher priority
CAN message. is message will bedropped by the gateway aer failing in verifying its
MAC. Furthermore, performing replay attacks is useless due to the nature of the CAN,
where all CAN packets are broadcasted and thus seen by all ECUs on the same bus.
e only possibility le for adv, in our scheme, is to guess secrets and MACs.
Weshow that our protocol is secure against these attacks in Section 5.2.3 (aer the
technical part).
ImplementationandEvaluation
5.1. Implementation
e automotive industry has seen processors with microcontrollers (MCU) transitioning
from a simple 8-bit MCU to a complex 64-bit multitasking one that communicates to
numerous other processor-based modules located throughout the entire vehicle. Hence,
Downloaded from SAE International by SAE International [Sales Team], Monday, September 21, 2020
98 Ammar et al. / SAE Int. J. Transp. Cyber. & Privacy / Volume 2, Issue 2, 2019
weimplement two proofs of concept scenarios of our protocol using two dierent types
of ECUs. In the rst proof, weuse two ECUs with a processor of 8-bit MCU each.
Demonstrating the efficiency and robustness of our proposal on such resource-
constrained components would give an indicator of the performance when using
powerful ECUs that are currently employed in modern vehicles. In particular, wehave
chosen two development kits of the type DVK90CAN1 [40], where the rst kit represents
the gateway and the second one the OBD-II-connected device. e DVK90CAN1
platform oers an 8-bit AT90CAN128 microcontroller [41] running at 8 MHz, with
4KB of static random-access memory (SRAM) and 128KB of ash memory. Most
importantly, it provides a CAN interface along with other on-board resources (dual
RS232, LIN, SPI and TWI, keyboard, light sensors, etc.).
A CAN-to-OBD-II and OBD-II-to-CAN connectors are used to act as an inter-
mediate bridge (OBD-II port) between the gateway and OBD-II-connected device.
Wehave connected the OBD-II-connected device to a local desktop computer through
the RS232 interface to simulate the OEM back-end server (in reality, wireless connec-
tivity is used). For demonstration purposes, wehave also congured the gateway device
to print what is going on through the authentication and authorization procedures via
its RS232 interface, which has been connected to another PC. Wehave implemented
the intra-vehicle network logically on the gateway platform leveraging the various
built-in sensors (acted as ECUs) on the same platform. Finally, wehave implemented
the CAN stack (up to the session layer) with the support of an open-source ISO-TP
library as indicated in [15].
In the second scenario, weimplement the same protocol using two more powerful
hardware platforms that are more representative of modern vehicles, i.e., self-driving
ones. Wehave chosen a development kit from NXP of the type TRKMPC560xB [42],
which is widely used in the automotive body and oers a 32-bit MPC560xB MCU [43],
running at 64 MHz, with 96KB of SRAM, 1.5MB of ash memory, and 6 CAN channels.
e MCU has an MPU.
Cryptographic primitives. Elliptic Curve Cryptography (ECC) is used [44]. In
particular, secp256rl curve is employed for key pairs generation, where the size of the
private key is 256 bits and the public key is 512 bits long. Elliptic Curve Digital Signature
Algorithm (ECDSA) is used for signing and verifying signatures. e ECDH Scheme is
used as a key agreement and derivation protocol to generate the session key. Furthermore,
HMAC-SHA256 is employed as a keyed hash-based message authentication code
(HMAC) to verify message authenticity and integrity. In the rst scenario, wehave
employed a soware-based trusted computing architecture [37] in AT90CAN128 MCU
to provide memory protection as it does not have an MPU. Atop both platforms (in both
scenarios), wehave implemented a secure remote update technique that preserves authen-
ticity, integrity, and condentiality. (is procedure is described in Appendix B.)
5.2. Evaluation
5.2.1. Performance We evaluate the performance of our protocol in terms of runtime
overhead and memory footprint.
Runtime overhead. Our protocol consists of two major procedures: (i) Role authen-
tication, which is performed once at the beginning of every session, and (ii) Role autho-
rization and message integrity checking, which is performed when receiving a CAN
message during the underlying session. e rst procedure consumes about 21.9 s and
2.34 s in Scenario 1 and Scenario 2, respectively, whereas the second one requires no
more than 79.5 ms (end-to-end: sending a CAN message with its MAC, verifying MAC,
looking up in the permissions table, etc.) in Scenario 1, compared to 8.39 ms in Scenario
2. Wehave performed our evaluation test on low-speed CAN (a baud rate of 125 Kbps).
is means that the runtime overhead is dominated by the cryptographic primitives
used, especially ECC. Tabl e 1 shows the runtime overhead incurred by such primitives
on both selected ECUs. (Please note that ECDSA sig n is performed on the OEM back-end
server but weindicated how long it takes when performing on the same platform.) While
Downloaded from SAE International by SAE International [Sales Team], Monday, September 21, 2020
Ammar et al. / SAE Int. J. Transp. Cyber. & Privacy / Volume 2, Issue 2, 2019 99
the performance on both scenarios is acceptable as upon authentication, sending and
receiving authenticated CAN packets consumes fractions of a second (few milliseconds),
reports point out that modern automotive gateways have MCUs with clock speeds
ranging from 48MHz to several hundred megahertz. Moreover, the vast majority of
such gateways are equipped with hardware-based ECC and SHA2 modules [35, 36]. is
indicates that the entire protocol runtime may require few milliseconds, and speaking
authenticated CAN messages would take a few microseconds. On the other hand, in
Scenario 1, the remote secure update mechanism does not require more than 171.6 ms
to update a data block of 256 bytes on the gateway (carried over RS232 and then CAN),
compared to 18.45 ms in Scenario 2.
Memory footprint. e gateway uses ash memory to store both code and data.
e memory footprint of various code components is indicated in Table 2. e overall
code size does not exceed 27KB (including the CAN driver that is already implemented
in the vehicle gateway), which amounts to less than 20% of the total 128KB ash avail-
able on the ECU used in Scenario 1, and less than 1.8% of the total ash available on the
ECU used in Scenario 2. e data represents public keys, role IDs, and the permissions
table. e size of data depends on the number of stored roles and their associated keys,
along with the size of the permissions table. In our demonstrative implementation, the
data consumes no more tha n 400 bytes of ash memory. To reduce the size of the permis-
sions table, OEMs can only include restricted CAN messages in it, thus allowing all
others by default to all roles. However, the size of considering all CAN messages with
even an extended identier will not go beyond 21KB (more or less, there are about 211
CAN messages) [2]. While the memory footprint measured is reasonable, reports show
that gateways used in modern vehicles include MCUs with Code Flash memories (and
separated Data Flash) ranging from 256KB to several hundred megabytes, as well as a
hardware-based ECC module [35, 36]. is means that in most of today’s vehicles, the
ash memory utilization, in the worst case, will not exceed 1% of overall ash available.
On the other hand, our implementation incurs no SRAM overhead as all data is stored
in the ash. e stack is used for short-term data storage when generating session keys
and calling subroutines. To guarantee that all code modules function properly, no more
than 2KB of free RAM is required.
5.2.2. System Requirements To satisfy the performance requirement (SY1),
wemeant to target a high security level while using lightweight cryptography. In partic-
ular, weuse symmetric keys in the periodic phase to compute MACs, reducing the
roundtrip time of authenticated CAN messages to a few milliseconds as illustrated in
Section 5.2.1. Furthermore, our protocol complies with all AUTOSAR specications
that require no changes to the CAN standards (SY2). Also legacy OBD-II devices can
still properly function when connected to security-enabled gateways/ECUs as they are
granted a basic authorization level as discussed previously. To address the last functional
requirement, our solution is pure soware that can beseamlessly integrated into new
vehicles without the need to change their design specications (SY3). Also the procedure
of applying it to the currently onroad vehicles is with the same ease of use as over-the-air
TABLE 2 The flash memory footprint of protocol code.
Module HMAC-SHA256 ECC CAN MicroVisor Rest (UART, etc.) Total
Size (byte) 2378 17684 4560 1110 842 26574
© SAE International
TABLE 1 Runtime overhead of cryptographic primitives used.
ECC HMAC-SHA256
Component KPGen ECDSA sign ECDSA verify ECDH (KGen)
CAN MAC
verification
MPC560xB 0.734 s 0.780 s 0.869 s 0.734 s 2.54 ms
AT90CAN128 6.84 s 7.2 74 s 8.123 s 6.838 s 23.77 ms
© SAE International
Downloaded from SAE International by SAE International [Sales Team], Monday, September 21, 2020
100 Ammar et al. / SAE Int. J. Transp. Cyber. & Privacy / Volume 2, Issue 2, 2019
updates (SY3). OEMs can collaborate with authorities to license its installation on
remotely unreachable vehicles when making the yearly check for control technique.
5.2.3. Security Evaluation Section 4.5 covered the various attack scenarios (w.r.t.
the attacker model [Section 4.1]) and showed how our protocol is secure against all of
them. In this case, the security argument reduces to the security of cryptographic
modules used, namely, ECC and HMAC-SHA2. Hence, the attacker would try to guess
either the private key of the corresponding role to send valid signatures, and thus being
authenticated, or the symmetric session key to send authorized CAN messages aer
getting access to the CAN bus somehow while there is a session going on. Each of these
keys is 256 bits long. In order to maintain a high-security level, AUTOSAR requires
symmetric keys of at least 128-bit length [14]. While the length of the symmetric key
chosen has a higher security level, the private key belongs to this level (half of the length,
according to ECC specs. [44]). So even with this length, to nd the correct secret key,
the attacker w ill try to brute-force attack all possible values, requiring 2127 MAC/si gnatu re
calculations, which is considered infeasible even for extremely powerful adversaries.
e only leverage le for an attacker is to guess the MAC value itself for a specic CAN
message. is value is variant and depends on the session key used. Even for long sessions,
guessing such values depends on the security level associated with the hash function,
which is half of the output length (in bits), 128 bits in our case, rendering it infeasible.
In the case of MAC truncation, MAC sizes of 64 bits and above are considered to provide
sucient protection against guessing attacks by NIST [14]. Furthermore, forging valid
signatures is nearly impossible as the ECDSA scheme used is designed to beexistentially
unforgeable, even in the presence of an adversary capable of launching chosen-message
attacks [44], that is, our protocol is secure against the attacker model specied in Section
4.1. Please note that the exclusion of public-key cryptography and depending only on
symmetric keys is not possible in any way, as extracting the secret keys from any vehicle
would render all other vehicles insecure.
5.2.4. Our Approach versus Others Recently, AUTOSAR has released version
4.4 specications for the classic platform, where they propose adding a Uni ed Diagnostics
Service (UDS), named service 0x29, for authentication [29]7
. In this version, they suggest
to use a certicate-based protocol to authenticate OBD-II devices and assign them xed
roles based on their certicates. Despite being in its infancy stage, as there is not yet a
concrete protocol and implementation, the AUTOSAR proposal has several limitations
compared to our approach. First, they build atop modern architectures where several
hardware-based cryptographic modules are employed to manage keys and perform
securit y operations. is makes it only suitable for the currently being developed vehicles,
not the already existing ones. Second, they propose to use full certicates where they
mention handling these certicates is very time consuming; whereas in our approach,
weuse only signatures, ta king into account the existence of resource-constrained ECUs.
ird, despite storing initial permissions and roles at the edge ECUs, they consider
adding new roles or permissions by embedding them each time in the exchanged certi-
cates, which is a very expensive and not scalable process; whereas in our approach,
weconsider a secure remote update technique that can be performed whenever the
external connectivity is available as users are forced to do it before ring any action over
the OBD-II port. Furthermore, it is unclear how the AUTOSAR proposal handles the
revocation of roles or permissions. Fourth, t hey consider storing some long-term private
keys in the vehicle itself, which makes physical attacks scalable as it would beextremely
dicult to assign millions of dierent keys to millions of vehicles; whereas in our
proposal, nothing secret is stored in the vehicle. Fih, our proposal takes into account
existing aermarket dongles and diagnostics tools where they still can beused without
sacricing security, whereas the AUTOSAR proposal clearly demands new tools with
specic characteristics. Last, the AUTOSAR proposal does not mention how exactly the
7 Please note that AUTOSAR has another newer release, named R19-11. However, in this release, nothing
is changed regarding the 0x29 authentication service.
Downloaded from SAE International by SAE International [Sales Team], Monday, September 21, 2020
Ammar et al. / SAE Int. J. Transp. Cyber. & Privacy / Volume 2, Issue 2, 2019 101
OBD-II devices will get their certicates and whether they are required to contact any
other entity during the interaction with the vehicle.
Conclusion
In this paper, wesurveyed the essential aspects of the OBD-II port and highlighted its
security issues. Wefurther proposed an AUTOSAR-compliant end-to-end security
protocol to protect the intra-vehicle network from unauthorized access via the OBD-II.
Our protocol is built on top of lightweight cry ptographic primitives along with a at RBAC
model. It is designed with architecture independence as a feature in mind. us, it can
beeasily implemented as a pure-soware protocol inside vehicles or standalone external
dongles dedicated to add ing a security layer to the OBD-II port. Evaluation results illustrate
high performance, eciency, and security, considering a powerful attacker model.
Acknowledgment
is research is supported by the research fund of KU Leuven and imec, a research
institute founded by the Flemish government. It is also partly supported by the EU
H2020-SU-ICT-03-2018 Project No. 830929 CyberSec4Europe.
e authors would like to thank Michiel Willems for implementing part of the
protocol during the work on his master thesis.
References
1. Itabashi, T. and Makino, A., “Electronic Control Unit,” US Patent 6,816,377, Nov. 9, 2004.
2. Davis, R.I., Burns, A., Bril, R.J., and Lukkien, J.J., “Controller Area Network (can)
Schedulability Analysis: Refuted, Revisited and Revised,” Real-Time Systems 35(3): 239-
272, 2007.
3. Viriyasitavat, W., Boban, M., Tsai, H.-M., and Vasilakos, A., “Vehicular Communications:
Survey and Challenges of Channel and Propagation Models,” IEEE Vehicular Technology
Magazine 10(2):55-66, 2015.
4. ENISA, “Cyber Security and Resilience of Smart Cars, Good practices and
Recommendations,” 2016.
5. Koscher, K., Czeskis, A., Roesner, F., Patel, S., Kohno, T., Checkoway, S., McCoy, D.,
Kantor, B., Anderson, D., Shacham, H. et al., “Experimental Security Analysis of a
Modern Automobile,” in Security and Privacy (SP), 2010 IEEE Symposium on. IEEE,
Berkeley/Oakland, CA, USA, 2010, 447-462.
6. Checkoway, S., McCoy, D., Kantor, B., Anderson, D., Shacham, H., Savage, S., Koscher, K.,
Czeskis, A., Roesner, F., Kohno, T. et al., “Comprehensive Experimental Analyses of
Automotive Attack Surfaces,” in USENIX Security Symposium, San Francisco, 2011, 77-
92.
7. Miller, C., and Valasek, C., “A Survey of Remote Automotive Attack Surfaces,” Black Hat
USA 2014:94 , 2014.
8. Petit, J., and Shladover, S.E., “Potential Cyberattacks on Automated Vehicles,” IEEE
Transactions on Intelligent Transportation Systems 16(2):5 46-556, 2015.
9. Bernardini, C., Asghar, M.R., and Crispo, B., “Security and Privacy in Vehicular
Communications: Challenges and Opportunities,” Vehicular Communications, 10:13-
28, 2 017.
10. Miller, C., and Valasek, C., “Remote Exploitation of an Unaltered Passenger Vehicle,”
Black Hat USA 2015:91, 2015.
Downloaded from SAE International by SAE International [Sales Team], Monday, September 21, 2020
102 Ammar et al. / SAE Int. J. Transp. Cyber. & Privacy / Volume 2, Issue 2, 2019
11. Miller, C., and Valasek, C., “Adventures in Automotive Networks and Control Units,” Def
Con 21:260-246, 2013.
12. Klinedinst, D. and King, C., “On Board Diagnostics: Risks and Vulnerabilities of the
Connected Vehicle,” CERT Coordination Center, Tech. Rep, 2016.
13. Wen, H., Chen, Q.A., and Lin, Z., “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), Boston, USA, 2020.
14. aUtOSAR, “Specication of Secure Onboard Communication Autosar cp release 4.4,”
Specication, 2018.
15. Authors of the paper, “e Source Code of the Secure OBD-II Protocol on AVR MCUs,”
2020, https://github.com/m3mmar/secure-OBD-II.
16. Tuohy, S., Glavin, M., Hughes, C., Jones, E. et al., “Intra-vehicle Networks: A Review,”
IEEE Transactions on Intelligent Transportation Systems 16(2):534 -545, 2015.
17. ISO, “Iso 11898-1:2015 Road Vehicles- Controller Area Network (can)- Part 1: Data Link
Layer and Physical Signalling,” International Organization for Standardization,
Standard, 2015.
18. SAE, “Diagnostic Trouble Code Denition J2012_201303,” 2013, https://www.sae.org/
standa rds/content /j2012 _ 201303/, Online; accessed 07-January-2019.
19. SAE, “Diagnostic Connector Equivalent to ISO/DIS 15031-3: December 14, 2001
J1962_201207,” 2001, https://www.sae.org/standards/content/j1962_201207/, Online;
accessed 07-January-2019.
20. McCord, K., Automotive Diagnostic Systems: Understanding OBD Iand OBD II
(S-A Design, 2011), ISBN:978-1934709061.
21. Smit h , C ., e Car Hacker’s Handbook: A Guide for the Penetration Tester (starch press,
2016), ISBN:9781593277031.
22. ISO, “Iso 15031-7:2013 Road Vehicles- Communication between Vehicle and External
Equipment for Emissions-related Diagnostics- part 7: Data Link Security,” International
Organization for Standardization, Standard, 2013.
23. Ring, M., Rensen, T., and Kriesten, R., “Evaluation of Vehicle Diagnostics Security-
implementation of a Reproducible Security Access,” in SE CU RWA RE 2014, Lisbon,
Portugal, 2014, 213.
24. AUTOCAR, “How Crooks Can Steal Your Car- Without the Key,” 2015, https://www.
autocar.co.uk/car-news/industry/how-crook s-can-steal-your-car-without-key/, [Online;
accessed 07-January-2019].
25. ExtremeTech, “Hack the Diagnostics Connector, Steal Yourself a BMW in 3 minutes,”
2012 , http://www.extremetech.com/extreme/132526-hack-the-diagnostics-connector-
steal-yourself-a-bmw-in-3-minutes, [Online; accessed 07-January-2019].
26. Argus Cyber Security, “A Remote Attack on an Aermarket Telematics Service,” 2014,
https://argus-sec.com/remote-attack-aermarket-telematics-service/, [Online; accessed
07-January-2019].
27. Argus Cyber Security, “A Remote Attack on the Bosch Drivelog Connector Dongle,” 2017,
https://argus-sec.com/remote-attack-bosch-drivelog-connector-dongle, [Online; accessed
09-Januar y-2019].
28. Markham, T.R., and Chernoguzov, A., “A Balanced Approach for Securing the
OBD-ii Port,” SAE Technical Paper 2017- 01-1662 , 2017, https://doi.org/10.4271/2017-
01-1662.
29. AUTOSAR, “Specication of Diagnostic Communication Manager cp Release 4.4.0,”
AUTOSAR, Standard, 2018.
30. Ferraiolo, D.F., Sandhu, R., Gavrila, S., Kuhn, D.R., and Chandramouli, R., “Proposed
NIST Standard for Role-based Access Control,” ACM Transactions on Information and
System Security (TISSEC) 4(3): 224 -274, 2001.
Downloaded from SAE International by SAE International [Sales Team], Monday, September 21, 2020
Ammar et al. / SAE Int. J. Transp. Cyber. & Privacy / Volume 2, Issue 2, 2019 103
31. “Memorandum of Understanding,” Auto Alliance, Global Automakers, Automotive
Aermarket Industry Association, and Coalition for Auto Repair Equality,
Specication, 2014.
32. Burgardt, C.A.P., “In-vehicle Network Security: Attacks and Countermeasures,” 2018.
33. Tan, H., Ma, M., Labiod, H., Boudguiga, A. et al., “A Secure and Authenticated Key
Management Protocol (sa-kmp) for Vehicular Networks,” IEEE Transactions on Vehicular
Technology 65(12):9570-9584, 2016.
34. ISO, “ISO 15765-2:2016,” 2016, https://www.iso.org/standard/66574.html, [Online;
accessed 07-January-2019].
35. Inneon Technologies, “Aurix 32-bit Microcontrollers for Automotive and Industrial
Applications,” Technical Report, 2018, https://www.inneon.com/dgdl/Inneon-
TriCore_Family_BR-2018-BC-v03_00-EN.pdf?leId=5546d4625d5945ed015dc81f47b43
6c7, [Online; accessed 01-January-2019].
36. STMicroelectronics, “32-bit Power Architecture mcu for Automotive Body and Gateway
Applications,” 2018, https://www.st.com/en/automotive-microcontrollers/spc560d30l3.
html, [Online; accessed 01-January-2019].
37. Ammar, M., Crispo, B., Jacobs, B., Hughes, D., and Daniels, W., “Sμv-the Security
Microvisor: A Formally-veried Soware-based Security Architecture for the Internet
of ings,” IEEE Transactions on Dependable and Secure Computing 16(5):8 85 -
901, 2019.
38. angarajan, A.S., Ammar, M., Crispo, B., and Hughes, D., “Towards Bridging the Gap
between Modern and Legacy Automotive ecus: A Soware-based Security Framework for
Legacy ecus,” in 2019 IEEE 2nd Connected and Automated Vehicles Symposium (CAVS).
IEEE, Honolulu, Hawaii, USA, 2019, 1-5.
39. Koeune, F. and Standaert, F.X., “A Tutorial on Physical Security and Side-Channel
Attacks,” In: Aldini, A., Gorrieri, R., and Martinelli, F., (eds), Foundations of Security
Analysis and Design III, FOSAD 2005, FOSAD 2004. Lecture Notes in Computer Science,
vol 3655 (Berlin, Heidelberg: Springer, 2005), https://doi.org/10.1007/11554578_3.
40. Atmel, “DVK90CAN1 Hardware User Guide,” 2008, http://ww1.microchip.com/
downloads/en/devicedoc/doc4381.pdf, [Online; accessed 01- January-2019].
41. Atmel, “8-bit AVR Microcontroller with 32K/64K/128K Bytes of ISPFlash and CAN
Controller,” 2008, http://ww1.microchip.com/downloads/en/devicedoc/doc7679.pdf,
[Online; accessed 01-January-2019].
42. NXP, “TRK-MPC5604B Automotive Body and Industrial Applications,” 2010, htt p://
cache.freescale.com/les/microcontrollers/doc/user_guide/TRKMPC5604BEVBUM.
pdf ?f psp =1, [Online; accessed 10- January-2019].
43. NXP, “MPC5606BK Microcontroller Data Sheet,” 2017, https://www.nxp.com/docs/en/
data-sheet/MPC5606B.pdf, [Online; accessed 10- January-2019].
44. Certicom Corp., “Standards for Ecient Cryptography sec 1: Elliptic Curve
Cryptography v2.0,” Certicom Corp., Standard, 2009.
45. AUTOSAR, “Specication of Can Transport Layer Autosarcp release 4.4,” AUTOSAR,
Standa rd , 2 018.
AppendixAISO-CAN
e ISO 15765-2 CAN [34], called also ISO-TP (Transport Layer), is the most popular
communication protocol used at the OBD-II DLC. All vehicles made aer 2008 should
implement this protocol [20]. In ISO-TP, the message length goes up to 4095 bytes. Most
importantly, it meets the requirements of any CAN network as specied in ISO 11898-1
and complies with the diagnostics services established in ISO 14229-1 and ISO 15031-5.
Downloaded from SAE International by SAE International [Sales Team], Monday, September 21, 2020
104 Ammar et al. / SAE Int. J. Transp. Cyber. & Privacy / Volume 2, Issue 2, 2019
Furthermore, it supports the standardized service primitive interface that is specied
in ISO 14229-2, the Unied Diagnostics Service (UDS).
Having it as a higher layer atop CAN2.0 (see Figure A.1), the format of the ISO-TP
messages follows the classical CAN frames format (see Figure 2); as whatever is the length
of the message, it will bedivided into multiple CAN frames with a maximum payload of
8 bytes long. In order to help the receiving controller know the length of the message and
number of frames that have to besent, ISO-TP reserves one byte of the payload in each
frame to act as Protocol Control Information (PCI) byte. us, the actual data has 7 out
of 8 bytes. e PCI byte is divided into two parts; the four most signicant bits represent
the PCI type, whereas the meaning of the remaining four bits depends on the length of
the message. ere are four types of frames (PCI): Single Frame (SF) = 0, First Frame
(FF) = 1, Consecutive Frame (CF) = 2, and Flow Control (FC) = 3. If the message length
is equal or less than 7 bytes, SF is used. So the rst part of the PCI byte will equal 0
(meaning SF) and the remaining bits represent the length of the message (e.g., 0x06 means
a single message with a lengt h of 6 bytes). In case of longer messages, Multi-Frame format
is used, in which the sender controller sends a frame of type FF as a rst frame, waits for
an FC frame as a reply from the receiving controller containing information on how and
when to send subsequent frames (synchronization), and then sends a ll subsequent frames
using the CF type according to guidelines specied in the FC reply. An exception in FF
is that 2 bytes are reserved as PCI bytes (compared to 1 byte in other types). e four
most signicant bits represent the PCI type which is 1, and the remaining 12 bits are for
the message length. In the CFs (the rest of the message), the four least-signicant bits in
the PCI byte act as a rolling counter starting at 1 and resetting aer reaching 0x0F. For
example, a message of 10 bytes long will berepresented by 2 frames; the rst one is of
type FF: 0x10 0x0A 0x01 0x02 0x03 0x04 0x05 0x06, and the second one is CF: 0x210x07
0x08 0x09 0x0A. For further technical details, werefer the reader to [45].
AppendixBTheSecureRemote
UpdateTechnique
Due to the change of access control model requirements and emerging security
threats, the secure remote update of roles and privileges is a necessity. While remote
updates oer exibility, they also increase the attack surface as attackers can misuse this
mechanism to install malware remotely. In our design, weconsider that the OEM can
ISO 11898 Series
Vehicle Diagnostics
ISO-TP/ISO 15765-2
CAN 2.0/CAN-FD
Physical and Datalink
Layer
Network andTransport
Layer
ISO 14229 Sessions Layer
Vehicle CAN Messages
Message Processing/
Validation
DTC Management Presentation Layer
OBD/OEM Specific
Diagnostics (ISO 15031, ISO
27145 etc.)
Application Layer
Message
Callbacks
Signal
Callbacks
Various OEM
Applications
Modules defined or
associated with standards
Modules maintained by OEM/
Other companies
FIGURE A.1 The automotive CAN stack.
© SAE International
Downloaded from SAE International by SAE International [Sales Team], Monday, September 21, 2020
Ammar et al. / SAE Int. J. Transp. Cyber. & Privacy / Volume 2, Issue 2, 2019 105
update the data on any security-enabled ECU in any vehicle aer generating the secret
session key and before sending it to the user of the OBD-II device. us, wetake advan-
tage of this key before its legacy use.
Secure remote update refers to the process of setting up, revoking, or adding new
roles, privileges, or public keys on the targeted ECU without compromising the security
of the vehicle. Four security threats can aect the remote secure update procedure: (i)
rmware/data alteration, (ii) rmware/data reverse engineering, (iii) loading unauthor-
ized rmware/data, and (iv) loading authorized rmware/data onto unauthorized
devices. Accordingly, three security attributes must befullled in order to secure the
updating process and overcome these threats: (i) data condentiality, (ii) authenticity,
and (iii) integrity. In our prototype (implementation), weskip data condentiality as
weupdate public data, which can beread by any party at any time. However, weaddress
data condentiality in the protocol below. Hence, secure update allows the target ECU
in the vehicle, denoted as an Updater, to verify that a data received over the (CAN)
network is uncompromised, condential, and issued by an authorized and trusted entity
(the OEM), denoted as an Issuer. More formally, wedene secure remote update
as follows:
Definition of Secure Remote Update: A protocol Q is comprised of the
following components:
•Setup(1K): A probabilistic algorithm that, given a security parameter 1K, outputs
short-term key K. is key is shared between both parties.
•Encrypt(K, i): A deterministic algorithm used by the Issuer that, given a pre-shared
key K and a binary text i, outputs a ciphertext γ.
•Sign(K, γ): A deterministic algorithm used by the Issuer that, given a pre-shared key
K and a ciphertext γ, outputs a token β.
•Ver ify (K, γ, β): A deterministic algorithm used by the Updater that, given a pre-
shared key K, a ciphertext γ, and a token β, outputs 1 i β reects the ciphertext γ at
the Issuer side, and outputs 0 otherwise.
•Decrypt(K, γ): A deterministic algorithm used by the Updater that, given a pre-shared
key K, a ciphertext γ, and a one value as an output of Verify, extracts the binary
image i.
ese components are used in the protocol Q between Issuer (the OEM) and
Updater (the target ECU- mostly the gateway) in this manner:
•Both Issuer and Updater possess a short-term key, K, generated by running Setup(1K),
which means running the authentication procedure, without sending K to the OBD-
II-connected device. is ensures authenticity. If encryption and decryption are
considered, it is better to generate another session key for that.
•Issuer issues an updated binary image of data i and encr ypts it using one of the session
keys to ensure condentiality. e output of the encryption process is γ.
•Issuer generates token β using the other session key, by executing Sign(K, γ). is
token serves as a MAC to ensure integrity. Both γ and β are sent to the Updater
following the specication of the communication medium at each intermediate point,
as illustrated in Appendix A.
•Updater receives the (encrypted) image of data γ and token β and runs Verify(K, γ, β)
and Decrypt(K,γ) respectively.
•e output is the binar y image of data i if the integrity is veried by Ve r i f y. Otherwise,
nothing occurs and update does not take place.
A. Implementing the secure remote update technique in legacy ECUs leveraging the
soware-based trusted computing architecture [37].
Downloaded from SAE International by SAE International [Sales Team], Monday, September 21, 2020
© 2020 SAE In ternational. Al l rights reser ved. No part of thi s publication may b e reproduced, s tored in a retrieval sys tem, or transmi tted, in any form or by a ny means,
electronic, mechanical, photocopying , recording, or otherwise, without the prior written permission of SAE International.
Positions and opinions advanced in this work are those of the author(s) and not necessa rily those of SAE International. Responsibility for the content of the work lies
solely with the author(s).
106 Ammar et al. / SAE Int. J. Transp. Cyber. & Privacy / Volume 2, Issue 2, 2019
e minimal set of properties required to ensure secure code update on the IoT
device coincides with the properties discussed in [37], namely, invocation from start,
exclusive access to secret K, uninterruptibility, immutability, and no leaks. As argued
in that paper, the formally veried soware-based architecture can guarantee these
properties without any specialized hardware support.
Sign and Ve r i fy rely once again on calculating a MAC of the entire encr ypted update
image and its metadata. e Issuer uses Sign to compute the MAC of the cipher image
using a pre-shared key that is dierent from the secret key used to encrypt the binary
image. e complete condential image along with its MAC is transmitted to the
Updater, where Verify computes the MAC once more using the corresponding secret
key. If this newly computed MAC does not match the received one, the image or its
metadata has been tampered with in transit (integrity), or the Issuer did not possess the
correct secret key (authenticity). e decryption process takes place if the output of
Verify is positive (condentiality).
Analogously, the secure remote update occurs on modern ECUs leveraging the
underlying hardware security modules.
Downloaded from SAE International by SAE International [Sales Team], Monday, September 21, 2020
