DEGREE PROJECT IN TECHNOLOGY,

SECOND CYCLE, 30 CREDITS

STOCKHOLM, SWEDEN 2019

Security Threats and Countermeasures

for Connected Vehicles

Xuwei Gong <xuweig@kth.se>

KTH ROYAL INSTITUTE OF TECHNOLOGY

ELECTRICAL ENGINEERING AND COMPUTER SCIENCE
Abstract

With the rapid development of connected vehicles, automotive security has

become one of the most important topics. To study how to protect the security
of vehicle communication, we analyze potential threats for connected vehicles
and discuss countermeasures to mitigate these threats. In this thesis, we
examine 25 services that connected vehicles can provide. Entities, connections,
and message flows in these services are investigated and synthesized into a
vehicle network structure. The 25 services are divided into six use cases
including: infotainment service, remote monitoring, device control, Vehicle-to-
everything (V2X), diagnostics service, and in-vehicle Intrusion Detection System
(IDS). We establish communication models for these use cases and analyze
the potential threats based on Confidentiality, Integrity and Availability (CIA)
criteria. We discuss possible countermeasures that can mitigate these threats
based on existing network security techniques. Each alternative countermeasure’s
advantages and limitations are presented. To filter possible attacks, we investigate
and design firewalls in four components of a vehicle: Dedicated Short-Range
Communications (DSRC) module, gateway, Telematic Control Unit (TCU), and
Human-Machine Interface (HMI). We also simulate a firewall for an HMI
application by building a communication model in Python.

Keywords

Connected vehicle; Use case; Threat analysis; Countermeasures

i
Abstract

Med den snabba utvecklingen av anslutna fordon har bilsäkerhet blivit ett
av de viktigaste ämnena. För att studera hur man skyddar säkerheten
för fordonskommunikation analyserar vi potentiella hot mot anslutna fordon
och diskuterar motåtgärder för att mildra dessa hot. I denna avhandling
undersöker vi 25 tjänster som anslutna fordon kan tillhandahålla. Entiteter,
anslutningar och meddelandeflöden i dessa tjänster undersöks och syntetiseras
i en fordonsnätverksstruktur. De 25 tjänsterna är indelade i sex användarvägar,
inklusive: infotainment service, fjärrövervakning, enhetskontroll, Fordon-till-
allt (V2X), diagnostikservice och IDS-system (Intrusion Detection System). Vi
etablerar kommunikationsmodeller för dessa användningsfall och analyserar
de potentiella hot som baseras på CIA-kriterier (Confidentiality, Integrity and
Availability). Vi diskuterar eventuella motåtgärder som kan mildra dessa hot
baserat på befintliga nätverkssäkerhetstekniker. Varje alternativ motåtgärds
fördelar och begränsningar presenteras. För att filtrera eventuella attacker
undersöker vi och utformar brandväggar i fyra delar av ett fordon: Dedicated
Short-Range Communications (DSRC) -modul, gateway, Telematic Control Unit
(TCU) och Human Machine Interface (HMI). Vi simulerar också en brandvägg för
en HMI-applikation genom att bygga en kommunikationsmodell i Python.

Nyckelord

anslutna fordon; användningsfall; hotanalys; motåtgärd

ii
Acknowledgements

I would like to thank to my supervisors in RISE SICS: Shahid Raza and Joel
Höglund, they offered me the chance and environment to do this project, and
provided me support and guidance in the whole process. It has been a nice
experience to finish my thesis in RISE SICS. I also want to thank to Ali Gholami
in CEVT, who helped me selflessly with state-of-art vehicle knowledge. I am also
grateful to my KTH examiner Peter Sjödin and supervisor Markus Hidell, they
gave me some valuable feedback on my thesis and their courses taught me a lot of
background knowledge in this project.

iii
Author

Xuwei Gong <xuweig@kth.se>

KTH Royal Institute of Technology

Place for Project

Stockholm, Sweden
RISE SICS

Examiner

Peter Sjödin
KTH Royal Institute of Technology

Supervisor

Markus Hidell
KTH Royal Institute of Technology

Supervisors

Shahid Raza and Joel Höglund

RISE SICS
List of abbreviations

ADAS Advanced Driver-Assistance Systems

AH Authentication Headers
API Application Programming Interface
ARP Address Resolution Protocol
AUTOSAR AUTomotive Open System ARchitecture
BLE Bluetooth Low Energy
CAN Controller Area Network
CIA Confidentiality, Integrity, Availability
DID Data IDentifier
DoS Denial of Service
DSRC Dedicated short-range communications
DTC Diagnostic Trouble Code
ECU Electronic Control Unit
ESP Encapsulating Security Payloads
ETC Electronic Toll Collection
HMI Human-Machine Interaction
IDS Intrusion Detection System
IKE Internet Key Exchange
IPSec Internet Protocol Security
LIN Local Interconnect Network
LTE Long-Term Evolution (telecommunication)
MA Measurement Assignment
MAC Message Authentication Code
MDP Measurement Data Packet
MOST Media Oriented Systems Transport
NAT Network Address Translation
NFC Near-Field Communication
OBD On-Board Diagnostics
OEM Original Equipment Manufacturer
OTA Over-The-Air
OS Operating System
RPC Remote Procedure Call
RTE Run Time Environment
RTOS Real-Time Operating System
RVDC Remote Vehicle Data Collection

v
 SD Service Discovery
SOME/IP Scalable service-Oriented MiddlewarE over IP
TCU Telecommunication Control Unit
TLS Transport Layer Security
UART Universal Asynchronous Receiver-Transmitter
V2I Vehicle to Infrastructure
V2P Vehicle to Pedestrian
V2V Vehicle to Vehicle
V2X Vehicle to everything
VCM Vehicle Connection Module
VIN Vehicle Identification Number

vi
Contents

1 Introduction 1
1.1 Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Benefits, Ethics and Sustainability . . . . . . . . . . . . . . . . . . . 1
1.3 Challenge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4 Delimitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.5 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Theoretical background 4
2.1 Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Vehicle bus systems . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Vehicle components . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4 AUTOSAR introduction . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.5 SOME/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.6 Secure mechanisms involved in this thesis . . . . . . . . . . . . . . . 12
2.7 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3 Methodology 16

4 Vehicle functions and structure 17

4.1 Functions provided by connected vehicles . . . . . . . . . . . . . . . 17
4.2 Messages involved in each functions . . . . . . . . . . . . . . . . . . 17
4.3 Vehicle communication architecture . . . . . . . . . . . . . . . . . . 21

5 Use cases 23
5.1 Infotainment service . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.2 Remote monitor by OEM server . . . . . . . . . . . . . . . . . . . . 27
5.3 Device control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.4 V2X . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.5 Diagnostics service . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.6 In-vehicle IDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

6 Firewall solutions in the vehicle 37

6.1 DSRC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.2 Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

vii
 6.3 TCU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.4 HMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
6.5 HMI firewall design and implementation . . . . . . . . . . . . . . . 43

7 Conclusions 48

References 50

viii
1 Introduction

Vehicles are no longer regarded as transportation equipment merely. Instead,

they can be considered as sets of network nodes to fulfill users’ driving needs.
Because of the increased connectivity, the capability to correctly filter and enforce
secure communication becomes crucial. Old models for vehicle communication
become outdated. New solutions which satisfy new connectivity demands for both
in-vehicle networks and external networks are needed.

In an in-vehicle network, there are hundreds of ECUs (Electronic Control Unit)

to support all functions in a vehicle [49]. So, when it comes to the security of
connected vehicles, the most important thing is to protect in-vehicle networks
from the outside. A firewall is a kind of network security mechanism to monitor
and control the traffic between a protected network and the external network. Our
thesis is to study the potential threats in connected vehicles, find countermeasures
for those threats, and design firewalls to protect in-vehicle networks.

1.1 Problem

To investigate the potential threats in connected vehicles, we should identify

the services and functions provided by connected vehicles. Because there are
too many services and functions, we can not analyze threats in each of them
individually. We need to group those services and functions into use cases. We
analyze threats in each use case and discuss how to mitigate these threats with
some existing network security techniques. Based on these threats, we design
firewalls to protect in-vehicle networks. The required firewall functions and
vehicle components properties are considered.

1.2 Benefits, Ethics and Sustainability

The security of a connected vehicle network is important. Besides the common

effects of being attacked (e.g., private data disclosure), serious safety issues
would arise when vehicle communication is attacked (e.g., traffic accident).

1
However, little research about the security of connected vehicle has been done
in a comprehensive way.

In this thesis, we define six use cases in connected vehicles. These use cases can be
the foundation for future research. Our countermeasure discussion and firewall
design for the threats would be referenced in the SECREDAS project, which may
become a realistic solution for connected vehicles security.

1.3 Challenge

Challenge 1: There are too many functions and services we can collect. How can
we divide them into several use cases properly?

We overcome this difficulty with three steps below:

• We collect connected vehicle functions and services from scientific papers

and company product introductions.

• We group these services and functions by their service type and the entities
involved in each service and function.

• We merge similar functions and services into one use case and we build six
different use cases.

Challenge 2: It is challenging to design firewalls for a vehicle, because a vehicle is

composed of several components, each of them runs in different operating systems
and provides various of network functions. Where and how can we place firewalls
in vehicles?

To investigate this question, we need to gain a detailed understanding of

connected vehicle components. We can find some resources online about the
properties of vehicle components. Some components’ properties are well defined,
such as gateways. But vehicle companies have not reached a consensus on
other components. We use the standard in CEVT provided by Ali Gholami
[3]. The details are discussed in the later parts. According to connected
vehicle components’ properties, we can discuss the implementations of vehicle
firewalls.

2
1.4 Delimitations

Some material is collected from companies’ product introductions, which may not
be accurate for the standard model building.

The uses cases defined in this thesis represent the current state of vehicular
communication, and may need to be modified in the future with the emergence of
new features in connected vehicles.

The firewall solutions are proposed for the service-oriented based communication
mainly, the firewall solutions for signal-based protocols (e.g., CAN, LIN and
FlexRay) are not the focus in this thesis.

1.5 Outline

Chapter 2 provides theoretical background knowledge. The methodology of this

thesis is introduced in Chapter 3. Chapter 4 lists the services connected vehicles
would provide as well as the entities and messages involved in these services.
Vehicle network structures and the interfaces which support those services are
also included in this chapter. Chapter 5 synthesizes six use cases from Chapter 4.
It also analyzes potential threats in these use cases and proposes some solutions
to mitigate those threats. To realize the solutions proposed in Chapter 5, firewalls
for each vehicle part are studied and designed in Chapter 6. Chapter 7 concludes
this thesis work and puts forward future work.

3
2 Theoretical background

In this chapter, a description about the background of this degree project and
some related work is presented.

2.1 Firewall

In this part, firewall definitions and some existing firewalls are introduced. It is
necessary for us to explain how existing firewalls work when we want to design a
new firewall for vehicles.

2.1.1 Related definition

