Reference Architecture for the design of secure Automotive Cyber Systems

Abstract

This paper presents a reference model for automotive cyber systems (ACS). It is the first step towards a security architecture for future ACS. Using a reference model and focus-ing on the whole system instead of separate domains allows for a holistic approach to automotive security. Thereby all interfaces and components are considered and effective countermeasures can be developed. Also derived security measures can be applied to the whole system and don't have to be repeated in each part. Finally the paper presents high risk components of ACS that were identified using a thread modeling approach in the reference model.

Full text

Reference Architecture for the design of secure
Automotive Cyber Systems
Tobias Madl
Munich University of
Applied Sciences
MuSe - Munich IT Security
Research Group
Munich, Germany
Email: madl@hm.edu
Prof. Dr.-Ing. Hans-Joachim Hof
Technical University of
Ingolstadt
INSicherheit - Ingolstadt Reasearch
Group Applied IT - Security
Ingolstadt, Germany
Email: hof@thi.de
Jasmin Br¨
uckmann
Munich University of
Applied Sciences
MuSe - Munich IT Security
Research Group
Munich, Germany
Email: brueckma@hm.edu
Abstract—This paper presents a reference model for automo-
tive cyber systems (ACS). It is the first step towards a security
architecture for future ACS. Using a reference model and focus-
ing on the whole system instead of separate domains allows for
a holistic approach to automotive security. Thereby all interfaces
and components are considered and effective countermeasures
can be developed. Also derived security measures can be applied
to the whole system and don’t have to be repeated in each part.
Finally the paper presents high risk components of ACS that
were identified using a thread modeling approach in the reference
model.
I. INTRODUCTION
In the automotive industry, safety is a well known topic
and relevant in every aspect of developing a modern vehicle.
But still the industry is actively pushing standards like ISO
26262 (Road vehicles Functional safety) in order to keep
up with the current developments. However IT security, the
degree of protection against malicious attacks, was until now
significantly less considered. Only in the recent years the
industry starts to adapt and also create standards for this field
of research like the ISO 21434 (Under Development: Road
Vehicles - Automotive Security Engineering). Also the ISO
26262 is currently discussing on how to integrate security. But
this only considers the car itself and not the whole automotive
cyber system.
Automotive cyber systems (ACS) are huge conglomerates
of systems and technologies, that interact with each other.
They could be roughly divided in four components: The first
component is the car itself with all its different subcomponents
(e.g., sensors, actors, ECUs and communication systems).
The second component is the communication infrastructure,
including cellular networks, WiFi access points and the like.
The third component are back-end systems of the OEM and
third parties that offer services to vehicles. The fourth com-
ponent consists of infrastructure like traffic lights. All these
systems communicate with each other and partly exchange
very important or even critical information and controlling
commands. In order to make this system secure a holistic
approach to security has to be created. By this the efficiency of
security controls could be increased and used in the different
domains as one control may be used in all. One particular
subject for example is identity or key management. This could
be used to identify a valid user in the whole system and
increase the authenticity of communication.
Through various new connections from interfaces to complex
systems, it is now way easier for an attacker to gain sensible
information or even get control over parts of the ACS. The
reason behind are new applications like autonomous driving
which require communications to the environment as a key
function. The result is a now more exposed system to the
open world and internet than ever before. To prevent attacks,
it is key to identify and protect the high risk components of
an ACS from a security point of view. In order to accomplish
this the car itself and all its containing components, as well
as the whole infrastructure and back-end systems have to be
considered.
The next step is to derive first ideas for security controls
to improve the security of ACS from the found high risk
components. This controls should include all communication
flows regardless of whether the communication takes place
in the car or is received from the outside. The remainder of
this paper is organized as follows: in the next section, related
work is discussed. After that we present our ACS Reference
Model as a holistic approach and Section IV the resulting high
risk components are introduced. Section V gives an outlook
to possible security controls. Finally we conclude the results
in Section VI.
II. RELATED WORK
In the first researches many models for automotive cyber
systems were found and analyzed. Most of them are focusing
on a specific domain of the ACS and don’t consider all
components of the system to get a holistic approach. In the
following, the most relevant models are presented.
In the paper [1] the author extends the Architecture Analysis
and Design Language (AADL) to model the cyber world
and physical world of automotive cyber system. The goal
of this approach is modeling spatial-temporal requirements.
The solution is illustrated via a Vehicular Ad-hoc NETwork
(VANET) example. Parts of this paper also influenced the
design of the here presented reference model, but the [1] paper

