2016 IEEE TrustCom-BigDataSE-ISPA

TrustCom/BigDataSE/ISPA

Log your car: The non-invasive vehicle forensics

Hafizah Mansor∗ , Konstantinos Markantonakis† , Raja Naeem Akram‡ , Keith Mayes§ and Iakovos Gurulian¶
Information Security Group, Smart Card Centre,
Royal Holloway, University of London, United Kingdom
Email: {∗ Hafizah.Mansor.2011,‡ RajaNaeem.Akram.2008,¶ Iakovos.Gurulian.2014}@live.rhul.ac.uk
{† K.Markantonakis,§ Keith.Mayes}@rhul.ac.uk

Abstract—Digital forensics is becoming an important fea-

ture for many embedded devices. In automotive systems, digi-
tal forensics involves multiple electronic control units (ECUs)
used to support the connected and intelligent vehicle’s
technology. Digital evidence from these ECUs can be used in
forensics investigation and analysis. Such a mechanism can
potentially facilitate crash investigation, insurance claims and
crime investigation. Issues related to forensics include the
Insurance
black box EDR ECU1 ...... ECUn
authenticity, integrity and privacy of the data. In this paper, with
the security of the forensic process and data in automotive telematics unit
systems is analysed. We propose an efficient, secure, privacy-
preserving and reliable mechanism to provide a forensics
data collection and storage process. A diagnostic application
CAN bus
for smart phones, DiaLOG, is incorporated in the proposed
process that uses a secure protocol to communicate the col- Fig. 1. Nodes on CAN bus
lected forensic data to a secure cloud storage. The proposed
protocol for communicating forensic data is implemented to
measure performance results and formally analysed using is relevant to a crash incident. At least fifteen parameters
Scyther and CasperFDR with no known attack found. are stored in order to be recovered during the forensic
investigation [1], which include speed, seat belt status and
I. INTRODUCTION
airbag deployment state. The data is continuously stored
Vehicle forensics is becoming an important feature in and overwritten on the Random Access Memory (RAM)
a vehicle’s design and operational life cycle. Interested of the EDR, and the storage to its persistent memory
stakeholders include insurance claim investigators and law (Electrically Erasable Programmable Read Only Memory
enforcement who are interested in crime and crash incident (EEPROM) or flash memory) is triggered by a crash-like
investigation. In recent years, the forensic feature has reading, for example a sudden change in the speed. The
been further used by insurance providers and companies retrieval of data during the investigation is conducted by
providing vehicles to their employees for business related reading the content of the EDR, either through the OBD-II
activities. port or by physical extraction of the data memory of the
An Electronic Control Unit (ECU) is a microcontroller EDR. There is however, a possibility that the data fails
that controls the operations of a car. In modern cars, to be recorded due to a vehicle’s electrical failure, which
there can be around seventy ECUs that control the overall causes insufficient power to write to the EEPROM or flash
operations of the vehicle [10]. Each ECU is responsible memory of the EDR. The second possibility of storage
for different operations, such as body control, engine failure is that the EDR module is defective. Whereas, an
control and telematics. A telematics unit for example, insurance black box continuously transfers the relevant
provides connectivity (Wi-Fi or cellular network) to the parameters to the insurance company’s server through the
car, through which the car is able to communicate with telematics unit, to monitor the driving style. The driving
the outside world [34]. The different ECUs are connected style is used to determine the insurance policy premium
within a car through networks such as Local Interconnect rate. A better and safer driving style will result in a
Network (LIN) [30], Controller Area Network (CAN) bus lower premium rate. However, there are unresolved issues
[13], FlexRay [15] and Media Oriented Systems Transport related to insurance black boxes, which include false data
(MOST) [16]. The networks operate at different baud rates being transmitted to the telematics unit or the server and
depending on the applications. The OBD-II (On-Board telematics data not being available.
Diagnostic) port is a port that interfaces the outside world
to the in-vehicle networks [31]. The port can be interfaced A. Problem statement
with a Wi-Fi, Bluetooth or serial connection using the (i) Current use of EDR and the insurance black box
ELM327 interface [6]. in forensic evidence provides limited features. The EDR
For digital automotive forensics, the two main and gives a restricted number of parameters for analysis,
commonly used features are the Event Data Recorder whereas the insurance black box and telematics unit do not
(EDR) [1] and the insurance black box that works together protect the privacy of the users. (ii) Although certain data
with a telematics unit [34]. Fig. 1 shows the related is compulsory to obtain a service, users do not have control
nodes on CAN bus. An EDR is used to store data that of the transmitted data and can not access it. (iii) The users

2324-9013/16 $31.00 © 2016 IEEE 975

974
DOI 10.1109/TrustCom.2016.162
10.1109/TrustCom/BigDataSE/ISPA.2016.162
are therefore unable to verify the correctness of the data Kowalick discussed in detail about the unaddressed
being transmitted. issues with automotive EDR [32] by the National Highway
Traffic Safety Administrator (NHTSA), which is under
B. Contribution the US Department of Transportation. Among the issues
In this paper, we propose DiaLOG, a mobile application are the EDR data ownership, authenticity, the security
that can be used as a forensic support feature. DiaLOG at the time of crash and the chain of custody after the
ensures only an authorised mobile device can be connected crash incident, tampering and manipulation, how data can
to the car, and provides integrity protected data that can be of use for civil/criminal proceedings, police’s access
be used for forensic investigation. It also protects the authorisation on the data, possibility of developing EDR
privacy of users and gives them control of the data being into a driver-monitoring tool, and third party’s access
transmitted. authorisation.