A firewall is an important network element that controls the packets going through
the boundaries of a secured network based on a specific security policy [37]. A
firewall security policy is a list of ordered filtering rules that defines the actions
performed on packets. A rule is composed of a set of filtering fields or network
fields, such as protocol type, source IP address, source port, destination IP
address, destination port, or an action field. The filtering fields of a rule represent
the possible values of the corresponding fields in the actual network traffic that
match this rule. Each network field could be a single value or a range of values.
The filtering actions can be either ’accept’, which allows the packets to go into or
from the secured network, or ’deny’, which blocks the packets.

2.1.2 Firewall types

There are four types of firewall introduced below [44].

Stateless firewall Stateless firewalls simply filter each packet based on the
packet content and preset rules in the firewall. The firewall can make ’accept’ or
’deny’ decisions according to the packet’s IP address or some other static values.
This type of firewall is very simple and not resource-intensive, but it has no

4
concept of state tables or connections. It cannot check traffic patterns or data
flows.

Circuit level gateway firewall Circuit level gateways are deployed at the
session layer of OSI model, and they monitor sessions (for example, TCP three way
handshake) to see whether a requested connection is legitimate or not. However,
this firewall would not filter the individual packet.

Stateful inspection firewall Stateful inspection firewalls are also known as

dynamic packet filters which not only drop packets based on the static values in
their content, but also keep track of the connections. For example, this kind of
firewalls can check whether an incoming packet for an unprivileged port (e.g.,
high number port) is a compromised response to a previous outgoing request.
The shortcoming of this firewall is that it requires high computation power and
may slow down the transfer rate.

Application proxy firewall Application proxy firewalls can drop packets

based on a set of rules related to the application layer protocols. It supports the
address and port translation for specific application layer protocols, such as, FTP
(File Transfer Protocol), RTSP (Real Time Streaming Protocol), and SIP (Session
Initiation Protocol). The application with this firewall should know which
addresses and ports allow incoming packets. This firewall can block unsolicited
connections to internal networks according to the information provided by the
application.

2.1.3 Existing firewall examples

We introduce four typical firewalls here.

Iptables: Iptables is a user-space utility program in which the root user can
configure the Linux kernel firewall (also called Netfilter) table [45]. There are
different types of iptables to support different protocols: iptables to support IPv4,

5
ip6tables to support IPv6, arptables to support ARP, and ebtables to support
Ethernet frames.

Netfilter: Netfilter is a Linux kernel framework which provides networking

operations including: packet filtering, network address translation, and port
translation [46]. Based on these operations, the functions of directing and
blocking packets from critical area in network can be implemented. Netfilter can
be configured by the user-space utility program (e.g., iptables and nftables).

Ipfw: Ipfirewall is an open-source Internet protocol, stateful firewall, packet

filter, and traffic accounting facility [9]. It was the built-in firewall of Mac OS
X.

Ipchains: Linux IP Firewalling Chains, normally called ipchains, is a free

software to control the packet filter or firewall capabilities. It was replaced by
iptables [28]. It is a stateless firewall.

2.2 Vehicle bus systems

In a vehicle network, various data is transferred by different types of buses

according to the data property [15]. The data in a vehicle network can be
classified into following domains: powertrain domain, body domain, and high-
speed information service domain [18].

Table 2.1 shows each domain’s applications, types of buses, and the data rate [8,
27, 41].

Domain Powertrain domain Body domain Information service domain

Bus type CAN/FlexRay CAN/LIN MOST/Ethernet
Data rate 1 Mbps–10 Mbps 20 kbps–250 kbps ≥100 Mbps
Application Engine Door locking Surround view system
Driving assistants Headlamp Audio

Table 2.1: Properties of different domains

6
In modern vehicles, most of ECUs are connected by the CAN bus. With the
emergence of connected vehicles, there are more interfaces in vehicles, such as
TCU, DSRC, HMI, and the OBD port. To fulfill the requirements of the increasing
data rate and communication complexity, Ethernets would be more and more
significant in vehicle bus systems.

2.3 Vehicle components

This part introduces the vehicles components we discuss in this thesis. The
reference of this part is provided by Ali Gholami from CEVT [3].

2.3.1 TCU

A telematic control unit is an on-boarding module responsible for a vehicle’s

connections to external networks [43]. It can receive and respond the traffic based
on GSM, GPRS, Wi-Fi, WiMax, or LTE with its mobile communication interface.
TCU’s major work is to handle different traffics based on different protocols, and
Linux is the operating system for TCU.

2.3.2 DSRC unit

The DSRC (Dedicated short-range communications) unit is responsible for short-

range communications [48]. DSRC includes a set of protocols and standards
designed for the automotive one-way or two-way short-range to medium-range
wireless communication. It is mainly based on IEEE 802.11p. The services in
DSRC have a strict requirement on the real time property. DSRC units can run on
RTOS (Real-time Operation System), such as Pike OS.

2.3.3 Vehicle gateway

A vehicle gateway is the core component for an in-vehicle network [10]. It acts as
a bridge between in-vehicle ECUs and external interfaces, as well as the router for
communications among ECUs in different domains. A vehicle gateway is involved

7
in almost all in-vehicle network communications, and it runs in the AUTOSAR OS
which is introduced in Section 2.4.

2.3.4 HMI

A Human–Machine Interaction is an interface through which the vehicle can

communicate to the driver [19]. HMI is responsible to receive users’ commands or
statuses, and show contents about in-vehicle ECUs’ statuses or external network
messages to users. Android can be the operating system for HMI.

2.4 AUTOSAR introduction

AUTOSAR (AUTomotive Open System ARchitecture) is a well known open

standard of software architecture for automotive electronic control units (ECUs)
[6]. In this thesis, we assume that all ECUs follows this standard. There are two
platforms for AUTOSAR: classic platform and adaptive platform. The differences
of these two platforms are introduced in Section 2.4.3.

2.4.1 Classic platform software structure

There are three layers of softwares included in the AUTOSAR classic platform
[6].

• Basic software: This layer provides some common software modules for
ECUs. These basic softwares can be the functional parts of services in the
upper layer.

• Runtime environment (RTE): This layer is the middleware used as the

network topology abstract for inter-ECUs and intra-ECUs information
exchange between the application software components.

• Application layer: This layer is for ECUs to provide services.

The application layer is the most hardware independent layer. Communications

between applications and access to basic software layer happens in RTE, and these

8
communications support applications’ functions.

2.4.2 Adaptive platform software structure

The AUTOSAR adaptive platform is used in some emerging use cases, such as,
Car-2-X applications, vehicle-in-the-cloud, and connectivity services [5]. To
support these use cases, future cars are expected to have a different electronic
architecture with mixing deeply embedded systems and more dynamic systems.
The adaptive platform is meant to combine the classic AUTOSAR platform,
which focuses on the real-time and safety, and dynamic applications needing
high computing power and security. It supports adaptive deployments, complex
microcontrollers, and interactions with non-AUTOSAR systems. In contrast to
the classic platform, the adaptive platform runtime environment dynamically
links services and clients during runtime.

2.4.3 Classic platform and adaptive platform

There are two kinds of platform in AUTOSAR: classic platform and adaptive
platform [6]. The comparisons of two platforms are shown in Table 2.2.

Platform Classic platform Adaptive platform

Operating system OSEK OS POSIX specification
Communication protocols Signal-based communication Service-oriented communication
(CAN, FlexRay, MOST) (SOME/IP)
Scheduling mechanisms Fixed task configuration Dynamic scheduling strategies
Memory management Same address space Virtual address space
for applications for each application

Table 2.2: Differences between two platforms

Each platform can support different functions. For example, engine control,
breaking systems, and other body control systems can run on the classic platform,
and Over The Air updates (OTA), infotainment services, and Human-Machine
Interaction (HMI) services can run on the adaptive platform.

9
2.5 SOME/IP

The adaptive platform of AUTOSAR is our focus in this thesis. The advantage
of the adaptive platform is its service-oriented property, so it is compatible to
other platforms. Scalable service-Oriented MiddlewarE over IP (SOME/IP) is the
protocol for the adaptive platform communication message control based on the
Ethernet [34]. It is designed to fit different devices including telematics devices,
AUTOSAR devices, and cameras, etc. The SOME/IP protocol can also support
features of infotainment domains and other domains, so it is possible that the
SOME/IP protocol can replace all communication protocols in vehicles in the
future.

2.5.1 SOME/IP middleware features

SOME/IP is an automotive middleware solution for different operating systems

in vehicles, and it can support several middleware features [34].

• Serialization: transform into and from on-wire representations.

• Remote Procedure Call (RPC): implement the remote invocation of

functions.

• Service Discovery (SD): find any functionality and configure its access
dynamically.

• Publish/Subscribe (Pub/Sub): configure which data is needed and shall be

sent to the client dynamically.

• Segmentation of UDP messages: allow the transport of large SOME/IP

messages over UDP without the need of fragmentation

These features make it possible for SOME/IP to be the communication protocol

among vehicle components in different operating systems.

2.5.2 SOME/IP message structure

The SOME/IP message’s header format is shown in Figure 2.1 [38].

10
 Message ID (Service ID /Method ID) [32 bit]

Length [32 bit]

Request ID (Client ID / Session ID) [32 bit]

Protocol Version [8 bit] Interface Version [8 bit] Message Type [8 bit] Return Code [8 bit]

Payload [variable size]

Figure 2.1: SOME/IP header format

The Message ID field is a 32-bit identifier that is used to identify the RPC (Remote
Procedure Call) which is either to call a method of an application, or to identify an
event. The message ID should be unique in the whole system. A Message ID field
is composed of a Service ID field (16-bit), a 0 (1-bit), and a Method ID field (last
15-bit).

The Length field shows the length in Byte from the Request ID/Client ID field to
the end of the SOME/IP message.

The Request ID field is to help a provider or subscriber identify the multiple uses
of the same method, event, getter or setter. The Request ID should be the same
in the corresponding request and response, and should not be reused until there
is no more response in this session any more. A Request ID field is composed of
a Client ID field (16-bit) and a Session ID field (16-bit).

The Protocol version field is an 8-bit field to show the SOME/IP protocol version.
The Interface version field is an 8-bit field to show major version of the service
interface.

The Message type field is to differentiate types of massages. The values of this field
and the corresponding description are available in the specification of SOME/IP
[38].

The Return code field is to signal whether a request was successfully processed.
The detailed specification of each message type’s return code is listed in Figure
2.2, they are available in the specification of SOME/IP [38].

Payload consists of the the event’s data or the method’s parameters. Because

11
 Figure 2.2: Return code values and descriptions

SOME/IP is based on the UDP protocol, the payload should be limited between 0
and 1400 bytes.

2.6 Secure mechanisms involved in this thesis

TLS and IPSec are introduced here. They are used in our later discussions.

2.6.1 TLS

TLS (Transport Layer Security protocol) is a standard for Internet security [47].
The goal of the TLS protocol is to provide the privacy and data integrity between
two communication applications. The process is shown in Figure 2.3. First,
the client sends a ClientHello message to the server which contains the protocol
version, the client identification, and a random number. Then, the server replies
with a ServerHello message which contains the agreed protocol version, the
certification of server, and a random number. After receiving the message, the

12
client sends back the secret key material encrypted with the server’s public key.
Finally, both the client and the server share a secret key, and they can have a
secured communication based on symmetric encryption.

ClientHello

