Received November 16, 2020, accepted December 1, 2020, date of publication December 7, 2020,

date of current version December 22, 2020.

Digital Object Identifier 10.1109/ACCESS.2020.3043070

An Overview of Automotive Service-Oriented

Architectures and Implications for
Security Countermeasures
MARCEL RUMEZ 1, DANIEL GRIMM 2, REINER KRIESTEN1 , AND ERIC SAX2
1 Institute of Energy Efficient Mobility, Karlsruhe University of Applied Sciences, 76133 Karlsruhe, Germany
2 Institute for Information Processing Technologies, Karlsruhe Institute of Technology, 76131 Karlsruhe, Germany

Corresponding author: Marcel Rumez ([email protected])

This work was supported by the German Federal Ministry of Education and Research (BMBF) within the Research Programme ICT
2020 through the AUTO-SIMA Project under Grant 13FH006IX6.

ABSTRACT New requirements from the customers’ and manufacturers’ point of view such as adding
new software functions during the product life cycle require a transformed architecture design for future
vehicles. The paradigm of signal-oriented communication established for many years will increasingly be
replaced by service-oriented approaches in order to increase the update and upgrade capability. In this article,
we provide an overview of current protocols and communication patterns for automotive architectures based
on the service-oriented architecture (SOA) paradigm and compare them with signal-oriented approaches.
Resulting challenges and opportunities of SOAs with respect to information security are outlined and
discussed. For this purpose, we explain different security countermeasures and present a state of the section
of automotive approaches in the fields of firewalls, Intrusion Detection Systems (IDSs) and Identity and
Access Management (IAM). Our final discussion is based on an exemplary hybrid architecture (signal- and
service-oriented) and examines the adaptation of existing security measures as well as their specific security
features.

INDEX TERMS Automotive SOA, service-oriented architectures, connected vehicles, cybersecurity, fire-
wall, intrusion detection system (IDS), access control.

I. INTRODUCTION in the automotive industry. This is also supported by the

Modern vehicles are transforming from hardware- to expectation that the growth of the software and E/E market
software-defined platforms, making software the main driver will significantly exceed the growth of the entire automotive
for new innovations. Among the functions that are only made market [2]. In order to support new technologies such as
possible by software are, for example, increased road safety connectivity, electrification, shared mobility or autonomous
through automated driving functions, better integration of driving, we experience a real paradigm shift in the field
vehicles into everyday life through integration into the Inter- of E/E architecture design [1]. Current vehicle architec-
net with app stores for users, and more ecological mobility tures have up to 150 ECUs [3] and roughly three million
through electrification and shared mobility services [1]. From implemented functions [4], which are interconnected via
simple microcontrollers in the past, Electronic Control Units bus systems such as Controller Area Network (CAN) and
(ECUs) are therefore also developing into highly sophisti- organized by different domains (e.g., powertrain, chassis).
cated computing machines that perform these advanced tasks The previous highly ECU focused development methods
such as artificial intelligence for autonomous driving. The with statically defined transmitter-receiver dependencies at
electrical and electronical architecture (E/E architecture), design time are very limited with regard to extensions and
consisting of the ECUs, its networking and the software modifications [5], [6].
running on it, is one of the key factors for new innovations In order to increase the update and upgrade capabili-
ties of vehicle systems in the future, due to dynamic cus-
The associate editor coordinating the review of this manuscript and tomer requirements and market changes, future architectures
approving it for publication was Ahmed Farouk . will be more centralized. For this transformation, SOAs are

This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/
221852 VOLUME 8, 2020
M. Rumez et al.: Overview of Automotive SOAs and Implications for Security Countermeasures

increasingly being introduced, which allow dynamic commu- communication, rising data rates, a vast amount of new
nication relationships at run time without static dependencies protocols, the integration of third-party services and stan-
mapped on ECUs [7]. SOAs are recognized as one of the dardized software components pose new challenges and
key elements to provide more flexibility, a better abstrac- requirements to automotive security measures. These were
tion of low-level hardware and sensors and integration of not in the scope of security concepts for the former
external services and on-demand functions [1]. In combina- signal-oriented E/E architectures.
tion with the rise of standardized operating systems, SOA
allows dynamic, transparent and simplified access to infor- B. SOLUTION
mation throughout the entire vehicle ecosystem. Therefore, Existing security solutions used in the signal-oriented world
if an application requires a sensor information, the informa- have to be examined for the transfer to the service-oriented
tion is provided by an internal control unit of the vehicle paradigm due to their changed communication characteris-
or over-the-air (OTA) by an Original Equipment Manufac- tics. Since signal-oriented approaches are partly based on
turer (OEM)-backend for environmental data. Furthermore, classic Information Technology (IT) measures, available IT
changes or the integration of new functions in vehicles that solutions for use in automotive SOAs should also be investi-
are already in the field are much easier, since other informa- gated. The convergence of IT networks and E/E architectures
tion or functions can be subscribed as services [6], [8]. further motivates this approach.
Furthermore, new network technologies and protocols
are used to integrate this new communication paradigm. C. CONTRIBUTION
The reliable CAN protocol [9] that has been used for We present a comprehensive overview of current standards,
decades for internal vehicle communication is increas- protocols and developments in the field of automotive SOAs
ingly being replaced by automotive Ethernet technology and E/E architectures. In particular, we sketch the newly
in order to meet the changing requirements with respect emerging challenges for the security of SOAs. Furthermore,
to data rate, interoperability and information security [2]. we explain various security measures (firewalls, access con-
On higher layers 5-7 of the ISO/OSI model [10] proto- trols, IDSs) in general as well as approaches published
cols like Scalable service-Oriented MiddlewarE over IP specifically for vehicles. In our discussion, we analyze the
(SOME/IP) or Data Distribution Service (DDS) are used, applicability of existing approaches from the automotive
which are specified in the AUTomotive Open System ARchi- sector and IT for SOAs. For this purpose we elaborate the
tecture (AUTOSAR) Adaptive standard [11]. While some of deployment of the different security measures for an exem-
these technologies are specific to the automotive industry, plary hybrid E/E architecture, which integrates the signal-
together with generic computing platforms based on stan- and service-oriented world. Finally, we identified necessary
dardized operating systems, there is a general trend in the research directions for future work to pave the way for a better
evolution of E/E architecture towards ordinary IT network security of SOAs.
architectures [12]. This work is structured as follows (s. also fig-
With the higher degree of connectivity as well as the ure 1): In section II, we explain principles of signal-
growing number of vehicle services [4], information secu- and service-oriented communication in E/E architectures.
rity requirements are also increasing significantly. Secu- In section III, we provide information about existing auto-
rity will become more and more a quality factor of motive protocols, vulnerabilities as well as attacks regard-
vehicles [13]. Attacks on previous vehicle architectures ing SOA security and outline deviations to classical IT.
(signal-oriented communication, mainly based on CAN pro- Furthermore, section IV presents various countermeasures
tocol) have been demonstrated in recent years by various and classifies research approaches published for automotive
publications [14]–[16]. networks. Section V includes an investigation and discussion
As a result, the subject of automotive security has gained a concerning the applicability of existing security approaches
major focus within academic facilities, industry and standard- in automotive SOAs. Finally, we summarize our work in
ization committees. On the one hand, this has led to various section VI and outline possible research topics for future work
approaches from academia for countermeasures to protect (s. section VII).
against vehicle attacks [17], [18]. On the other hand, various
standards and guidelines such as SAE J3061 [19], ISO/SAE II. SERVICE-ORIENTED AND HYBRID E/E
21434 [20] or AUTOSAR Secure Onboard Communication ARCHITECTURES
(SecOC) [21] were specified. The increased integration of service-orientation in the
E/E architecture creates new challenges for the cyber security
A. PROBLEM of vehicles. To evaluate the transferability of existing counter-
The change from signal-oriented to service-oriented com- measures, it is necessary to clarify the differences between the
munication in vehicle architectures leads to a fundamen- paradigms of signal-oriented and service-oriented communi-
tal paradigm shift. Since communication design is no cation. These differences manifest in terms of architecture
longer exclusively statically specified, previous security mea- in general, the runtime stacks used and the communication
sures cannot be directly adopted in SOAs. Dynamicity in protocols.

VOLUME 8, 2020 221853

 M. Rumez et al.: Overview of Automotive SOAs and Implications for Security Countermeasures

today for the signal-oriented paradigm, whereas Ethernet is

mainly used for service-oriented communication.
1) CAN
CAN is a serial multi-master bus that supports different data
rates with a maximum of 1 MBit s (High-speed CAN) and
with CAN with Flexible Data Rate (CAN-FD) [28] up to
about 8 MBit
s , depending on the physical transceiver. Modern
in-vehicle networks consist of multiple CAN buses, that are
interconnected via gateways and a backbone network, if nec-
essary [25]. Each message contains a unique Identifier (ID)
that defines the priority of a message. A message’s payload
is broken down into different signals of arbitrary length,
however the sequence of signals in a message with a specific
identifier is specified in the course of vehicle development.
On a specific CAN bus, a message with a specific ID is sent
by no more than one ECU. All ECUs in the vehicle network
can subscribe to any message ID. However, a gateway may
be needed to route the messages, if sending and receiving
ECU are attached to different buses. CAN messages are sent
cyclically, which is mostly used to realize control and feed-
back loops with multiple ECUs or event-based, usually for
interaction with the user (e.g., activation of the turn indicator,
window regulator). Finally, the transmission of a specific ID
can also be requested by another bus participant.
2) AUTOMOTIVE ETHERNET
Autonomous driving and connectivity increase the need
for bandwidth [1]. In addition to diagnostics and flash-
FIGURE 1. Structure of the research article.
ing of ECUs, Ethernet is therefore increasingly used for
communication within the vehicle. In modern Ethernet net-
A. E/E ARCHITECTURE works, each participant communicates only with its con-
The distributed system of ECUs communicates via different nected switch, which establishes collision-free point-to-point
bus systems. Together, the network of interconnected bus connections between all connected devices. Special physical
systems, ECUs and software running on them forms the layers are required for the vehicle to meet environmental
E/E architecture. The most relevant bus system technolo- requirements such as freedom from interference. With the
gies are CAN, Local Interconnect Network (LIN), FlexRay, 100BASE-T1 standard [29] (formerly known as BroadR-
Media Oriented Systems Transport (MOST) and Automo- Reach standard) data rates of 100 MBit s are possible, with
tive Ethernet. In current vehicles, multiple instances of any 1000BASE-T1 even 1 GBit s [30]. Further increases in data
of these technologies can be used. To give an example, rates above 1 MBit
s were recently published [31]. To bridge
the E/E architecture of a 2019 Audi A8 consists of seven CAN the gap of data rates between CAN-FD and the 100BASE-
buses, one MOST bus and one FlexRay [23]. For diagnos- T1 standard but still maintaining the low costs of CAN,
tic purposes, an additional CAN bus and an Ethernet port the 10BASE-T1S physical layer was specified [32], [33].
are included. Besides, various LIN and proprietary systems This can be a viable alternative to CAN for low-cost and
are part of the architecture. LIN is especially used as very hard-realtime requirements in the future. As an extension
low-cost option for connecting to simple devices such as seat of the IEEE 802.1Q standard [34], Ethernet Time Sensitive
control. However, in this work we want to focus on future Networking (TSN) has been introduced to the automotive
architectures that will develop due to the main drivers for domain to achieve higher real-time capability. Additionally,
innovation in automotive industry such as automated driving the IEEE 802.1Q standard specifies so-called tagged Virtual
and connectivity [24]. While today CAN is the dominant Local Area Networks (VLANs), that allow for logical sepa-
system, the diversity of bus systems will decrease in the ration of sub-networks.
future and Ethernet will take over the leading role in the vehi- Above the automotive-specific physical layer, the IT stan-
cle [25]. CAN will possibly still be used as a cost-effective dard protocol stack TCP/IP (Internet Protocol (IP), Trans-
alternative for low data rates and high reliability. The hybrid mission Control Protocol (TCP), User Datagram Protocol
and hierarchical nature of future architectures, consisting of (UDP)) is used. Furthermore, automotive-specific protocols
both Ethernet and conventional bus systems is shared among such as Diagnostics over IP (DoIP) and SOME/IP were
different researchers [6], [25]–[27]. In general CAN is used introduced.