II. RELATED WORK ON AUTOMOTIVE III. AUTOMOTIVE FORENSICS

FORENSICS In this section, we discuss use cases, storage, retrieval,
Nillson et. al discussed about performing forensics issues, security requirements and threat model of automo-
on in-vehicle networks [29]. They discussed an attacker tive forensics.
model and requirements for detection, collection and event
A. Automotive forensics use cases
reconstruction. According to them, the features like di-
agnostic, firmware update, vehicle-to-vehicle (V2V) and Commonly, forensic data is used during crash incidents
vehicle-to-infrastructure (V2I) communications are desir- investigation. However, there are many other use cases
able and could be achieved wirelessly, but these features when forensic evidence and data logging could be useful.
introduced cyber attacks capability. In their forensic pro- As an example, a current trend adopted by insurance
posal design, their goals are to detect events in the vehicle companies is to set the insurance premium rate depending
(which require a device to detect, notify and store the on the driving style. The driving style of a driver is
forensic evidence); to answer the required questions in sent through a telematics unit to the insurance company’s
forensics (from the collected forensic data); and to obtain server. In another example, available technology like eCall
the current state of the firmware version. In order to service [3] is used during crash accidents, and can call
perform this, a list of hashes of current firmware installed emergency contacts. The service transmits location and
on all ECUs needs to be accessible. Their proposal de- time of accident to ensure rapid assistance. For criminal
scribed what to do, without providing any practical im- investigations, the GPS information could be used [2] to
plementation. During the presentation phase of forensics, determine the location of a suspect.
conclusions can be made from both the physical evidence Data logging can also be useful during car rental. Bob
through EDR data and also digital evidence through the goes to the car rental company and is given a car. Similar
network. to how the physical body checks are conducted, if Bob
Hoppe et. al proposed a route reconstruction forensics can use a diagnostic feature, he can verify the status of
in a hit-and-run scenario [11]. They proposed two meth- the ECUs, and the car as a whole (i.e. digital check).
ods, i.e manual and semi automated. Firstly, a Global If the car is in a good condition, then Bob agrees to
Positioning System (GPS) receiver is installed in the car rent the car. Otherwise, Bob should notify the company
and connected to the ECU through the CAN bus. Any about the current condition and he has the choice whether
communication is logged in the data logger. The direc- to rent the car or to choose a different car. If a crash
tions for navigation are displayed on the instrument panel or accident happens later, both parties, Bob and the car
cluster for safety and comfort. By having this feature, rental company, will have the evidence to prove the actual
they propose to use it as forensic evidence by providing situation. Similar to the car rental use case, a potential
route reconstruction. In the manual method, the data from buyer of a second hand car can conduct a diagnostic to
the data logger is manually analysed, and optimisation is ensure that all the units are working correctly as suggested
conducted by filtering data that are potentially relevant to by the seller.
the incident. The semi automated method is by connecting For network intrusion, for example, an attacker, Mallory,
a prober to the navigation unit and to a graphical user is able to access the in-vehicle network, via the CAN bus
interface (GUI) to show the data read from the navigation network. He injects malicious messages to the CAN bus
unit. It is an invasive method since there is a physical to cause denial of service (DoS), or to manipulate the
connection to the unit required to get the relevant data. In operations of a car. The injection of malicious messages
order to log all the communication to the data logger, a into the CAN bus network may cause a change in the
large memory space is required. For example, according normal frequency of messages [27], [28]. By having a data
to [33], it shows there are 63 CAN IDs just to identify logging system, a driver/owner could be notified about the
different operations of the car. A single operation is intrusion. Another example is in a valeting application, the
represented by a single CAN ID. As an example, just car key is left to the valet service. Users do not want the
for the sideway acceleration sensor, there are 35 frames valet to compromise their cars, either by trying to steal
per second. For a car without a navigation system or a stored private information, or trying to trace their future
data logger, this might contribute to the cost of additional locations by adding a malicious device (for example a USB
installation. stick or a malicious ECU) or application on the car.

975
976
 The final example use case is diagnostic data. If there also attempt to modify or corrupt this data to conceal