Statistics/Usage Data
Infotainment Requests
SOS Request
from the car
Management Data
Infotainment Response
SOS Response
to the car
Status Information
Location Based Services Status Information
Communication Infrastructure Car
Infrastructure
Origin al Equi pment M anufactu rer
& External P artner
Management Data
Infotainment Response
SOS-Response
from OEM &
External Partner
(a) Overview
Destination or
data to/from
destination/source
CAN
Input
Output
1
Entity 2
Gateway 6
In Out
3
4
5
Component
MOST
LIN
(b) Graphical syntax
Figure 1: Automotive Cyber System overview and explanation of graphical syntax
only focuses on the car and road side units.
The reference [2] already describes a holistic approach for
the security design of a car. The authors include the process
of design and development, measures for production and
measures in the field. The also propose ideas for the security
of car-to-x communication. But the reference does not include
the composition of other communication partners and their
interfaces or data flow.
The authors in [3] propose a V-Cloud architecture, which
includes vehicular cyber-physical system, vehicle-to-vehicle
network and vehicle-to-infrastructure network layers. In the
paper, the different layers and their services are described
for further research. But the paper keeps the analysis of the
components on a very high abstraction level and does not
include all communication partners and data flows.
In contrast to the related work stated above, our approach is to
create a model for the whole ACS and the associated data flow
between the components. The goal of our reference model is
to enable improved security architectures for future ACS.
III. AUTOMOTIVE CYBER SYSTEM REFERENCE MODEL
An automotive cyber system reverence model was designed
and developed in order to consider all elements of the system
for our future security research. To create this model, we have
looked at all internal and external communication partners and
systems of a state of the art vehicle. Next standard services
and functions of the car and its electronics were analyzed. The
goal is to include all relevant components, thus it contains all
important electronics down to the ECUs.
A general overview can be seen in figure 1(a). The car
communicates to the close infrastructure and other vehicle via
ad-hoc LTE or WiFi. For a more far-reaching communication
and to get access to other networks it uses for example LTE or
UMTS, which is represented by communication infrastructure.
This part provides connectivity to the interface units of OEM
and external partners. The exchanged information can be seen
in the figure and further down in this paper. Please note
that the following figures use the same graphical syntax as
described in figure 1(b). Graphical element one in figure 1(b)
represents the components of a system and implicates that it
consist of one or more sub components or entities. Graphical
element two in figure 1(b) is a entity, which represents the
lowest demonstrable, relevant part of a component. Graphical
element three in figure 1(b) shows the used communication
medium in the car. Graphical element four in figure 1(b)
represents a bi-directional communication and it’s associated
exchanged data. Graphical element five in figure 1(b) describes
a unidirectional connection and the transfered data. And the
graphical element number six in figure 1(b) displays interfaces
to external components.
This paper focuses on the car and it’s interfaces, otherwise
the paper would exceed its limits. For the OEM with external
Partners and the car environment, as can be seen in figure 1(a),
the paper from J. Br¨
uckmann [4] is a recommended read. For
a quick overall view, the rest of the ACS model can also be
found in the appendix. The car itself can be divided in five
subcomponents. The infotainment unit, the processing units,
the communication systems, the sensors and actors. The exact
partition can be seen in figure 2.
The infotainment unit is the main interface for human in-
teractions with the electronic system of the car. It provides
Apps and services like telephone, mail, Internet, contacts,
navigation, music, or emergency calls. It communicates with
other nearby devices (e.g. smart phones etc.) via Bluetooth,
WiFi or USB.
Next, there are the processing units. Normally, each subcom-
ponent has at least one ECU for processing the incoming
data and controlling the resulting actions. These ECUs are
distributed over the whole car and communicate with the
respective unit to be controlled. An example would be a sensor
ECU for receiving raw data, form ultrasonic sensors, and
converting it to standardized data like meters. This data is