ServerHello
Certificate
ServerHelloDone

Client ClientKeyExchange Server

ChangeCipherSpec
Finished

ChangeCipherSpec
Finished

Figure 2.3: TLS establishment process

2.6.2 IPSec

IP security (IPSec) is an IETF standard for Network Layer security [40]. IPSec
is popular for creating trusted link (e.g., VPN). There are two modes of IPSec:
transport mode and tunnel mode. The transport mode is mainly to handle the
services between two hosts or host to the gateway, and the tunnel mode is mainly
to handle the services between gateways. In this thesis, for there is only one single
gateway in an in-vehicle network, we focus on the transport mode. IPSec consists
of three parts: AH (IP Authentication Header), ESP (IP Encapsulating Security
Payload), and IKE (Internet Key Exchange).

AH and ESP The authentication header and the encapsulating security payload
both rely on an existing security association, which means both ends should share
a set of secret keys and agree on each other’s IP addresses and crypto algorithms.
This is done in the IKE process.

The authentication header provides the authentication and integrity of the packet

13
content and IP header. The IP header includes ICV (Integrity Check Value) which
is HMAC of the IP header, AH, and the payload. The authentication header
can also provide anti-replay services to avoid Deny-of-Service attacks with its
sequence number field. However, AH cannot provide the confidentiality. The
encapsulating security payload adds new header and trailer fields to the packet,
which can provide the confidentiality and integrity to the packet payload. Figure
2.4 and Figure 2.5 show a packet’s structure with AH and ESP.

Figure 2.4: A message with AH

Figure 2.5: A message with ESP

IKE IKE (Internet Key Exchange) is to set up a security association for AH and
ESP. For in-vehicle networks, this would be done in the future, and it is not the
focus in this thesis. We would not introduce IKE details here.

2.7 Related Work

Huang et al. evaluate the structure on in-vehicle networks and analyze the threats
in each domain [18]. However, the paper is limited to in-vehicle networks, and it
only considers the traditional model of a vehicle network structure. In other word,
Huang et al. focus on the classic platform, but our thesis focuses on the adaptive
platform.

5GCAR project proposes some detailed secure models and solutions for the V2X
use case [13]. However, it didn’t cover the firewall solutions about how to block
illegal messages and connections. This point is discussed in this paper’s following
parts.

14
Jin Ho Kim et al. present detailed hardware and software structures of an in-
vehicle gateway [25]. However, it mentions little about the gateway firewall, which
is not enough for the future connected vehicle functions. Also, it does not mention
the SOME/IP protocol, which would be the most popular protocol for vehicle in
the future.

Joakim Karlsson and Pontus Khosravi introduce the mechanisms in the

AUTOSAR platform and how they work [24]. But in their thesis, the scope is
limited to the AUTOSAR OS, it didn’t discuss other operating systems which are
also included in connected vehicles.

Feng Luo and Shuo Hou propose firewall solutions for the vehicle gateway, and
separate a gateway in two domains, one for the CAN/FD bus and one for the
Ethernet [29]. Packet filter mechanisms are provided to the CAN/FD bus, since
its security level and time delay are significant. The Ethernet firewall mechanisms
are designed based on stateful firewalls. Packet filter, anti-DoS, and access control
mechanisms are provided. This paper is the foundation of our discussion of
gateway firewalls.

15
3 Methodology

We use the OCTAVE Allegro method in this thesis [33]. There are eight steps
included in this method:

• Establish risk measurement criteria

• Develop an information asset profile

• Identify information asset containers

• Identify areas of concern

• Identify threat scenarios

• Identify risks

• Analyze risks

• Select mitigation approach

We can summarize the eight steps into the following five steps: establish security
measurement criteria, build the system, identify the vulnerable area, identify the
threats, and select solutions for those threats.

The security measurement criteria can be CIA (Confidentiality, Integrity, and

Availability). We build the vehicle network system first. Because we want to build
a comprehensive connected vehicle system which can support as many services
and functions as possible, we collect all services and functions connected vehicles
can provide, and group them by their categories and involved entities. Then
we identify those services and functions into several use cases. These use cases
are considered as vulnerable area in a vehicle network. After that, we analyze
potential threats in these use cases based on their communication models. Finally,
we discuss firewall solutions to mitigate these threats.

16
4 Vehicle functions and structure

In this section, we first collect what functions and services future connected
vehicles should have. Then, we can list the entities that involved in these services,
and what messages involved to realize these functions and services. Based on
the things above, we can have an overview of vehicle networks with various of
interfaces, and summarize services into several use cases. Those use cases are
our foundation to discuss potential security threats and possible solutions in the
following sections.

The functions and services are mainly collected from some companies’ product
introductions. The companies include: Tesla, Continental Automotive,
HARMAN, driverfocusedhmi, and NHTSA.

4.1 Functions provided by connected vehicles

The functions are listed in Table 4.1, and we collect these functions from
different company websites [14, 17, 42]. We grouped these functions into five
types: infotainment, comfort, OEM service, emergence, and ADAS (Advanced
Driver-Assistance Systems). In Table 4.2, we generalize each exact service or
function into each type. The entities involved in vehicle communication and their
connections to vehicles are shown in Figure 4.1. We also sort the functions and
services according to the entity that vehicles communicate to. As shown in Table
4.3, the services and functions are grouped by communication entities.

4.2 Messages involved in each functions

In the list below, message flows in each function are introduced briefly. We build
communication models based on these message flows.

1. A driver has commands through HMI to TCU. TCU sends requests to a content
provider, the provider replies content to HMI through TCU. HMI shows the
content to driver.

17
Index Function description
1 Provide driver access to their personal universe of apps and content
2 Update and download apps by OTA
3 Remote diagnostics service for repair purpose
4 Remote vehicle data collection
5 Static content includes geolocation, route calculation, and navigation
6 Dynamic content includes parking condition, road weather, and road
construction information
7 Pre-open vehicle air conditioner remotely
8 Remote start car
9 Contact police for an accident, e.g. airbag released
10 Report accident severity and situation to insurance company
11 Display infotainment or ADAS information to driver
12 Accept and recognize driver’s command by haptic, voice, or gesture
13 Monitor driver by driver’s behavior, focus, stress, and health condition
14 Unexpected decelerating
15 Rollover warning
16 Collision warning
17 Do not pass warning
18 Incoming vehicle warning
19 Pedestrian identification recognizes, e.g. old man, children
20 Potential collision warning
21 ETC (Electronic Toll Collection)
22 Warning on blind spots
23 Rail intersection warning
24 In-vehicle display of road signs and billboards
25 Inspect vehicle condition through physical connection to OBD port

Table 4.1: Functions and services in connected vehicles

Type Function index

Infotainment 1,2,5,6,11
Comfort 7,8
OEM service 3,4,25
Emergence 9,10
ADAS 11-24

Table 4.2: Functions grouped by their types

18
 Figure 4.1: Vehicle communication entities

Communication entity Function index

Infotainment content provider 1,2
OEM server 3,4
Map data service 5,6
Mobile application 7,8
Emergence and insurance center 9,10
Driver 11-13
Vehicle 14-18
Pedestrian 19,20
Infrastructure 21-24
Diagnostic tester 25

Table 4.3: Functions provided by each communication entity

19
2. A vehicle establishes a connection to a content provider server. The server
publishes update by OTA. The vehicle receives the update.

3-4. TCU establishes a connection to an OEM server. The server sends data
collection or diagnostic requests to TCU. TCU sends requests to the gateway
through the Ethernet, the gateway gets corresponding data from ECUs in the
in-vehicle network and sends it to TCU. TCU sends data responses to the OEM
server.

5. A driver inputs his or her destination to vehicle TCU through HMI. TCU sends
requests to a map data server. The server replies the geolocation, route calculation
result to HMI through TCU showing the map and navigation information to the
driver.

6. A vehicle collects the road data by its sensors (e.g., camera) and sends the data
to a map data server by its TCU as dynamic data.

7-8. A device (e.g., electric key or mobile phone) sends commands to a vehicle
based on Wi-Fi or BLE through TCU. The vehicle replies status through TCU to
the device.

9-10. An E-call module (SIM card) reports a vehicle status (e.g., airbag released)
or an accident situation to a police center and an insurance company through
TCU.

11. After receiving data from TCU, HMI shows the data to its user.

12-13. After receiving commands from the driver or the driver’s status from
sensors, HMI sends message to the external network through TCU, or in-vehicle
networks through the gateway.

14-18. Vehicles build connections through their DSRC modules, and send
messages to each other.

19-20. The device on a pedestrian sends information of the pedestrian (e.g.,

location and identification) to the vehicles in range through DSRC modules.

21-24. An infrastructure broadcasts messages to the vehicles in range through

DSRC, and those vehicles reply messages through DSRC.

20
25. A tester connects to in-vehicle networks through the OBD port and
implements diagnostic services.

4.3 Vehicle communication architecture

There are some relevant references online, but none of them presents a
comprehensive connected vehicle structure from communication view. Some of
online references focus on a specific function, some of others present the physical
architecture of a connected vehicle. We tried to summarize those references and
propose our own communication architecture for connected vehicles. But we
should make sure that our architecture matches the realistic vehicles. Thanks
to Ali from CEVT, he helped us modify the architecture which can represent
real vehicles communications [3]. Figure 4.2 is a simplified topology of vehicle
interfaces and the in-vehicle networks structure.

LTE, Wi-Fi, and BLE

In-vehicle network
Telematrics Avtive
Control Unit Powertrain
Safety

Safety Domain
V2X DSRC Secure Gateway

Comfort Domain

HMI Body Cluster

OBDⅡ Port
Bluetooth and USB

Figure 4.2: Vehicle interfaces and in-vehicle network structure

TCU can be considered as an interface communicating with external networks,

such as remote server (e.g., OEM server or infotainment content provider server),
emergency center (by SIM card), and some devices (e.g., user mobile phones
through BLE, or key cards through NFC). DSRC is an interface to provide services
requiring real-time property, such as V2V, V2I and V2P. HMI is an interface for

21
communications between users and vehicles. The gateway works as a bridge to
separate in-vehicle ECUs and external interfaces, it also contains the OBD port
for diagnostics.

22
5 Use cases

Considering all functions, services, and interfaces stated above, we derive six use
cases. In this part, we introduce each use case and discuss possible solutions.

5.1 Infotainment service

This use case includes services 1, 2, 5, 6, 11, 12, and 13 in Section 4.1 which are
provided by infotainment content provider servers. A vehicle user sends requests
to infotainment service through HMI in vehicle. The requests are transferred to
TCU via the gateway. TCU sends the requests to an infotainment content provider
server, the server answers the requests with infotainment content to TCU. TCU
receives it and transfers the content to HMI through the gateway. HMI shows the
content to the user. The threats in this use case are listed below.

5.1.1 Threat scenario

There are three types of communication in this scenario: communications

between users and HMI, communications between HMI and TCU through the
gateway, and communications between TCU and remote cloud servers. All
communications are two-way and the potential threats in each communication
are discussed below:

• For the communication between users and HMI, attackers may impersonate
the user to send requests to HMI. The attackers can also connect to HMI
through a Bluetooth or USB port to show the content that the user didn’t
require.