is any problem with the car, the car owner can conduct wrongdoing.
a first step diagnostic before visiting a workshop to get Data stored in a black box can be retrieved in three
the problem solved. This will give a brief idea to the car possible ways: firstly, through physical connection to the
owner of what should be fixed and its estimated cost. They OBD-II port, then logically accessing the black box from
can also benefit from assessing their driving styles from the CAN bus; secondly, through physical connection to the
the stored data, and perhaps modify their style to reduce ECU, then logically accessing the EEPROM or flash mem-
service costs and likelihood of accidents [12]. ory from the black box operating system and application;
and finally, data can also be accessed through physical
B. Storage of forensic data connection to the ECU’s EEPROM or flash memory and
conducting a memory dump. If the data is stored on a
The ECU could be the storage place for forensic data.
server, only authorised parties are able to retrieve the data.
Although, in case of total disruption to the car (and/or
its units) caused by an accident, the data may not be D. Issues related to automotive forensics
retrievable. The data in the EDR could be corrupted or
A number of issues related to automotive forensics. One
changed as a result of a bad retrieval technique [12], or it
issue is on the privacy of data. The existing telematics
could be tampered with before the storage, e.g. by hacking
unit provides connectivity to the car and sends the forensic
the CAN bus and injecting malicious data. The cloud or
data directly to a server (for example insurance black box)
a remote server could be a safe place to store forensic
without the owner knowing what is transmitted. The access
data, as long as the data is recoverable and protected from
control authorisation of data should really be given to
unauthorised access. The vehicle user should have control
the owner although certain data is compulsory to obtain
of what data is shared with third parties via the cloud or
a service. There is a campaign to try and establish this
server. A mobile device could be another potential place
right [7]. The owner also needs access to the stored and
to store the forensic data, however there are concerns on
transferred data to verify that it is correct. It is also
the tamper resistance of data since a mobile is easily
necessary to consider technical and security issues. The
accessible compared to an EDR. A mobile device would
retrieval of data currently requires expensive specialised
be a potential solution for a non-intrusive retrieval method.
tools and expertise [12], although anyone can attempt to
Compared to data retrieval directly from the car’s black
access private data via the vehicle network, accessible
box, retrieving data from a mobile device or a cloud would
through the OBD-II port. Integrity and correctness of the
only involve logical digital access rather than physical
stored data could not be verified in the existing system.
access. It is a user-friendly method and can be used as
The availability of data could be compromised if the
a first hand/first impression forensic result, and it reduces
automotive forensics is only relying on the availability of
the possibility of causing any changes to the actual ECU
the EDR data [1].
that could invalidate the evidential data. The mobile could
also be used as a backup or complementary unit for the E. Security and privacy requirements
EDR, as there are known problems related to the black From previous discussion, we conclude the security and
box including failure to record, software and cable faults, privacy requirements for automotive forensics as follows:
OBD port retrieval issues, technical/training problems and
permission issues [12]. Compared to an EDR, the mobile
(i) Integrity: It is crucial to determine if the data stored
having a GUI through the application can help ensure that
is not being tampered with or corrupted.
the data is always available. The owner or driver can also
(ii) Authenticity: Data must be original and the person
protect his interests by having the first hand forensic data.
handling the data is authorised.
Forensic data are usually difficult to retrieve (requiring
(iii) Availability: Ensuring all the required data is avail-
specialised tools and technical expertise if stored in the
able for investigation, and updated all the time.
car). By having the data in the mobile device, the data
(iv) Reliability: Having a backup device for forensic data
is always available, where the owner or driver can have
storage can increase the reliability of the forensic
easy access, however, the data must be protected from any
system.
malicious tampering.
(v) Privacy: It is important to protect the privacy of the
car owner, especially when handling privacy-related
C. Data retrieval of forensic data
data such as driving habits.
Parties interested in retrieving forensic data would in-
clude the law enforcement, lawyers, investigators (for F. Vehicle forensics threat model
insurance or police), and car manufacturers, as well as the In automotive forensics, assets to protect are the read
vehicle owner/user. Law enforcement may be interested and write access authorisation and the authentication,
in the data to determine causes in accidents. Vehicle integrity and privacy of the data. Potential attackers are un-
manufacturers may use this information in order to im- trustworthy workshops, owners, investigators and hackers
prove their vehicle designs and performance, and where with financial motivation. In our threat model, a malicious
possible to avoid or minimise the causes of accidents. entity: (i) can access the CAN bus and manipulate the con-
State and highway officials maybe interested in the data to tent before the storage (ii) can access and manipulate the
evaluate road conditions and safety. The driver or the car content after the storage (iii) cannot break well-established
owner might be interested in the vehicle data, but may cryptographic algorithms.

976
977
 A number of possible attacks for automotive forensics