221854 VOLUME 8, 2020

M. Rumez et al.: Overview of Automotive SOAs and Implications for Security Countermeasures

TABLE 1. Comparison of AUTOSAR Classic and Adaptive platform. (adapted from [22].)

3) RUNTIME PLATFORMS connectivity leads to centralization and stronger computing

More and more the software architecture of ECUs is based platforms [1], [7]. For example, a central computing cluster
on different operating systems and standardized runtime is introduced that runs AUTOSAR Adaptive. The Adaptive
stacks [5]. For example, the average annual growth rate platforms may consist of multiple processors and ECUs that
of development efforts for operating systems and middle- are networked via switched Ethernet. The physical separa-
ware is expected to be as high as the growth rate of tion of functional domains (chassis, Advanced Driver Assis-
development effort for automated driving functions [2]. The tance Systems (ADAS), infotainment, body) still exists in
most important ones are the two platforms specified by our example, but for hierarchical Ethernet networks, this
the AUTOSAR foundation, namely AUTOSAR Classic and separation can also be a virtual separation using a different
AUTOSAR Adaptive [7], [11], [22]. The Classic Platform VLAN tag for each domain. The chassis and ADAS related
is suitable for highest real-time requirements, whereas the functions are connected in a hierarchical Ethernet topology to
Adaptive Platform makes use of stronger computing power the central unit. Since the functions must fulfill strict safety
and was designed to introduce the SOA paradigm to auto- and timing requirements, these platforms run AUTOSAR
motive industry. The current standard to which this article Classic. For control functions with strong needs on reliability
refers is Release 19-11. Between 2013 and 2016, the number and low cycle times, CAN may be used to connect the ECUs
of ECUs with AUTOSAR increased from about 50 million to the switched Ethernet network. In our example, besides
to almost 300 million [35]. Besides AUTOSAR, different the central cluster also the I/O cluster and the connectivity
platforms for infotainment domain exist, e.g., GENIVI,1 control gateway are AUTOSAR Adaptive platforms. External
QNX2 [5], [36]. We focus on AUTOSAR-based ECUs, since communication is handled for smart charging, diagnostics
these fulfill most of the safety-critical functions. A successful and wireless connectivity through the connectivity control.
attack on safety-critical functions (e.g., control steering [14]) In our example (s. figure 2), the AUTOSAR Classic platforms
can cause major harm to the vehicles passengers and their in the infotainment and body domain are connected via CAN
surrounding. Thus, security for these platforms is also of great or LIN to the I/O cluster because infotainment and body
importance. Table 1 sums up the major differences. From the functions are mostly user I/O driven with low data rates.
comparison, it can be seen that AUTOSAR Adaptive is far Hence, the cheaper CAN / LIN is preferred to Ethernet.
more dynamic than the Classic Platform. Applications are Summing up, figure 2 outlines a hybrid architec-
dynamically scheduled and installed. Furthermore, the Adap- ture of AUTOSAR Classic driven ECUs, that commu-
tive Platform relies on a subset of the standard POSIX inter- nicate mostly in signal-oriented paradigm via CAN and
face for embedded real-time systems. Thus, the interface for the Adaptive platforms that form a SOA using Ether-
all applications and software components to the machines net. Furthermore, the architecture contains high-performance
operating system is standardized. In addition, the paradigms POSIX-based computing clusters as well as low-performance
for communication of the applications via a network differ microcontrollers.
between the Adaptive Platform and the Classic Platform.
Although the Classic Platform specifies the use of SOME/IP, B. RELEVANT PROTOCOLS AND MIDDLEWARE
it does not support the SOA paradigm. Instead only a trans- For automotive SOA, different protocols and middleware
lation from signal-oriented CAN communication to Ethernet approaches are relevant. Most important are SOME/IP and
is implemented, that defines a static mapping of signals to a DDS, since they are standardized in AUTOSAR and hence
specific service. available as first-class solution to the industry. Furthermore,
an approach from research for bringing SOA to CAN is
4) EXEMPLARY FUTURE ARCHITECTURE outlined.
In figure 2, an exemplary E/E architecture of a future vehi-
cle is shown. The trend towards autonomous driving and 1) COMMUNICATION PATTERNS
In signal-oriented and service-oriented communication, dif-
1 GENIVI Alliance, https://www.genivi.org/ ferent communication patterns are relevant. The typical con-
2 BlackBerry Limited, https://blackberry.qnx.com/ trol flow of the patterns is shown in figure 3. Figures 3a to 3c

VOLUME 8, 2020 221855

 M. Rumez et al.: Overview of Automotive SOAs and Implications for Security Countermeasures

FIGURE 2. Exemplary hybrid E/E architecture based on AUTOSAR Classic & Adaptive. ECU colors indicate the
respective bus systems they are attached to. (adapted from [7].)

FIGURE 3. Overview of communication patterns in automotive architectures.

show the typical patterns of a SOA. The publish-subscribe configuration occurs fully static at design-time. It is specified,
pattern, the Remote Procedure Call (RPC) as well as the which ECU is allowed to send payload by using a static mes-
fire-forget pattern are driven by the clients. Thus, data is only sage ID. In addition, also the subscribers are assigned to IDs
transmitted to the clients if it is necessary. In comparison, at design-time. In comparison, the SOA paradigm allows for
3d shows the signal-oriented communication, where the data configuration at startup or run-time. When the subscription to
is published as broadcast disregarding if any subscriber is a service is specified at design-time, the communication path
present. However, the subscription to the publisher has to be is instantiated at startup by just subscribing to the well-known
made statically. server(s) that provides the service. For runtime configura-
Therefore the main difference between the communication tion, a method to discover services and subscribe to them
patterns of SOA and signal orientation is the time when is required. Figure 3e and 3f show two options for service
the communication path is configured (time, when client is discovery. It can be either registry-based, where a dedicated
able to exchange data with the server). Generally, commu- registry server handles the offering and finding of services,
nication paths can be configured at design-time, at startup or registry-less, where the discovery protocol enables servers
of the vehicle or at run-time. In signal-orientation, the and clients to discover each other.

221856 VOLUME 8, 2020

M. Rumez et al.: Overview of Automotive SOAs and Implications for Security Countermeasures

2) SCALABLE SERVICE-ORIENTED MIDDLEWARE OVER IP Transport: SOME/IP uses the TCP/IP or UDP/IP stack
(SOME/IP) for the transmission. To enable data exchange between
The specification of SOME/IP is not only a communica- AUTOSAR Adaptive and Classic (Inter-Platform Communi-
tion protocol but rather a middleware and standardized in cation), SOME/IP is specified for both platforms. This allows
AUTOSAR. The middleware simultaneously creates a certain a Classic ECU, which is additionally connected to legacy
degree of abstraction between the application and the net- bus systems such as CAN, to act as a gateway. Signals are
work. For example, it is not necessary for an application to converted into a service in order to be able to offer it for
know which ECU provides a desired function. If the func- Adaptive ECUs. In case the Classic control unit does not pro-
tion is integrated on the same ECU, a local connection is vide SOME/IP communication, signal-to-service conversion
established between the software components. If the function is only feasible on an Adaptive ECU.
is located on another ECU, the middleware establishes a
corresponding network link between two applications. 3) DATA DISTRIBUTION SERVICE (DDS)
Communication Principles: The SOME/IP specification Another middleware that is recently used in automotive
defines three basic types for the communication between industry is DDS [37] which is standardized by the Object
clients and servers. Services in SOME/IP consist of events, Management Group (OMG) and used across many indus-
fields and methods. tries. DDS is a data centric middleware based on the
publish-subscribe pattern to control the flow of data between
• Events: Event-based communication in SOME/IP pro- different nodes. Since Release 18-10 of the AUTOSAR Adap-
vides a way for clients to subscribe required information tive Platform published in November 2018, the DDS standard
from a provider. The provider is able to transmit the is implemented for automotive industry [11]. AUTOSAR
information to the clients at a specified time interval or includes only a subset of the various DDS standard parts.3
if a value has been changed. In addition, various event Communication Principles: The Data-Centric Publish-
groups can be created which contain different fields for Subscribe (DCPS) interface of DDS organizes the data flow
subscribed clients. in DDS based communication. The information that is pro-
• Fields: Services allow the definition of fields which duced is published as samples in different topics that are
can be read or modified by clients using get- and set- identified by a unique name. A DDS communication consists
methods. In addition, they include the same notification of one or more domains, that contain the various topics.
concept of Events. However, the usage between Fields The domains are separated of each other, therefore no data
and Events is different, because fields are intended for exchange between different domains is possible. One essen-
status-like properties that refer to a history, whereas tial element of DDS is content and data rate filtering of the
events shall be used for information that is only valid published data for the subscriber of a topic. Hence, only data
for a short time. of interest is published to a topic and transmitted via the
• Methods: In addition, RPC are available. These allow a middleware. For example, only samples with a value > 300
client to execute a method provided by the server. There and a message rate of five messages per second. The topics
are two different variants. With the first variant, a return form a logical global data space defining the data model. Each
value is transmitted by the provider. With the fire-forget topic is associated with a type, hence the middleware is able
option, the client does not receive a return value on call- to manipulate the data correctly and perform type checking.
ing. Therefore this variant is mainly suitable for control The OMG specified also a remote procedure call stan-
commands. dard via DDS to enable the use of a request-reply pat-
tern. This standard consists of a high-level abstraction on
The publish-subscribe pattern is implemented by fields and top of DDS that re-uses the substantial parts of DDS to
events. With the standard methods and get/set field methods, define requesters as clients and repliers as services. In this
the request-response pattern is included. Finally, the fire & case, every request-reply connection consists of two topics,
forget pattern can be fulfilled by SOME/IP methods using the a request topic and a reply topic. AUTOSAR Adaptive also
respective option. provides this concept to enable the RPC pattern via DDS.
In addition, the SOME/IP Service Discovery (SOME/IP- Transport: Regarding the underlying data transport
SD) protocol allows for publication and subscription to events model, Real-time Publish-Subscribe Protocol DDS Interop-
and fields. If clients want to use certain services, these have erability Wire Protocol (DDSI-RTPS) is used. DDSI-RTPS
to be known or must be discoverable. The SOME/IP Service specifies that at least the communication via UDP/IP has to
Discovery (SOME/IP-SD) protocol provides two different be supported by every DDS implementation, however most
mechanisms to find or announce services, which are exe- vendors also provide a TCP implementation and also shared
cuted during system startup. With offerService a provider can memory access is possible. The use of further transport pro-
announce his offered services as broadcast in the network. tocols is possible as long as the notion of specific unicast
On the other hand, findService allows clients to find certain addresses and ports is supported and incomplete or erroneous
services that may not have been announced. SOME/IP-SD is
registry-based. 3 14 DDS standards in May 2020.

VOLUME 8, 2020 221857

 M. Rumez et al.: Overview of Automotive SOAs and Implications for Security Countermeasures

TABLE 2. Comparison of relevant protocols and middleware for automotive SOA.