<<com ponen t>>
Car
<<com ponen t>>
In-Vehicle Infotainment Unit
<<com ponen t>>
Communication System
<<com ponen t>>
Sensors
<<com ponen t>>
Act ua tor s
<<component>>
Processing Units
Sensors ECU
Akto rs E CU
Communication ECU
Infotainment ECU
USB
App s
Mail Phone
Navi Musi c
Bluetooth
WLAN
SOS News
Extern al Internal
Ethern et
MOS T LIN
CAN
WLAN
LTE
Cellular & Adh oc
PDC
GPS
EBATPMS
OBD II Gateway
HumidityLight
Engine
Keyless
entr y
OBU
Window
lifters
Light
Wipers
Figure 2: Car components
then send to the central controlling ECU for processing.
Another subcomponent of the vehicle is the communication
system, which consists of various bus technologies. The di-
verse systems all have their different characteristics, optimized
for their connected parts. This system is also the interface
for connections to external partners or infrastructure via LTE,
UMTS or WiFi. Also inter-bus communication is possible
via gateways for exchange of various information, like tire
pressure or oil temperature. This system additionally includes
the well known OBD II connector, which enables quick, easy
and profound analysis of the vehicle. Reason behind this
is a direct connection to the CAN and possibly other bus
technologies to inspect all transferred data and retrieve or set
status information.
Another subcomponent are the already mentioned sensors.
These are also spread over the whole car for various functions.
Those sensors constantly deliver important informations the
system needs to interact with the surroundings and to keep a
well working vehicle. The data they deliver differ from things
like open doors , GPS or park distance control, to the engine
temperature or tire pressure.
The last subcomponent are the actors. These subcomponents
are the working and reacting parts of the system. They receive
the commands processed through the ECU triggered by the
sensor recorded data. An example is the engine, the lights or
the windshield wipers.
Figure 2 is completed by figure 3 which shows the communi-
cation between the subcomponents. The Car, in this figure, has
mainly two interfaces to external components. One used for
receiving GPS data and the other one used for the remaining
information exchange (This picture excludes interfaces for
communication inside of the car, like OBD, and only shows
“outside” interfaces). Next, the sensors transfer their sensed
data to their associated ECU and on the other side, the ECU
sends configuration data to the sensor to adjust the measured
data and settings. The actors only got a unidirectional commu-
nication, because commands and configuration is send by the
ECU. Both actors and sensors have two lines representing the
communication of different subcomponents by different bus
technologies
The infotainment unit and the processing units also communi-
cate via different bus technologies. One is the CAN network
for mostly important information and configuration data. The
other one is the MOST, mainly for informational and enter-
taining data. The infotainment unit uses three communication
interfaces, the in car WiFi, USB connectors and a Bluetooth
interface. These are meant for communication with systems
inside of the car, like smart phones, USB sticks or other data
exchanging mediums. Also in this subcomponent are the apps,
which exchange data with the external partners and the OEM
via the car communication.
The subcomponent of the processing units receive and send
lots of information. On the one hand, they process input data
from sensors or human interactions, on the other hand they
calculate the resulting actions and transmit the commands
to the relevant parts. They also manage the communication
interfaces of the vehicle.
IV. AUTOMOTIVE CYBER SYSTEM HIGH RISK
COMPONENTS
In the following section above shown elements are analyses
and, via a threat modeling approach, high risk components