• For the communication between HMI and TCU, attackers may snoop or
tamper the messages content if they have access to the connection. If
attackers get the content of these messages, the user’s personal data may
be disclosed. If attackers change the content of the message without being
detected, the service cannot run in the proper way.

23
 • Because the communication between HMI and TCU goes through the
gateway, it is possible for attackers to get access to the in-vehicle network
through the gateway from HMI or TCU. This could cause serious safety
threats when in-vehicle ECUs are compromised.

• For the communication between TCU and remote cloud servers, the message
goes through the external network. Attackers could snoop or tamper
the message content, which would cause user personal data disclosure or
services not working. In addition, attackers can impersonate a remote server
to provide malicious data to vehicles.

For the first threat scenario, We assume that the people in the vehicle is
authenticated by vehicle’s physical secure mechanism, e.g., door lock. In that case,
HMI can trust that the commands are from authenticated users.In addition, HMI
only shows the content from trusted devices which are added in the trust list by
authorized users manually. Based on this assumption, we do not discuss the first
threat scenario in the following part.

5.1.2 Solution discussion

The solution for this use case is shown in Figure 5.1, and the illustration for Figure
5.1 follows.

At first, we can list existing security mechanisms we can use as solutions:

symmetric encryption, public-key encryption, cryptographic hash, TLS, and
IPSec. Both the symmetric encryption and the public-key encryption can provide
confidentiality to messages. The difference between two encryption methods is
that the keys for encryption and decryption are same in the symmetric encryption,
and different in the public-key encryption. The disadvantage of the symmetric
encryption is that the distribution process of the secret keys would be challenging.
The disadvantage of the public-key encryption is that it is much slower than the
symmetric encryption for its complicated algorithms. The cryptographic hash
is the only way to ensure messages integrity as we know. TLS and IPSec has
been introduced in the Section 2.6. Both of these two techniques can provide
the confidentiality, authenticity, and integrity for communications. TLS is a

24
 Figure 5.1: Solution for the infotainment service use case

predominating standard for application-level security, but its handshake process

may cause an unacceptable delay in some situations. IPSec can protect IP packets
to go through unsafe networks (e.g., VPN), but it does not include the key exchange
process.

For the communication between TCU and remote cloud server (the blue
line in Figure 5.1), the solution should provide the confidentiality, integrity
and authenticity. To fulfill the confidentiality, the communication should
be encrypted. The symmetric encryption is a suitable way considering that
infotainment service data size would be huge. The integrity requirement can be
satisfied if TCU and the remote cloud server agree on a same hash function and add
the MAC (Message Authentication Code) part in the message. Considering that
there will be more and more infotainment service cloud servers, it is necessary for
vehicles and servers to authenticate each other and share a symmetric key before
they can have a secure communication. TLS is suitable for this kind of server-
client communication model because of its handshake process. In the handshake
process, the server and the client can exchange their certificate, authenticate
each other, and negotiate the symmetric key, hash function, and encryption
method. No other existing security mechanism can provide this function. After
the handshake process, the infotainment servers and vehicles can send and receive

25
messages in the secured TLS connection. A firewall can be implemented in TCU to
block malicious messages. The details of the TCU firewall are discussed in Section
6.3.

For the communication between TCU and HMI (the green line in Figure 5.1), the
situation is different. As a previous work says, the authenticity and integrity of
messages are necessary for the in-vehicle network [26]. However, because of the
increasing importance of the data transferred in in-vehicle networks, we think the
confidentiality of messages is needed as well. Because the size of infotainment
data is huge, the symmetric encryption is a better solution. There are several ways
for the symmetric key distribution process. The first and the simplest way is to use
a permanent pre-shared key for HMI and TCU. The advantage of this method is
that it is easy, and the disadvantage of this method is that the longer the secret
key is been used, the more possible this secret key is cracked. The second way
is that TCU and HMI exchange a key periodically by a TLS handshake process.
But the latency caused by TLS handshake process is not acceptable [50]. The
third way is to use Time-Based One-Time Password Algorithm in which a new
secret key can be generated separately in HMI and TCU. The disadvantage of this
method is that it requires a relative high computation power in HMI and TCU. TLS
may not be the best solution in this situation, as we mentioned, the latency of the
handshake process is cannot meet the requirement of in-vehicle communications.
There is an alternative way that the handshake can be performed during an ECU’s
idle time [50]. But attackers may crack the secret key when an ECU is running
and this ECU cannot update its secret key at this time. IPSec can ensure the
confidentiality, authenticity and integrity of messages, so it can be used here with
the help of the time-based one-time key. A firewall in HMI can be implemented
to filter the messages, the details of the firewall are discussed in Section 6.4 and
Section 6.5.

There should also be a firewall on the gateway to block this kind of messages going
into in-vehicle networks, which may cause serious safety problems. There are
some researches on this problem as we mentioned in Section 2.7. We are going to
look deeper into it in Section 6.2.

26
5.2 Remote monitor by OEM server

The services in this use case include function 3, 4, 9, and 10 in Section 4.1
which are provided by OEM servers. RVDC (Remote Vehicle Data Collection)
is one of the services provided by OEM servers. RVDC is to collect vehicles’
data remotely, monitor vehicles’ running condition, and require vehicles’ DTCs
(Diagnostic Trouble Code) remotely. The services in this use case are about
the communication between the cloud server and in-vehicle ECUs. The server
sends requests to TCU, then TCU sends the requests to the in-vehicle network
through the gateway. ECUs respond vehicle data requests to the server through
the gateway and TCU. The threats in this use case are listed below.

5.2.1 Threat scenario

There are two differences in this use case compared to the first one: there
is only one or limited number of OEM servers for a specific vehicle, and the
communications are between OEM servers and in-vehicle ECUs.

• For the connection between TCU and OEM servers, it is very similar to the
first use case. The difference is that the OEM servers’ addresses should be
known by TCU. But attackers can still snoop or tamper the message, or even
perform IP address spoofing attacks to impersonate OEM servers.

• For the connection between TCU and the gateway, attackers could snoop the
message about vehicle data, or tamper the message to disturb the services.
In addition, in this use case, most of the messages are control messages,
attackers may perform replay attacks.

• For the in-vehicle network, attackers may control some ECUs, and keep
sending high priority messages to perform DoS attacks. Other functions and
communications can not be able to work in this situation.

• Attackers could impersonate TCU to send message to in-vehicle ECUs, or

impersonate normal ECUs to send messages to TCU. In this attack, ECUs
would receive malicious commands and run in a wrong way, TCU would send
out wrong messages about ECUs.

27
5.2.2 Solution discussion

The solution for this use case is shown in Figure 5.2, and the illustration for Figure
5.2 follows.

Block messages whose source

address is not in white-list
Diagnostics or vehicle
data collect requests OEM server
Telematrics
Control Unit
Both request and response
traffics are based on TLS

Gateway

Traffic between gateway and TCU should be

symmetic encrypted, add hash function, and fresh index
Vehicle data request/response

In-vehicle network
(ECUs)

Figure 5.2: Solution for remote monitor by the OEM server

For the connection between TCU and OEM servers, it is different from the first
use case, for there is only one or limited number of OEM servers, TCU can store
their IP addresses and accept the connections initialized by these IP addresses.
But the authentication process is still necessary to prevent IP address spoofing
attacks. When OEM servers want to send some messages to TCU, they should first
exchange their certificates, then TCU can confirm that the messages are from the
trusted source. So, the TCU firewall we mentioned before should add a whitelist to
store OEM servers’ addresses. From a security perspective, this whitelist should
not be changed after the vehicle was manufactured. The whitelist can be placed in
the TCU firewall. The connections between the OEM servers and vehicles should
be based on TLS for the same reason in the first use case.

For the connection between the gateway and TCU, the RVDC messages could
be similar in each time. Attackers may perform replay attacks in this situation.

28
There are two methods to mitigate this threat. The first one is to use Time-Based
One-Time Password Algorithm, the key used in the replayed message and the
key used in the fresh message are different, and the attack can not success. The
second method is to add a fresh index in the message payload. The first method
requires higher computation power, and the second method increases the payload
of messages, but either of the methods is doable and effective. We can still use
IPSec for the reasons discussed in the previous use case.

For communication in in-vehicle networks, ECUs are mostly connected by the

CAN bus. However, the CAN bus has no security mechanism when it was invented.
There are some solutions such as add encryption in the CAN bus [4]. But this is
not the best solution.We discuss the reason in Section 5.6.

For the final threat, the way TCU and the gateway authenticate each other is that
they use a shared secret key to encrypt messages. This is the way to prevent
attackers impersonating TCU to send malicious messages to in-vehicle networks.
The way for them to share secret key has been discussed in the previous use
case. The way the gateway authenticate ECUs is more complicated, because of
the features of the CAN bus and its protocol. The messages in the CAN bus do not
contain the information of its sender, and the number of messages in an CAN bus
should be limited or all messages in the whole bus would be blocked. The best
way we propose is that the gateway classifies in-vehicle ECUs by their behaviors,
because most CAN traffics are highly regular and follow the specifications defined
by OEMs. We discuss this in detail in Section 5.6.

5.3 Device control

The services in this use case include function 7 and 8 in Section 4.1 which are about
communications between vehicles and devices. The devices include mobile phone
and key card. Taking remote car opening service as an example, there are three
ways to open the car: tap the key card on the car, use the mobile phone’s BLE with
key card nearby, or contact the server to open the car remotely with LTE [32]. The
threats in this use case are listed below.

29
5.3.1 Threat scenario

When vehicles become connected, users can have various ways to control their
vehicles. Security threats would happen in this case. We use a Tesla’s product
as the example of how users can control their vehicles through their devices, and
analyze potential threats in this use case.

• According to Wired, the vehicle key card can be cloned if attackers can get
close to the vehicle and the driver’s key card [16].

• With the key card nearby, users can connect their mobile phones to their
vehicles based on BLE. Then users can use a mobile app to control their
vehicles in the range. However, attackers may impersonate users to control
their vehicles.

• In some situations, users cannot open their vehicles with the two methods
stated above, they need to contact the service center for help to open their
vehicles remotely based on LTE. However, attackers may impersonate users
to ask the service center to open the car.

5.3.2 Solution discussion

The solution for this use case is shown in Figure 5.3, and the illustration for Figure
5.3 follows.

Increasing the complexity of the handshake algorithm between the key card and
the vehicle can mitigate the first threat. However, this method is not practical
for the key card’s limited computation power. The alternative way is primitive
but effective: using a RF-block wallet to protect the key card from cloning. When
we assume that users can protect their devices from cloning, the first threat is
solved.

For the second threat, the allowed connect device should be stored in the whitelist
of the TCU BLE interface. A firewall can be implemented to block BLE connection
attempts from out-of-white-list devices. The operation to add malicious devices
into white-list should be impossible for attackers. The firewall whitelist should be
encrypted. This solution is based on the assumption that user’s device would not

30
 Traffic should Traffic should
Server cloud
be encrypted be encrypted
Operation
User name
and password Block traffics
not from server
Block connection from
devices not in white-list
Telematrics
BLE
Control Unit

Key card should be nearby for BLE