messages are identified. In AUTOSAR, the DDS specifica- Service IDs are invoked during discovery and the servers
tion allows the use of both UDP and TCP. are unknown at first. In contrast, SOME/IP is server-based
because a client must subscribe to events from a specific
4) EMBEDDED SERVICE-ORIENTED COMMUNICATION
server. In addition SOME/IP requires a system-wide map-
(eSOC)
ping of services to specific ports on UDP/TCP and specified
service IDs during design time. However, AUTOSAR also
The embedded Service-Oriented Communication protocol
allows for a design- or startup time configuration of the
outlined by Wagner et al. [38] introduces service-oriented
communication path for DDS and SOME/IP, if the discovery
communication based on the CAN protocol. They specify
protocols are not used.
a 64 Bit service descriptor and a shorter 29 Bit identifer to
implement a SOA, that maintains the priority principles of
III. SOA SECURITY
CAN and enables a simple integration with SOME/IP. The
With the introduction of SOA in vehicle networks, new chal-
short identifier fits into the standard CAN identifier, hence no
lenges arise with regard to existing security measures. On the
overhead is introduced by means of eSOC during operation.
one hand, this can be attributed to the new protocol diversity,
During startup of an eSOC communication, the 64 Bit ser-
on the other hand, the communication paths are no longer
vice descriptor is used for service initialization via a register
statically defined. In the following sections we will describe
server. The register server is not working as broker for the
these issues in more detail.
communication, it only assigns the shortened identifier to the
service provider. The eSOC protocol supports publish / sub- A. PROTOCOLS
scribe and request / response as the two basic communication
Previous communication protocols such as CAN were based
principles. With the first one, information is sent event-based
exclusively on OSI layer 1 & 2 (exception: diagnostic proto-
or with a specific frequency from the server to the client.
cols). In table 3, we classified common automotive network
Using the second principle, methods can be called remotely
protocols based on the ISO/OSI model. By using automotive
and data can be exchanged as one-time transmission. An addi-
Ethernet on layers 1 & 2, conventional protocols from Classic
tional find/offer pattern allows for service discovery between
IT are used on layers 3 & 4 such as TCP/IP. In addition to
the requesting and providing ECUs.
benefits such as better interoperability or higher bandwidths,
this development brings new risks with regard to information
C. COMPARISON security. Over the past few years, numerous hacker tools
The main differences between the relevant protocols are have been developed in the IT world to simplify the use of
summarized in table 2. For comparison, the traditional such techniques [39]–[41]. The amount of different protocols
signal-oriented approach is also included here. The CAN used on Ethernet increases the complexity of networking and
standard also specifies a request frame. However, this is packet handling and induces higher risks of protocol design
typically not used to implement a request-response pattern and implementation flaws. Hence, new vulnerabilities of the
in the traditional signal-oriented approach. The main differ- protocol stack may be uncovered in the future [41]. Fur-
ences manifest in the discovery of services if the discovery thermore, for protecting the information asset confidential-
protocols of SOME/IP and DDS are used. DDS is the most ity, the protocols provide the feature to encrypt header- and
dynamic, i.e. a subscriber only subscribes to a specific topic, payload data on different OSI layers. Thus, when integrating
which means that no static link to a server is established. security measures, it has to be taken into account that certain

221858 VOLUME 8, 2020

M. Rumez et al.: Overview of Automotive SOAs and Implications for Security Countermeasures

TABLE 3. Common automotive protocols within the ISO/OSI model. (Diagnostics specific protocols are italicized.)

information may not be available on every network node C. VULNERABILITIES

throughout the whole network path. Since integration of SOA technology in vehicle architec-
The security measures already included in the SOA pro- tures is still in its infancy (e.g., Volkswagen MEB [44]),
tocols and signal-oriented communication are outlined in no attacks of this kind are known at the time of this arti-
table 2. For message authentication and freshness of mes- cle. However, appropriate security analyses can already be
sages in signal-oriented communication, the AUTOSAR performed for upcoming protocols and possible architec-
Classic standard introduced SecOC [21]. A message authen- ture designs. A detailed article on SOME/IP presented by
tication code as well as a freshness value are attached to the Kreissl [45] included a threat analysis and risk assessment
payload of a message to prevent different attacks such as as well as suggestions for appropriate countermeasures for
replay and spoofing. For the the message authentication code, 18 identified threats. Furthermore, the SOME/IP-TP proto-
a symmetric key is required. However, SecOC is a lightweight col amendment (SOME/IP-Transport Protocol Segmentation
protocol for low-cost embedded devices and does not allow over UDP) was shown to be vulnerable for selective Denial-
for encryption of the payload data on CAN. As SOME/IP and of-Service attacks [46]. An early work analyzed the vulner-
DDS are included in AUTOSAR, they can rely on transport abilities of the diagnostic protocol DoIP [47] and found it
layer protocols for security that are specified in AUTOSAR. to be vulnerable in various ways such as spoofing, denial-
AUTOSAR Adaptive specifies the following concepts: of-service, or fingerprinting via OEM-specific fields in the
• DTLS for secure communication over UDP protocol. As outlined in section III-A, with standard pro-
• TLS for secure communication over TCP tocols and operating systems, common vulnerabilities are
• IPSec for secure communication over IP introduced. One example is the well-known buffer overflow
However, SOME/IP does not provide any additional mea- vulnerability caused by IP fragmentation, which may also
sures for security. One approach to address this issue was be found in an AUTOSAR implementation [46]. Another
presented by the researchers Iorio et al. [42], who provide example is the possibility to use ARP cache poisoning, if the
a security framework for Ethernet-based SOME/IP commu- ARP table is not statically defined [48].
nication. In contrast, DDS includes an additional standard for Besides the outlined threat analysis results we have to keep
security [43]. With the additional DDS security measures, in mind, that with the SOA also AUTOSAR Adaptive is intro-
access control, authentication, encryption and tagging of data duced to the automotive domain as runtime platform. With the
(e.g., ‘confidential’) is provided. The access control mecha- standardized POSIX kernel and common operating systems,
nism enables the developer to separately grant read and write also the vulnerabilities of the kernel and operating system
permissions to DDS Domains and Topics. are common to all vehicles running the specific AUTOSAR
Adaptive Platform implementation [41]. Hence, any possible
B. NETWORK PATHS vulnerability of the runtime platform has a larger impact to
In comparison to signal-oriented communication, the net- industry than with OEM-specific runtime platforms.
work paths are only defined at system runtime or startup.
As a result, the ability to extract static characteristics (e.g., D. AUTOMOTIVE ATTACKS
cycle times, routing tables) from the communication matrix In order to secure future vehicle architectures, it is essen-
specified in development is only partially feasible. For this tial to investigate already known attacks regarding their
reason, corresponding impacts on the design of security mea- exploited vulnerabilities. The researchers Sommer et al. [49]
sures such as IDSs or firewalls have to be investigated (for a published a taxonomy for automotive attacks as well as a
detailed analysis, s. section IV). As a result, securing the vehi- database containing 162 published attacks [50]. The tax-
cle also involves these systems such as OEM back ends or the onomy contains 23 different categories and multiple lay-
infrastructure. Furthermore, it has also to be considered that ers of abstraction such as a short description of the attack,
the system boundary (vehicle) is extended by externally used violated security properties or an explanation of exploited
OTA services. As a result, securing the vehicle also includes vulnerabilities. Since attacks of vehicles usually consist of
these systems such as OEM-backend or infrastructure. several attack steps, the database also provides an extended

VOLUME 8, 2020 221859

 M. Rumez et al.: Overview of Automotive SOAs and Implications for Security Countermeasures

version, which contains 413 sub-steps of captured attacks. system platforms (e.g., AUTOSAR Classic and Adaptive)
Based on this information, detailed attack analyses [51] can require tailor-made solutions. Where common IT technology
be performed. Besides academic institutions, there are also is used (e.g. infotainment systems), common IT security
commercial repositories for automotive incidents provided measures may also be sufficient. However, with increasingly
by industry [52], [53]. The datasets of these repositories not centralized E/E architectures, a clear separation between
only focus exclusively on attacks in vehicles but also include safety-critical or automotive-specific systems and generic IT
known vulnerabilities in backends or vehicle apps. components is not always possible.
Furthermore, the United Nations Economic Commission
for Europe (UNECE) WP.29 Working Party on Automated IV. COUNTERMEASURES
and Connected Vehicles (GRVA) [54] is expected to come The protection of IT networks and automotive archi-
into force in 2021, which will be the first regulation concern- tectures should generally follow the defense-in-depth
ing information security in vehicles. The regulation will be principle [61]–[63]. This approach is based on the integration
mandatory for all OEMs of the associated member states for of different protection layers to minimize the risk of a suc-
International Whole Vehicle Type Approval (IWVTA) [55] cessful attack. Therefore, an attacker has to overcome several
of new vehicles. In addition, a list of high-level threats and protection mechanisms to intrude into the system completely.
vulnerabilities as well as a mapping to real attack methods In this article, we focus on countermeasures of firewalls, IDSs
based on vehicle systems is included. as well as IAM and examine below their applicability for
Vehicles with a mature SOA or hybrid architecture are service-oriented architectures.
currently not very often found on the roads. Accordingly,
no attacks focusing specifically on SOA have yet become A. FIREWALLS
public. Nevertheless, due to known vulnerabilities of SOA Firewalls are part of the access control group and used in
technologies (see Section III-C) and successfully performed IT as an integral part to implement previously defined secu-
attacks on previous vehicle architectures, future SOAs will rity strategies in the form of access restrictions [61], [64].
most likely be exploited and attacked. Especially due to the According to RFC 4949 [65], a firewall represents a gate-
increasing spread of SOA technology, the exploitation of way that allows data traffic between two different networks
vulnerabilities is only a matter of time. (e.g., the internet and internal company network) to protect
resources against threats from other networks. Over the last
E. COMPARISON TO IT SECURITY decades different types of firewall systems have been estab-
Although there is a trend in in-vehicle networks towards lished, which are divided into different classes (packet filter,
common IT networks in terms of physical (i.e. Ethernet) net- proxy and application-level) [66] and shown in table 4. These
working, there are still major differences that need to be taken filtering types can be used in different architectures and are
into account in automotive security measures [12]. These often integrated as a combination of them.
specific requirements are not new to SOA but are generic Classic firewall packet filters are based on OSI layers
to automotive security. However, the gained dynamics and three and four (network and transport layer). This allows the
flexibility of the networking of a SOA comes at the expense integration of filter tables based on protocol information of
of the static predefinition of the network traffic. This was these layers to enforce predefined access control policies.
one of the advantages of automotive networks in terms of An extension of the static packet filters are dynamic ones.
security compared to IT networks, because static behavior These are able to store already analyzed packet information
allows simple rule-based control [56]. in order to consider them in subsequent filter decisions [64].
In general, security for conventional IT networks does not This type of filter is also called stateful filter, because access
have to worry about safety-critical systems, while failing decisions depend on past behavior.
automotive security is responsible for physical damage in the Proxy firewalls, which also work on the transport level
worst case. For example, taking over the steering or power- of the ISO/OSI model, represent a further development. The
train functionality can have a direct physical impact, which firewall works as a broker between two networks and pro-
is why particularly high security precautions must be taken vides only a certain amount of services that a client can
here. Closely related to this are the requirements for determin- access, for example, from a network to another. This allows
ism and real-time of the security measures [57]. For example, defining the amount of services in the firewall for each client.
a firewall that erroneously blocks a brake command by a false Compared to packet filters, special context information can
alarm or delays it too much by a slow analysis are not suitable be included in the rules [61]. It is also possible to limit the
for use in a vehicle. Another difference between IT security number of simultaneous links and throughput rates to avoid
and vehicle security is the user interaction. While in IT every Denial of Service (DoS) attacks.
user can be confronted with security measures on his personal The application filters (application firewall) are specified
device, automotive security must run completely automati- on the top level of the ISO/OSI model (application layer).
cally in the background. In contrast to IT, a user reaction while This type extends the filtering capabilities of the proxy fire-
driving is not possible here. Finally, the automotive-specific wall through precise information about the applications used.
protocols and technologies (e.g., CAN, DoIP, SOME/IP) and Therefore these filters are able to analyze application-specific