Car
Sensors
Act ua tor s
Sensordata
Processing Units
Sensors ECU
Akto rs E CU
Communication ECU
Infotainment ECU In-vehicle Infotainment Unit
Activate Actuators
Sensordata
Processed
Sensordata
Loc ation
Data
Infotainment Data
Statistic/Usage Data
Managem ent Data
SOS Signal
Location Based Services
Infrastructure
GPS
LTE/WL AN /
UMTS
Sensordata
In-Vehicle Infotainment Unit
USB
Bluetooth
WLAN
Entertai nment Dat a
Navigation Information
SOS Signal
etc.
WLA N H ots po ts/
WLAN Devices
Managem ent Data
Sensorinformation/
Sensorwarning
SOS Signal
Infotainment Data
Statistic/Usage Data
Location Based Services
App s
Bluetooth USB
WLA N
Figure 3: Car data flow
identified. Said components can be divided in three groups.
First of all the greatest dangers originate from components
with direct user interaction. An example is the infotainment
unit. It partly consists of apps, which can be malicious by
itself and try to attack the car or an attacker could try
to exploit vulnerabilities in the installed applications. Both
could lead to a possible compromising of the system and
pushed further to gain access to more internal systems via
the connected bus. A similar entry point is provided by the
offered interfaces of the infotainment unit like USB, Bluetooth
and WiFi. All devices connected to these interfaces could try
to attack the infotainment system and exploit vulnerabilities,
either by purpose of an attacker or by accident from virus
infected devices. Another openly vulnerable component is
the OBD II connector. By itself the OBD II should only be
accessible from inside the car for maintenance purposes, but
in the meantime it is common practice to connect dongles
on this interface to expand the car for 3rd party services. An
example of an exploit of such dongles is presented in [5]. Via
this interface an attacker can instantly communicate with the
CAN network in the vehicle. By this, it is possible to sniff
valuable information or even start attacks against the car, like
forging wrong information or flooding the system to prevent
communication. Once the attacker has a connection to the
OBD, the car can be considered as compromised.
The next group are components with indirect user access.
Normally the communication ECUs only communicate with
Radio stations, external partners or the OEM. But these
connections can be intercepted and manipulated. For example
compromised Road side units could broadcast malicious data
via ad-hoc LTE and this would be received by surrounding
vehicles. Another proof-of-concept attack was presented on
the Blackhat a few years ago, which is still present [6]. This
injects traffic information signals in the radio communication
to manipulate the drivers behavior or even the navigation
systems calculated routes.