Phone connection between phone and vehicle Operation or
data request

NFC

Gateway
Keycard

Should not be accessable

when not used
In-vehicle network
(comfort domain)

Figure 5.3: Solution for device control

be accessible for attackers. This mechanism is well developed in all Bluetooth-

enable devices. So we do not discuss this further.

For the third threat, this communication is similar to the situation stated in
Section 5.2, except the first step that users try to contact the service center. The
proposed solution is that users should authenticate themselves, e.g., provide their
username and password.

Things become much easier when the biometric authentication comes into being.
This authentication method based on human characteristics, such as voice,
fingerprint, iris, and face. It is very convenient for user to authenticate themselves,
and it is difficult for attackers to steal these kinds of information.

31
5.4 V2X

In this use case, the communication is based on DSRC. There are three types of
V2X: V2V, V2P, and V2I. The functions in this use case include function 14-24 in
Section 4.1. The threats in this use case are listed below.

5.4.1 Threat scenario

• In all situations including V2V, V2P, and V2I, the most serious problem
is authentication. When a vehicle communicates with other vehicles,
pedestrians, or infrastructures, both communication entities should know
the identity of each other. Then, the communication entities can trust the
received messages.

• The content of DSRC communication should be encrypted, or attackers can

easily snoop the message in the range of DSRC.

5.4.2 Solution discuss

According to the 5GCAR project delivery, the possible solution can be illustrated
as shown in Figure 5.4 [13]:

Each application based on DSRC should have an application server, which stores
all entities’ certifications in this application. Vehicles and communication entities
can send signed messages to the same application server. The application
server validates their certification, then responds session key encrypted with
application’s private key. Vehicles and other entities decrypt the message with
server’s public key and get the session key. Then all vehicles and entities
involved in the application can communicate with the messages encrypted by the
symmetric session key. However, this solution is not perfect. For the longer
a session key is used, the higher possibility attackers can get the session key.
Then attackers can implement impersonation, spoofing or tamper attacks. On
the contrary, application servers would have a high traffic load if the session key
is altered frequently. It is a trade-off between the traffic load and the security
level.

32
 Symmetric session key
(Encrypted) Process to get
session key
Application
server
Signed message

Telematrics Vehicle
Control Unit Entity in the same
application
Symmetric session key
Application content
Content
Gateway
Communication encrypted
Key with the symmetric key
HMI
DSRC

Only accept communication

with session key encrypted

Figure 5.4: Solution for V2X

The solutions stated above is effective to solve the encrypted and authenticated
threats. However, the firewall on the DSRC module is still necessary to block
malicious messages to fulfill latency requirements, for if we rely to handle all
messages on the application layer, the vehicle’s computation power would face
a huge challenge. Attackers can perform Deny-of-Service attacks easily. It is
especially unacceptable in the DSRC module which requires real-time property.
We discuss the firewall in Section 6.1 based on the DSRC protocol.

5.5 Diagnostics service

This use case includes function 3 and 25 in Section 4.1 which are about diagnostics
services. There are two kinds of diagnostics services. The first one is the remote
diagnostics service, an OEM server sends diagnostics requests to the vehicle
through TCU, then TCU forwards the requests to in-vehicle ECUs via the gateway,
finally ECUs respond with diagnostics data to the OEM server through the gateway
and TCU. This type was discussed in Section 5.2. The second one is the diagnostics

33
service through the OBDII port. An OBDII tester sends diagnostics messages to
ECUs via the gateway. The threats in this use case are listed below.

5.5.1 Threat scenario

For remote diagnostic services, the gateway should confirm that the messages are
from TCU and have not been changed. It is the same as remote monitor use case.
We do not repeat this part. For the OBDII port diagnostic services, the connection
is physical, and it is mainly based on the CAN bus. It is possible for attackers
to implement man-in-the-middle attacks. In addition, attackers may spoof the
vehicle data or even write data to in-vehicle ECUs by the physical connection to
the OBDII port.

5.5.2 Solution discussion

For the OBD service, the authentication of tester devices can be done as Figure
5.5 shows [30]. By this process, the vehicle can trust the tester. When the tester
connects to the OBD security module, the tester sends its certificate to the OBD
security module. The OBD security module checks the certificate and get the
tester’s public key. Then the OBD security module generates a random session
key, encrypts this key and sends it to the tester. Finally, the tester can decrypt
the encrypted session key with its private key. The tester and the OBD security
mode can communicate with each other with messages encrypted by their shared
secret session key. This method can provide the confidentiality and authenticity
for diagnostics services.

There is also a module in the gateway called OFM: On-board firewall module
which acts a CAN whitelist to allow only CAN signals originating from OBD-II
dongles. With the authentication process and OFM, the threats mentioned in the
OBD service is solved.

34
 Tester OBD Security module

Device Certification Certification

storage check

Device private Device

key public key
Generate random
session key

Decrypted Encrypted session key Encrypted

session key session key

Secured communications

Figure 5.5: OBD tester authentication process

5.6 In-vehicle IDS

In this use case, the gateway should detect ECUs’ misbehaviors and report it to
users and OEM servers. When the situation is serious, the vehicle should inform
an emergence center and an insurance company.

The first threat of this use case is about in-vehicle ECUs. The in-vehicle network
is mostly based on the CAN bus, and the CAN bus does not have a security
mechanism. There are several security mechanisms, like encryption, can be added
to a CAN bus network [4]. However, we think that this added security mechanism
is not practical for reasons below:

• The ECU’s computation ability is limited. The encryption process may

decrease the real-time performance.

• Encryption can only mitigate impersonation and spoofing attacks. However,

in most situations, the threats of in-vehicle networks are: ECUs stop
working, or ECU is controlled to send many high-priority messages to
implement deny-of-service attacks. These attacks are from the physical
level, which is not the point of this thesis.

35
Compared to adding security mechanism to in-vehicle networks, IDS can be a
better solution. There are many IDS algorithms have been studied [35, 39]. Most
of them are effective for detecting DoS attacks. IDS should be able to detect
compromised ECUs according to the messages in the CAN bus. After abnormal
behaviors are detected, the gateway should report the fault to users, OEM servers,
and even emergence centers if the problem is serious. The communications
between the gateway and TCU or HMI should be authenticated and encrypted.
The symmetric encryption can be implemented in this situation.

Furthermore, the result of IDS can be the source for improving firewall rules.
After OEM servers receive IDS reports from lots of vehicles, they can analyze the
results and update the firewall rules in vehicles. Then OEM servers can release
the new firewall which can defend the intrusions which have been reported. The
IDS mechanism will have a bright future, for it can detect intrusions as soon as
possible to minimize the consequence of an attack, and prevent the attacker to
perform same attacks again.

36
6 Firewall solutions in the vehicle

In this section, we discuss firewall solutions in different vehicle components. We

state the required functions of each firewall, propose some solutions considering
the feature of each component, and introduce the implementation work we have
done at the end of this section.

6.1 DSRC

We introduced 5GCAR solutions for the V2X authentication and encryption

method in the previous chapter, and there is a detailed description about the
management of V2X communication systems in [11]. In this part, we discuss
firewall solutions for V2X services. Some protocols and standards for DSRC are
listed below:

IEEE 1609.0: Guide for Wireless Access in Vehicular Environments (WAVE)

Architecture: It is a general standard with the protocol architecture, interfaces,
spectrum allocations and device roles [20].

IEEE 1609.2: Security Services for Applications and Management Messages:

This standard defines how V2X messages are exchanged and protected from
eavesdropping, spoofing, alteration, and replay attacks [23].

IEEE 1609.3: Network Services: This standard defines the services in the network
and transport layer like addressing and routing in DSRC systems [22].

IEEE 1609.12: Identifier Allocations: This standard specifies the format of

provider service identifiers (PSID), and points out identifier values that have been
allocated by WAVE systems [21].

SAE J2735: DSRC Message Set Dictionary: This standard specifies the message
set, data frame, data elements and applications in 5.9 GHz DSRC [12].

According to these standards, we can know that the DSRC system is well
developed. But there is no firewall mentioned in all this standards and protocols.
We describe a possible mechanism for firewalls in different layers in the following
parts. A possible alternative solution is mentioned.

37
6.1.1 DSRC Firewall mechanism

There should be a table storing enabled DSRC services’ IDs and the corresponding
secret key for each service. The key should be updated once the application server
broadcast a new key to all entities involved in this service. When packets come in,
the DSRC module can filter the packets according to following steps:

• Extract the service type of this packet, and check whether this service is
enabled. Drop the packet if the service is not in the enabled service list.

• Decrypt the packet with this service’s secret key.

• Check if the message has been tampered, drop it if it has been tampered.

• Check some information in the packet content.

In the following part, We explain the firewalls used in the first step and the forth
step.

6.1.2 Service ID firewall

In DSRC communications, all services at present are identified by the service ID

[21]. For a vehicle, it can only enable several services and store these services’
IDs in a whitelist. The firewall can then block messages with the service ID not
included in the whitelist.

6.1.3 Content-aware firewall

A content-aware firewall can be implemented. For example: in the V2V scenario,

the BSM (Basic Safety Message) should contain the position information, so the
receiver can block all basic safety message with the position information showing
that the sender is not in the valid range of DSRC. However, this firewall requires
high computation power and may cause latency when it processes messages.
The specific rules of the content-aware firewall can be designed according to the
protocols we mentioned above.

38
6.1.4 Physical interface filter

The spectrum band plan for DSRC services is standardized [11]. The plan is shown
in Figure 6.1. When the interface receives a message, the frequency of this message
can indicate what the service of this message. By checking the whitelist of allowed
services, the interface can drop or allow the packet without inspecting the header
of the message. This filter on the interface layer can not be called as a firewall,
but it is more efficient than classic packet processing firewalls. At present, the
filter is constrained by the DSRC module’s classification ability. The filter can only
recognize the service type, rather than what exactly the service is. In the future,
the interface filter can be a good supplement for DSRC firewall mechanisms.

5.580 5.855 5.865 5.875 5.885 5.895 5.905 5.915 5.925(GHz)

I2V Security Non I2V
safety manage- BSM- safety
and ment based and
Reser- V2V Control Public
mobility download safety mobility
verd Safety Channel Safety
Service Channel Service Channel

Figure 6.1: DSRC band plan

6.2 Gateway

A vehicle gateway provides functionality of translating different protocols. The

classic AUTOSAR is usually used for such functionality. Figure 6.2 is the gateway
software structure provided by CEVT. As it is shown in Figure 6.2, the Ethernet
and CAN communications can be firewalled in the CAN or Ethernet stacks.
However, it lacks firewalling features for SOME/IP messages in stacks, which
means if a SOME/IP traffic comes in, only if it is forwarded to the application
layer, can the gateway provides the firewall ability to the SOME/IP traffic. In this
situation, it may cause the unacceptable latency bottleneck, when the delivery of
messages are required in millisecond scale. For example, active safety messages
are required to be forwarded in 100 ms from TCU to ADAS (the example is
provided by CEVT).

There are two possible solutions:

39
 Figure 6.2: Gateway software architecture (source : AUTOSAR)

• Change the gateway’s operating system to the AUTOSAR adaptive platform