221860 VOLUME 8, 2020

M. Rumez et al.: Overview of Automotive SOAs and Implications for Security Countermeasures

TABLE 4. Overview about established firewall types.

TABLE 5. Classification of reviewed automotive Firewalls.

TABLE 6. Classification of reviewed automotive IDS (adapted from [17]).

user data (Deep Packet Inspection (DPI)), because for each and stateful packet inspection were software-based. Their
application a dedicated proxy within the firewall is pro- evaluation contains investigations on end-to-end latency and
vided [67]. Furthermore, an authentication between the jitter, throughput, memory consumption and CPU load. Fur-
user (client) and the proxy can be established to make spoof- thermore, the authors consider it possible to extend the
ing attacks more difficult [61]. Depending on the imple- approach for filtering DoIP or SOME/IP protocols on appli-
mentation variant, these firewall types are also capable of cation level.
performing certain IDS features. Another gateway firewall design presented by Holle and
Shukla [59] for an automotive Ethernet switch includes
1) AUTOMOTIVE FIREWALLS packet and application filter. However, the authors do not
In recent years, the firewall technology of traditional IT has explain the precise details about these filtering techniques.
also become interesting for the automotive domain. A clas- In addition, they provide an overview of future Ethernet archi-
sification of the following reviewed approaches is shown tectures and illustrate the necessity for integrating firewalls.
in table 5. In 2014, Seifert and Obermaisser [18] presented The researchers Luo and Hou [60] performed a risk anal-
a gateway firewall for time- and event-triggered as well as ysis for potential attacks by using an attack tree. For this
stream communication. The authors used a hierarchical timed purpose they analyzed different attack vectors (e.g., sensors,
automata to describe the different communication behaviors. ECUs, interfaces) and calculated the probabilities of exposure
For example, they defined an interarrival time with min and based on the identified attack paths. Based on this, they
max thresholds for event-triggered communication in CAN derived a security concept for a gateway firewall including
networks or dynamic parts of FlexRay to detect deviations stateful packet filter and IDS features by using information
of them. They also explained that the presented approach entropy techniques. They also point out the limitation that
explicitly works for a statically defined communication. traditional embedded real-time operating systems do not sup-
Another firewall approach was published by port any kind of access control and integrate a Discretionary
Pesé et al. [58], who considered both software and hard- Access Control (DAC) on their used FreeRTOS.
ware aspects as well as specific automotive requirements.
For the detection of attacks they used three different filter B. INTRUSION DETECTION SYSTEMS
types. A classic packet filter was implemented on a Field Compared to firewalls or encryption methods, which are
Programmable Gate Array (FPGA), whereas the rate-limiting defined as proactive measures, IDSs are assigned to reactive

VOLUME 8, 2020 221861

 M. Rumez et al.: Overview of Automotive SOAs and Implications for Security Countermeasures

protection measures [17], [61], since IDSs detect possible intrusion detection. Vehicles differ from classic IT by the
attacks only when they occur. In contrast, pro-active measures fact that they consist of a composition of sensors, process-
are intended to preventively minimize the potential attack ing logic and actuators. In addition, they have interfaces to
surface of the system. For detection of attacks, IDSs analyze external systems (e.g., OEM backend). Therefore, vehicles
data traffic in networks, evaluate system log files or examine can be defined as a Cyber-Physical System (CPS). Compared
user behavior. A basic distinction is made between host-based to IT, besides cyber features, which there are also physical
and network-based, depending on their location [61], [66]. features for detection. Cyber features include protocol and
Host-based IDS (HIDS) are used exclusively on workstations communication properties (e.g., cycle time, message length)
or servers to detect anomalies within this system bound- [68], [69]. In contrast, physical features (e.g., speed, location,
ary. An anomaly could be an attempt by an user to modify signal courses) can be used to determine the current vehicle
system-critical files or generally to bring the system into a state [70], [71]. According to the review of 42 IDS publica-
risky state. tions in [17], 81% used cyber features, 5% physical and 10% a
In addition, network-based IDS (NIDS) analyze the data mixture of both. However, there are further approaches based
streams within networks by creating a copy of all packets on physical features which use physical characteristics (e.g.,
in order to check these with regard to protocol deviations or voltage courses of transmitted bits, characteristic impedance)
malicious user data. The detection techniques of both systems of sender/receiver and transmission channel [72], [73].
can be divided into two different types. Signature-based Furthermore, Grimm et al. [12] provide a classification
techniques are based on features extracted from already for security monitoring within the automotive domain by
known attacks and regularly updated. However, this implies defining three aspects (vantage, operational area, action).
the limitation that only very similar attacks can be detected. Each aspect includes different categories such as external
In contrast, new types of attacks remain partially undetected. communication or sub-network root. Each category is then
On the other hand, anomaly-based methods detect devia- assigned to automotive network representatives (e.g., cen-
tions in relation to predefined features that are extracted tral gateway, backbone network, network switch ECU on
from a normal behavior. Statistical, protocol-specific, Ethernet). In addition, they also outline that IDS research
rule-based and heuristic techniques are often used for this today is focused on the signal-oriented communication, and
purpose [61]. only few works tackle intrusion detection for Ethernet and
SOA.
1) AUTOMOTIVE IDS
In addition to traditional IT, there is also an increasing C. IDENTITY- AND ACCESS MANAGEMENT (IAM)
research effort on IDS approaches for vehicles to detect An access control can generally be defined as automated
attacks at an early stage as well as to support pro-active prevention of unauthorized access from subjects to resources.
countermeasures such as firewalls. Due to growing dynamic Furthermore, certain rules (policies) can be specified to con-
communication parts within automotive architectures, with trol and enforce this purpose. Therefore an access control
protocols like SOME/IP, firewalls based on static filter tables ensures a rule-compliant use of resources. Over the last
are not able to ensure sufficient security [59]. Furthermore, decades of the IT century, various access control models for
the already mentioned UNECE WP.29 specifically calls for authorization have been developed or extended accordingly.
the integration of in-vehicle IDS. An overview of such The models control which subject (e.g., user or service) in a
approaches for the automotive domain described below is system is authorized to access a specific resource/object (e.g.,
shown in table 6. file, service). The access can be granted on different autho-
An early work by Müter et al. [56] introduced eight dif- rization levels (read, write, execute), which are defined by
ferent anomaly detection sensors (e.g., formality, location, access policies for each subject or resource. In the following,
plausibility of messages) to identify intrusions on the CAN the four most significant access control models are presented
bus. Especially, they compared the applicability of the sen- in a chronological order.
sors with respect to six different criteria, e.g., if the sensor
can be developed only based on the vehicles specification 1) DISCRETIONARY ACCESS CONTROL (DAC)
or if messages of different bus systems need to be consid- In the DAC, the owner is exclusively responsible for assigning
ered for detection. In recent years, various features have permissions to a resource [67]. For example, in a company
been developed which allow the detection of anomalies. this instance could be a head of department who owns a lot
A comprehensive survey for intra-vehicle IDS approaches of data. In order to assign and manage the permissions of
was published by Al-Jarrah et al. [17] in 2019. According each subject, an Access Control List (ACL) is mapped to each
to their detailed analysis, three main categories were identi- resource, which defines the access rights [61].
fied for classification the works (flow-based, payload-based,
hybrid). For each main category, seven characteristics (tech- 2) MANDATORY ACCESS CONTROL (MAC)
nique, features, dataset, attack type, performance metrics and The Mandatory Access Control (MAC) provides an access
benchmark models) were defined to allow comparability. The model for strictly controlling and enforcing permissions.
authors also analyzed in more detail the features used for Compared to DAC, permissions on resources are not mapped

221862 VOLUME 8, 2020

M. Rumez et al.: Overview of Automotive SOAs and Implications for Security Countermeasures

to subjects, but rather security labels are assigned [61]. 5) ACCESS CONTROL TECHNIQUES
The labels may contain different levels of security (public, For access control models already mentioned, there are basi-
confidential, secret or top secret). At the same time, these cally two different techniques for mapping access permis-
labels are also assigned to the participating subjects of an sions to subjects and objects. Both variants can be specified
organization. If a subject wants to access a resource, a central using an access control matrix (s. table 7) [61]. This type is
instance checks whether both have the appropriate label or usually used with the DAC model. The permissions can be
security level. mapped either to the capabilities or to the objects (ACL).

3) ROLE-BASED ACCESS CONTROL (RBAC) a: CAPABILITY TABLE

With Role-based Access Control (RBAC), authorizations are This type of table specifies a set of permissions for a partic-
assigned as a set to specific roles. For example, the roles can ular subject [77]. In table 7, the capabilities for each subject
correspond to different departments (purchasing, shipping, are defined horizontally for the three different objects (file
board of management) of a company. This eliminates the need 1, 2, 3). A capability can be represented by different formats
to assign individual authorizations for each subject or object. (token, key or ticket). If a subject wants to access an object,
The control and enforcement of RBAC is done centrally on a the underlying system or application checks whether the
system or network. If a new employee is hired, he or she only permissions within the transferred capability are sufficient for
has to be assigned to one role and thus receives the stored set the requested action.
of authorizations. In addition, this reduces the administrative
effort of the responsible IT staff member, since changes can b: ACCESS CONTROL LIST
be made at a central location [61].
This lists are mostly used within operating systems, appli-
cations or network devices (e.g., switches, routers). These
4) ATTRIBUTE-BASED ACCESS CONTROL (ABAC) include entries of different subjects who are authorized to
The basic idea of the Attribute-based Access Control (ABAC) access a certain object with defined permissions [61]. Fur-
approach is to allow or deny access to resources of service thermore, ACLs are also used in RBAC to assign permissions
users via attributes [74], [75]. A distinction is made between for objects to specific roles.
the following attributes:
• User attributes: Describe the service user in more detail 6) AUTOMOTIVE IAM
(e.g., age, department, title). Until the introduction of AUTOSAR Adaptive 18-03 in
• Action attributes: Describe the action performed on the 2018 [78], a comprehensive IAM for vehicular embedded
resource (e.g., read, write, delete). systems was missing, with the exception of diagnostic appli-
• Resource attributes: Describe the object that is accessed, cations. For this kind of functions a lightweight access control
e.g., bank account, document. exists by using the Security Access service [79]. This service
• Environment attributes: Attributes that relate to time, provides an authentication and authorization procedure for
place or dynamic aspects of the access control scenario diagnostic applications based on challenge-response princi-
deal, for example, with access permissions only to cer- ple. For initiating an extended diagnostics session, an external
tain times. diagnostics device sends a request to an in-vehicle ECU.
By applying attributes, the rigid coupling between users Thereupon, the ECU responds with a random number to
and roles as well as roles and authorizations (s. RBAC) the diagnostics device, which calculates a key by using a
designed more flexible. secret algorithm. Subsequently, the device sends this key to
To fulfill the dynamic requirements of distributed systems, the ECU, which checks the correct calculation and thus the
a dynamic access control decision is needed. For this purpose validity of the authentication. As a final step, the autho-
the user attributes are evaluated at runtime and compared with rization is performed by granting the execution of extended
a stored security policy. This enables defining permissions diagnostic services. However, this procedure has to be con-
without prior knowledge of specific subjects [74]. If a subject sidered as unsecure, since various research studies have
wants to access an object (1), the ABAC module checks already shown its weaknesses and resulting vulnerabilities
whether the access is allowed based on the policy (2) and [15], [80], [81]. Through the integration of a fine-grained
enforces the access decision (3) (allow, block) accordingly. IAM, many of the exploited vulnerabilities of vehicles would
Therefore it is no longer necessary to specify an individual have been avoided [45].
subject. The eXtensible Access Control Markup Language For these reasons, in recent years there has been increased
(XACML) standard [76] is recommended for implementa- academia research on approaches as well as specifica-
tion. Furthermore, the standard supports the integration of tion efforts for managing permissions in vehicles.The
subject and object attributes within access policies, which are approaches presented below are classified in table 8. In 2016,
the core of ABAC. The XACML architecture and associated Kim et al. [82] published an decentralized approach for an
modules define the authorization infrastructure necessary for authorization management by integrating an ABAC mod-
an ABAC model. ule into the AUTOSAR Classic Platform. The predefined