The last group are elements of the system, which usually
serves a completely user independent service, nonetheless
these components are also exposed to manipulation. To under-
stand this scenario, we have to get in an attackers perspective.
The main goal of the attacker is to gain control over the car,
best case via remote or external connection. If he can’t get in
the car, he would have to attack from the outside, but if the car
does not have a wireless communication it is not possible to
gain access. Except if he attacks a part of the car which is con-
nected to the communication infrastructure of the vehicle like
the CAN bus. To achieve this the attacker could rip of some
“hidden” sensors like the tire pressure measurement sensor or
something similar and connect a remote controllable dongle
to the open CAN wires. By this he also gains remote access
to the communication network as described before, without
breaking in the car. This is only one example. Another one is
already described in books like [7]. In this case an attacker has
full access to the car and extracts ECUs to manipulate their
functions for tuning, but this will not be further researched in
this paper, as the main topic are external attacks without full
access to the car. But the book also describes a scenario for
a key-less entry vehicle. In the described attack, the author
replicates a signal of the remote from far away to the car, to
get inside. This could then be used to install a remote OBD
dongle and execute above described attacks. To conclude, the
main goal of the attacker is to get unrestricted access to the
communication infrastructure of the car to gain information
and to execute malicious commands.
A last possibility for the attacker could be a GPS signal
manipulation in order to again change the behavior of the
driver or the navigation system. But this attack is very unlikely
and at most only used if every other remote attack fails to get
possible access to the car.
V. O UTLOOK FOR AUTOMOTIVE CYBER SYSTEM
SECURITY CONTROL
In the current state of development, first researches were
made to counteract above shown attacks. The first goal is to
secure the internal systems against an attacker and to maintain
the functional safety of the car. Next, it should not be possible
to maliciously influence the behavior of driver or navigation
system.
An example are firmware updates. In the modern complex
vehicle a firmware update is a common and necessary require-
ment. However firmware updates of automotive subsystems
are security critical and often an objective for attackers. As
described in the paper [8] there are many approaches to update
the vehicle via a mobile device or other external devices. But
this extra devices are not really necessary. Firmware-over-the-
air (FOTA) is the key. This technology is not new and already
used in systems like smartphones or other mobile devices.
The car however, has the additional requirement to persist its
functional safety and security at any price.
To ensure this requirement, each ECU has to decrypt the
update from the OEM and check its signature before it is
installed. The obvious problem of this idea is, that most
ECUs are reduced to their main function and don’t have the
possibility to do tasks like decrypting or a signature check.
Furthermore it would be way to expensive to equip the ECUs
with this functions.
To solve this problem, we have to view the holistic system.
Most attacks against FOTA updates are forged updates from
attackers or intercepted and manipulated ones. Therefore,
it would be enough to install one component in the car,
which handles the FOTAs received from the external OEM.
This would then decrypt the update and check the signature.
Thereby the rest of the components would not need any extra
functions. Afterwards the checked update can be flashed to
the ECUs. Alternatively, the update could be symmetrically
encrypted inside the internal car communication system, so
the ECUs only have to symmetrically decrypt the data.
Nevertheless this would enable a secure remote update mech-
anism without any external devices or user interaction and no
more efforts or checks are needed to secure the FOTA updates.
Additionally only one new component has to be added to the
system. This is only one example where the holistic approach
can increase and simplify the security of the ACS.
VI. CONCLUSION
This paper presents a reference model for automotive cyber
systems with a focus on the car. This is done by firstly
introducing the relevant components, subcomponents and en-
tities. Secondly the data flow between said components is
identified and analyzed. From this model, the current high
risk components of the car are identified. One of the most
vulnerable component is the communication infrastructure of
the car. For the rest of the ACS, the paper [4] is referred.
Last but not least, we propose an outlook on how our holistic
approach can increase and simplify the security and future
security architectures of the ACS.
REFERENCES
[1] L. Zhang, “Modeling automotive cyber physical systems,” in Dis-
tributed Computing and Applications to Business, Engineering & Science
(DCABES), 2013 12th International Symposium on. IEEE, 2013, pp. 71–
75.
[2] C. Ebert and I. N. Adler, “Automotive cyber-security–erfahrungen f¨
ur die
entwicklungspraxis,” ATZextra, vol. 21, no. 2, 2016.
[3] H. Abid, L. T. T. Phuong, J. Wang, S. Lee, and S. Qaisar, “V-cloud:
vehicular cyber-physical systems and cloud computing,” in Proceedings
of the 4th International Symposium on Applied Sciences in Biomedical
and Communication Technologies. ACM, 2011, p. 165.
[4] J. Br¨
uckmann, “A reference model as means for security of automotive
cyber systems,” in Arc-Conference accepted, 2017.
[5] P. Umbelino. (2017, Apr.) Obd-ii dongle attack: Stopping a moving
car via bluetooth. [Online]. Available: http://hackaday.com/2017/04/14/
obd-ii- dongle-attack- stopping-a- moving-car- via-bluetooth/
[6] A. Barisani and D. Bianco. (2007) Injecting rds-tmc
traffic information signals. Inverse Path. [Online]. Avail-
able: https://www.blackhat.com/presentations/bh-usa-07/Barisani and
Bianco/Presentation/bh-usa- 07-barisani and bianco.pdf
[7] C. Smith, Car Hackers Handbook. A Guide for the Penetration Tester.
Nostarch. No Starch Press, 2016.
[8] H. Mansor, K. Markantonakis, R. N. Akram, and K. Mayes, “Lets get
mobile: Secure fota for automotive system,” in International Conference
on Network and System Security. Springer, 2015.