can be conducted as follows:
(i) Denial of service (DoS) attack: To cause availability
issue, where data stored is not able to be retrieved, Cloud Mobile application Car
or data not able to be stored. Denying access of data
to an authorised party is also a method of DoS. Fig. 2. Architecture of the proposed framework
(ii) Impersonation attack: To impersonate an authorised
party to conduct further attacks. For example, an
attacker impersonating an authorised person to ac- after a certain time, the owner will be notified. Finally,
cess the data during investigation to manipulate the the cloud is securely managed. A user is authenticated to
content, or a device impersonating an authorised access the cloud server, and only authorised users have
tool to access the data during the storage (i.e CAN access to the data. However, even if an attacker is able to
bus manipulation). This will violate the authenticity get access to the data in the cloud, our protocol protects
requirement. Further attacks could lead to the viola- the integrity and confidentiality of the data.
tion of all other security requirements mentioned in
B. The DiaLOG application
section III-E.
(iii) Data manipulation attack: To change the content of The architecture of the proposed framework with mobile
the forensic data, either by changing the data before application and cloud based backup storage is shown in
or after the storage, or during the retrieval process. Fig. 2. A mobile device with the DiaLOG application can
This will violate the integrity property. Attacks can log the latest vehicle operations. This data is uploaded to
be performed mechanically by simply destroying the the cloud when a suitable network connection is available.
black box and its data contents. Attacks might also From this framework, the forensic investigators have the
be mounted electrically which will cause disruption options to get the data from three different sources: the
or change of data. Attacks through malicious CAN car EDR, the mobile device or the cloud. The car owner
bus messages might distract the driver, or hack the (having the DiaLOG application and access to the forensic
engine or brake operation, or cause a crash and then data) has control of what data to share with third parties.
erase all traces from the black box. Certain data is compulsory to obtain a service and the car
owner will need to give access to the service provider.
IV. PROPOSED SOLUTION However, he/she has the control of the transmitted data
Commonly, during vehicle forensic investigation, the and can verify the correctness of data. The proposed
EDR, the infotainment unit and other ECUs are analysed architecture safeguards the privacy of the car owner/driver,
[1]. In this proposal, the mobile application, DiaLOG, will in a way that is not possible with the current system
be the backup data for the EDR and other related data that that transmits data via the telematics unit. The keys for
might be of interest for forensics. the mobile device are stored in a secure memory for
Our proposal is based on the EVITA project [9], which example on a secure element, or the mobile device could
proposed an embedded Hardware Security Module (HSM) be supporting TrustZone. The keys for the CCU are stored
in the ECU to ensure secure communications for on-board in the HSM of the CCU.
system. As proposed in the EVITA project, each ECU has 1) Authentication phase: In order to use the DiaLOG
its own HSM. This suggests that any node communicating with the mobile device, the mobile device is required to
through the CAN bus is required to have access authorisa- be authenticated to the car. Only the authorised mobile
tion in order to send or receive messages. In our proposal, device is given permission to access the data from the car,
the mobile device acts as a communicating node through and most importantly to connect with the car’s internal
the CAN bus, and so requires access authorisation. network. An authorised device is divided into two different
To conduct a diagnostic on the car, the mobile device is levels: basic or full authorisation. These levels will be
connected to the OBD-II port via Wi-Fi or Bluetooth. Once further explained in Section IV-C.
connected, the mobile device will be authenticated, to 2) Diagnostic phase: In this phase, the mobile device
determine whether it is authorised to retrieve the requested is connected to the vehicle through a Wi-Fi connection,
data. Once authenticated, the mobile device is connected via an on-board router. The mobile device needs to be
to the CAN bus, and able to access the required data. authenticated to the vehicle to ensure only authorised
The main idea of the DiaLOG application is to read mobile devices are permitted to acquire the vehicle’s
the DTCs (Diagnostic Transmission Code) and log them diagnostic data. If authentication is successful, the mobile
securely. The DTCs can be read by the user of the DiaLOG device will send a diagnostic command to the ECU, and
application, and from there, the user is aware of the car’s the mobile will receive the resulting data. This operation
condition and state. is automated once connection is established and authenti-
cation is verified. This way, the driver is always aware of
A. Assumptions his/her vehicle condition. Apart from that, the consistency
The assumptions of the proposed DiaLOG application of data can be maintained between the mobile application
are as follows: The mobile application is installed on and the vehicle.
a mobile device and the mobile device is available for 3) Data logging: Data to be logged in the DiaLOG
investigation. The data is always automatically transmitted application are as follows:
to the phone and later to the cloud. If data is not updated

977
978
 (i) DTCs: are the error codes associated with the compo- TABLE I
C REDENTIALS FOR READ ACCESS
nents in the vehicle. The main function of a diagnostic
is to read the DTCs and to resolve the associated Data User
Car owner Car rental Potential buyer Investigator
problems of the vehicle according to the codes. DTC    
(ii) ECU content is the firmware, application and data Hash chains    
External device    
available in each ECU. To retrieve all the data in Crash data    
all the ECUs would be time consuming and require Bus attack    
Crash history    
a large memory to store it all. The (concatenated) Authorisation Full Basic Basic Full
hashed value of each ECU can be stored to provide
an integrity check. Using the architecture as proposed
in the EVITA project [9], the master ECU contains TABLE II
all the hashed values of all the ECUs. Any changes P ROTOCOL NOTATIONS
in the content of the ECUs, i.e. any write operation to CCU Central Communication Unit
the flash, will change the hashed value stored in the Mo Mobile device of car owner (full authorisation)
Mt Mobile device for temporary access (basic authorisation)
master ECU. Hence, the master ECU is also alerted kmc Symmetric key for CCU (shared between Mo and CCU)
ktemp Symmetric key shared between M t and M o
of the changes. The DiaLOG application data is also idM o Identification number of mobile device of car owner
being updated accordingly. idM t Identification number of mobile device for temporary access
idccu Identification number of CCU
(iii) Interface connection: to the vehicle is logged in ks Temporary symmetric key shared between mobile device and CCU
pkccu Public key of CCU used to verify signature
the DiaLOG application. The authentication process skccu Private key of CCU used to sign
from the interface connection will also be logged by nc , n M o , n M t Nonces
reqdtc Request to access DTC
DiaLOG to get the identity of the entity involved. The dtc Diagnostic Transmission Code
ENC Encryption using AES128
identification, authentication method, interface, time sign Signature using RSA1024
and location, which is related to the communication
events (for example firmware update) are among the
relevant data to be logged.
(iv) Crash-like data: There are two different ways the (i) Full authorisation: For a full authorisation, the in-
EDRs record the crash incident data. The first option tended entity (e.g. the car owner) is required to
is by continuously recording and overwriting the data be registered with the car manufacturer. After the
on the EDR EEPROM/flash. The second option is installation of the DiaLOG application, a registra-
by recording the data only when there is crash- tion process is proposed. By registering, the mo-
like data. Similar to an EDR, crash-like parameters bile device, M o, will have access to the car via a
such as a sudden change in the velocity, could be a set of keys (kmc and pkccu ) provided by the car
triggering factor for the DiaLOG application to start manufacturer. Car owners and law enforcement are
recording the required parameters for crash incidents. given full authorisation provided they are registered
Triggering uses less mobile battery than continuous with the car manufacturer. The key is a symmetric
polling of data. key shared between the mobile device and the car,
(v) Change in the frequency of messages through the kmc . CCU is the central unit that interfaces the
CAN bus: could be an indicator of a potential remote communication of the in-car ECUs to the outside
attack being conducted. DiaLOG will record the world. The symmetric key, kmc , is a medium term
normal frequency of messages and compare to the key that requires an update from the car manufacturer.
current operational frequency. It will be used to authenticate the mobile device to
4) Storage to cloud: The user can transfer the data the car’s CCU. Referring to Table III, the mobile
from the mobile device to the cloud. For example, after device M o will start the protocol by sending its ID,
each driving cycle, all data is transferred to the cloud as concatenated with an encrypted message using the
a storage backup. At any required time, the data can be pre-shared key kmc containing ID of CCU, request
retrieved and analysed. to access the data and a generated nonce nM o . The
5) During forensics: Requirements during forensics in- CCU will then reply with its ID, concatenated with
clude (i) Availability of mobile application data, (ii) Avail- an encrypted message using the pre-shared key kmc
ability of ECU data, (iii) Authenticity, integrity and cor- containing ID of CCU, nonce from M o from previous
rectness of data. The latest diagnostic data stored in message, nM o and a session key ks . After a mutual
the mobile device is read during data collection. The authentication and freshness verification (Step 1-2),
ECU data, including the EDR is also read. During the the mobile device will request the DTC from CCU.
forensic analysis process, this data is compared to ensure The dtc transmitted from CCU will then be encrypted
its consistency. to provide confidentiality and signed to ensure its
integrity.
C. Protocols (ii) Basic authorisation: Entities included in this group
There will be two levels of mobile device authorisation are for example, anyone interested to rent a car from
with different data access: basic and full, as shown in Table a company, or a potential buyer when a car is being
I. The protocol notations are shown in Table II. resold. In order to be given access authorisation,
1) Protocol description: There are two protocols de- the person interested is required to acquire a set of
pending on the different access authorisation. keys from the car owner. The key is transmitted and