VOLUME 8, 2020 221863

 M. Rumez et al.: Overview of Automotive SOAs and Implications for Security Countermeasures

TABLE 7. Access control matrix for illustrating ACLs and capabilities (adapted from [61]).

TABLE 8. Classification of reviewed automotive IAM. each application or service (subjects) a list of access per-
missions for other resources or services (objects) can be
assigned. Thus the AUTOSAR Adaptive specification is
based on a capability-based access control. If a service wants
to access an associated object during runtime, the modules
Policy Decision Point (PDP) and Policy Enforcement Point
(PEP) are specified for controlling and enforcing the per-
missions outside of applications and services. Furthermore,
attributes consist of CAN message, ECU service, and envi- AUTOSAR Adaptive offers the possibility to use the inte-
ronment properties, which are used to create access control grated fine-grained access control of the supported DDS
lists on each network node. protocol for Domains and Topics.
Another approach regarding a policy-based secure com- An approach for the integration of a dynamic access
munication was presented by Hamad [83]. They focused on control into an automotive middleware was published by
a trustworthy creation of security policies during the entire Hugot et al. [86]. The authors first explain the previous weak-
development process with various stakeholders (OEM and nesses of automotive ECUs with regard to access manage-
Tiers). The policies include certain specifications (e.g., secu- ment. Furthermore, they specify requirements for an access
rity properties such as integrity or security protocol require- control (controls should be performed on OSI layer 5 and
ments) for provided or required services interfaces within higher, middleware should control services depending on
a software component. Furthermore, a security module was current vehicle state). As an example, the authors refer to
introduced for each ECU, which acts as a distributed proxy an Adaptive Cruise Control (ACC) which is only allowed to
firewall for in-vehicle TCP/IP communication. This allows communicate with a Transmission Control Module (TCM)
fine-grained access control of each application to the under- when switched on. The presented approach is based on a
lying network stack based on stored policy. dynamic MAC, which controls information flows between
The authors Gupta and Sandhu [84] focus their research source and destination as well as their sequences by using
on the increasing connectivity of the vehicle with its envi- a state machine. They also show the integration of their
ronment and the resulting risk for possible security vulnera- approach into the SOME/IP protocol by explaining and eval-
bilities. For this the authors first explain different vehicular uating three different methods.
Internet of Things (IoT) architectures based on clouds and
fogs. They further explain the structure of their authorization
V. DISCUSSION
frameworks including different level and types of access
control approaches (ACLs, CapBAC, ABAC) for static and In this section, we explain potential challenges and benefits
dynamic communication. In addition, they illustrate their of security measures mentioned in section IV for the inte-
approaches based on use cases such as single cloud and multi gration in SOAs. The analysis and discussion is based on
cloud scenarios. the hybrid E/E architecture and different deployment points
An overview and analysis of traditional (e.g., DAC or shown in figure 2.
MAC) as well as modern access control models (e.g.,
CapBAC, Task-Role-Based Access Control (T-RBAC), A. GENERAL RECOMMENDATIONS/REMARKS
Privacy-Aware Role-Based Access Control (P-RBAC)) with When securing networks, it can generally be noted that pre-
focus on CPS were published by Lopez and Rubio [85]. dominantly static communication (signal-oriented) is easier
The authors identify requirements for access controls based to secure than dynamic communication (service-oriented).
on an exemplary future industrial system. Furthermore, they This can be argued with the fact that static communication
analyzed the applicability of existing access controls by intro- does not change during runtime. For example, no new net-
ducing a comparison criteria such as dynamicity, scalability work nodes are added and the nodes send predefined mes-
or flexibility, which are rated with high, medium or low. sages based on a specification. For the configuration of a
With the introduction of AUTOSAR Adaptive, an IAM firewall or IDS, this means that filter rules or normal behavior
module was specified. This module enables a comprehen- can be derived directly from the specification. This paradigm
sive rights management based on services. In detail, for change based on SOAs also brings new challenges in other

221864 VOLUME 8, 2020

M. Rumez et al.: Overview of Automotive SOAs and Implications for Security Countermeasures

domains such as the traditional IT [87]. For this reason, provide signal information from legacy device (e.g., engine
we believe it is essential to examine the requirements for new speed, wheel speed) as a service to clients of the AUTOSAR
systems to determine whether dynamic communication is Adaptive platform. From the perspective of a firewall, filter-
absolutely necessary or a static specification is also feasible. ing is more challenging. In principle, any client is able to
In general, when securing a new E/E architecture, a threat subscribe services (assuming the client has necessary permis-
and risk analysis [88] should be performed first in order sions). This means that source IP addresses are not perma-
to derive appropriate security measures. However, in this nently static and predictable during the runtime. Therefore
article we want to analyze certain measures regarding sig- classical packet filters (OSI layer 3,4) are not suitable. There
nal and service-oriented communication without integrating is only the possibility to filter certain properties based on
them into a specific one. higher protocols like SOME/IP or DDS. However, it should
For a more precise analysis of the different security mea- be considered whether application-related filtering can be
sures we make the following assumptions: performed comprehensively within firewalls at all or whether
• An OEM backend server has always the same and static this should not be solved by using IAM features.
network address from the vehicle point of view.
• The signal/service mapping is statically defined. 2) CONNECTIVITY ECU
• The OBD interface is used by various external devices. Considering the interface on-board/off-board communication
within the connectivity gateway, different possibilities for
firewall filtering can be identified depending on external
B. FIREWALLS network nodes. In the first use case we analyze a connection
Traditional IT firewall techniques have existed for over between a vehicle and an OEM backend. In principle, filtering
25 years and were introduced as a countermeasure for secu- on ISO/OSI layers 3 and 4 could be performed. In detail it
rity design flaws in protocols and software. Firewalls can would be conceivable to block all IP addresses except the
be classified as measures which do not solve the existing static IP of the backend. In addition, a restriction of allowed
shortcomings of today’s communication protocols. Rather, ports could be integrated in a more fine-granular manner.
they attempt to limit the impact of these shortcomings through
additional inspections. However, there is a risk that an 3) OBD-GATEWAY
attacker could bypass these additional controls and exploit At this point, various external network participants are able
persistent protocol weaknesses [67]. Moreover, firewalls are to establish a connection to the vehicle’s internal network.
not able to perform semantic checks on the data. Only Examples are diagnostic devices from different manufactur-
application-level firewalls are capable of detecting signatures ers as well as On-Board Diagnostics (OBD) dongles allow-
based on already known attack techniques. However, they ing a connection to a smartphone or third-party backend.
are not able to check safety-critical messages in real time as If the DoIP protocol is used for diagnostics, a dynamic IP
well as to take into account the current vehicle condition with address is assigned to each external device. This means that
respect to the context [86]. If an end-to-end encryption (e.g., filtering on certain IP-addresses is not generally feasible.
on layer 7) is used, it should also be noted that a firewall is If a device is connected, a white-list can be activated which
not able to inspect the data on this layer. blocks all other IP addresses during this session. Furthermore,
Transferred to future automotive networks, design flaws a restriction of available ports could be implemented on OSI
of classic IT should not be adopted by using secure proto- layer 4. It should be noted that different applications could
cols. Therefore it is necessary that network protocols are able use the same port. In case the CAN protocol and correspond-
to ensure information security assets such as confidentiality, ing transport protocol ISO TP is used for diagnostics, other
integrity/authenticity and availability on different ISO/OSI aspects have to be considered. This impedes the integration of
layers. It should also be considered whether firewalls in com- rate-limiting features due to the separation time or amount of
bination with secure protocols is the best solution (due to the consecutive frames without flow control. Moreover, it has to
limitations mentioned above and the purposes for which they be ensured that different diagnostic services can be requested
were used in the past) or whether other measures available in parallel e.g., with the same CAN ID (End-of-Line
today are more appropriate. scenario).
For a more detailed analysis of firewall protection capabil-
ities, we have examined the three deployment points below: C. INTRUSION DETECTION SYSTEMS
To date, IDS in the automotive sector has mainly focused on
1) CLASSIC/ADAPTIVE PLATFORM GATEWAY detecting anomalies on the signal-based CAN bus, while SOA
At this point the transformation of service and signal-oriented and Ethernet are not considered. The discussion on IDS for
communication is performed. Coming from the service direc- automotive SOA has to include four major differences and
tion, each service is statically assigned to specific messages challenges in contrast to CAN. One point is, it is of impor-
and their payloads. This allows the filtering of statically tance what network data and features shall be analyzed, since
known assignments and ranges of signal values. In reverse the nature of the data differs to the signal-oriented paradigm.
direction, the gateway acts as a service provider in order to Furthermore, the deployment and placement strategy needs

VOLUME 8, 2020 221865

 M. Rumez et al.: Overview of Automotive SOAs and Implications for Security Countermeasures

TABLE 9. Applicability of in-vehicle anomaly detection sensors [56] - adopted and discussed w.r.t. SOA requirements.

to be discussed, because the architecture itself changes due the whole architecture is one hierarchical Ethernet topology.
to SOA. This also leads to the third point, the necessity of Thus, for SOA this criterion should e.g., consider the number
host-based detection in addition to network-based detection. of flows, number of data topics or VLANs under analysis.
Lastly, besides anomaly based IDS also signature-based IDS Then, the Location is a valid sensor to identify e.g., VLAN
can be of interest. hopping. Nevertheless, location may not be feasible because
with any newly introduced service in the vehicle, with an
1) FEATURES FOR (SOA NETWORK) INTRUSION DETECTION updated service requesting further data, or even on every
Lots of CAN intrusion detection systems focus on pay- startup, new communication paths are established. Hence,
load analysis, which is possible since the data rates on also the benign locations (i.e. benign communication paths)
CAN are low, and the structure of the payload is specified are highly dynamic. This is basically the same for the Cor-
during vehicle development. Besides analyzing the signals, relation sensor. Summing up the comparison, lots of sensors
Al-Jarrah et al. [17] also mention the flow-based analy- can not be simply transferred to SOA or make no sense any
sis. In traditional IT, this is the most common method to more. Instrumenting each service with monitoring capabil-
network-based IDS [89], where the features the IDS observes ities would be the same as payload based analysis, which
are captured at OSI layers 2 or 3. For the automotive SOA on is not feasible. Hence, intelligent features on middleware
Ethernet with multiple layers, headers, encryption and larger layer are necessary to develop suitable network based IDS for
payloads in comparison to CAN, payload based inspection is automotive SOA. Nevertheless, the features must be generic
not feasible. Hence, it makes sense to use flow-based IDS to all SOA middlewares so that they can be implemented
for Ethernet and SOA in automotive architectures. Indeed, throughout the industry. Besides the features of flow-based
the features an automotive SOA flow should contain are IDS in IT, we suggest to include features capturing Quality
unclear today. In comparison, Müter et al. [56] formulated of Service (QoS) parameters (derived from SOA middleware
the information that should be observed for automotive IDS, or from Ethernet protocols), as QoS parameters are means
especially for anomaly based detection on the CAN bus. They to specify the priority of data and separate data of different
outlined eight so-called sensors and compared them w.r.t. criticality. Another interesting option would be to include
their applicability. We analysed which sensor are also appli- statistical measures on the payload that do not require deep
cable to the SOA and what challenges arise in using them. packet inspection (e.g., information entropy [90]) because
The results are shown in table 9. As outlined above, payload these could also be computed on encrypted traffic and induce
analysis is difficult, thus the sensorsRange, Plausibility and low computational overhead.
Consistency are not feasible in general on the network level.
For information on sensor/actor level, where the range is 2) SIGNATURE-BASED AND HOST-BASED DETECTION
limited by physical constraints and data rates are medium, On the one hand, with standardized operating systems and
the sensor are still feasible. The publish-subscribe and common well-known IT protocols, future attacks on vehi-
request-response communication schemes are not any more cles may target more than one vehicle type or manufacturer.
driven by specification of the sender, but driven by data or the On the other hand, shared knowledge on threats and vul-
requester. Thus, for SOA the Range, Frequency and Protocol nerabilities such as Auto-ISAC [53] enables the industry to
are not specified beforehand (marked in orange color), mak- develop attack signatures. Hence, in the future it is more
ing the analysis more difficult (e.g., requiring machine learn- feasible for Ethernet and automotive SOA than for CAN and
ing techniques). Formality of the data is still specified to some the signal-oriented paradigm to use signature-based detec-
extent, but less than for signal-orientation (more protocols tion. This would complement the anomaly-based detection,
with more degrees of freedom, e.g., message size). Hence, enabling the car detecting known as well as unknown attacks
detection capabilities are also lower. In addition, the crite- with higher accuracy. In addition, with standardized POSIX
rion Number of Bus Systems makes no sense to SOA, since operating systems, dynamic scheduling of processes and the