APPENDIX
<<com pon ent>>
Original Equipment Manufacturer & External Partner
<<component>>
OEM
<<component>>
Data Analysis Platform
Usage
Statistics
<<component>>
OEM Se rvices
FAS/FAS
Server
<<com ponen t>>
Management Services
SW/FW
Updates
Incident
Mana gem.
Error
Statistics
<<com pon ent>>
exa mple: AD AC
<<component>>
Data Analysis Platform
<<component>>
Main ten ance
cont rol
<<com ponen t>>
Insurance adjustments
Exhaust gas
stati stics
Check mainte-
nance status
Driving supervision
Traf fic
Update
Gateway
Security
Platform
Gateway
Security
Platform
<<component>>
exa mple: Google
<<component>>
Maps
<<com ponen t>>
Search
<<component>>
Gmail
Navigation
Requests
Search Requests
Mail Re ques ts
Gateway
Security
Platform
<<component>>
Data Analysis Platform
Usage
Statistics
Error
Statistics
<<com ponen t>>
Mob ility Ser vi ces
Traf fic
Update
<<component>>
Mob ility Ser vi ces
Traf fic
Update
Figure 4: Original Equipment Manufacture and External Partners components
<<component>>
Communication Infrastructure
<<com ponen t>>
Cellular Phone Networks
<<com ponen t>>
WLAN Hotspots
<<component>>
UMTS
<<component>>
LTE
RNC
GGSN
SGSN
Node B
eNod e B PDN-GW
Serving-GW
Router Switch
Figure 5: Communication Infrastructure components
<<co mpon ent >>
Infrastructure
<<co mpon ent >>
RSU
Street
Light
<<co mpon ent >>
Location Based
Services
Beacon Service
SOS
Boxes
Figure 6: Infrastructure components

External Partne r
example: Google
Usage Data
Send E-Ma ils
Search Queries
Location Da ta
Traffic Request
Received E-Mails
Search Results
Navigation/
Map dat a
Traffic Respo nse
Gateway
Security Platform
External Partne r
example: ADAC
Gateway
Security Platform
Statistics/
Usage
Data
Driving Data
Statistics/U sage Data
Location Data
Traffic Informa tion
Mainten ance
Information
Car OEM
OEM
Car
Special/Sponsor ed
Offers
Search
Gmail
Data Analysis Platform
Mobility Ser vices
Maps Maintenance
Control
Data Analysis
Platform
Insurance
Adjustments
Mobility Ser vices
Statistic/Usage Data
(back Processe d Data)
Statistic/
Usage
Data
Process
ed Data
Statistic/Usage Da ta
(back Processed Da ta)
Special/Sponsor ed
Offers
Figure 7: External Partners data flow
Sponsored
offeres/
Promotions
Car
Exte rnal Partner s
Ori ginal E quipment Manuf acturer
Statistics Data
Incidents
HAF/FAS Data
SOS Request
Traffic Requests
Loc ati on Da ta
Car-related Information
Manag ement Dat a
Service Information
HAF/FAS Data
SOS Response
Traff ic Updat es
Gateway
Security Platform
OEM S ervice sData Analysis Platform Ma nagem ent S ervi ces
Processed Data
Figure 8: Original Equipment Manufacture data flow

<<co mpon ent >>
Communication Infrastructure
<<co mpon ent >>
Cellular Phone Networks
<<component>>
WiFi Hotspots
<<component>>
UMTS
<<co mpon ent >>
LTE
Car
Transfer
Information
UMTS
Wi Fi
LT E
Infrastructure
Car
UMTS/LTE
Transfer
Information
Wi Fi
Figure 9: Communication Infrastructure data flow
Infrastructure
RSU Location Based
Services
LT E/Wi Fi /
UMTS
Status Information
Location Based Services
Status
Information
Car
OEM &
External Partners
Figure 10: Infrastructure data flow