978
979
 TABLE III automatically updated once connection is available,
F ULL AUTHORISATION DATA ACCESS
or whenever the owner is notified.
1. M o → CCU : idM o ||EN Ckmc {idccu ||f ullreq||nM o } (iv) Reliability: of the forensic system is improved by
2. CCU → M o : idccu ||EN Ckmc {idM o ||ks ||nM o }
3. M o → CCU : idM o ||EN Cks {idccu ||reqdtc} having a backup data on the cloud as well as on the
4. CCU → M o : EN Cks {idccu ||dtc}||signskccu {EN Cks {idccu ||dtc}} mobile phone. If any of the stored data in the three
different components does not match to each other,
it shows that the data might be potentially corrupted.
TABLE IV
BASIC AUTHORISATION DATA ACCESS (v) Privacy: of the car owner and its driving related data
is protected. The owner has the control over the data.
1. Mt → Mo : idM t ||idM o ||EN Cktemp {idccu ||basicreq||nM t }
2. M o → CCU : idM o ||idccu ||EN Ckmc {idM t ||basicreq||nM o ||nM t } Based on the threat model in Section III-F, the proposal
3. CCU → M o : idccu ||idM o ||EN Ckmc {idM t ||ks ||nM o ||nc ||nM t }
4. Mo → Mt : idM o ||idM t ||EN Cktemp {idM t ||idccu ||ks ||nc ||nM o ||nM t } addresses them as follows:
5. M t → CCU : idM t ||idccu ||EN Cks {idM t ||idM o ||idccu ||nc ||reqdtc}
6. CCU → M t : EN Cks {idccu ||dtc}||signskccu {EN Cks {idccu ||dtc}} (i) Denial of service (DoS) attack: The data is always
stored in the mobile device of the interested party. automatically transmitted to the phone and later to
It is then used to authenticate the mobile device to the cloud. If data is not updated after a certain time,
the car. Basic authorisation only gives limited data the owner will be notified. Having a backup copy
accessibility as described in Table I. The key, ks is of the data can ensure that the data is available
only valid per transaction, i.e. once communication to be retrieved if the person is authorised. If the
is disconnected, a new key is required to access the owner himself is the attacker, the data can always be
data again. accessible directly through the car’s CCU or the EDR.
Prior to the start of the protocol, both mobile devices If the investigator is able to get to the mobile device
(M o and M t) share a symmetric temporary key, or the cloud data, then the data is always available.
ktemp and public key of CCU, pkccu . Referring to (ii) Impersonation attack: Data can be retrieved by any
Table IV, the temporary mobile device, M t, will entity having the correct authorisation, whether it is
request an access to the car from an authorised a full authorisation or a basic authorisation. Instead of
mobile device (car owner’s), M o. M t will send its using specialised tools, a mobile application provides
ID, concatenated with idM o , and encrypted message easy data access without sacrificing authenticity of
using the preshared ktemp containing the CCU’s ID, the person/tool in use.
the request and a nonce, nM t . The car owner’s mobile (iii) Data manipulation attack: The content uploaded on
device will then send a message to notify the CCU the mobile device and cloud are integrity-protected by
about the temporary device’s request which contains the use of signature by the CCU. Furthermore, since
its ID, CCU’s ID concatenated with an encrypted this proposal uses a mobile device, the cloud and also
message using kmc containing the temporary mobile’s the ECU as the storage device to store the required
ID, the request, nonces nM o and nM t . The CCU will data, there are three different components to verify
then acknowledge this by sharing ks to the owner’s the consistency of the data. All three components
mobile device. The owner’s mobile device will then (ECU, mobile device and cloud) should have the same
reply to M t with its ID and the temporary mobile’s content of data. However, if content is manipulated
ID, concatenated with an encrypted message contain- by injecting malicious data through the CAN bus,
ing idM t , idccu , ks and all the nonces nc , nM o , nM t . all three components would have the same falsified
Now, the temporary mobile device can communicate data. However, our proposal is based on the EVITA
with the CCU using the ks . It will request the DTC project [9], where each ECU contains its own HSM
and the CCU will reply with an encrypted DTC plus and the communication through the CAN bus requires
a signature to provide confidentiality and integrity. authentication. Therefore, any nodes communicating
through the CAN bus are authorised.
2) Formal Analysis: The protocol is analysed using
D. Security Analysis formal analysis tools to attain indicative results regarding
its security. CasperFDR [14] and Scyther [5] tools are used
1) Informal analysis: Based on the security require- to verify the protocol. The required security requirements
ments in Section III-E, the proposal addresses them as include confidentiality of the secret keys, kmc and ks ,
follows: and the authentication properties, which include aliveness,
agreement and synchronisation. The full scripts can be
(i) Integrity: The DTCs being transmitted and stored are found in the link: CasperFDR and Scyther input scripts.
signed by CCU to ensure that the DTCs are integrity For CasperFDR, the security properties verified are
protected. the secrecy, aliveness and agreement. The confidentiality
(ii) Authenticity: of the communicating parties are ver- property is to verify the secrecy of the ks and kmc ,
ified for every protocol transaction. They are given that are shared between the mobile device and the CCU.
access depending on the different levels of permis- The aliveness property is to verify the aliveness between
sion. mobile device and CCU. The agreement property is to
(iii) Availability: of the data is ensured by the update ensure the agreement of ks shared between mobile device
of data every time the authorised mobile device is and CCU. The intruder has the knowledge of all the
connected to the car. The data on the cloud will be entities (CCU, Mo and Mt) and the request messages to