221866 VOLUME 8, 2020

M. Rumez et al.: Overview of Automotive SOAs and Implications for Security Countermeasures

introduction of third-party services into vehicles, host-based minimize the risk for a successful attack by limiting man-
intrusion detection must come into the focus of research in-the middle attacks. However, there is still the threat of
and industry. Here, more dynamics are introduced also on insider attacks [92], which cannot be prevented by these
the software and application layer with the introduction of measures. In this case, the attacker acts from a compromised
SOA, not only on the network. Having in mind, that pay- ECU or generally from a network node which is considered
load analysis or monitoring of each service on the network trustworthy by the receivers involved. As a result, no violation
is not feasible, the observation of host behavior becomes of the security objects (e.g., authenticity or integrity) occurs.
even more important. The AUTOSAR foundation also paid As a result it becomes even more important to implement
attention to host-based IDS, as the coming IDS standard the principle of least privileges [93] consistently. Through
already defines some host-based monitoring capabilities for the specification of the IAM module of AUTOSAR this
AUTOSAR-based ECUs [91]. principle is increasingly applied for automotive systems by
capability-based access control methods for services. How-
3) DEPLOYMENT ever, it should be noted here that a pure specification of
Addressing the last point of the discussion, from an architec- privileges for each service still contains security risks. Due
tural point of view, CAN IDS can be deployed anywhere on to the fact that vehicles represent CPSs and therefore operate
the bus, since all data is broadcasted. On Ethernet and SOA, in different physical states, this aspect is crucial for access
the deployment must consider the availability of the data and controls [86]. However, the challenge is to determine the
stronger computing resources for higher data rates. Hence, current state correctly in order to derive appropriate access
in our exemplary architecture in figure 2 for network-based decisions based on it. Therefore, the current context has to be
detection all data has to be made available to the IDS. To give taken into account for the authorization of control commands
an example, the data exchanged between the Camera and the for actuators. The future architectures as shown in figure 2
ESP ECU can not be observed in the central computing clus- could give an advantage compared with highly distributed
ter, as (in comparison to CAN) the switches establish unicast architectures. Since the central computing cluster contains
communication between the ECUs. The relevant ECUs for all sensor/actuator information and executes extensive func-
capturing the network data are the ECUs that contain the tional calculations, context analyses could be performed cen-
switches. Either the switches (in hardware) or the respective trally in this cluster.
ECU (in software) have to calculate flow information on Eth- Another important aspect which should be considered in
ernet and the communication of services in our SOA. In addi- access control models is the revocation of privileges. If the
tion, the connectivity ECU is required to capture the network model is based on capabilities, the revocation is much more
behavior with regard to the external communication. After- difficult compared to ACLs. Transferred to automotive SOAs,
wards the calculated flow information can be collected and all service privileges are stored in the manifest file according
analysed on one of the Adaptive platforms high-performance to the AUTOSAR specification during development or when
controllers. adding new services in the life cycle. If the service is rolled
Thus, a decentralized monitoring of the SOA commu- out on different ECUs, each manifest file has to be modified
nication behavior all over the vehicles network with a in case of a revocation. To avoid incorrect configuration of
decentralized or centralized IDS e.g., on the Central Com- permissions, it is necessary to verify and validate them suffi-
puting Cluster enables us to observe the whole SOA with ciently. The authors Hu et al. published different verification
sophisticated analysis techniques such as machine learning. and test methods for access control policies and models [94].
Monitoring and IDS systems for CAN and signal-oriented With capability-based approaches, which are statically based
communication should still be deployed additionally on on pre-defined permissions, verification is easier than with
the Classic/Adaptive Platform Gateways, because signal- models such as ABAC, which additionally include various
to-service mapping is performed here and the high-frequency attribute information for decision making.
real-time control commands can be observed. However,
the integration of CAN IDS and SOA IDS into a VI. CONCLUSION
vehicle-monitoring approach is still in its infancy. Never- To sum up the major differences in security between the old
theless, the currently ongoing standardization of Intrusion paradigm of signal-orientation and the recent developments
Detection Systems for vehicles [91] provides the technologi- of service-oriented architectures, we see two contrasting
cal foundation to implement these monitoring capabilities. points. On the one hand, SOA is based on switched Ethernet
with its secured protocol stack, which minimizes the attack
D. IDENTITY- AND ACCESS MANAGEMENT surface. Furthermore, physical architectures are developed
An analysis based on the database from Sommer et al. [49] with security-by-design in mind and not only focusing on
indicates that no or only a limited and weak IAM (diagnos- security by obscurity. On the other hand, the rising dynamics
tics) has been implemented on ECUs in the past. As a result, with regard to data, network connections and software appli-
attackers were able to execute or modify various functions on cations places even stronger demands on vehicular security
an ECU. The integration of measures for secure connections mechanisms. From a security point of view, the more is spec-
(authentication/integrity) in CAN or Ethernet networks can ified during design time, the less attack surface we have and

VOLUME 8, 2020 221867

 M. Rumez et al.: Overview of Automotive SOAs and Implications for Security Countermeasures

the more we can check and verify during runtime with sim- to AUTOSAR or the standard may have to be extended as
ple measures derived from specification. However, without well. In case the eSOC protocol is used in future vehicles,
dynamic deployment of applications, dynamic network paths the protocol should be evaluated more closely with focus on
or POSIX operating systems, future automotive architectures security.
will not have the capabilities to follow customer needs of
frequent updates and new features. Hence, dynamic behavior ACKNOWLEDGMENT
will rise and thus we expect that all active measures (firewalls, The authors would like to thank the reviewers (Houssem
intrusion detection, access control) will be required in future Guissouma, Jaqueline Henle, Marc Schindewolf, and
service-oriented and hybrid architectures. Andreas Vetter) for their inspiring comments. (Marcel Rumez
But, as the capabilities of firewalls, IDS and access control and Daniel Grimm contributed equally to this work.)
mechanisms are developing towards each other, a structured
approach is required for a suitable placement of the mea- REFERENCES
sures that coordinates what data is analyzed where. Such a [1] O. Burkacky, J. Deichmann, G. Doll, and C. Knochenhauer, ‘‘Rethinking
system-wide strategy should also be accompanied by threat car software and electronics architecture,’’ McKinsey Company,
modeling results (e.g., [95]). In addition, there are several New York, NY, USA, Tech. Rep., 2018. Accessed: May 10, 2020.
[Online]. Available: https://www.mckinsey.com/industries/automotive-
countermeasures to ensure certain security properties. How- and-assembly/our-insights/rethinking-car-software-and-electronics-
ever, it must be analyzed which measures in combination architecture
fulfill automotive boundary conditions (e.g., real-time behav- [2] O. Burkacky, J. Deichmann, and J. P. Stein, ‘‘Mapping the automotive
software-and-electronics landscape through 2030,’’ McKinsey Company,
ior, bandwidth) most efficiently. Moreover, to capture the New York, NY, USA, Tech. Rep., 2019. Accessed: Apr. 4, 2020. [Online].
increasing dynamics, sophisticated defense mechanisms are Available: https://mck.co/3mSkfiW
required. Static rules, thresholds or access lists are no longer [3] J. Deichmann, B. Klein, G. Scherf, and R. Stützle, ‘‘The race for cyber-
security: Protecting the connected car in the era of new regulation,’’
sufficient to defend future vehicles without false alarms or McKinsey Company, New York, NY, USA, Tech. Rep., 2019. Accessed:
missed attacks. Contextual information, such as the vehicle May 10, 2020. [Online]. Available: https://mck.co/2xcXm4G
state, environmental behavior, or information regarding exter- [4] V. Antinyan. Revealing the Complexity of Automotive Software.
Accessed: 2018. [Online]. Available: https://www.researchgate.net/
nal interfaces needs to be included in cyber security decisions publication/327285609_Revealing_the_Complexity_of_Automotive
and analytics. _Software
[5] M. Traub, A. Maier, and K. L. Barbehon, ‘‘Future automotive architecture
VII. FUTURE WORK and the impact of IT trends,’’ IEEE Softw., vol. 34, no. 3, pp. 27–32,
May 2017.
In this work, we compared the conventional signal-oriented [6] A. Vetter, P. Obergfell, H. Guissouma, D. Grimm, M. Rumez, and E. Sax,
architecture of in-vehicle networks with its emerging succes- ‘‘Development processes in automotive service-oriented architectures,’’ in
sor, the service-oriented or hybrid architecture. We outlined Proc. 9th Medit. Conf. Embedded Comput. (MECO), Jun. 2020, pp. 1–7.
[7] M. Tischer. The Computing Center in the Vehicle: AUTOSAR
the challenges with regard to the security of these future Adaptive. Accessed: 2018. [Online]. Available: https://assets.vector.
automotive network architectures. Focusing on firewalls, IDS com/cms/content/know-how/_technical-articles/AUTOSAR/AUTOSAR
and access control, we emphasized the need of progressive _Adaptive_ElektronikAutomotive_201809_PressArticle_EN.pdf
[8] M. Schweiker and T. Huck, ‘‘CHASSIS ARCHITECTURES–partitioning
defense methods, that need to be combined to ensure vehicu- of cross-domain functions,’’ in Proc. 7th Int. Munich Chassis Symp.,
lar security with rising dynamics. Suggestions for the security P. P. E. Pfeffer, Ed. Wiesbaden, Germany: Springer, 2017, pp. 367–379.
of an exemplary architecture are given to sketch the chal- [9] Road Vehicles—Controller Area Network (CAN)—Part 1: Data Link Layer
and Physical Signalling, Standard ISO 11898-1:2015, 2003.
lenges that security architects have to face.
[10] Information Technology—Open Systems Interconnection—Basic Refer-
For future research, we see context-aware security methods ence Model: The Basic Model, Standard ISO/IEC 7498-1:1994, 1994.
as a promising direction to cope with the infinite amount of [11] AUTOSAR. Adaptive Platform. Accessed: Jun. 17, 2020. [Online]. Avail-
possible situations, a vehicle may be in. However, to date able: https://www.autosar.org/standards/adaptive-platform/
[12] D. Grimm, F. Pistorius, and E. Sax, ‘‘Network security monitoring in
it is an unsolved question, what information is necessary automotive domain,’’ in Advances in Information and Communication
to describe the security context of a vehicle and how this (Advances in Intelligent Systems and Computing), vol. 1129, K. Arai,
information is combined optimally with the different security S. Kapoor, and R. Bhatia, Eds. Cham, Switzerland: Springer, 2020,
pp. 782–799.
mechanisms. Additionally, the E/E architecture of the future [13] O. Burkacky, J. Deichmann, B. Klein, K. Pototzky, and G. Scherf, ‘‘Cyber-
will not end at the vehicles external borders, but spans to the security in automotive: Mastering the challenge,’’ McKinsey Company,
backend systems that can also provide services to the vehi- New York, NY, USA, Tech. Rep., 2020. Accessed: May 10, 2020. [Online].
Available: https://www.mckinsey.com
cle. Thus, offloading a vehicles security computations may [14] C. Miller and C. Valasek, ‘‘Remote exploitation of an unaltered passenger
be a feasible option (e.g., [96], [97]). Furthermore, from a vehicle,’’ Black Hat USA, vol. 2015, p. 91, Aug. 2015.
technological perspective more efficient access controls with [15] J. Durrwang, J. Braun, M. Rumez, and R. Kriesten, ‘‘Security evaluation
of an airbag-ECU by reusing threat modeling artefacts,’’ in Proc. Int. Conf.
revocation capabilities, intelligent IDS features for encrypted Comput. Sci. Comput. Intell. (CSCI), Dec. 2017, pp. 37–43.
traffic or high-throughput firewalls for sensory data are an [16] L. Pan, X. Zheng, H. X. Chen, T. Luan, H. Bootwala, and L. Batten, ‘‘Cyber
open topic for research. Today, AUTOSAR Classic and Adap- security attacks to modern vehicular systems,’’ J. Inf. Secur. Appl., vol. 36,
tive already include some security features, but for the future pp. 90–100, Oct. 2017.
[17] O. Y. Al-Jarrah, C. Maple, M. Dianati, D. Oxtoby, and A. Mouzakitis,
this will not be enough. Hence, also sophisticated security ‘‘Intrusion detection systems for intra-vehicle networks: A review,’’ IEEE
mechanisms to be developed shall ensure their compliance Access, vol. 7, pp. 21266–21289, 2019.