which supports service-oriented communications

• Implement firewall functions in the application layer, increase the gateway

module’s computation ability to decrease the latency

For the first solution, it may come true when all ECUs in future connected vehicle
run on AUTOSAR adaptive platform. However, this solution is not practical at
present. For the second solution, it may solve the problem at present, but it
cannot be a permanent solution with the increasing functionalities of the vehicle
and increasing complexity of in-vehicle networks.

Except the solutions above, there are some very detailed and complete firewall
solutions for the gateway [29]. We do not repeat its work in this thesis.

6.3 TCU

TCU can receive Bluetooth traffics and internet (LTE or WiFi) traffics. For
Bluetooth traffics, the security mechanism technology is mature [7] . TCU can only
accept connections from devices in the whitelist, the process of adding devices to
the whitelist can only be done manually. Then Bluetooth traffics in TCU is secure
enough. We mainly focus on the internet access in the firewall part.

40
A typical TCU may consists of two separated CPUs and communicate using
UART (Universal Asynchronous Receiver/Transmitter). The structure is shown
in Figure 6.3.

Fw2 Fw1

SOME/IP
using
Classic
Gateway UART Linux OS Remote server
IPSec AUTOSAR

ECU2 ECU1

Figure 6.3: TCU structure

The firewall rules are included in Figure 6.4:

Packet received

Header of packet

Message is encrypted and

Exist in the state table? Yes Yes Accept
not tampered?

No
Yes

Source address in whitelist?

No

Drop No

Figure 6.4: Rules of the TCU firewall

We need a stateful firewall here to handle the connection state. Fw1 in Figure
6.3 can use iptabels in theLinux operating system to block any unsolicited traffic
from the external interfaces. Such firewall provides the protection against DoS or
spoofing attacks.

Fw2 in Figure 6.3 is the firewalling mechanisms of the data traffic from the Linux
OS towards the classic AUTOSAR. In this thesis, we don’t discuss much about this

41
part, which need to be done in future work.

6.4 HMI

The Human-Machine-Interaction module can run on the Android operating