979
980
access the data (fullreq, basicreq and reqdtc). Referring dentiality. Authentication properties are verified through
to CasperFDR full authorisation script, the script starts Agreement (such as claim x3 (mt, Weakagree), claim x5
with #Free variables declaration, which declares all the (mt, Niagree)), Synchronisation (claim x4 (mt, Nisynch)),
variables used in the protocol. It is followed with the and Aliveness (claim x6 (mt, Alive)). The results for all
#Protocol description. This describes the messages be- the claims made are verified as “Ok” in the “Status”
ing transmitted (in sequence) during the authentication with “Verified” and “No attacks” in the “Comments”.
and diagnostics, which starts with a request from MD This means that no attack was found within the bounded
to the CCU (i.e 1.a->b:a,{b,fullreq,nmo}{kab}). In 5.a- or unbounded statespace; the security property has been
>b:a,reqdtc,{b,reqdtc}{ks}, the MD requests the dtc after successfully verified [4].
being authenticated and verified the freshness in mes-
sages 1-4. In the #Processes, all the involved entities E. Implementation
in the protocol and their knowledge are declared. For The proposed protocol was then implemented on a PIC
example INITIATOR(a,b,kab,nmo,fullreq,reqdtc), where a Microchip microcontroller (PIC32MZ2048ECM144) and
is the MD, b is the CCU and nmo is the random an Android device to obtain indicative performance results.
nonce generated by MD. MD knows kab which is pre- 1) Implementation platform: Our approach of imple-
shared. The #Specification declares all the assertions mentation is to observe the computation time on both
made to verify the security properties. The confidentiality the CCU and the mobile device separately. The mobile
of kmc and ks are declared as Secret(a,kab,[a,b]) and device communicates via Wi-Fi, while the CCU commu-
Secret(b,ks,[a,b]). As an authentication verification, the nicates via CAN bus. There is a Wi-Fi module connected
aliveness property and the agreement property between to the CCU to receive the Wi-Fi messages from the
MD-CCU are verified. The #Actual variables section de- mobile device and convert these messages into UART
scribes the names of the actual agents, and the actual messages. There is another interface module between the
variables such as MD and CCU. Nothing is declared in the Wi-Fi module and the CCU to translate UART messages
#Functions section. The #System section again declares into CAN messages and vice versa. Figure 3 shows the
all the involved entities in the protocol and their knowl- connection setup for CCU’s communication. The CCU is
edge, but with their actual names. For example, INITIA- simulated using a microcontroller with all the functions
TOR(MD,CCU,KAB,Nmo,FULLREQ,REQDTC). The #In- required to be an actual ECU with cryptographic engines.
truder Information declares the intruder X who has the PIC32MZ2048ECM144 [26] is chosen as the implementa-
knowledge of all the entities involved, i.e IntruderKnowl- tion platform for CCU. It is a 32 bit microcontroller with
edge={MD,CCU,X,FULLREQ,REQDTC}. All the specifi- 2048 KB of flash and 512 KB of SRAM, and operates at
cations made are verified and no attack is found for all the 200 MHz clock. It supports CAN bus communication, as
assertions. required in an ECU. The hardware cryptographic engines
support the computation of cryptographic algorithms to
For Scyther, the security properties verified are the non- produce faster performance. For the mobile device, the
injective synchronisation, non-injective agreement, weak application protocol is loaded into a LG Nexus 5 with
agreement, aliveness and secrecy. The default verification a Quad-core 2.3 GHz Krait 400 CPU running on An-
setup was used (i.e. five as the maximum number of droid 5.1. There are two platforms used as the interface
runs, type matching and to find the best attack with ten module to translate UART-CAN messages to compare
maximum patterns per claim). The secrecy property is to different platform performance. They are PIC18F4580
verify the confidentiality of the ks and kmc , that are shared and PIC32MZ2048ECM144. PIC18F4580 [18] is an 8 bit
between the mobile device and the CCU. Non-injective microcontroller with 32 KB of flash and 256 bytes of
synchronisation property is to verify that parties know who RAM. It operates with a 16 MHz clock and supports CAN
they are communicating with, agree on the content of the bus and UART communication. For the Wi-Fi module, the
messages and the order of the messages. The non-injective Wi-Fi G demo board [25] is used.
agreement is to verify that parties agreed on the content
Wi-Fi UART Interface module CAN CCU
of the variables. In Scyther, all the security properties are
module (PIC32MZ or PIC18F) (PIC32MZ)
modeled as role-based. Each entity is considered as one
role. The properties are viewed from the local view of
Fig. 3. CCU’s setup for communication
each role. Referring to Scyther basic authorisation script,
the script starts with functions declarations. Then, we 2) Experiment setup: For the CCU setup, the simula-
have macros of messages to make the script neat and tion of the messages from and to the mobile application
easy to be followed. Next, the events and claims are is using the Microchip CAN bus analyser tool [20]. The
made for each role (starts with MT, followed by MO and tool can be used to observe the messages sent from the
CCU). For example, for MT role, the events are send 1 PIC32MZ microcontroller and also send messages to it.
(mt,mo,m1), recv 4 (mo,mt,m4), send 5 (mt,ccu,m5) and On the PIC32MZ part, the PIC32MZ2048ECM144 starter
recv 6 (ccu,mt,m6), which means MT sends the macro kit [24] is connected to a CAN PICtail daughter board [21]
m1 to MO and later, receives macro m4 from MO and through a starter kit adapter [23] and an I/O expansion
sends macro m5 to CCU to then receive macro m6 from board [19]. The CAN PICtail daughter board is then
CCU. Claims are the security properties to be verified. connected to the CAN bus analyser. The setup is shown in
For example, for the MT role, claim R4 (mt, Secret, Fig. 4. The CCU’s computation performance is measured
ks ) and claim R6 (mt,Secret, k(mo,mt)) are for confi- based on cycle count given by MPLABX debugger.