221868 VOLUME 8, 2020

M. Rumez et al.: Overview of Automotive SOAs and Implications for Security Countermeasures

[18] S. Seifert and R. Obermaisser, ‘‘Secure automotive gateway—Secure com- [42] M. Iorio, A. Buttiglieri, M. Reineri, F. Risso, R. Sisto, and F. Valenza,
munication for future cars,’’ in Proc. 12th IEEE Int. Conf. Ind. Informat. ‘‘Protecting in-vehicle services: Security-enabled SOME/IP middleware,’’
(INDIN), Jul. 2014, pp. 213–220. IEEE Veh. Technol. Mag., vol. 15, no. 3, pp. 77–85, Sep. 2020.
[19] ‘‘Cybersecurity guidebook for cyber-physical vehicle systems,’’ SAE Int. [43] Object Management Group. DDS Security. Accessed: 2018. [Online].
J3061, 2016. Available: https://www.omg.org/spec/DDS-SECURITY/1.1
[20] ‘‘Road vehicles—Cybersecurity engineering,’’ SAE Int. 21434, 2020. [44] M. Wille and O. Krieger. Ethernet & Adaptive AUTOSAR: Key
[21] ‘‘Specification of secure onboard communication (SecOC),’’ AUTOSAR Elements of the New Volkswagen E/E Architecture. Accessed:
Classic R19-11:2019, 2019. 2017. [Online]. Available: https://assets.vector.com/cms/content/
[22] AUTOSAR. Standards. Accessed: Jun. 17, 2020. [Online]. Available: events/2017/vAES17/vAES17_01_Ethernet-Adaptive-AUTOSAR-at-
https://www.autosar.org/standards/ VW_Krieger_Wille.pdf
[45] J. Kreissl, ‘‘Absicherung der SOME/IP Kommunikation bei Adap-
[23] Audi Service Training I/VK-35, ‘‘Audi A8 (type 4N) Electrics and elec-
tive AUTOSAR,’’ M.S. thesis, Inst. Inf. Secur. (SEC), Universität
tronics: Self study programme 664,’’ Audi AG, Ingolstadt, Germany,
Stuttgart, Stuttgart, Germany, 2017. [Online]. Available: https://elib.uni-
Tech. Rep., Aug. 2017.
stuttgart.de/bitstream/11682/9482/1/ausarbeitung.pdf
[24] S. Apostu, O. Burkacky, J. Deichmann, and G. Doll. Automotive Software
[46] M. Atad and A. Geynis. The Devil is in the Fragments. Accessed:
and Electrical/Electronic Architecture: Implications for OEMs. Accessed:
2019. [Online]. Available: https://www.escar.info/images/2019
2019. [Online]. Available: https://mck.co/2Pswpzr
_ESCAR_US_Atad_Lecture.pdf
[25] V. M. Navale, K. Williams, A. Lagospiris, M. Schaffert, and [47] J. Lindberg, ‘‘Security analysis of vehicle diagnostics using DoIP,’’
M.-A. Schweiker, ‘‘(R)evolution of E/E architectures,’’ SAE Int. J. M.S. thesis, Dept. Comput. Sci. Eng., Chalmers Univ. Technol.,
Passenger Cars Electron. Elect. Syst., vol. 8, no. 2, pp. 282–288, 2015. Gothenburg, Sweden, 2011. [Online]. Available: http://publications.
[26] R. Johansson, R. Andersson, and M. Dernevik, ‘‘Enabling tomorrow’s road lib.chalmers.se/records/fulltext/143639.pdf
vehicles by service-oriented platform patterns,’’ in Proc. 9th Eur. Congr. [48] A. Talic, ‘‘Security analysis of Ethernet in cars,’’ M.S. thesis, Dept.
Embedded Real Time Softw. Syst., 2018, pp. 1–9. [Online]. Available: Commun. Syst., KTH Roy. Inst. Technol., Stockholm, Sweden, 2017.
https://hal.archives-ouvertes.fr/hal-02156243/ [Online]. Available: https://people.kth.se/~maguire/DEGREE-PROJECT-
[27] M. Maul, G. Becker, and U. Bernhard, ‘‘Service-oriented EE zone archi- REPORTS/171006-Ammar_Talic_with_cover.pdf
tecture key elements for new market segments,’’ ATZelektronik Worldwide, [49] F. Sommer, J. Dürrwang, and R. Kriesten, ‘‘Survey and classification of
vol. 13, no. 1, pp. 36–41, Feb. 2018. automotive security attacks,’’ Information, vol. 10, no. 4, p. 148, Apr. 2019.
[28] R. B. GmbH, ‘‘CAN with Flexible Data-Rate: CAN-FD, version: 1.0,’’ [50] F. Sommer and J. Dürrwang. IEEM-HsKA/AAD : Automotive Attack
Robert Bosch GmbH, Gerlingen, Germany, Tech. Rep., Apr. 2012. Database (AAD). Accessed: Apr. 1, 2019. [Online]. Available:
Accessed: Jun. 17, 2020. [Online]. Available: https://can-newsletter. https://github.com/IEEM-HsKA/AAD
org/assets/files/ttmedia/raw/e5740b7b5781b8960f55efcc2b93edf8.pdf [51] R. Bolz, M. Rumez, F. Sommer, J. Dürrwang, and R. Kriesten, ‘‘Enhance-
[29] IEEE Standard for Ethernet Amendment 1: Physical Layer Specifications ment of cyber security for cyber physical systems in the automotive
and Management Parameters for 100 Mb/s Operation Over a Single Bal- field through attack analysis,’’ in Proc. Embedded World Conf., 2020,
anced Twisted Pair Cable: 100BASE-T1, Standard IEEE 802.3bw:2015, pp. 453–459.
2015. [52] Upstream Security Inc. AutoThreat Intelligence Cyber Incident Repos-
[30] ISO/IEC/IEEE 8802-3:2017/AMD 4-2017 Information Technology— itory. Accessed: Nov. 13, 2020. [Online]. Available: https://upstream.
Telecommunications and Information Exchange Between Systems—Local auto/research/automotive-cybersecurity/
and Metropolitan Area Networks—Specific Requirements—Part 3: Stan- [53] Auto-ISAC. Automotive Information Sharing and Analysis Center.
dard for Ethernet Amendment 4: Physical Layer Specifications and Man- Accessed: Jun. 25, 2020. [Online]. Available: https://automotiveisac.com/
agement Parameters for 1 Gb/S Operation Over a Single Twisted-Pair [54] UNECE. Draft New Un Regulation on Uniform Provisions Concerning
Copper Cable: 1000BASE-T1, Standard IEEE 802.3bp:2016, 2016. the Approval of Vehicles With Regard to Cyber Security and of Their
[31] IEEE Standard for Ethernet—Amendment 8: Physical Layer Specifications Cybersecurity Management Systems. Accessed: 2020. [Online]. Available:
and Management Parameters for 2.5 Gb/s, 5 Gb/s, and 10 Gb/s Automo- https://www.unece.org/fileadmin/DAM/trans/doc/2020/wp29grva/GRVA-
tive Electrical Ethernet: 2.5GBASE-T1, 5GBASE-T1 and 10GBASE-T1, 05-05r1e.docx
Standard IEEE 802.3ch:2020, 2020. [55] UNECE. Uniform Provisions Concerning the International Whole
[32] IEEE Standard for Ethernet—Amendment 5: Physical Layer Specifica- Vehicle Type Approval (IWVTA). Accessed: 2018. [Online]. Available:
tions and Management Parameters for 10 Mb/s Operation and Associated https://www.unece.org/fileadmin/DAM/trans/main/wp29/wp29regs/2018/
Power Delivery Over a Single Balanced Pair of Conductors: 10BASE-T1S, R000e.pdf
Standard IEEE 802.3cg:2019, 2019. [56] M. Muter, A. Groll, and F. C. Freiling, ‘‘A structured approach to anomaly
[33] H. Zweck. 10 Mbps Ethernet Technology and the Challenges Facing Auto- detection for in-vehicle networks,’’ in Proc. 6th Int. Conf. Inf. Assurance
motive Microcontrollers. Stuttgart. Accessed: 2019. [Online]. Available: Secur., Aug. 2010, pp. 92–98.
https://assets.vector.com/cms/content/events/2019/vAES19/vAES19_01 [57] F. Kargl, P. Papadimitratos, L. Buttyan, M. Müter, E. Schoch,
_Zweck_Infineon.pdf B. Wiedersheim, T.-V. Thong, G. Calandriello, A. Held, A. Kung, and
[34] IEEE Standard for Local and Metropolitan Area Networks–Timing J.-P. Hubaux, ‘‘Secure vehicular communication systems: Implementation,
and Synchronization for Time-Sensitive Applications, Standard IEEE performance, and research challenges,’’ IEEE Commun. Mag., vol. 46,
802.1AS:2020, 2020. no. 11, pp. 110–118, Nov. 2008.
[58] M. D. Pesé, K. Schmidt, and H. Zweck, ‘‘Hardware/software co-design of
[35] V. Informatik. Introduction to AUTOSAR: Vector E-Learning.
an automotive embedded firewall,’’ SAE Tech. Paper 2017-01-1659, 2017.
Accessed: 2018. [Online]. Available: https://elearning.
[59] J. Holle and S. Shukla, ‘‘Gatekeeper for in-vehicle network communica-
vector.com/mod/page/view.php?id=437
tion,’’ ATZelektronik Worldwide, vol. 13, no. 6, pp. 40–43, Dec. 2018.
[36] R. Coppola and M. Morisio, ‘‘Connected car,’’ ACM Comput. Surveys,
[60] F. Luo and S. Hou, ‘‘Security mechanisms design of automotive gateway
vol. 49, no. 3, pp. 1–36, 2016.
firewall,’’ SAE Tech. Paper 2019-01-0481, 2019.
[37] Object Management Group. Data Distribution Service (DDS). [61] S. Harris and F. Maymi, CISSP All-in-One Exam Guide. New York, NY,
Accessed: 2015. [Online]. Available: http://www.omg.org/spec/DDS/1.4 USA: McGraw-Hill, 2016.
[38] M. Wagner, S. Schildt, and M. Poehnl, ‘‘Service-oriented communication [62] C. Miller and C. Valasek, ‘‘A survey of remote automotive attack surfaces,’’
for controller area networks,’’ in Proc. IEEE 84th Veh. Technol. Conf. Black Hat USA, vol. 2014, p. 94, Aug. 2014.
(VTC-Fall), Sep. 2016, pp. 1–5. [63] M. Ziehensack and R. Pallierer. Secure Automotive Ethernet for
[39] Rapid7. Metasploit: Penetration Testing Software, Pen Testing Security. Automated Driving. Accessed: 2016. [Online]. Available: https://
Accessed: Jun. 17, 2020. [Online]. Available: https://www.metasploit.com/ www.elektrobit.com/tech-corner/secure-automotive-ethernet-automated-
[40] Offensive Security. Kali Linux. Accessed: Jun. 17, 2020. [Online]. Avail- driving/
able: https://www.kali.org/ [64] K. Scarfone and P. Hoffman, ‘‘Guidelines on firewalls and firewall policy,’’
[41] F. Luo and S. Hou, ‘‘Cyberattacks and countermeasures for intelligent and NIST, Gaithersburg, MD, USA, NIST Special Publication 800, 2009, p. 41.
connected vehicles,’’ SAE Int. J. Passenger Cars Electron. Electr. Syst., [65] R. Shirey. Internet Security Glossary, Version 2. Accessed: 2007. [Online].
vol. 12, no. 1, pp. 55–66, Oct. 2019. Available: https://tools.ietf.org/html/rfc4949