system, because Android is the most popular operating system of touch screen
mobile devices, which is similar to the future vehicle’s HMI interface (some
cars, like Tesla, have already implemented it). Furthermore, Android Auto
has been developed especially for cars. As we can find on the Android Auto
website (https://www.android.com/auto/), Android Auto can either run on a
user’s mobile phone, or run on a vehicle screen with an USB connection to the
mobile phone. So if we implement a firewall that can run on Android mobile
phones, it would be compatible on vehicles as well.

We introduce the HMI structure and HMI firewall functions in this part, then we
implement the HMI firewall in the next part. HMI services are service-oriented, so
it should based on the AUTOSAR adaptive platform. The HMI structure is shown
in Figure 6.5.

Firewall

AUTOSAR
SOME/IP messages
ADAS adaptive USB Android OS from gateway
platform

Hypervisor

Figure 6.5: HMI structure

When messages come from the gateway to HMI hypervisor, they would first be
filtered by the firewall, then get into the Android operating system. The messages
are processed by Android and expressed in a well designed layout in Android Auto.
Then, the layout would be transferred to the vehicle HMI screen, which is in the
AUTOSAR adaptive platform, by USB or Bluetooth. Finally, the user can read the
content (e.g., ADAS information) on the vehicle screen without distraction.

42
In HMI, the firewall should block the packet not from the gateway, TCU,
or DSRC module, the messages of disabled service type, and the messages
without the encryption (all messages in vehicle-networks should be encrypted
to prevent snooping attacks). In addition, too frequent function invocations and
messages sending are regarded as a DoS attack. High privilege requests from an
unauthorized entity are blocked as well. Considering all this required functions,
we would first investigate what firewall mechanisms are available at present,
which functions they cannot fulfill, and then design our new firewall solutions
to realize all functions stated above.

6.5 HMI firewall design and implementation

We follow the steps stated above to design the HMI firewall, then try to implement
it to check if it can work.

6.5.1 Android firewall

Firewall is supported on Android through NetFilter [36]. Netfilter is a Linux

kernel subsystem that provides firewalling capabilities (e.g., packet filtering and
connection tracking capabilities). The root privilege is required to set firewall
rules. In vehicle situation, the firewall rules should be configured frequently,
for example: a user doesn’t want to receive notification from his work email box
on his way home. It is not convenient to run the root privilege every time we
want to update firewall rules. What’s more, for this firewall is specific for vehicle
communication, which is based on the SOME/IP protocol, we want to implement
a firewall to block illegal SOME/IP messages, rather than only filter packets on
the transport layer or network layer.

We try to find some available Android firewall applications and analyze their
abilities. We find three Android firewall applications [1].

AFWall+ (Root Required) AFWall+ is a firewall application based on

iptables [2]. It can block applications’ network privilege and configure firewall

43
rules easily. The user-interface is clear as shown in Figure 6.6. However, it
requires the root privilege which is not convenient as we mentioned before.

Figure 6.6: AFWall+ user interface

NetStop Firewall The user interface of NetStop Firewall is a huge red button.
When the user clicks the red button, all applications network accesses are blocked.
It is more a net-activity kill switch than a firewall, so it is not suitable for our
purpose. And I am a little confused that there are several easy ways to disable
network functions. Why do we need an application (a giant red button) to block
the network access?

NetGuard NetGuard is as powerful as AFWall+, and it doesn’t need the root

privilege [31]. The principle is that when users run the NetGuard application, an
own built-in VPN is activated. Then the user can take control of each application’s
network access without the root privilege. We have downloaded it from Google
Play and the user interface is clear and easy to use. The screen shot of user
interfaces is shown in Figure 6.7. In addition, some functions in NetGuard are
charging, for example, check blocked traffic logger and filter network traffics. But
NetGuard is an open-source application. It is the best firewall application for our
thesis research.

After researching Android firewall mechanisms and some existing Android

44
 Figure 6.7: NetGuard user interface

firewalls, we can have the conclusion that the present Android firewall can filter
packets on the network layer and transport layer. We should add the packet
content-aware firewalling ability to filter SOME/IP packets.

6.5.2 Content-aware firewall design

As we introduced in Section 2.5, a SOME/IP packet includes following parts:

message ID (service ID and method ID), length (payload length plus 8 bytes),
request ID (client ID and session ID), protocol version, interface version, message
type, return code, and payload.

Considering the return code types shown in Figure 2.2, the protocol itself can deal
with the service type error, method type error, protocol version error, interface
version error, payload error, and message type error. So, our firewalling ability
should include the function to check the packets’ following properties:

• Whether the packets are encrypted

• Whether they are tampered

• Whether the client have privilege to the service type

45
 • Whether this service has been called more frequently than normal

• Whether an entity has sent too many packets in a period of time

To fulfill the firewalling abilities mentioned above, we designed the firewall rules
in Figure 6.8:

Figure 6.8: Firewall rules

6.5.3 HMI firewall implementation

We also build a small communication model in Python to simulate the filter

process, the simple structure of this model is shown in Figure 6.9, and the
source code can be found in appendix A. The client module can generate different
SOME/IP messages and send them to the server module. The packetcheck module
can parse the message and extract the information in the message. The firewall

46
module can filter the message by its rules and make the decision to allow or drop
the message. If the message is allowed, it can be transfer to the server module
to implement corresponding services. This implemented communication model
proves that our HMI firewall can realize the properties we stated above.

Services
handler

Allowed
firewall.py messages
server.py

Parsed
DoS check
message
client.py

packetcheck.py IPSec packetgenerator.py

Figure 6.9: Python model structure

47
7 Conclusions

In this thesis, we identify 25 services that connected vehicles can provide. Then we
divide these 25 services into six use cases: infotainment services, remote monitor,
device control, V2X, diagnostics service, and in-vehicle IDS. After analyzing these
six use cases’ security threats, we propose solutions based on CIA (Confidentiality,
Integrity, and Availability) for each vehicle part and for the connections between
them.

The solutions include: TLS based connection from TCU to remote servers to
ensure communication’s authenticity, integrity, and confidentiality. IPsec is
selected for in-vehicle communication with the Time-based One-Time Password
algorithm to allocate secret keys. The communication between vehicles and
devices (e.g., mobile phone and key card) need to authenticate the user’s identity,
the emergence of biometric authentication would make this process easier.

In V2X scenarios, 5GCAR has proposed the model to implement real-time

communication, but the DSRC firewall is needed to filter malicious traffic and
improve the performance of service. For diagnostic service through the OBD
port, the authentication for testers is needed, and the on-board firewall module
is necessary to block non-CAN signals from going through the OBD port to the
gateway. We choose IDS to be the main mechanism for ECU communication
security because of the property of the CAN bus.

In the next part, we study the possible firewall solutions on the TCU, DSRC, HMI,
and the gateway. For the DSRC part, we want to propose firewalls based on related
protocols. A service ID firewall before the decryption process and a content-
aware firewall after the decryption process can meet our firewall requirement.
A physical interface filter can be an alternative solution in the future. To
design firewall for HMI part, we investigate what firewalls exist in Android OS
and what functions these firewalls provide, then we design and implement an
application level content-aware firewall in the HMI for the SOME/IP protocol.
For the gateway part, we found that it contains firewall mechanisms, but the
firewall cannot support the SOME/IP protocol. We propose two solutions for this
problem. For the TCU part, we find that the the Linux-based stateless Iptables

48
can be the solution for TCU firewall to external network, we also need to place
a firewall between Linux OS and AUTOSAR OS to filter the traffic, which is not
existing at present.

For future work, with the development of connected vehicles, more and more
services will come into being. Collecting these services and taking them into
consideration to make our use cases more detailed and complete would be the
most significant future work. Besides improving our use cases, we can go
further in the firewall solutions part. For the HMI firewall, we can develop
more compatible firewall applications combining existing firewall functions and
our content-aware functions. For the DSRC part, we can dig deeper of relative
protocols and design more specific firewall rules. For the TCU and gateway parts,
the most challenging future work can be firewall solutions for classic AUTOSAR,
which are implemented in the CAN bus mainly.

49
References

[1] 3 of the Best Firewall Apps for Android in 2018. https : / / www .
maketecheasier.com/best-firewall-apps-android/. Accessed April 22,
2019.

[2] AFWall+ (Android Firewall +). https://play.google.com/store/apps/

details?id=dev.ukanth.ufirewall. Accessed April 22, 2019.

[3] Ali Gholami. China Euro Vehicle Technology (CEVT). ali.gholami@cevt.se.

[4] Authentication And Encryption for SAE J1939 And Other CAN Bus
Protocols. https : / / copperhilltech . com / blog / authentication - and -
encryption-for-sae-j1939-and-other-can-bus-protocols/. Accessed
March 20, 2019.

[5] AUTOSAR. Adaptive platform. Autosar . https : / / www . autosar . org /

standards/adaptive-platform/. Accessed April 21, 2019.

[6] AUTOSAR Introduction. https://www.autosar.org/fileadmin/ABOUT/

AUTOSAR_Introduction.pdf. Accessed April 18, 2019.

[7] “Bluetooth Security”. eng. In: Network Security. Hoboken, NJ, USA: John
Wiley Sons, Inc., 2006, pp. 313–329. ISBN: 9780471703556.

[8] Brunner, Stefan et al. “Automotive E/E-architecture enhancements

by usage of ethernet TSN”. eng. In: IEEE, 2017, pp. 9–13. ISBN:
9781538611579.

[9] Chapter 30. Firewalls:30.4. IPFW. https : / / www . freebsd . org / doc /
handbook/firewalls-ipfw.html. Accessed May 9, 2019.

[10] Connected Vehicle Gateway. http : / / pravala . com / automotive /

connected-vehicle-gateway/. Accessed May 9, 2019.

[11] Connected Vehicles Intelligent Transportation Systems. eng. Wireless

Networks. 2019. ISBN: 3-319-94785-0.

[12] “Dedicated
Short Range Communications (DSRC) Message Set Dictionary”. In: SAE
International (Mar. 2016).

50
[13] “Deliverable D4.1 Initial design of 5G V2X system level architecture
and security framework”. eng. In: Fifth Generation Communication
Automotive Research and innovation 22 (2018), pp. 70–72.

[14] DSRC functions. https://www.fluidmesh.com/dsrc-dedicated-short-

range-communications/. Accessed March 25, 2019.

[15] Fischer, Robert et al. The automotive transmission book. eng. Powertrain.
2015, pp. 197–224. ISBN: 3-319-05263-2.

[16] HACKERS CAN STEAL A TESLA MODEL S IN SECONDS BY CLONING

ITS KEY FOB. https://www.wired.com/story/hackers- steal- tesla-
model-s-seconds-key-fob/. Accessed March 19, 2019.

[17] HMI functions. https : / / www . conti - engineering . com / Navigation /

Areas - Expertise / Interior - Electronic - Functions / HMI - Functions.
Accessed March 25, 2019.

[18] Huang, T. et al. “On the security of in-vehicle hybrid network: Status and
challenges”. In: vol. 10701. Springer Verlag, 2017, pp. 621–637. ISBN:
9783319723587.

[19] HUMAN MACHINE INTERFACE (HMI) SERVICES FOR AUTOMOTIVE.

https : / / services . harman . com / industries / automotive - connected -
car / automotive - engineering - services / hmi - services - automotive.
Accessed May 9, 2019.

[20] “IEEE Guide for Wireless Access in Vehicular Environments (WAVE) -

Architecture”. In: IEEE Std 1609.0-2013 (Mar. 2014), pp. 1–78. DOI: 10.
1109/IEEESTD.2014.6755433.

[21] “IEEE Standard for Wireless Access in Vehicular Environments (WAVE) -

Identifier Allocations”. In: IEEE Std 1609.12-2016 (Revision of IEEE Std
1609.12-2012) (Mar. 2016), pp. 1–21. DOI: 10 . 1109 / IEEESTD . 2016 .
7428792.

[22] “IEEE Standard for Wireless Access in Vehicular Environments (WAVE)

– Networking Services”. In: IEEE Std 1609.3-2016 (Revision of IEEE Std
1609.3-2010) (Apr. 2016), pp. 1–160. DOI: 10 . 1109 / IEEESTD . 2016 .
7458115.

51
[23] “IEEE Standard for Wireless Access in Vehicular Environments–Security
Services for Applications and Management Messages”. In: IEEE Std
1609.2-2016 (Revision of IEEE Std 1609.2-2013) (Mar. 2016), pp. 1–240.
DOI: 10.1109/IEEESTD.2016.7426684.

[24] JOAKIM KARLSSON, PONTUS KHOSRAVI. “Master thesis: Evaluation of

Security Mechanisms for an Integrated Automotive System Architecture”.
In: ().

[25] Kim, Jin Ho et al. “Gateway Framework for In-Vehicle Networks Based on
CAN, FlexRay, and Ethernet”. eng. In: IEEE Transactions on Vehicular
Technology 64.10 (2015), pp. 4472–4486. ISSN: 0018-9545.

[26] Lastinec, Jan and Hudec, Ladislav. “A performance analysis of IPSec/AH

protocol for automotive environment”. eng.
In: Proceedings of the 16th International Conference on computer systems
and technologies. Vol. 1008. CompSysTech ’15. ACM, 2015, pp. 299–304.
ISBN: 9781450333573.

[27] Lee, S. Y. et al. “MOST network system supporting full-duplexing

communication”. In: 2012, pp. 1272–1275. ISBN: 9788955191639.

[28] Linux IP Firewalling Chains. http : / / people . netfilter . org / rusty /

ipchains/. Accessed May 9, 2019.

[29] Luo, Feng and Hou, Shuo. “Security Mechanisms Design of Automotive
Gateway Firewall”. In: SAE Technical Paper. SAE International, Apr. 2019.
DOI: 10.4271/2019-01-0481. URL: https://doi.org/10.4271/2019-01-
0481.

[30] Markham, Tom R and Chernoguzov, Alex. “A Balanced Approach for

Securing the OBD-II Port”. eng. In: SAE International Journal of
Passenger Cars - Electronic and Electrical Systems 10.2 (2017). ISSN:
1946-4622.

[31] NetGuard - no-root firewall. https : / / play . google . com / store / apps /
details?id=eu.faircode.netguard. Accessed April 22, 2019.

[32] Phone Key and Key Card. https://www.tesla.com/support/model- 3.

Accessed March 19, 2019.

52
[33] R. A. Caralli James F. Stevens, Lisa R. Young and Wilson, William R. The
OCTAVE Allegro Guidebook, v1.0. 2007.

[34] Scalable service-Oriented MiddlewarE over IP (SOME/IP). http://some-

ip.com/. Accessed April 18, 2019.

[35] Seo, Eunbi, Song, Hyun Min, and Kim, Huy Kang. “GIDS: GAN based
Intrusion Detection System for In-Vehicle Network”. eng. In: 2018 16th
Annual Conference on Privacy, Security and Trust (PST). IEEE, 2018,
pp. 1–6. ISBN: 9781538674932.

[36] Shabtai, Asaf, Mimran, Dudu, and Elovici, Yuval. “Evaluation of Security
Solutions for Android Systems”. In: (Feb. 2015).

[37] Al-Shaer, Ehab. Automated Firewall Analytics Design, Configuration and

Optimization. eng. 2014. ISBN: 3-319-10371-7.

[38] SOME/IP Protocol Specification. https : / / www . autosar . org /

fileadmin / user _ upload / standards / foundation / 1 - 0 / AUTOSAR _ PRS _
SOMEIPProtocol.pdf. Accessed April 18, 2019.

[39] Song, Hyun Min, Kim, Ha Rang, and Kim, Huy Kang. “Intrusion
detection system based on the analysis of time intervals of CAN messages
for in-vehicle network”. eng. In: 2016 International Conference on
Information Networking (ICOIN). Vol. 2016-. IEEE, 2016, pp. 63–68.
ISBN: 9781509017249.

[40] Stallings, William. Network

Security Essentials: Applications and Standards, International Edition.
eng. Pearson Education UK, 2014. ISBN: 9780273793809.

[41] Steinbach, T. et al. “Tomorrow’s In-Car Interconnect? A Competitive

Evaluation of IEEE 802.1 AVB and Time-Triggered Ethernet (AS6802)”.
eng. In: IEEE, 2012, pp. 1–5. ISBN: 978-1-4673-1880-8.

[42] TCU functions. http://www.threadcn.com/news/shownews.php?lang=cn&

id=134. Accessed March 25, 2019.

[43] Telematics and Connectivity Control Unit. https : / / www . st . com /

en / applications / telematics - and - networking / telematics - and -
connectivity-control-unit.html. Accessed May 9, 2019.

53
[44] The Different Types of Firewall Architectures. https://www.compuquip.
com/blog/the-different-types-of-firewall-architectures. Accessed
April 20, 2019.

[45] The netfilter.org ”iptables” project. https : / / www . netfilter . org /

projects/iptables/index.html. Accessed May 9, 2019.

[46] The netfilter.org project. https://www.netfilter.org/. Accessed May 9,

2019.

[47] “Transport Layer Security”. In: IEEE Internet Computing 18.6 (2014),
pp. 60–63. ISSN: 1089-7801.

[48] Understanding DSRC. https : / / connectedvehicle . devpost . com /

details/understanding-dsrc. Accessed May 9, 2019.

[49] Your Car, Your Computer: ECUs and the Controller Area Network. https:
/ / www . techopedia . com / your - car - your - computer - ecus - and - the -
controller-area-network/2/32218. Accessed April 29, 2019.

[50] Zelle, Daniel et al. “On Using TLS to Secure In-Vehicle Networks”. eng.
In: Proceedings of the 12th International Conference on availability,
reliability and security. Vol. 130521. ARES ’17. ACM, 2017, pp. 1–10. ISBN:
9781450352574.

54
Appendices

55
Appendix - Contents

A Python scripts source codes for communication model 57

56
A Python scripts source codes for communication
model

client.py
import s o c k e t
import p a c k e t g e n e r a t o r

d e f encrypthash ( data ) :
r e t u r n ’ encryptedandhashed ’ + data

def c l i e n t n o i p s e c ( t e x t ) :
sock=s o c k e t . s o c k e t ( s o c k e t . AF_INET , s o c k e t .SOCK_DGRAM)
data= t e x t . encode ( ’ a s c i i ’ )
sock . sendto ( data , ( ’ 1 2 7 . 0 . 0 . 1 ’ , 1 2 3 4 5 ) )
data , address=sock . recvfrom (65535)
t e x t =data . decode ( ’ a s c i i ’ )
p r i n t ( ’ \ n ’ + ’ Reply : ’ + t e x t + ’\n ’ )

def clientsamport ( t e x t ) :
sock=s o c k e t . s o c k e t ( s o c k e t . AF_INET , s o c k e t .SOCK_DGRAM)
sock . bind ( ( ’ 1 2 7 . 0 . 0 . 1 ’ , 6 3 3 3 3 ) )
t e x t =encrypthash ( t e x t )
data= t e x t . encode ( ’ a s c i i ’ )
sock . sendto ( data , ( ’ 1 2 7 . 0 . 0 . 1 ’ , 1 2 3 4 5 ) )
data , address=sock . recvfrom (65535)
t e x t =data . decode ( ’ a s c i i ’ )
p r i n t ( ’ \ n ’ + ’ Reply : ’ + t e x t + ’\n ’ )

def c l i e n t d i f p o r t ( t e x t ) :

57
 sock=s o c k e t . s o c k e t ( s o c k e t . AF_INET , s o c k e t .SOCK_DGRAM)
t e x t =encrypthash ( t e x t )
data= t e x t . encode ( ’ a s c i i ’ )
sock . sendto ( data , ( ’ 1 2 7 . 0 . 0 . 1 ’ , 1 2 3 4 5 ) )
data , address=sock . recvfrom (65535)
t e x t =data . decode ( ’ a s c i i ’ )
p r i n t ( ’ \ n ’ + ’ Reply : ’ + t e x t + ’\n ’ )

i f __name__ == ’__main__ ’ :
while ( 1 ) :
print (”1 for service 1 , 2 for service 2 ,”)
p r i n t ( ” 3 f o r no−e x i s t s e r v i c e , 4 f o r over−p r i v i l e g e s e r v i c e , ” )
p r i n t ( ” 5 f o r no IPSec message , 6 f o r s e r v i c e Dos , ” )
c h o i c e=i n p u t ( ” 7 f o r p o r t Dos , : ” )
i f c h o i c e == ’ 1 ’ :
pack=p a c k e t g e n e r a t o r . pack ( p a c k e t g e n e r a t o r . Message1 )
c l i e n t d i f p o r t ( pack )
e l i f c h o i c e == ’ 2 ’ :
pack=p a c k e t g e n e r a t o r . pack ( p a c k e t g e n e r a t o r . Message2 )
c l i e n t d i f p o r t ( pack )
e l i f c h o i c e == ’ 3 ’ :
pack=p a c k e t g e n e r a t o r . pack ( p a c k e t g e n e r a t o r . Message3 )
c l i e n t d i f p o r t ( pack )
e l i f c h o i c e == ’ 4 ’ :
pack=p a c k e t g e n e r a t o r . pack ( p a c k e t g e n e r a t o r . Message4 )
c l i e n t d i f p o r t ( pack )
e l i f c h o i c e == ’ 6 ’ :
while ( 1 ) :
pack=p a c k e t g e n e r a t o r . pack ( p a c k e t g e n e r a t o r . Message1 )
c l i e n t d i f p o r t ( pack )
e l i f c h o i c e == ’ 7 ’ :
while ( 1 ) :
pack=p a c k e t g e n e r a t o r . pack ( p a c k e t g e n e r a t o r . Message1 )

58
 c l i e n t s a m p o r t ( pack )
pack=p a c k e t g e n e r a t o r . pack ( p a c k e t g e n e r a t o r . Message2 )
c l i e n t s a m p o r t ( pack )
e l i f c h o i c e == ’ 5 ’ :
pack=p a c k e t g e n e r a t o r . pack ( p a c k e t g e n e r a t o r . Message1 )
c l i e n t n o i p s e c ( pack )
e l i f c h o i c e == ’ q u i t ’ :
break
else :
p r i n t ( ’ no s e r v i c e found ’ )

packetgenerator.py
import random

Message1 = { ’ s e r v i c e ’ : 0 x 1 1 1 1 ,
’ method ’ : 0 x2222 ,
’ c l i e n t ’ : 0 x3333 ,
’ s e s s i o n ’ : 0 x4444 ,
’ proto ’ : 0 x55 ,
’ i f a c e ’ : 0 x66 ,
’ type ’ : 0 x77 ,
’ r e t ’ : 0 x88 }

Message2 = { ’ s e r v i c e ’ : 0x2222 ,
’ method ’ : 0 x3333 ,
’ c l i e n t ’ : 0 x4444 ,
’ s e s s i o n ’ : 0 x5555 ,
’ proto ’ : 0 x66 ,
’ i f a c e ’ : 0 x77 ,
’ type ’ : 0 x88 ,
’ r e t ’ : 0 x99 }

59
Message3 = { ’ s e r v i c e ’ : 0x5555 ,
’ method ’ : 0 x2222 ,
’ c l i e n t ’ : 0 x3333 ,
’ s e s s i o n ’ : 0 x4444 ,
’ proto ’ : 0 x55 ,
’ i f a c e ’ : 0 x66 ,
’ type ’ : 0 x77 ,
’ r e t ’ : 0 x88 }

Message4 = { ’ s e r v i c e ’ : 0 x 1 1 1 1 ,
’ method ’ : 0 x2222 ,
’ c l i e n t ’ : 0 x0000 ,
’ s e s s i o n ’ : 0 x4444 ,
’ proto ’ : 0 x55 ,
’ i f a c e ’ : 0 x66 ,
’ type ’ : 0 x77 ,
’ r e t ’ : 0 x88 }

def t r a n f t o s t r 1 ( x ) :
i f x >255:
return ’00 ’
y= s t r ( hex ( x ) )
y=y [ 2 : ]
i f l e n ( y )== 1:
y = ’0 ’+ y
return y
def t r a n f t o s t r 2 ( x ) :
i f x >65535:
r e t u r n ’0000 ’
y= s t r ( hex ( x ) )
y=y [ 2 : ]
i f l e n ( y )== 1:

60
 y = ’000 ’+ y
e l i f l e n ( y )==2:
y = ’00 ’+ y
e l i f l e n ( y )==3:
y = ’0 ’+ y
return y
def t r a n f t o s t r 4 ( x ) :
y= s t r ( hex ( x ) )
y=y [ 2 : ]
w h i l e l e n ( y ) <8:
y = ’0 ’+ y
return y
def createPayload ( ) :
alpha1 = [”0” , ” 1 ” , ”2” , ”3” , ”4” , ”5” , ”6” , ” 7 ” ]
alpha2 = [ ” 8 ” , ” 9 ” , ”A” , ”B ” , ”C ” , ”D” , ”E ” , ”F ” ]
alpha = a l p h a 1+alpha2
l e n g t h = 2*random . r a n d i n t (0 ,20 )
payload = ’ ’ . j o i n ( [ random . c h o i c e ( alpha ) f o r _ i n range ( l e n g t h ) ] )
r e t u r n payload
d e f pack ( d i c ) :
a= ’ ’
p l=c r e a t e P a y l o a d ( )
l e n g=l e n ( p l )+8
d i c [ ’ l e n gth ’ ] = l e n g
a=a+ t r a n f t o s t r 2 ( d i c [ ’ s e r v i c e ’ ] ) + t r a n f t o s t r 2 ( d i c [ ’ method ’ ] )
a=a+ t r a n f t o s t r 4 ( d i c [ ’ l eng th ’ ] ) + t r a n f t o s t r 2 ( d i c [ ’ c l i e n t ’ ] )
a=a+ t r a n f t o s t r 2 ( d i c [ ’ s e s s i o n ’ ] )
a=a+ t r a n f t o s t r 1 ( d i c [ ’ proto ’ ] ) + t r a n f t o s t r 1 ( d i c [ ’ i f a c e ’ ] )
a=a+ t r a n f t o s t r 1 ( d i c [ ’ type ’ ] ) + t r a n f t o s t r 1 ( d i c [ ’ r e t ’ ] ) + p l
return a
i f __name__ == ’__main__ ’ :
r e s=pack ( S e r v i c e 1 )
print ( res )

61
 packetcheck.py
import time
import s e r v e r

d e f p a rse ( p a c k e t ) :
r e c ={}
r e c [ ’ messageID ’ ] = p a c k e t [ 0 : 8 ]
r e c [ ’ le n g th ’ ] = p a c k e t [ 8 : 1 6 ]
rec [ ’ c l i e n t ’ ] = packet [16:20]
rec [ ’ session ’ ] = packet [20:24]
r e c [ ’ proto ’ ] = p ac k e t [ 2 4 : 2 6 ]
rec [ ’ i f a c e ’ ] = packet [26:28]
r e c [ ’ type ’ ] = p a c k et [ 2 8 : 3 0 ]
r e c [ ’ r e t ’ ] = p ac k e t [ 3 0 : 3 2 ]
r e c [ ’ payload ’ ] = p a c k e t [ 3 2 : ]
r e c [ ’ time ’ ] = time . time ( )
return rec

d e f dosfunc ( rec , funccheck ) :

key =( r e c [ ’ messageID ’ ] )
i f ( key i n funccheck ) :
h i s =funccheck [ key ]
i f l e n ( h i s ) <5:
h i s . append ( r e c [ ’ time ’ ] )
funccheck [ key ]= h i s
r e t u r n 1 , funccheck
else :
i f r e c [ ’ time ’] − h i s [ 1 ] > 1 :
h i s . append ( r e c [ ’ time ’ ] )
del his [0]

62
 funccheck [ key ]= h i s
r e t u r n 1 , funccheck
else :
r e t u r n 0 , funccheck
else :
funccheck [ key ] = [ r e c [ ’ time ’ ] ]
r e t u r n 1 , funccheck
d e f dosport ( rec , port , p o r t c h e c k ) :
i f ( port in portcheck ) :
h i s =p o r t c h e c k [ p o r t ]
i f l e n ( h i s ) <5:
h i s . append ( r e c [ ’ time ’ ] )
p o r t c h e c k [ p o r t ]= h i s
return 1 , portcheck
else :
i f r e c [ ’ time ’] − h i s [ 1 ] > 1 :
h i s . append ( r e c [ ’ time ’ ] )
del his [0]
p o r t c h e c k [ p o r t ]= h i s
return 1 , portcheck
else :
return 0 , portcheck
else :
portcheck [ port ]=[ port ]
return 1 , portcheck

firewall.py
import pa cke tche ck

funccheck ={}
p o r t c h e c k ={}

63
d e f decryptcheckhash ( data ) :
i f data [ 0 : 1 8 ] = = ’ encryptedandhashed ’ :
r e t u r n data [ 1 8 : ]
else :
return 0

d e f f i r e w a l l ( data , p o r t ) :
g l o b a l funccheck
global portcheck
i f decryptcheckhash ( data )==0:
r e t u r n ’ This message i s not based on IPSec ’
else :
data=decryptcheckhash ( data )
d i c=p acke tcheck . parse ( data )
s e r v i c e I D= i n t ( d i c [ ’ messageID ’ ] )
clientID=int ( dic [ ’ client ’ ] * 2 )
i f s e r v i c e I D >33333333:
r e t u r n ’ The s e r v i c e t y p e i s i l l e g a l ’
i f c l i e n t I D <s e r v i c e I D :
r e t u r n ’ The c l i e n t have no p r i v i l e g e t o t h i s s e r v i c e ’
e r r 1 , funccheck=packetcheck . dosfunc ( dic , funccheck )
i f e r r 1 ==0:
p r i n t ( ’ This f u n c t i o n i s been DoS a t t a c k e d ’ )
return 0
err2 , p o r t c h e c k=packetcheck . dosport ( dic , port , p o r t c h e c k )
i f e r r 2 ==0:
p r i n t ( ’ This address i s doing DoS a t t a c k e d ’ )
return 0
return 1

server.py

64
import s o c k e t
import pa cke tche ck
import f i r e w a l l

def server ( ) :
sock=s o c k e t . s o c k e t ( s o c k e t . AF_INET , s o c k e t .SOCK_DGRAM)
sock . bind ( ( ’ 1 2 7 . 0 . 0 . 1 ’ , 1 2 3 4 5 ) )
w h i l e True :
data , address=sock . recvfrom (65535)
p o r t= s t r ( address )[ −6: −1]
t e x t =data . decode ( ’ a s c i i ’ )
i f f i r e w a l l . f i r e w a l l ( text , port ) ! = 1 :
t e x t= f i r e w a l l . f i r e w a l l ( text , port )
e l i f f i r e w a l l . f i r e w a l l ( text , port )!=0:
t e x t = ’ The s e r v i c e i s operated s u c c e s s f u l l y ’
else :
break
data= t e x t . encode ( ’ a s c i i ’ )
sock . sendto ( data , address )

i f __name__ == ’__main__ ’ :
server ()

65
TRITA-EECS-EX-2019:586

www.kth.se