980
981
 The same setup is used for the interface module using R EFERENCES
PIC32MZ. For interface module using PIC18F4580, an [1] David Randall Peterman Bill Canis. “Black Boxes” in Passenger
additional CAN transceiver, MCP2551 [17], is connected Vehicles: Policy Issues. Technical report, Congressional Research
to the PIC18. The interface module is then connected to Service, 2014.
[2] Kangsuk Chae, Daihoon Kim, Seohyun Jung, Jaeduck Choi, and
MCP2200 breakout module [22] to observe the UART Souhwan Jung. Evidence Collecting System From Car Black
messages. The performance of communication is measured Boxes. In Consumer Communications and Networking Conference
using oscilloscope. The performance of Wi-Fi commu- (CCNC), 2010 7th IEEE, pages 1–2. IEEE, 2010.
[3] European Commission. eCall Do You Have Any Concerns for Your
nication is measured using “Inspector” feature from the Privacy? You Shouldn’t. Technical report, Europian Commission,
internet browser. 2014.
[4] Cas Cremers. Scyther User Manual, draft edition, February 2014.
[5] Cas JF Cremers. The Scyther Tool: Verification, falsification, and
analysis of security protocols. In Computer Aided Verification,
pages 414–418. Springer, 2008.
[6] ELM Electronics. ELM327L. http://www.elmelectronics.com/
DSheets/ELM327L Data Sheet.pdf/.
[7] FIA. My Car My Data. http://www.mycarmydata.eu/, 2015.
[8] Florian Hartwich. CAN with flexible data rate, 2012.
[9] Olaf Henniger. EVITA:E-Safety Vehicle Intrusion Protected Appli-
cations. Technical report, EVITA, 2011.
[10] Olaf Henniger, Ludovic Apvrille, Andreas Fuchs, Yves Roudier,
Alastair Ruddle, and Benjamin Weyl. Security Requirements for
Automotive On-board Networks. In Intelligent Transport Systems
Telecommunications,(ITST), 2009 9th International Conference on,
pages 641–646. IEEE, 2009.
[11] Tobias Hoppe, Sven Kuhlmann, Stefan Kiltz, and Jana Dittmann.
IT-forensic automotive investigations on the example of route
reconstruction on automotive system and communication data. Lec-
Fig. 4. Lab setup for CCU’s CAN bus communication ture Notes in Computer Science (including subseries Lecture Notes
in Artificial Intelligence and Lecture Notes in Bioinformatics), 7612
LNCS:125–136, 2012.
3) Performance results: Based on the proposed proto- [12] David Hynd and Mike McCarthy. Final report: Study on the
col, the length of a message is more than eight bytes, Benefits Resulting From the Installation of Event Data Recorders.
hence, all the messages will need to be divided into more 2014.
[13] Road vehicles – Controller Area Network (CAN) – Part 1: Data link
than one CAN message due to the limited number of bytes layer and physical signalling. Standard, International Organization
(8 bytes) of data per CAN message transmission. The for Standardization, February 2013.
messages are divided into three to eighteen messages to be [14] Gavin Lowe. Casper: A compiler for the analysis of security
protocols. Journal of computer security, 6(1):53–84, 1998.
transmitted via CAN. The computation and communica- [15] Rainer Makowitz and Christopher Temple. FlexRay- A Commu-
tion performance for full and basic authorisation protocols nication Network for Automotive Control Systems. In 2006 IEEE
is as shown in Table V. The communication includes the International Workshop on Factory Communication Systems, pages
207–212, 2006.
transfer of data from Wi-Fi module to the middle interface [16] Media Oriented Systems Transport Specifications, 2006.
module (via UART) and from middle interface module [17] Microchip. High-Speed CAN Transceiver. http:
to the CCU (via CAN). Based on the results, it can be //ww1.microchip.com/downloads/en/devicedoc/21667d.pdf, 2003.
[18] Microchip. PIC18F2480/2580/4480/4580 Data Sheet. http://
observed that the performance for the interface module ww1.microchip.com/downloads/en/DeviceDoc/39637c.pdf, 2007.
is almost the same for the different platforms used. This [19] Microchip. Starter Kit I/O Expansion Board Informa-
is because both the devices use the same baud rates of tion Sheet. http://ww1.microchip.com/downloads/en/DeviceDoc/
51950A.pdf/, 2010.
communication, i.e for UART (at 9600 bps) and CAN (at 1 [20] Microchip. CAN BUS Analyzer Users Guide. http://
Mbps). The communication time can be further improved ww1.microchip.com/downloads/en/DeviceDoc/51848B.pdf/, 2011.
if CAN FD [8] is used, where one message can contain [21] Microchip. CAN/LIN/J2602 PICtail (Plus) Daughter Board
Users Guide. http://ww1.microchip.com/downloads/en/DeviceDoc/
up to 64 bytes of data, instead of just 8 bytes. 70319B.pdf/, 2011.
[22] Microchip. MCP2200 Breakout Module User’s Guide. http://
V. CONCLUSION ww1.microchip.com/downloads/en/DeviceDoc/52064A.pdf, 2012.
[23] Microchip. PIC32MZ Embedded Connectivity (EC) Adapter
As car operations are digitally controlled, security is Board Information Sheet. http://ww1.microchip.com/downloads/
en/DeviceDoc/50002199A.pdf/, 2013.
now part of the main consideration in the automotive [24] Microchip. PIC32MZ Embedded Connectivity (EC) Starter Kit
systems implementation. Our proposal is based on the new Users Guide. http://ww1.microchip.com/downloads/en/DeviceDoc/
ECU architecture where a HSM is included in the ECU. 70005147A.pdf/, 2013.
[25] Microchip. Wi-Fi G Demo Board Users Guide. http:
By having a mobile application as a logging platform for //ww1.microchip.com/downloads/en/DeviceDoc/50002147A.pdf,
the vehicle operation, it can help the forensic investigation 2013.
to be more effective. More data options can be stored [26] Microchip. PIC32MZ Embedded Connectivity (EC) Family. http:
//ww1.microchip.com/downloads/en/DeviceDoc/60001191E.pdf/,
and thus increase the accuracy of forensic analysis. A 2015.
secure framework for vehicle forensics is proposed to [27] Charlie Miller and Chris Valasek. Adventures in Automotive
ensure the security of data and at the same time protect Networks and Control Units. In DEF CON 21 Hacking Conference.
Las Vegas, NV: DEF CON, 2013.
the users’ privacy. The DiaLOG application proposed uses [28] Charlie Miller and Chris Valasek. A Survey of Remote Automotive
a new framework of automotive forensics, which provides Attack Surfaces. Black Hat USA, 2014.
usability and reliability. Our future work is to include more [29] Dennis K Nilsson and Ulf E Larson. Conducting forensic in-
vestigations of cyber attacks on automobile in-vehicle networks.
logging features on the DiaLOG application as discussed In Proceedings of the 1st international conference on Forensic
in Section IV-B3. applications and techniques in telecommunications, information,