VOLUME 8, 2020 221869

 M. Rumez et al.: Overview of Automotive SOAs and Implications for Security Countermeasures

[66] M. E. Whitman and H. J. Mattord, Principles of Information Security. [90] M. Muter and N. Asaj, ‘‘Entropy-based anomaly detection for in-vehicle
Boston, MA, USA: Cengage, 2011. networks,’’ in Proc. 4th IEEE Intell. Vehicles Symp., Baden-Baden,
[67] C. Eckert, IT-Sicherheit: Konzepte-Verfahren-Protokolle. Berlin, Germany, Jun. 2011, pp. 1110–1115.
Germany: De Gruyter, 2018. [91] E. Metzker. (2020). Reliably Detecting and Defending Against Attacks:
[68] D. Stabili, M. Marchetti, and M. Colajanni, ‘‘Detecting attacks to internal Requirements for Automotive Intrusion Detection Systems. [Online].
vehicle networks through Hamming distance,’’ in Proc. AEIT Int. Annu. Available: https://assets.vector.com/cms/content/know-how/_technical-
Conf., Sep. 2017, pp. 1–6. articles/Security_Intrusion_Detection_AutomobilElektronik_202003_
[69] A. Taylor, S. Leblanc, and N. Japkowicz, ‘‘Anomaly detection in automo- PressArticle_EN.pdf
[92] C. W. Probst, Insider Threats Cyber Security (Advances in Information
bile control network data with long short-term memory networks,’’ in Proc.
Security), vol. 49. Boston, MA, USA: Springer, 2010.
IEEE Int. Conf. Data Sci. Adv. Analytics (DSAA), Oct. 2016, pp. 130–139.
[93] J. H. Saltzer, ‘‘Protection and the control of information sharing in mul-
[70] A. Wasicek, M. D. Pesé, A. Weimerskirch, Y. Burakova, and K. Singh, tics,’’ Commun. ACM, vol. 17, no. 7, pp. 388–402, Jul. 1974.
‘‘Context-aware intrusion detection in automotive control systems,’’ in [94] V. C. Hu, R. Kuhn, and D. Yaga, ‘‘Verification and test methods for access
Proc. 5th ESCAR USA Conf, 2017, pp. 21–22. control policies/models,’’ NIST Special, vol. 800, p. 192, May 2017.
[71] O. Avatefipour, ‘‘Physical-fingerprinting of electronic control unit [95] T. Rosenstatter and T. Olovsson, ‘‘Towards a standardized mapping from
(ECU) based on machine learning algorithm for in-vehicle network automotive security levels to security mechanisms,’’ in Proc. 21st Int.
communication protocol,’’ M.S. thesis, Dept. Elect. Comput. Eng., Univ. Conf. Intell. Transp. Syst. (ITSC), Piscataway, NJ, USA, Nov. 2018,
Michigan-Dearborn, Dearborn, MI, USA, 2017. [Online]. Available: pp. 1501–1507.
https://deepblue.lib.umich.edu/bitstream/handle/2027.42/140731/Thesis% [96] G. Loukas, Y. Yoon, G. Sakellari, T. Vuong, and R. Heartfield, ‘‘Computa-
20manuscript_v3.pdf?sequence=1 tion offloading of a vehicle’s continuous intrusion detection workload for
[72] M. Kneib and C. Huth, ‘‘Scission: Signal characteristic-based sender iden- energy efficiency and performance,’’ Simul. Model. Pract. Theory, vol. 73,
tification and intrusion detection in automotive networks,’’ in Proc. ACM pp. 83–94, Apr. 2017.
SIGSAC Conf. Comput. Commun. Secur., Oct. 2018, pp. 787–800. [97] G. Loukas, T. Vuong, R. Heartfield, G. Sakellari, Y. Yoon, and D. Gan,
[73] M. Rumez, J. Durrwang, T. Brecht, T. Steinshorn, P. Neugebauer, ‘‘Cloud-based cyber-physical intrusion detection for vehicles using deep
R. Kriesten, and E. Sax, ‘‘CAN radar: Sensing physical devices in CAN learning,’’ IEEE Access, vol. 6, pp. 3491–3508, 2018.
networks based on time domain reflectometry,’’ in Proc. IEEE Veh. Netw.
Conf. (VNC), Dec. 2019, pp. 1–8. MARCEL RUMEZ received the B.Eng. and M.Sc.
[74] V. C. Hu, ‘‘Guide to attribute based access control (ABAC) definition and degrees in automotive engineering from the Karl-
considerations,’’ NIST, Gaithersburg, MD, USA, NIST Special Publication sruhe University of Applied Sciences, Germany,
800, 2013, p. 162. in 2013 and 2015, respectively. He is currently
[75] D. Servos and S. L. Osborn, ‘‘Current research and open problems in pursuing the Ph.D. degree with the Institute for
attribute-based access control,’’ ACM Comput. Surveys, vol. 49, no. 4, Information Processing Technologies, Karlsruhe
pp. 1–45, Feb. 2017. Institute of Technology. Since 2015, he has been a
[76] OASIS. Extensible Access Control Markup Language (XACML) Research Assistant with the Group of Automotive
Version 3.0. Accessed: 2013. [Online]. Available: http://docs.oasis- Security, Institute of Energy Efficient Mobility,
open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html Karlsruhe University of Applied Sciences.
[77] V. C. Hu and K. Scarfone, ‘‘Guidelines for access control system eval-
uation metrics,’’ NIST Interagency, Gaithersburg, MD, USA, Tech. Rep. DANIEL GRIMM received the B.Sc. and M.Sc.
NISTIR 7874, 2012. degrees in electrical engineering and information
[78] AUTOSAR. Adaptive Platform 18.03. Accessed: 2018. [Online]. technology from the Karlsruhe Institute of Tech-
Available: https://www.autosar.org/standards/adaptive-platform/adaptive- nology (KIT), Germany, in 2015 and 2017, respec-
platform-1803/ tively, where he is currently pursuing the Ph.D.
[79] Road Vehicles—Unified Diagnostic Services (UDS)—Part 1: Specification degree with the Group of Systems Engineering,
and Requirements, Standard ISO 14229-1:2013, 2013. Institute for Information Processing Technologies
[80] C. Miller and C. Valasek, ‘‘Adventures in automotive networks and control (ITIV). Since 2018, he has been a Research Assis-
units,’’ Def Con, vol. 21, pp. 260–264, Aug. 2013. tant with the Group of Systems Engineering, ITIV,
[81] M. Ring, T. Rensen, and R. Kriesten, ‘‘Evaluation of vehicle diagnos- KIT.
tics security–implementation of a reproducible security access,’’ in Proc.
SECUREWARE, 2014, p. 213. REINER KRIESTEN received the Dr.-Ing. degree.
[82] D.-K. Kim, E. Song, and H. Yu, ‘‘Introducing attribute-based access control He is currently the Head and a Speaker with the
to AUTOSAR,’’ SAE Tech. Paper 2016-01-0069, 2016. Institute of Energy Efficient Mobility, University
[83] M. Hamad, ‘‘A multilayer secure framework for vehicular systems,’’ Ph.D. of Applied Sciences Karlsruhe. His main areas of
dissertation, Inst. Comput. Netw. Eng., TU Braunschweig, Braunschweig, research are software (SW) and systems engineer-
Germany, 2020. [Online]. Available: https://www.researchgate.net/ ing of cyber-physical and embedded systems and
publication/341597533_A_Multilayer_Secure_Framework_for_ research in automotive security. Since 2003, he has
Vehicular_Systems been with Robert Bosch GmbH, where his applied
[84] M. Gupta and R. Sandhu, ‘‘Authorization framework for secure cloud research is based on a strong connection to the
assisted connected cars and vehicular Internet of Things,’’ in Proc. 23rd automotive industry, such as due to SW/system
ACM Symp. Access Control Models Technol., Jun. 2018, pp. 193–204. engineering and project management activities for automotive gateways and
[85] J. Lopez and J. E. Rubio, ‘‘Access control for cyber-physical systems inter- body computers.
connected to the cloud,’’ Comput. Netw., vol. 134, pp. 46–54, Apr. 2018.
[86] V. Hugot, A. Jousse, C. Toinard, and B. Venelle, OMAC: Open Model for
ERIC SAX received the Dr.-Ing. degree. He is
Automotive Cybersecurity. Bochum, Germany: Ruhr-Universität Bochum, currently the Head with the Institute of Infor-
2019. mation Processing Technology, Karlsruhe Insti-
[87] B. Rudra and O. P. Vyas, ‘‘Investigation of security issues for service- tute of Technology. He was the Head of test
oriented network architecture,’’ Secur. Commun. Netw., vol. 9, no. 10, engineering with the MBtech Group. His main
pp. 1025–1039, Jul. 2016. areas of research are processes, methods, and
[88] J. Dürrwang, K. Beckers, and R. Kriesten, ‘‘A lightweight threat analysis tools in systems engineering and data-driven and
approach intertwining safety and security for the automotive domain,’’ in service-oriented architectures supported by the
Proc. Int. Conf. Comput. Saf., Rel., Secur., 2017, pp. 305–319. idea of machine learning. A tight link to industry
[89] N. Moustafa, J. Hu, and J. Slay, ‘‘A holistic review of network anomaly derives from the fact that he was responsible for
detection systems: A comprehensive survey,’’ J. Netw. Comput. Appl., E/E at Daimler Buses from 2009 to 2014.
vol. 128, pp. 33–55, Feb. 2019.

221870 VOLUME 8, 2020