981
982
 TABLE V
F ULL AND BASIC AUTHORISATION PERFORMANCE ON S AMSUNG G ALAXY S5 MINI AND PIC32MZ

Time(ms)
Computation Communication Total
Protocol Message Mo Mt CCU PIC32MZ PIC18F with PIC32MZ with PIC18F
Full 1 1.972 - 0.055 57.686 57.605 59.713 59.632
2 0.506 - 0.082 57.816 57.991 58.404 58.579
3 0.458 - 0.037 42.472 42.423 42.966 42.918
4 1.069 - 39.646 157.047 157.676 197.762 198.391
Basic 1 0.724 1.861 - 19.650 19.650 22.235 22.235
2 1.956 - 0.059 34.864 34.832 36.879 36.847
3 0.660 - 0.149 80.715 80.995 81.525 81.804
4 0.922 0.500 - 19.650 19.650 21.072 21.072
5 - 0.752 0.041 72.900 72.787 73.694 73.580
6 - 0.994 39.651 157.047 157.676 197.692 198.322

and multimedia and workshop, page 8. ICST (Institute for Com-

puter Sciences, Social-Informatics and Telecommunications Engi-
neering), 2008.
[30] Matthew Ruff. Evolution of Local Interconnect Network (LIN)
solutions. In Vehicular Technology Conference, VTC-Fall. IEEE
58th, volume 5, pages 3382–3389. IEEE, 2003.
[31] SAE J1962 Revised APR2002. Standard, SAE Vehicle Electrical
and Electronics Diagnostics Systems Standards Committee, April
2002.
[32] Kowalick Thomas Michael. Motor Vehicle ’EDR’ Global Standard-
isation and Related Issues. http://onlinepubs.trb.org/onlinepubs/
UA/111610Kowalick.pdf.
[33] Szia Vilg. Toyota PRIUS CAN ID. http://www.vassfamily.net/
ToyotaPrius/CAN/cindex.html, 2008.
[34] Yilin Zhao. Telematics: Safe and Fun Driving. IEEE Intelligent
Systems, (1):10–14, 2002.

982
983